P7 - Mochi: The Longest Tuesday

-- Project Summary --

  • 15 weeks, 50%
  • Reference Game: Jak and Daxter

This project was made in our groups second iteration of our proper engine. It was developed alongside other diciplines such as Graphical Artists, Game Animators, Level Designers and Sound Designers. You play as the cat of a scientist who recently got you a brand new mech, but suddenly a meteor hits your spaceship and breaks a window. Luckily the only thing that flew away was the box the mech came in, but being a cat its the main thing you are interested in. Despite your owners warnings, you decide to go after the box so you can snuggle in it.

-- My Contribution --

-- Pseudo Physics Controller for Actors --

Originally we were supposed to use PhysX for actors physics, but our group struggled really hard with the implementation of PhysX. As time went on I made more and more improvements to the prototype physics to try and capture the feel I wanted the game to have. At some point I realised that I would not have enough time to properly implement a PhysX controller so I decided to instead just implement PhysX collision data into my existing pseudo physics controller.

-- Player Controller --

I learnt a lot from the previous project when it came to structuring the player controller more properly. I used a slightly modified version of a statemachine where it is the controller itself that tells which state to switch to based on the input it recieves. Each state also has a priority value to evaluate whether or not you are allowed to switch to the new state. I also implemented the option to run a secondary state to run multiple states at the same time, such as run & jump or shoot & fall.

-- Buttons, Projectiles & Button Activated Platforms --

These were implemented as simply as possible to not overcomplicate things. Each button and projectile has a colour enum that it compares upon collision to decide if the button should activate its platforms. For the activasion of the platforms I had to do a small work-around since we did not have support for accessing objects in the scene by ID or name. I then made the button send out a postmaster message with its ID. Each platform holds an ID to the button that activates it and compares it to the message it recieves. 

-- Behaviour Tree System & Enemy AI --

For this project it was required to use some form of behaviour tree, but since I had never used an external library for it before but knew the very basic things about how they work, I decided to make my own. It was surprisingly easy and I added more nodes and features whenever I needed them. It was very comfortable to work on and iterate the AI behaviour, however as the tree for the AI grew larger it became quite cluttered. Properly playing animations also became quite ugly with how I needed to structure the tree. After discussing with some other programmers I definitely want to make some form of behaviour tree and state machine hybrid to help declutter the tree and have an easier to follow animation flow.

-- Leveling & Pickups & Checkpoints & Respawning --

These are very small features that I decided to clump together since there is not a lot to talk about them. The level of the players gun is determined by in integer that increases whenever you pickup a level-pickup allowing you to shoot different balls. The checkpoints and respawning are also very simple, I save the position and rotation of the most recent checkpoint in the player and just set those values on the player when they die. The checkpoint also holds story dialogue, a laser to show directions and an NPC. Some story parts of the checkpoint was moved to another programmer while I was sick for a long time.

-- Credits --

-- Programmers --

-- Level Designers --

-- Graphical Artists --

-- Animators --

-- Tech Artists --