Progress has been slow this week. I needed to put together some maps and dungeons for my tabletop RPG groups, and my toddler has been waking up earlier than usual, eating into my game dev time. That said, I’ve laid the foundations for building the game’s battle maps, including placing the tokens semi-randomly around a spawn point. These are both important parts of my game – I want to be able to build story quest maps as well as chunks of maps that can be stitched together for random quests, and I also want to define a spawn location around which enemies are placed semi-randomly.
What do battles need?
My game’s tactical combat uses the rules from Pathfinder 2E and draws inspiration from XCOM. Both of these games break up the combat arena into a square grid. Seeing the grid is a vital part of both games – it is used to determine where the various combatants are, how far they can move, what the range on certain abilities is, and a whole lot more. The grid is the foundation I need for all combat in this game and so I’ve focused on getting that in place first.
Building battlemaps
A while ago, I wrote about how I’d built a world map editor so that I can easily edit the world map without having to dive into thousands of lines of json. I’ve done a similar thing for battlemaps – created an editor scene in the Godot editor which, at the moment, just has a single tile available and the option to choose where to save the json it outputs.
As I need new features, such as walls, cover, areas of difficult terrain, etc., I’ll add it into the editor first. This approach means I’m not going to make something in the editor that seems cool but has no purpose in the game itself.
Battlemaps as a Godot component
I made myself a flowchart of how the map data should move from being loaded in to being rendered on the player’s screen.
As always in my current code structure, the logic about what data to use lives in the model. The model sends a signal that the data has changed, which is picked up by any viewmodels that have subscribed to the event – in this case, the viewmodel for the battlemap. The viewmodel can then structure or filter the data before telling the view to do something with it, e.g. rendering the map.
For the component itself, I’ve started out with a relatively simple set of nodes for my battlemap scene.
The BaseTileMap is the visual representation of the terrain, which, for the time being, is only available in a single orange-brown colour.
The BordersLayer renders a black border around each square. It’s technically its own scene as I use the same logic both here and in the level editor and don’t want to have to change it in multiple places if I make a new decision. It has a script on it that accepts a map size and draws the borders on each square.
Next we have the CombatantsLayer. This is where the tokens that represent each combatant are placed.
And finally there’s a camera. I expect some levels to be larger than others and want players to be able to zoom in and out and pan the camera around. I may force the camera to move to the active combatant during their turn and follow them around. The SubViewportContainer and SubViewport exist so that the camera only moves around the battlemap. I’m not convinced they belong here, but, for now, they’re fine.
Integrating the battlemap
With the battlemap component working, I added it to the combat scene.
Something felt off. Besides the orange-brown background, that is. That’s just a placeholder and I know that’s not great. The initiative tracker at the top feels a bit too big to me.
So I shrunk it down, which I like.
I also tried to make it transparent, which I don’t like.
I took the transparency out, but left the smaller initiative tracker in. I suspect the UI will change anyway as I continue development, but if my gut says something’s wrong then I should listen to it.
How about some combatants?
The main thing I need the map for is to display the positions of the combatants, so it’s time to add some. Eventually I want the player to be able to customise their adventurers’ portraits, which will be reflected on the tokens displayed on the battlemap, so I decided to learn how to dynamically switch images. I fired up Krita and, with my amazing art skills, created a player and enemy token.
Aren’t they fantastic?
Well, they get the job done – I can easily see which tokens on the battlemap belong to which side.
Now to put them on the map.
For now, I’ve implemented a very simple spawning algorithm.
- Choose which side the player’s adventurers spawn
- Choose a position about half-way down the map within three tiles of the map edge
- Spawn the player tokens within two tiles of that central coordinate.
- Choose a position about half-way down the map within three tiles of the opposite edge
- Spawn the enemy tokens within four tiles (because there are more of them) of that coordinate
This is definitely going to change, but it works for now.
The spawn locations are sent to the battlemap, which translates them from tile coordinates into pixel coordinates before rendering the appropriate token on the map.
Next steps
At this point I have:
- Player and AI combatants
- A turn order for the combatants
- A way to see the combatants on a map
Now I need to add something for the combatants to do on the map. I need to add movement and the ability to attack enemy tokens. So that’s where I’m going to focus next week’s efforts.