Virion devlog #6

2018/04/24

3 minute read

summary

When displayin enemy firing arcs I didn’t want any water tiles to be considered in range, as it made it look like water tiles were traversable, which is false. So I just declared them as obsticles and excluded from the arc. This lead to an undesired side effect of players not being able to shoot enemies on the other side of the river. So I had to remedy the situation by just not displaying the arc if the tile is a water tile.

Another thing that was bugging me was that the armor support units boost was effecting the enemy units only after the first enemy moves were made. I changed this by giving the boost in the _ready function call with gets called every frame. I like to refrain from using this function as it consumes a lot of CPU cycles. Another option would be to implement some kind of post enemy creation hook that runs after all enemies are spawned and then distribute the boosts. I would have to run this code again after each in-level spawn has happened which I thought would be unnecessary complication in the code. One optimization I did was instead of executing the call every frame I added a check to execute it one every 0.5 seconds which is good enough for my purposes.

I was thinking about a type of enemy unit that would manipulate the terrain, e.g expand the water tiles or make the volcanos errupt and make lava flow around the map having the same effect as water. When I set out to implement this I realized that the backing array that I used when creating the map initially was kind of limiting. If I wanted to add a new lava tile, I would have to come up with a constant that represented that tile, and then add manage path finding code, etc to account for this new tile type. Besides this I was maintaning 2 datastructures: the scene tree and matrix containing redundant data. Since I can’t dump the scene tree, I had to dump the matrix. The first iteration constructs a new matrix when needed from the scene tree on the fly, the use of a 2d matrix makes path finding code a lot more simple. For the second iteration of refactoring I’m thinking about getting rid of the constant that I had been using to compare tile types, but I’m not sure this can be done. I was thinking about comparing class types to get to tile types, but some tiles share a class type, and gd script class type comparision isn’t that good. For instance I could not find a way to compare a class to it self. Say I have a function that returns all the enemy units on the map and in the support unit I want to skip over the enemy types “support unit”. You can preload the support unit within itself, so you are kind of stuck with the constant comparisons.