Saturday began as an interesting day. I had gotten a late start as I had been up late the night before working on coding the wandering and rotating of the enemies for the game. Because I had such a late start, most of my fellow students had already left for the gameslab. I had a vague recollection of where the bus stop to get onto in order to get to the university was, but I was unfortunately unable to locate it exactly.
As a result, I decided that it was a nice enough day out to instead walk to the university as opposed to taking the bus. As such, I put in the address for the university on my phone, and began walking in the direction it was pointing me. Unfortunately, however, there appeared to be an issue with google maps on my phone that day, as it was constantly saying I was in the wrong position and facing the wrong direction after I had already gotten some distance towards where it was telling me to go. This lead to a situation where my phone was constantly “recalculating” the route I was supposed to travel on, and was causing my phone to act rather slow. Eventually, I decided to use the directions my phone was giving me as more of a general “guideline” for the direction I should be heading, and was lucky enough to eventually find street signs that had “Universität Paderborn” written on them with arrows pointing in the right direction. I began following the directions on the signs, and while walking around got a rather nice view of the surrounding town, though unfortunately I did not think to take pictures during my walk. All in all, it took about 40 minutes to get from the hotel to the university, but that is including all the times I got turned around and went down incorrect streets trying to follow the directions I was given by my phone.
Once I got into the gameslab, I began continuing to refine and show off the rotational code I had put in place the night before for the enemy AI to my fellow team members, but then soon after began coding for the different interactions the player would have with the enemies in the game.
I started out working on two of the three types of enemies that would be implemented into the game. The first of which was a neutral NPC that would wander aimlessly within the boundaries of its designated wander zone. When the player collides with this type of enemy, a method is run that checks the size/mass of the player compared to the NPC. If the player is bigger than the enemy they are colliding with, they consume that enemy as they would a normal collectible around the map. If they are smaller, however, the enemy will consume the player instead and the player that got consume is set to be inactive. This enemy type was relatively easy to code, and was functional soon after I began working on the code.
The second type of enemy that was implemented into the game was an aggressive enemy type. This enemy had an “aggro range” that determine whether or not a player was close enough to the enemy for it to begin chasing after that player. I accomplished setting this up by having a Game Manager entity within the scene that stored lists of the players that were active within the scene and all the enemies that were in the scene. Because the number of enemies within a scene was going to usually be a lot smaller than the amount of collectibles, I decided to implement the “aggro range” for the enemies by doing distance checks between the player and the enemies, and if the player got to close to an aggressive enemy, the player’s location became the directional target for the enemy and the enemy would no longer wander within the bounds of their wander zone. Getting this initially setup was not difficult, but I had a hard time implementing a constant rotation toward the player while it was being chased by the enemy (following the theme that I am not the best at quaternion math). After a lot of google searching and reading through the unity documentation, I was able to setup a system I was satisfied with where the enemy would be constantly rotating towards the player’s position while chasing them, and I was able to reuse a lot of my code from before when I got the enemies to rotate toward the direction they were moving in the wander zones.
Once I had the movement setup for the aggressive NPCs, I then moved onto coding what would happen when the two collided. As a team we decided something different should happen as opposed to the “Eat or Be Eaten” interaction that was in place for the neutral NPCs. In the end we decided on having a knockback and split system where if an aggressive NPC collides with the player, if the player is above a certain mass/size threshold but smaller than the NPC, the player would be split in half. When this occurs, one half of the original player, still being controlled by the player themselves, is shot off in the direction the enemy was coming towards the player at while the other half is set as a general collectible for the player to reacquire to get back their original mass/size. If the player is below that splitting threshold, they are instead consumed as normal by the NPC. If they are bigger than the NPC, they instead consume the NPC as normal. While not originally hard to setup compared to the neutral NPCs, this system did take some time to get working.
Right around the time that I finished getting the aggressive NPC setup, it was time for the German and American students to leave for a few hours to travel to a nearby park for a barbecue and lawn games event that had been setup. We all packed up our things and left the lab, and when we got to the park proceeded to lounge around while enjoying delicious food, discussing mechanics for the various games that were being worked on, and some of us even began playing a more classic drinking game called Flunkyball.
This game involved two teams, one on each side of a bottle of water placed between them. The teams would line up and place their drinks infront of them, and go back and forth throwing a ball to try and knock over the bottle of water between them. If a team manages to knock over the bottle with the ball, everyone on that team begins to drink their drink as fast as they can while the other team sends out two people: one to stand the bottle up and the other to collect the ball. Once the opposing team collects the ball and stands the bottle up, the team that knocked it over has to stop drink. The game goes back and forth like this until one team completely finishes all of their drinks.
All in all I found this game to be incredibly enjoyable, and we played it many times throughout the barbecue.
After the barbecue had gone on for a while, I and a number of other students decided it would be a good idea to return to the lab to continue working on our games. We traveled back to the lab, and I spent a few more hours refining and smoothing out the random walking for the enemies and the aggressive enemy type. Just as I was about to leave, however, I was informed that they no longer wanted the enemies to rotate, as this would be handled by the artists with the sprite animations. After the news was given to me and I discussed the subject of rotating the enemies with the team lead, I then had to heavily modify the movement code to have the enemies no longer rotate as they moved to fall in line with the new requirements I was given. Having to do that was a bit heartbreaking, as I had spent a lot of time building that rotational system up, and was not informed it was not necessary during any of the times I was show casing it to my fellow team members.
Once the rotational system was removed for the code, I packed up my things and went back to the hotel to try and get some rest before the final day of the Game Jam.
