Virion devlog #8

2018/04/26

3 minute read

summary

I had implemented the dups check for the spawn queue in a inefficient way, so I corrected that. No need to scan the queue everytime, just keep track of the element in the queue in a set. I also realized during test playing that newly spawned water tiles could lead to islands in the map. So a check for connectivity was needed before adding that new water tile to the queue. This lead me to fix a performance issue in the connectivity checking code. A split the tile-tile checking code from the slower building - tile checking code. I’m still not sure if I should let water tiles spawn on building tiles. This is frustrating for the player because most of the time there is nothing you can do to stop it. It’s simply not possible to kill the remaining enemies in the number of turn given to save the building and this does reduce the global building preservation count. On the other hand it does make the game a bit more difficult and exciting.

A couple of days ago I had noticed that some enemies froze occasionally. Investigation into this led me to discover that it was possible for the enemies to select a building/mountain tile as the location for an attack on the player in some configurations. I implemented a fix for this and also implemented a fix for selecting unreachable tiles. I’m wondering if I should just let the enemies do a random walk if they don’t get a movement tile or just let them sit frozen for a coulpe of turns?

During one test game I was blessed (!) with a mech that had 5 speed. This made it super easy to go around killing all the enemies very fast before a wave came in to their rescue. After progressing about 5 levels the game crashed with a NPE because the level generator could not place the number of required units on the deployment zone for the enemies. There just wasn’t enough free tiles!. What this means is this

These were issues I was previously aware of, and had in my todo list. The solution is a points system which measures the strength of the units and adjusts the level difficulty based on this. Also I’m thinking of introducing a weight and maybe a heat system to implement the trade off between items. To install an AC with +2 damage means your speed is reduced by 1. So if you have a mech that’s only speed 1 you can’t install that weapon. With the current setup of only 1 item per mech this also means that if can’t have armor + speed. So if your mechs initial speed is 1 you cannot have AC2 + armor which may have a negative effect on game play.

I also saw an issue where the supports unit would surround a normal enemy unit and would not budge effectively freezing that unit in place. I set an upper limit of 1 for support units on the map.

Now that the unit lab development is complete and we can equip the units with items and weapons things are looking a lot better. We also implemented a budgeting system for generating the weapon stats based on level. Each level you get a budget of say 5 units and this beduget is distributed randomly to the stats of the loot being generated. This type of generation also brought a balance to the game. No more Bruce Lee’ing around the map killing everybody.