Virion devlog #4

2018/04/22

4 minute read

summary

I though about different AI enemy types today. Currently the damage, and the health/armor for the AI was being set within an interval appropriate with the current level, but this doesn’t really give the sense that you are fighting agains different enemies. The AI also tries to compansate for the static nature by introducing some non-determinism into target selection but still not enough. What I need is to have different types of units. E.g a unit that stuns the enemy, like the half snake monsters from XCOM2. Or support units that boost the health of the all the enemies in the level unless it’s destroyed. These types of units will need their own AI implementations. E.g a support unit won’t go around chasing enemies, it will try to stay as far away from the player as it can and evade the player. So to facilitate this, I moved the AI into the enemy base class and a portion of it (target selection/movement) to the current type of enemy. (called type A, because I haven’t yet thought about names or a story line etc.). This turned to be a bit tedious with subtle variable shadowing bugs creeping in an took a good portion of my day.

This also lead the way for letting the enemies use the same types of weapons the player was using, for the time being which means that the enemies will soon get ranged weapons. This actually has an implication on the user interface, the player should be able to see which enemy has a ranged weapon and the area that it covers. Maybe if this were a PC game a mouse-over the enemy would reveal it’s range and coverage but this doesn’t work when you are targeting handheld devices. I also don’t want to complicate the selection states further by revealing this information when a player is not selected and an enemy is selected etc. So the idea I came up with is to display the ranged attack arc of the enemy when the player selects his own unit and that unit can actually move, as it only matters when moving. This refactoring lead me to the decision to also move the targeting code from the player and enemy classes into the weapon classes themselves, using the wielder information for target selection (you don’t want to shoot at friendlies). Coming from a server-side programming background I am used to using lists, arrays etc to use composition in objects, but with the scene tree there, it actually makes more sense to use a node in the scene tree to hold stuff like weapons, as you get the holder of that item from the scene tree way more easier. Otherwise you have to pass around the reference of the parent etc. This model of programming should also find it’s way into other domains. You should be able to freely traverse the object graph.

I was also thinking that all player units would carry a ranged weapon but this doesn’t seem optimal to me now. Some units should only have a melee attack, and loot a ranged weapon after progressing in the game? One thing is for sure though you can’t have 2 ranged weapons, as that would require the player to select which one to fire. I want to take a convention over configuration type of approach for a mobile game. The convention here being that if you are in melee range you can only do a melee attack. This is also kind of more realistic. If you were in a close brawl with someone would you leave that and try to shoot at something far away?

I was able to squeeze a couple of hours more out of the day (mostly because my SO is away on an MBA class reunion in Nashville) to implement the range arc display for enemies that are equipped with a ranged weapon. I also changed the sprite they use for a visual distinction between the current 2 types of enemies.

image