Meowmentum
Meowmentum is a first-person single-player speedrunning platformer where you play as a novice catmage facing a series of trials in magical universes. To inherit the elders' magic, finish each trial as fast as possible 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 Apoorv Taneja)
Player Movement
BASE MOVEMENT
The foundation of the movement behaviour was facilitated by Quin Henshaw, our VFS instructor at the beginning of the project, which has been heavily modified to provide the variety of movement mechanics present in the game in conjunction with the state machine which helped determine the responsibilities of the system as follows:
Movement execution: Localized functionality that managed velocity, momentum, and the base state of movement (Running and Jumping)
State detection: Different states of movement triggered by external functionality, which indicated any changes of behaviour in the movement execution.
This enabled the inclusion of new states and behaviours of movement and allowed for the easy addition or removal of any new state or possible mechanic, keeping in mind that some states were being prototyped and developed separately.
WALL RUNNING
Wall running was initially prototyped and it is implemented in a way that adapts to the shape of any perpendicular platform, following its shape and allowing for freedom of design and world-building. The structure provided for this mechanic is the following:
Detection: It consists of ray casts pointed to the sides and below the player that assures the player is within the desired height and proximity to walls and ground, to initiate a wall run.
Movement Information: Once on a wall run state, information for movement derived from the rays, like the forward direction of a wall, as well as the desired speeds, are delivered to the base state machine to be handled and executed.
The system was designed and iterated to work independently from the camera movement so that players can ride a wall and yet be able to see freely in any direction.
SLIDE
The slide movement state is thought to be one of the main mechanics that work directly with momentum, focused on building on it and providing a fast-paced run if used correctly, so to achieve this, it is structured as follows:
Enviroment detection: Since it is the players who decide when to use the mechanic, here the challenge came from knowing how should they move given the inclination they were in, which through raycast, was determined and stored.
Movement Information: Thanks to the detection of the environment they were in, the player received different movement behaviours depending on what was detected, gaining momentum if there were slopes for example, or losing it if there was a long straight which drags your speed down.
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, through an automatic process that happens whenever players get close to a ledge, providing a second chance to continue the level in exchange for time. The way this state worked was this:
Detection: A sphere cast is used with a limited range of vision to the front which simulates looking and facing that direction to be saved, combined with an altitude range of how much past the top of the player the ledge could be.
Movement handling: This is the only state that handles movement separately through non-physics movement, which ensures a consistent way of saving the players from near-loss situations, and smoothly gives the control back to them.
When it came to prototyping this one took the most time, which I consider at the end of the day paid off, given that research and perseverance helped me build an easy-to-iterate integration of the state to the system, which facilitated changes down the line.
Data Management, use and Networking
DATA ARCHITECTURE
As a speedrunner game, time and pathing are information valuable to keep and track, since it provides incentives for players all over the experience to be better every time they complete 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.
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 represent the best path that a player followed in a level, recorded in a fixed time progression.
It is formed by multiple serializable structures which in conjunction allow the easy storage of the path and a comprehensive way of interpreting it back for different purposes.
Provided in-engine tools for the easy testing and management of game progression and data-dependent systems.
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 given that some of the features that used the data came down the line so it kept evolving naturally, which never represented a lengthy process given that the system was easy to iterate on, and could quickly include new data or remove it.
LEADERBOARDS
Thanks to the Data Architecture we were able to provide an organized way for the Unity Gaming Services back-end leaderboards system to save and interpret the information for it to be organized appropriately, which later could be displayed on the game’s UI by requesting the info from the already stored times, all to drive a sense of competitiveness on our game and feeding the compulsion loop that encouraged players engagement.
This system naturally had to have an information filter, where only the best runs of the players are stored, which are the ones who provide their best shot when competing.
The front-end flow of this system counts with ingenious tweaks, to take into account large numbers of players, as follows:
Information is only called by groups, only adding more entries to the list if the player decides to scroll down to the bottom to see more times.
UI entry assets are recycled, so that the system does not have to generate new UI assets every time a new batch of info is called, instead, by renaming and reassigning the data of the existing entries and adding or removing them, in case there is more or less information to be shown.
PATH REPLAY SYSTEM
This system relayed on the data architecture path point system, which provided the information necessary to know the player’s positions and movements over time, of their best path taken on their fastest run. This feature aims to provide visual feedback on how they achieve their time and what is the objective to beat, again building on the compulsion loop of competitiveness of the game and giving motivation to players to improve on their skills to grasp those better ranks and times.
The data collection of this system is based on snapshots in a fixed rate of positions and rotations over time that helped determine the path.
This path is reconstructed on a list of movements that then the replay system follows to show the path through the little orange character, and in case of being necessary, is able to support multiple paths for future challenges.
ANALYTICS
An analytics system was included in the project making use of the Unity Gaming Services systems, which provide a bulk of the back end needed in conjunction with the data system, which provides the relevant data, for us to compare and visualize the players’ progress throughout the game and their average times when facing different levels, and evaluating balance components such as the time ranks for each skillset of players on playtesting.
This system had a separate manager that allowed to send information, whenever it was necessary, and not depending on the data stored locally.
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.
