Deadlines are important for developers. Yes, we all hate deadlines, and professionally I keep seeing ridiculously unrealistic ones from customers who don’t know the difference between software and a operating system. It leads to bad quality: my games in particular could have benefited greatly by an extra few months of waiting and thinking. But it also gives a goal and motivation, something that it difficult for indie developers to find.
In past years, I relied on public events to showcase my game and spread the word. I’d work day and night up until a deadline to make a short demo and video to submit with an application, and would continue working several hours each day up until the event to improve what I’d be showing, even making last-minute modifications in the hotel room the night before. So when a deadline was announced for March for an event I was eyeing, I realized I hadn’t even enough of a game to showcase: only walking around worked, and a huge portion (the turn-based strategy bits) was never implemented. So, I got to work…
Working Prototype of Tactical Strategy Gameplay Map
To remind of my intention of game flow: you control and play a character meant to overtake the kingdom as what might possibly be the rightful heir. Starting in one corner of the map and seeing the 3D open-world in front of you, you walk. Walking and talking to NPC’s is about all the world offers, as most limited RPG’s might give in the overworld. When you walk into each of the towns of the world, you can talk to the leader of each town, and after suggesting you can free the town from the existing king’s tyranny, you enter into a strategy map separate from the 3D world and begin gameplay similar to something from Fire Emblem, Advanced Wars or Final Fantasy Tactics. This means a big chess game on a big board, you move your players one turn at a time, the opponent moves theirs one at a time, you attack your opponent one at a time until you clear the other side. After freeing a town to join your side, you continue to the next town, growing your supporters until you are ready to face the king directly.
In the first few minutes of the game, you would “awake” into one corner of the 3D world, walk down a path directly into a small town, and almost immediately get talked into freeing the small town in a tutorial session with this strategy-map-gameplay. After winning and freeing this town, you would be able to walk on and to the rest of the world. This first town would take about 5-15 minutes, and as such this would be the logical place to end a demo level for the public to try. I had the walking to the town part done, NPC talking wouldn’t be hard to fake and implement quickly, but the strategy map hadn’t been started yet.
Fairly quickly, I decided I wanted to be able to spawn the map based on reading data from a file or some other source, such that I could design maps without relying on making a separate hand-crafted scene for each one (this would also allow better potential for user-custom maps in the future). I didn’t implement reading from a file yet, but quickly read from a hard-coded array that could be filled in with an api later without much hassle. As the screenshots show, I was able to define map size, and location of player and opponent units (different player types would be able to be defined later also simply with new api’s, to define attack, range, etc.), and I settled on the UI/color-scheme the user would see to show this.
Hovering mouse over a unit shows more information.
Further, I was able to define information like health and movement range. This can be seen by hovering a mouse over either a player or opponent unit, to help you make your strategy.
How far can a enemy move?
If you click on your side’s unit, it is highlighted to be in “selected” mode, allowing you to choose where to move it, or to click outside the range to undo this choice. This is all handled by a state-machine manager, but also with independent logic each cell has about clicking. Your mouse’s position is highlighted on the cell it hovers over.
Moving your character.
Not stopping there, the state machine was able to read if a player unit had already moved to decide if it could be selected again, and if all player units had moved, it would be the opponent’s turn. I made a really basic (read: “random”) AI to have the opponent player move their units at this point. Thus, turn-logic existed, each side took turns moving their characters closer to each other.
Even further, I was able to have both you be able to attack the opponent, and the opponent attack you, during respective turns. You noticed the red bars over the selected units in the screenshots, this UI fully works in showing the health of a unit, and if a unit goes to 0, they die and are removed from the map. With this, I was able to implement when a winner is decided, and end the game.
Players are greyed-out when already moved, are able to attack and their health updates (background darkened to show grey units).
That’s a lot of progress, and what I described so far took about four weeks, mostly on weekends or evenings after work. Effectively, it is a fully-functioning prototype of what will be the final strategy map. The logic is kind of hideous, the type of rapid-prototyping that software engineers would cringe at, but it works, and again, is mostly complete.
What’s left? So the enemy AI is mostly non-existent. I know how to write a basic chess AI, but I only now realize that being able to move multiple units in the same turn makes it a little different… it will be interesting to design. If you look closely above, you will notice that the range of movement does not go around obstacles properly, I have to update that logic to be based on path range rather than just cell index (this is also related to basic path-finding that would be used for enemy AI, both can be implemented together).
Also, you notice the map looks a little bare, and that was the big problem I faced. Yes, I could populate each player and enemy unit with a copy of my current player model, but when I tried this, the game slowed down to a crawl: I’m talking 15 frames a minute, not playable in any sense. Basically the “3D cel animation” system as I’ve had it up until now was not efficient, especially highlighted when I had a over 100 such objects in the scene using it. It took a few weeks and is fixed now, but that’s worth a separate blog post to explain as I continue further optimization. Because of this unforeseen development, making anything like a demo by Spring was unlikely.
In the near future, your players and enemies will be animated in the board.
I never did meet that deadline in March, and given the current state of “True King,” I wouldn’t have been able to prepare a demo properly in time for the real event anyway. But trying to get done in time helped me make more progress in a few weeks than I had in almost a year. I’m exhausted and always seem to have trouble focusing, but if I keep finding reasons like this to push myself, then I’m excited to see the progress soon to be made.
