*******************

GLOWUP TIME!

*******************

In this week, I took a long hard look at the walls of code I wrote  in the week prior and came to the educated conclusion that they were rather trash. The logic was clunky and could be implemented way better, so I decided to go back and make it way better. 

Obstructed Path to Target square

For a unit move to be classified as valid, there can be no units in its path between the units current and target square.

Old :(

The old method of analysing this was super brute force and not efficient at all. It involved manually Finding all squares between the current and target square, finding all units on those squares and then processing logic for those units. This method overused the find function and would be to hard to alter for different unit movement types. It hit me one morning that there was an infinitely better way of doing this….

New :)

The new, sexy method involved using a straight line raycast between the current and target square, with a layerMask to target only units. This would return all units hit between the current and target. Furthermore, this method works for both the diagonal and straight movement unit types.

• -Doing this managed to cut down the code significantly
• -It was much easier to understand and debug when errors occurred
• -A lot more versatile for different movement types

Move Logic

The basic move logic got the same makeover…

Old

Similar to above, the old logic was brute force. It involved performing many lines of arithmetic on the name of the current square to see if the target square was in the correct path. This was clunky and didn’t spark joy.

New <3

When doing the raycast I had a moment of big brain enlightenment specifically to do with the line made between the current and target square.

A horizontal move always produced a line with angle 45, 135 degrees to the horizontal. Similarly, straight movement either produced lines of 0, 180, 270 degrees to the horizontal. Therefore, a move could be analysed and determined valid based on the angle of the line.

All in all, these two adjustments managed to cut the move logic code down by about 200 lines.

Info Book  

Following this little tangent, I decided to implement the book. The book provides info on a given unit to the player. As discussed before, the info tab appears in the action UI and the button can be selected to bring up important information on the selected unit.

As seen when button is pressed a canvas is instantiated corresponding with the name of the selected unit. If another canvas is present prior to this it is closed/destroyed. Future implementation will involve adding tabs to each canvas which provide: Flavour Text, ability info, movement info. This will be a straight forward yet time consuming task.

Abilities

Here’s a lil sneak peak of the abilities I been working on…..

I’ll talk about it next week 

Next Week Goals

• -Finish book implementation add information to canvas’s
• -Finish implementing all abilities
• -Implement army build scene

Thanks for reading x