Project Cappy
My Capstone project while studying at Full Sail
Project Cappy was my capstone project to round out my education at Full Sail University. A group of 4 other designers and I all decided on a reference game (Super Mario Odyssey) and spent the 1st month of our project trying to recreate the core systems of the game, such as the movement, capture mechanics, health, and collectables. In the first month, I focused a lot of pickups, camera, and the cap throwing mechanic.
My goal this first month with pickups was to create an expandable base class that could be used to create further pickups down the line, since I knew we'd have at least two with different functionalities. I created a parent class that had the functionality of watching for overlaps with the player, running a function that could be defined by the child class, then destroying itself. In later months this class was very easily built upon to create Coins and Moons as well as our Keycards in the final month. For the camera, I spent a lot of time playing through levels of Super Mario Odyssey and paying very close attention to how the camera moves. Whenever the camera was not on rails, I observed the following traits about it:
When mario jumps, the z level of the camera remains at the floor
When mario lands, the z level of the camera glides up to the new floor level
If mario gets too far away from the floor he jumped off of, the camera glides back to him while he falls
These observations became my completion criteria for the camera. In theory, these elements were very simple to implement into the game, but in practice, there were some strange bugs that cropped up as a cosequence of this system. My initial solution was to check if the player was falling, and if so, to hold the camera boom's z position at whatever it was when they began falling. This worked until that z position overlapped with a bit of level geometry, which then caused the camera boom to quickly retract inside of the geometry, making it impossible to see until the character landed again. Unfortunaely as this month came to a close, I had to make a comprimise and disable the probing on the camera boom while in the air to avoid this issue, despite that allowing the player to clip the camera into walls briefly while in air. If I were to go back and fix this today, I might have the player do a line cast to the point where the boom wants to be to see if it's obscured, and adjust accordingly based on that.
Come month 2, we were set sort of free to come up with our own mechanics and explore them in our levels. These levels can be seen in the videos below, exploring a mechanic based around redirecting light beams, and a block pushing mechanic. The light beams mechanic I built was inspired by the laser puzzles from Portal 2, being one of my all-time favorite games. Playing through some of those levels inspired me to create wires that could light up and show what puzzle elements were connected to what as well as a pressure plate and cube that interact with each other as well as the player. I really enjoyed designing and building this system, but as I began to design my level for it, I realized the mechanic was somewhat out of place in the collect-a-thon game we were creating, at least in its current iteration. The level design of the block pushing level I like a lot more, being much more open ended and classic collect-a-thon, though the mechanic itself is somewhat simple in my opinion. Each of these mechanics and levels were designed in 2 week sprints, where I spent roughly half of the time working out the mechanic and the other half designing the level.
In our 3rd month, we spent time adjusting and tweaking our levels to be a bit more polished, as well as cleaning up the game as a whole. This involved working on game-wide systems, such as the save system in my case. The save system became most of my work that month, learning through Unreal Engine documentation, forum posts, and my own trial and error how saves work and how to use them effectively in tandem with game instances and the levels themselves. In the end, I had created a (mostly) bug free save system that allows our game to function properly between levels and play sessions. Had I had the time, I probably would have totally rebuilt the save system at the end of the month, since it was riddled with strange issues from earlier in the month when I didn't totally understand how to get it working quite yet, but we had to move on to the final phase of the game. Also during this month, I spent some time polishing my light puzzle system for use in the next month's activities, adding the pressure plate and logic gates.
In our 4th and final month, we worked with artists from the Game Art program to create art assets for the game to match the new style we wanted to pivot into, as well as worked on some final new simple mechanics and a whole new set of levels to match our new theme. Being the last month, where the project needed to be in a finished state by the end, we knew that this would be quite the undertaking to redesign all the menues and create brand new levels, but we managed it. In the first week, myself and one of the other designers created a brand new keycard mechanic that would allow us to place keycards in the levels (another child class of the pickup base) that would get an ID and pull all it's data from a datatable. This table had keycard names and descriptions to act as hints to the player as to where that keycard could be used. Upon pickup, an array on the player would be updated to indicate which keycard was obtained and that data would be saved to persist between levels. Then in any other level, including the same one if desired, we could place keycard doors that could have a keycard ID assigned to it to be opened. This helped to add a more interconnected feel to our game and allow for paths between levels to be discovered over time. For example, my level connected to 2 different levels, but you could only go to 1 of them without finding a keycard in a different level and coming back.
Project Gallery
