Kaleb Eberhart
Gameplay Designer & Producer
Rollossus
Overview
Rollossus is a third person ball rolling game where players utilize physics-defying navigational abilities to trick enemies to their deaths and activate towers to take down The Rollossus.
Core Experience
The goal of Rollossus is to provide players with the feeling of exhilaration by narrowly surviving. The exhilaration comes from fluctuating between fear of being beaten and the relief of barely escaping danger. The inspiration for this comes from the astroid belt chase scene in Star Wars: Episode V where Han Solo and friends are being chased by TIE fighters. The main component that made this chase scene so effective was that overwhelming danger was always present, whether it be TIE fighters or the astroids. In addition, the player must feel like Han Solo controlling the Falcon, they are aware that they are in danger but they know that surviving is possible through skillful navigation.
I achieved this overwhelming sensation of danger by:
​
-
Instantiating copious amounts and types of enemies at all times.
-
Players have no way to directly attack enemies.
-
Enemies can always find & catch up to the player.
-
Players can only get hit 2 times in short time spans. They can recover but they don't have room for error putting pressure on the player.
-
A deadly environment that will kill the player and enemies.
​
To prevent the player from becoming overwhelmed by sheer difficulty or making the game impossible to play, I designated the following rules:
​
-
The player abilities keep the enemies at a slight distance when used properly.
-
Player health can recover only if they avoid being hit a second time within a specified timeframe.
-
Enemy attacks are slightly less accurate when the player is moving to incentivize constant movement.​
Communication with Documentation
I implemented documentation I called "One Pagers" to communicate exactly how I wanted the systems to work. The approach I took with each one pager was:
​
-
Communicate everything visually.
-
What couldn't be drawn would receive explanation text.
​
I designed the one pagers with one goal in mind: Don't waste people's time. The results I achieved by using one pagers were:
​
-
Prevented the design doc from reaching immense numbers
-
Images captured actions more effectively and efficiently than words
-
Brief explanation text was enough to communicate specific details that couldn't be captured in the art.
-
Color coding maintained organization and structure.
-
Easier to keep updated.
​
I applied the one pager design to every aspect of the player abilities and enemy types along with their behaviors. My inspiration for this form of documentation comes from Stone Librande's 2010 GDC talk "One-Page Designs".
​
Below I have a gallery of docs that I either passed on to my team, used in presentations, and made to argue why things should work the way they did.
Traversal System
The most essential part of the overall game experience was based on establishing deep fun through the movement system. Through rigorous play-testing and rapid iteration, I worked with the lead programmer to ensure that the rolling mechanic itself was as fun as possible from the start and we continued to build from there. The fun arose from a ball that rolled in a way that defies the laws of physics which I expanded on by creating abilities that allowed the player to move in ways that are not natural to a normal ball. To keep the danger levels high, all abilities had to allow the player to distance themselves from enemies but prevent them from trying to attack the enemies.
​
All abilities needed to meet at least one of the following requirements:
​
-
It must create interesting ways to navigate the environment.
-
It should help the player narrowly escape death when used correctly.
-
It should be tied to a resource if it gives the player a strong advantage over the enemies.
​
The player was given 7 abilities and below follows a brief description of each:
*Click to navigate faster*
​
MVP Mechanics: Rolling and Jumping
Rolling and Jumping met requirements 1 & 2. Standard physics didn't fit the desired gameplay so rolling and jumping used exaggerated, custom physics to create the feeling of being fast and nimble. Because rolling is the fundamental mechanic, I decided to expand on rolling by creating additional mechanics that modified the way the player moves.
​
Weight Gain
Weight gain can satisfy requirements 1 & 2. Weight gain ability is a tool that helps the player fall faster or go down slopes faster but also slows the player down on flat ground, making them vulnerable to attacks. This ability makes it easier for players to land on small areas that require precise jumps or avoiding attacks on sloped surfaces.
​
Boost
I designed boosting to satisfy the 2nd & 3rd requirement. As the name implies the mechanic pushes the player in a desired direction with additional force. Boost consumes a "stamina" resource that automatically recharges when the player is on the ground. This restraint was created because the altered physics of the ball while in the air could allow players too possibly boost across the entire map but it also added to the desired gameplay experience by giving them only a brief chance to escape with their lives.
​
Super Jump
This meets requirement 3 while providing a great opportunity for players to advance through the level, can also back fire and leave them more vulnerable than they were before they used it. Player feedback showed that they struggled to clear certain gaps or needed just a small amount of vertical boost to make challenging jumps. Super jump was designed as a rubber band mechanic that would grant the player a chance to save themselves The Super Jump is a costly resource though as using it drains the player's ability to boost completely and reduces forward velocity to 0.
​
Redirection
This ability meets requirements 1, 2 & 3. Making it so that the player can change direction instantaneously builds off the rolling mechanic and allows players to weave between enemies. To give the player time to decide where to launch themselves, time slows and a charge builds up. When this charge is full, the player is immediately launched in the corresponding direction. If the players are not decisive in the direction they want to go, this ability can backfire on them as they accidentally launch themselves to their death.
​
Tether
Tether meets requirements 1 & 2. I created the tether to extend the rolling mechanic as a form of aerial rolling. Tethering across large gaps that enemies couldn't make it over resulted in players reporting that they felt that they barely escaped; matching the desired game experience.
Passive Combat & Enemy Encounters
In order to evoke the feeling of fear in Rollossus, I designed the combat so that the player holds no power over the enemies. They cannot directly attack any enemies. This forces the player to either run away or evade the enemies in a way that tricks them into running into deadly spike pits and bountiful lava lakes and rivers throughout the world in an attempt to reduce their numbers.
One other method that I used to create a sense of fear in the players comes from the numbers of enemies that were on screen at all times chasing the player. If players got to an area that the enemies couldn't reach having them patiently wait like sharks circling their meal or use a fake tunnel system to "teleport" closer to the player ensured that the player was never safe. Testing showed that ~20 enemies at a time kept frame-rates high and simulated the feeling of being chased by a horde without making it impossible to navigate around them.
User testing revealed that players enjoy running away from enemies more than they did attacking them when I was in the early stages of designing the combat. Using this data, I established guidelines where at least one requirement had to be met with every enemy design. These guidelines were heavily influenced by George Fan's contribution to the 2016 GDC talk, "Rules of the Game: Five Techniques from Quite Inventive Designers".
​
-
The enemy must directly affect the player's movement.
-
The enemy must teach the player to move in a new way.
-
The enemy must be able to affect other enemies.
​
My reasoning for this originates from previously established rules:
​
-
The movement should be as fun as possible, there's no point in being a ball if moving around isn't fun.
-
The enemies should always be a threat and challenging the player
​
With the programmers available and scope management being kept in mind, 4 enemies were made:
​
Basic Grunt
The grunt challenges the player in the most fundamental way: keep moving and don't get hit. The most important facet of this enemy's behavior is that the faster the player moves, the more inaccurate it becomes, but it will still come close to trick the player into thinking they had just barely missed and they might not be so lucky next time. The close calls are what make the player feel like they are just barely escaping with their lives, which rewards them with relief when they temporarily get away from them.
Projectile
The function of the Projectile enemy is essentially the same as the Basic Grunt but it's purpose is to be a permanent threat in a local area. Projectiles cannot be killed because they are stationary and forces the player to stay on the move even where enemies might not be able to get to right away or at all. While there are small sections in the map where the player can relax slightly, these enemies keep the pressure on the player if they try to hide out in one spot of the level. The side effect that players can utilize is that Projectiles hurt other enemies
​
Leech
The leech is designed to have one job: stick to the player and slow them down. The leech does not deal direct damage, they grossly damage the player's chances of surviving because they can't roll fast or consistently. Communicating feedback regarding the Leech's behavior came naturally as when something sticks to a ball its rotation is disrupted. To keep the leech from being over powered and resulting in the player dying every time it made contact, I designed the leeches to crumble off after a set period of time. Because players are always on the move, the players stated that they thought smashing them against the ground is what hurt them.
​
Twins
The Twins' main goal was another simple behavior: trap the player within a "net". Their behavior forces the player to realize that rolling sometimes won't help them escape a situation. The play could use a boost to try and evade them sideways but will almost always result in failure. I designed the Twins to have the capabilities of stretching incredibly far apart combined with predictive behaviors so that the player will almost always have to resort to vertical movement to survive, teaching them that they should explore more options to evade enemies.
Source Control &
Project Management
Working in Unreal with multiple team members proved to be a challenge at first. We discovered quickly that people could not work on the same things at the same time due to the binary file structure Unreal uses. Frequent mishaps resulted in people loosing work that had to be recreated thus causing most of our burn down charts to get skewed. A work around for this was the creation of a check out sheet in Google Sheets. If people worked on something without checking the item out, they had to accept that their changes were going to be over written. Once the team got fluent with the checkout sheets, our communication and productivity improved drastically and allowed us to work well under pressure for deadlines like the Independent Games Festival and the official release.