A* is Born

A little shorter entry this week, not because there was a shortage of progress, but more because a lot of it is, frankly, pretty boring to talk about. Great intro, no?

After last time, I had a pretty functional prototype of the battle system up and running. The next step was the totally simple process of building the rest of the game to go around it.

Easy!

Seeing the Forest Instead of the Trees

To understand what additional layers are needed, it’s worthwhile to step back and look at what exactly my vision of the final product is. It’s easy to build pieces in isolation, but it all needs to gel into a coherent whole at some point. For TMF (the working project title), my overarching vision is a narrative strategy game in the vein of a Fire Emblem, but with a more interactive, tactical battle system for individual encounters as opposed to just smashing individual units into each other. It's a little Fire Emblem, a little Ogre Battle, and hopefully a lot of something new.

That being the case, the next step was thinking about the higher-level scenarios where the individual battles would take place. In this case, I wanted to prototype out a map to handle the movement of the player and enemy armies, resulting in a battle when the two meet.

I want the map to be tile-based, so my first instinct was to use the Unity Tilemap system to draw the maps. My second instinct - based on previous experiences trying to use Unity Tilemaps this way - was to not do that. Unity’s Tilemaps were great when I was designing Station Zeta, when it was just a matter of collisions and layers. In some other experiments, trying to access the actual data at an individual tile level was really fiddly, and not particularly intuitive.

What I settled on was a bit of a “best of both worlds” situation. I decided to use the Tilemaps to draw out my blocking for the map - where units can and can’t move - but to create an abstracted layer on top of that I could manage more directly to handle the actual navigation and tile interaction. It’s not as complicated as it sounds, and for my purposes is working well.

With the grid in place, the next trick was getting everything to move around it. The words “pathfinding algorithm” have been ones that had scared me for a very long time. For someone who didn’t consider themselves a coder, the entire concept felt like it just too advanced to even dive into. In some earlier projects I honestly did whatever I could to build around having to implement one. But at some point, you just have to make the jump or you’ll never be able to build the games you actually want to.

I did a lot of research on the options avaiable and determined that for the project I was working on at the time, I wanted to use A*. I made things even more complicated for myself by starting my experiment with a hex map. Can't go wrong diving straight into the deep end, right?

In the end, it wasn’t nearly as scary an experience as I thought it was going to be. I’d advanced enough in my coding at that point that I understood what it was A* was doing, and how I could make it work with my game at the time. While that game ended up being put on hold, it did leave me with a nice little chunk of A* functionality all built out and ready to use on future projects.

Shifting A* to work with my grid system was simple enough. Within a few hours I had my little unit tokens running around the map just like they were supposed to. Now it was time to tie it all together.

…this was actually the much harder bit.

As I said back at the beginning, building things in isolation is easy. Now I had to make sure I could connect two separate layers of gameplay, pass along all the relevant information, and have everything in the original layer pick up where it left off. It takes time, it takes planning, and it takes an awful lot of debugging (if you’re me). After a few days, fortunately, it all came together as expected. Not only could I now have my units move around (with some rudimentary enemy AI), but they could get into battles and have the results of those battles impact the overall state of the scenario. In short: doing what a game is supposed to do.

It doesn't look like much at the moment, but it's the foundation on which the entire rest of the game will be built. The other upside of this work is that the structure is now in place to expand the game to the next layer as well - the larger world.

With that all set, I decided to shift my focus back to the battle system and work on some visual updates. Nothing near final yet, of course, but just figuring out overall placement, visual flow, and readability. One thing I care a ton about - especially in a game where information needs to be easily digested by the player in a rapid fashion - is readability.

I’ll talk about that more next time, as well as a deeper dive into the more strategic elements of the battle system and what kind of choices it will give the player!