Virion devlog #12

2018/05/07

4 minute read

Summary

ported over the path finding code and map validation. I ran into a stupid typo bug that was screwing up the lee path expansion matrix code, which took me 2 hours to debug and fix. And it turned out to be one of those 1 character typos (wrote a y instead of x). This stuff can be so frustrating sometimes! I also started generifying the names for the in-game components as the theme is not decided completely yet. So instead of calling a tile “water” I just call it a “killer” tile as it could be water or it could be fire. I also did JetBrains Rider a favor and cleared 99% of the warnings and applied it’s suggestions. It’s annoying to have code fragments underlined and highlighted. In the prototype move of the behaviour and data and logic code were in the same file, but with unity using the component system it’s easy to seperate these so the unit selection and unit movement code went into their own components. It’s quite nice to have a unit class that’s pretty short and these types attributes and behaviours in different components. I have seen a player class in one of the open source roguelikes that around 5K lines of code. I could never wrap my head around it or even manage that much code in a single file. I also implemented the movement arcs, and the unit selection indication. I refactored some methods to return game objects (tile processing code) which I later reverted back the base component class to take better advantage of static typing. It’s easy to access the game object on the component to get another one anyways, so it makes more sense to return the base component.

In the protoype the units were kind of teleported to a location when clicked on them, with a line showing path it came from. Now I have the units animate tile by tile to their destination. This is a nice way to reduce the clutter on the map and make the game look more professional. But now I had to come up with a way to disable the next turn button when a unit is moving. Otherwise if the player would press the button the enemies would start moving and the game would stop being turn based but be more real time, and I’m sure it would cause a lot more bugs and complications. The animation of the units works by calculating the path it will take and queuing these tiles up in the movement behaviour. If the queue is full, it means the unit is moving and the button should be disabled. So I added a coroutine in the button behaviour that checks this for all ally units and adjusts the button state accordingly. The queue is processed in the Update loop for each unit, so the checks have to be done in a seperate thread. I also added some enemy units, and after the players turn the enemy units make their move. In the prototype the enemy units were teleporting too, so I could just process their calculations sequentially and be done with it. Now I have to do the same checks I did for the “next turn” button for the enemies so that they play one after the other.

I also ported a part of the loot generator for weapons. This part was bugging me in the prototype as the implementation done by GO was based on a data centric approach you would use in a functional language and not really OOP. What I have so far is a function that returns a random prefab from the available weapons, and the code that spawns the player randomizes the weapon parameters and adds the weapon instance as a child node to the player. I need to get the parameter randomization code into the loot generator, and add the items to a player inventory. In the unit lab the player will assign a weapon from the inventory to the player, and the player with spawn with that.