Friday, after I had fully rested up and felt much better than the day before, I began my deep dive into coding for the team that I had been placed on, A-blob-calypse. We spent the initial parts of the morning finalizing our ideas for the game and discussing what would and wouldn’t be in the final product, building off of what we had discussed the day before. The game became centered around the player controlling a magical blob monster that went around absorbing objects, animals, and people in order to grow in size and strength. We also decided that in order to incorporate the Game Jam theme of “better together” we would implement a system where multiple players could control the same or different blobs, by coming together to form one mega-blob or splitting apart into smaller individually controlled blobs. We also decided on a number of NPCs that would be implemented in the game, each with their own specific interactions setup.
I was put in charge of coding the AI interactions between the player and the enemies of the game, as well as setting up a collectibles system for the players to absorb non-enemies in order to grow their character. A lot of the coding that I did on Friday involved setting up enemies that would move around in a designated area so that the Game Designers could build sections of the maps where enemies would and wouldn’t be. Because of the nature of these systems, building them up required a lot of vector math, and while I am fairly well versed in vector based math and coding for game mechanics, it is far from one of my stronger suits. I spent a lot of time working on getting it as close to “just right” as I could.
For the collectibles portion of my coding tasks, I found coding this system to be the easier of the two. Originally I tried to do vector comparisons with the position vectors for the player and all the objects to determine how close they were to each other, but soon after beginning to code this I decided to do something else as I felt constantly checking position vectors against each other may be a bit unnecessary. After the initial idea was scrapped, to accomplish allowing the player to absorb collectibles I decided to use 2D colliders on the player and the objects, and coded it so the when an OnCollisionEnter function was fired off, it would run a script for both the player and the object the player was absorbing. The script run on the object that was being absorb allowed for an absorption animation to be played and eventually deleted the game object from the scene, while the script for the player increased their size and mass.
For the enemies portion of my coding task, I decided to go about doing this by using Empty Game Objects in Unity and attaching a Polygon colliders to them. This polygon collider was used to draw out a designated area for the enemies to wander around in that could be shaped as necessary for each level. The enemies would pick a random direction within that area, then begin to update their position towards that direction. Each time they would go to update their position, however, they would run a check to ensure that their future position would still be within the bounds of the Polygon collider. If it wasn’t, originally I had them retarget and pick a new direction that would be within the bounds of the collider.
After that system was implemented, I decided to go with a different approach for keeping the enemies within their wander zone, as I ran into an issue where the NPCs were constantly moving in and out of the wandering area in one or two corners. So, instead of the retargeting system to keep them within the area, I instead had the enemies target the center of the wandering area and move to it, then retarget a new direction. This caused the enemies moving around to look a lot better than at first.
Once I had the enemies setup to wander within a specific zone, I then began working on having them rotate to face the direction they were moving towards. This added a lot of quaternion math into the already vector heavy code that I was working on. While I am able to work my way around vector based coding, coding game mechanics involving rotations and quaternions was something I had rarely ever done before, and posed a big challenge for me. Luckily, I was surrounded with other coders working on various elements for their own games, and many were happy to help me work my way through the rotational math and provide input on the various game ideas I had. Eventually, I got to a solid point where the NPCs were rotating towards the directions they were moving, although this was accomplished much later in the evening back at the hotel, as everyone had already left the gameslab to go home by that point and it took me a long time to get the quaternion rotations working.
