week 3

Week 3 went a bit slower than expected, but that was expected (even though not wanted). However, most of the planned work was done. Exactly what was done will be explored below but to sum it up: the game is actually starting to look like a game now. 

The overall goal for this week was to make fully functional minions that could walk around the dungeon and affect how the rooms work and if they work at all. I decided to start with the most daunting part: pathfinding. I looked over the code from the practicals and realised that I don't understand it enough to be able to adapt it to my specific needs. I did take some inspiration from it though. I liked the idea of each minion having its own target and path that they follow. I also liked the idea of that path being a list of nodes and the simple action of popping off the first node once the minion gets to it. For a bit, I contemplated using a stack because it seems to fit the situation almost perfectly, but I decided against it in the end. I am not familiar enough with stacks in unity and, from my understanding, it wouldn't provide any great benefits other than being more contextually appropriate. I still wrote all of those parts in my manner but they are still very similar to the example code. Everything else is of my own.

The first thing I decided to do to implement my pathfinding is creating the nodes. I spent a big chunk of time implementing it into the room manager and the room scripts to make each room have nodes and to seamlessly connect those nodes between each other. The basic idea is to make each room only have 1 node in the middle of it. When the room is created already existing methods would be used to check for the rooms around it to connect all of their nodes node to. Special rooms proved a bit troublesome to implement. For tall rooms, I need to shift the node downwards, and for the vertical connection rooms, I also need to check rooms above and below it. You can see the existing nodes on the image below in blue. (tall rooms are broken at the moment due to an unfinished implementation of a new feature)

Once all my rooms had nodes and they were all connected I had to start on the actual implementation of the monsters. I decided to try and stay consistent. I made 3 structures: the one-fits-all script for monsters, the manager for the monsters, and the library. I decided that it would be best to keep the monsters dumb and to centralise all the thinking in the manager and I designed both accordingly. Monsters would not be able to come up with a path on their own, they would simply be given a path (which is a list of nodes) and they would follow it. Monsters would know their target but they would not do anything with that information other than provide it to other classes (mainly the monster manager). The monster manager, on the other hand, would collect the information from both the monsters and the player and create routes for them accordingly.

For the implementation of the pathfinding algorithm itself, I decided to keep it fairly simple and brute force every calculation. Initially, I did have ideas on how to make it smarter and more efficient, but I decided not to worry about that until the need arises. I don't expect the calculation times to be too excessive in the game and if it proves to be a problem and I have time to fix it, it should be a fairly isolated change. The algorithm I decided to go with was how I would solve a maze puzzle if I couldn't see further than neighbouring rooms. The program would check all of the neighbouring rooms of the room it is in (if it hasn't been there before), and to "check" the room, it would check all the neighbouring rooms of the room it is in. (recursive definition) It would continue checking rooms until it either runs into a dead end, a room it has already been to, or the target room. Such an algorithm provided a path to the room, but it wasn't the most optimal path. To fix that issue I made the algorithm check each route it could possibly check instead of stopping when it found a path to the target and then comparing all the solutions that it found by the distance a minion would have to walk. You can see in the picture above the optimal path to the selected room (one of the vertical rooms) is highlighted with red, but another possible solution is highlighted with yellow.

I kept my node traversal code fairly faithful to the reference code. When the monster receives its path they move to the first node, once they arrive at it, they remove the first node and move to the new first node until there are no more nodes left. The problem was, there is only one node in each room, regardless of the size, meaning that all the minions would stay in exactly the same spot. That is very troublesome because it's impossible to tell how many minions are in the room.

This was the last challenge I tackled this week. The very first thing I did was work out how far the nodes would have to be separated in a room of any size. Then, I wanted to implement a mechanism that would create multiple nodes in each room, but I ran into a lot of trouble. The trouble was that node creation and assignment was somewhat of a bulky system. Changing rooms from having just one node to multiple would require a lot of reworking. For time efficiency purposes I decided to simply make another type of node. I call the new type of nodes room nodes. They don't have any connections to their neighbours, but they know if there is a monster assigned to them or if they're free.

Once the player selects a monster and clicks on a room, the room will check if it has any free room nodes. If it does, the monster manager will come up with the path to the room node from the minion's position and provide the monster with it. If there are no free room nodes, the monster will be de-selected and no path will be created. Also, the rooms keep track of what monsters are in them. The monsters will be removed when they leave the room and added when they are in the room. Next week I will implement the rooms taking different amounts of time to complete their tasks and the amount of resources will be dependent on the stats of the monsters in the bed. I will also try to implement monsters consuming food and implement expeditions to generate food.