Meowmentum Mori
Meowmentum Mori is a first-person single-player speedrunning platformer where you play as Mori, a novice catmage facing a series of coming-of-age trials in a pocket universe. In order to inherit the family elders' magic, finish each trial as fast as you can and become a full-fledged catmage!
Content Breakdown
Given how important movement is in this game, all of the states were prototyped quickly, to have a feel of how it would work and what the player was capable of doing in this world, evolving into the final result through feedback and iteration. In this case, it boiled down to the following states:
Base Movement
Slide | Slide jump
Wall Running | Wall Jumping
Ledge climb
Dash (Handled by the other tech designer in the team)
Player Movement
BASE MOVEMENT
Movement behaviour is initially provided by Quin Henshaw, one of our instructors at VFS, so the approach was to build upon it, including the states of movement that were designed for the game. The solution was to include a state machine that served as a bridge between the additional behaviours and atomized functionality and logic, into two main branches:
Movement execution: Localized functionality that managed velocity, momentum, and the base state of movement (Running and Jumping)
State detection: External functionality that triggered state changes, providing the necessary information for it to be executed.
This facilitated the inclusion of new states and allowed for the easy inclusion or removal of any state, keeping in mind that some states were being prototyped and developed separately.
WALL RUNNING
Wall running was initially prototyped and implemented in a way that adapted to the shape of any perpendicular platform, allowing the level designer to shape the world and moments involving this mechanic freely. The structure provided for this mechanic is the following:
Detection: It consisted of ray casts on the sides and below the player that made sure the player was within the desired height and proximity to walls and ground, to initiate a wall run.
Movement Information: Once a wall run is initiated, information derived from the rays, like the forward direction of a wall or its normal, as well as the desired speeds, both delivered to the base state machine for it to be handled and executed.
This got iterated over time for players to have a range of movement within a wall run to move the camera freely and have a sight of where to go.
SLIDE
This was one of the features that had the most influence on momentum since all movement generated here was influenced by it, with that in mind, the way this mechanic got implemented was the following:
Trigger: In this case, activating this state was up to the player, since they would decide when to slide, this was a simple binding added to Unity’s input system in charge of triggering the state.
Movement Information: This was an interesting challenge since the trigger for this state was triggered once and not constantly, but given the inclination of the ground and a forward direction, the direction on which the player was provided taking into account the momentum of the player, for momentum to be conserved appropriately.
The feature was prototyped very early into the project, but it was by far the one that I iterated on the most given the feedback that playtesters gave, tweaking it to the point momentum felt satisfying to gain and maintain.
LEDGE CLIMB
This is a feature designed as a lifeline for players, it made sure to save them from near-loss situations, which meant it was an automatic process that happened whenever players got close to a ledge, providing a second chance to continue the level in exchange for time. The way this state worked was this:
Detection: I used a sphere cast limited to a range of vision, that combined with an altitude range triggered the state if a ledge was detected between both ranges.
Movement handling: In this case, the movement was handled separately through non-physics motion to make the climb reliable since using them did not always save the player, even though any remaining momentum was handled by applying it at the end of the process, giving the illusion of a character that wants to recover, and reducing the punishment that a player got out of this mechanic.
When it came to prototyping this one took the most time, even though the amount of research from the get-go made this feature easy to iterate and one and a challenge that taught me a lot about gameplay programming along the way.
As a speedrunner game, time and pathing are information valuable to keep and track, since it provides incentives for players all over the experience for them to be better every time they completed a level. The management of data opened the doors for so many systems that are focused precisely on feeding the compulsion loop of this game and the progression of players along the way.
I introduced a data architecture that, per level, made persistence of the following data:
Time: Represents the best time a player ever got in a level.
Rank achieved: Represents the best rank that a player ever got in a level.
Path Followed (Position & Time Stamps): This is a collection of points in the world that represented the best path that a player followed in a level, recorded in a fixed time progression.
This specific type of information required a couple of structures behind it, as shown in the images, to make the information relevant across the project.
Providing tools as well, to test and manipulate data during development
This was a data manager, designed as a Scriptable object, enabling any other script to reference data when needed.
The data structure changed over time, some of the features that used the data came down the line and so it kept evolving naturally, but given the way it was implemented, including and removing information was easy and could be tested more frequently.
Data Management
Systems possible Thanks to Data Management
Thanks to the Data Architecture in the project and front-end implementations, capable of translating the information into visual UI elements, combined with a back-end solution provided by Unity Gaming Services, players had the chance of comparing their performance with other players around the globe.
The front-end system managed the information recieved on leaderboard entries, which localized the information of each player in a hierarchy that was organized by the back-end system
LEADERBOARDS
PATH REPLAY SYSTEM
The path data structure here was crucial since it enabled the chance of replaying as close as possible, player movement. Alongside a spline that translated data into world space, enabling players to improve upon their best performance, and providing the game’s core design.
The path itself was built by a spline, that got its nodes thanks to the data stored, and animated in a custom manner to match player’s run as close as possible
Once again, alongside Unity Gaming Services, the analytics system was included in the project. This allowed the level design to contrast the performance of players at each level, providing information on their runs, using the data architecture that allowed the recollection of information.
This system had a separate manager that allowed to send information, whenever it was necessary, and not depending on the data stored locally
ANALYTICS
Gameplay Modes
This game has a target audience of mainly competitive players, it focuses on the idea of “You can always do better, keep trying”, and yet we got constant feedback from playtesting and a wide variety of skill levels that got a chance to play the game, that it demonstrated to be harsh on newcomers or inexperienced players. A practice mode and game states were introduced to allow more levels of skill to have a more enjoyable experience with the game.
The solution I provided for this modes implementation had two main components:
Game Manager: This was a component accessible throughout the whole project, that provided information to all systems of the state that the player was on, and that determined the behaviours that multiple systems had to change or take depending on what the player wanted to do.
Checkpoint System: This was a component specific to the practice mode, capable of triggering and changing the behaviour of the game, with the specific focus of allowing players to practice sections of a level, without time penalties, but without the chance of submitting times to leaderboards or to local times.
