This post is a status update, which is how I track progress specific to my game. Check out my timeline to see what I've recently accomplished.
This update is similar to my last update in that I spent a month trying to improve the framework of a more complicated portion of the codebase. Last time was pathfinding, this time is combat. In addition to improving combat, I wanted to focus on data integrity and porting combat pathfinding to iOS9 / GameplayKit.
Note: This post has been backdated to keep the documentation accurate — the game was in this state as of Oct. 1st.
A Sampling of Combat Issues
Combat has a bunch of tricky issues that need to be tackled. Among them are:
- Only attack enemies you can see.
- Try to avoid units by walking around them instead of through them.
- AI and UI have to use the same code.
- Range overlays have to be dynamic.
- UI should lock certain abilities when engaged.
- Units engaged while walking should stop walking and defend.
- Unit attacked by multiple enemies should remain engaged until last enemy defeated.
- What happens after combat?
- Data integrity for all units tracking who is attacking, who has died, and who is engaging.
As you can imagine, things get complicated quickly. I had to tackle each item one at a time to avoid being overwhelmed. I’ve taken quite a mental beating between this update and last.
Implementing Line of Sight
One of the more interesting tasks with line of sight for combat. Each unit should be able to see an enemy before walking towards them. This will prevent units from walking through their friends just to get to a target. Steering behaviors can help avoid friendlies, but in order to prevent units from walking in circles, you can’t rely on steering behaviors alone. With that in mind, the logic works like this:
- Look through all enemy units and sort them by distance.
- Take the top X units, and see if you have line of sight.
- Note: Since LoS is intensive, X will depend on device / CPU.
- Pick the closet target and engage.
- Run the steps above every 1 second.
- If a change in target occurs, clear any state data and engage new target.
- While walking, use steering behaviors to partially avoid other units.
Attacked From Both Sides
Units will often be close to one another, so combat between multiple squads has to look decent. I started by tackling a unit surrounded on both sides.
While not finished, the results are promising. To take it a step further, I had to run the simulation multiple times from multiple directions because it has to always work. The end goal is for squads to keep their shape to some extent, which will also have the side effect of keeping things balanced.
A quick note on cutscenes — they are still being worked on, and are getting better each iteration. As of this update, a proof of concept of the final scene 2 is finished. The same style will then be applied to each scene. After that, sound design will go in. Finally, voice will be done. I’ll make periodic updates just to track the status.
Where Does This Leave Us?
In a decent spot. Combat isn’t close to done, but it is no in a place that I can iterate on. In particular, the state machine has been cleaned up significantly and is easier to read. Also, I’m more confident that the data is accurate. To test it, I have characters logging when they are attacking air, or stuck doing nothing. Those log items are almost non-existent now.
For the next month I’ll be adding more combat features like catapults and improved AI. I’ll also be tackling a huge refactor to abilities with the goal of making them reusable, easy to construct, easy to modify, and usable by AI. That will be a huge departure from what powers the commands now. Finally, I’ll set up level two and also get a proof of concept working for experience and levels.