Github link: https://github.com/DarienCaron/A-Small-Soul-Github
Google Drive download: https://drive.google.com/open?id=1Lg5P8VycgC5gRO8hIdbTkQk3QpRDy63Y
A Small Soul is my capstone game I took part in creating. We finished in April 2019. It is a 3D action platformer that takes inspiration from games such as hollow knight and ratatouille to some extent.
Our game’s main mechanic is the ability to scurry (climb) up walls and other various surfaces. Other mechanics include tool usage, which allows for changing into different creatures. Active ledge detection, a needle throw, and combat.
The roles during this project were programmer, artist, designer and audio technician.
My Role as a Programmer
This project was made in the Unity Engine version 2018.2.5f. At the time I had only used unity a handful of times. Which meant I had to learn C# on my own time. I personally believe I reached a level where I am comfortable working with C# on my own.
As a lead programmer, I was in charge of making various systems for our game. They are the following:
Creature System/Character Controller
From the beginning of the project we decided that we wanted our creatures to be able to control the same way. Thus we designed a three class system that would be the base for all controllable or AI controlled creatures. A Brain class, a Puppeteer class and a Creature class.
The Brain class serves as the input and logic handler. For the player, it handles all controls and external links. For example, the menu system goes through the player brain to pause the game. The brain will then send a message to the player creature to pause.
In the case of the AI, their brain’s handle their AI behaviors and interprets a situations like if the player is close or if they need to wander. This then gets passed to the child AI creature classes as movement instructions or attacks.
As a result, we were able to utilize our design to convert it into a playable mechanic in late development.
I programmed the creatures in our game utilizing this system. Some of which include the roach and the rat characters in our game.
Active Ledge Detection
This system was entirely made and maintained by me. Our game needed a way to help players make that last minute grab for an edge. Seeing as we were a small team, we didn’t want to burden designers with placing triggers around the level that serve as grapple points. The solution was to create a system that calculates when a ray cast is touching a surface, and figure out if its a point that can be grabbed on to. Below is a visualization of the process.
The idea came from looking at the way Overgrowth managed to do their ledge grab. I noticed they swept a cylinder downwards when their sphere cast his a surface. I recycled the concept and converted it using Unity’s tool set.
While our ledge grab doesn’t allow for movement from left to right, its very simple for me to convert it.
The beauty of the system is that its works with our modular mechanics. We can give the creatures mechanic scripts that allow them to perform tasks. Meaning if an enemy was using this script, this would allow them to grab a ledge.
To break down the math. Once the forward raycast collides, it will call a function to check if its a valid wall or fairly flat surface. It was designed this way to account for small platforms. If it returns true, a box cast as illustrated above will come down. If it collides, that means there’s some sort of box shape available to grab. The final check is to see if the player is air born. I made this decision because of the fast paced nature of the game.
If all these conditions are met, it uses the collided boxcast point as the Y, and the collided raycast point as the X & Z.
Furthermore, illustrated by the dependency, the ledge detection triggers the 3rd person camera to change to a behavior i wrote myself. It places the camera behind the player using its forward and allows it to orbit around the player. There are ray casts that check if there will be an obstacle, if one is detected, the camera is clamped in between the two ranges, the left point of collision and the right.
Link to github repository: https://github.com/DarienCaron/Active-Ledge-Detection
I took lead of creating the menu system for our game. While another member of the team created our UIRoot system, which holds all the desired menus in a scriptable object and keeps them on hold till they are called through an event. The UIRoot game object is the parent of a hierarchy that gets generated at start. Once one of the menu is pushed to the top of the pile, it becomes the active menu.
My role was to create the inventory menu , tool, hat selection menu and the shop menu.
For the shop menu, i wanted to create a multi purpose shop without having to copy paste too much code.
With the help of the parent class inventory menu. I was able to utilize some of the overridden functions for using the event system which allowed most menus that were inventory driven to work the same. For example i was able to get the hovered slot for all of my inventory menus.
One of the mistakes I made during this project was not properly researching design patterns. I designed my slot classes to work across all menus, but I do it in a way that required allot of manual tweaks with certain cases. I should have used the builder pattern and I would have gotten the same result.
We decided as a team that we wanted to implement hats in the game as a means to take advantage of our plans for a shop. Similar to the shop menu, it uses generic slots that hold hat prefabs.
Once the player selects a hat and confirms it, it swaps out the current hat on the player with the new one.
The way the hat menu gets access to its inventory is it uses a scriptable object, which in unity makes for an easy and scale-able container. Once it gets the list of hat prefabs, it generates and fills each slot with the item description attached to the hat and fills the hat container component with a hat.
The hat container is a child class of item container. After some research I managed to figure out how to convert a MonoBehaviour component into a templated class. So for every possible item that’s meant to be held in our game by a slot has a overridden item container class.
This is the inventory menu, its quite simple. I programmed it to work with what the intended design was, meaning the sketches provided.
There are several slots that all do different things.
The slots that have icons in them, similar to the tool ui in the bottom left corner of the screen. They are meant to display the current tools and their abilities. Originally, I programmed a menu that would allow you to change what tool was in what slot. Instead it simply uses the item viewer to showcase what the tool does.
The hat and souvenir slots are menu pushing slots. Once pressed, they fire off an event to open their respective menu’s.
The beauty of it is that all of the slots are one type. They have been tweaked and adjusted to work differently and scale well. Not to mention the inventory menu was designed to work in cohesion with the item viewer class and any slot.