Dev Log #1

Good news is that I finished refactoring my code and everything is much more understandable now. I can actually see everything that is going to happen when a turn ends in ONE place.

I also added basic enemy movement towards the player. It was a lot more difficult than I initially thought it would be. It turns out that Astar2D does not just take in a TileMap as a parameter and connect all the points on the Tilemap together.

So, I had to create a bunch of Vector2 objects in a loop and generate a unique ID number for each point in my hex grid. This was annoying and I also had to do conversions between Vector2 and Vector2I to make sure that the correct coordinates on the TileMap were going to be used for the enemy to follow a path to the player.

ChatGPT saved me a ton of time, so thankfully I didn't have to think about every single step in the process. Although, I will say that sometimes GPT suggests creating a bunch of methods when they are definitely not needed. I'm also prototyping, so I'm not interested in over-engineering this code. I was able to adjust a lot of its suggestions to make the code simpler.

I did have to fix some funny bugs as well. When I clicked the “End Turn” button, the enemy would go back to its original position and then move towards the player again as if it was controlled by a rubber band. Apparently, I had set the starting point to always be its initial position on my hex grid, so it kept going back there 😆.

I also ran into a weird jiggle at its destination hex sometimes because apparently the distance to the target position logic would be off by just enough to keep it perpetually moving on the same hex and never getting to its destination. I fixed this by forcing the enemy to the target position when it got close enough, so the enemy wouldn't just miss its destination slightly.