Roll
Roll is a first person arena shooter, where the player rolls dice and crashes out. It is themed around the experience of emotional spirals, which it conveys through the analogue of getting mad while rolling dice.
With each dice roll, the player is given the ability to sway the balance of blue and red NPCs, which represent supportive and destructive thoughts. As destructive thoughts build the player will step closer to a crash out, their vision becoming distorted, allies seeming like foes and the dice playing games outside your control.
The game took inspiration from shooters such as Devil Daggers and Superhot, with additional visual inspiration from the works of Junji Ito and Moebius.
Roll was created during my time in the CG Spectrum Gamechanger Academy program and was created under the mentorship of Lauren Temos aka. T-Dog eXtreme.
Engine
Unreal
Role
Solo Developer
Duration
3 Months
The Brief
The goal of this project was to create a game which focused on creating a strong atmosphere and practice using top down design, working from the high level concept of an emotional spiral and designing mechanics and systems to fit.
Randomization System Design
One of the largest challenges I faced during the production of Roll was balancing the player experience with the roll of the die. In this break down I’ll go into the initial research into some pain points for randomness in games, the first solution that I chose and its issues, and then the final in game system.
Issues with random number generation (RNG)
One of the early decisions made for roll was that I wanted the experience to center around making guesses on the roll of a die. Considering how contentious "RNG" can be in games, I looked into some factors that tend to be pain points for players. This led me to make a couple immediate realizations:
-
Prioritize input randomness over output randomness. Input randomness is when the RNG is done before the player takes an action. Which, to generalize players prefer being dealt a random set of options and then strategizing on how they can use that set. Output randomness however is when a random roll is made after a player action is taken, which can lead to frustration if not done correctly.
-
Your brain lies! While I might design for fair and realistic probability, the perception of what we expect from probability can differ greatly from reality. This means that when considering a system, I need to be able to tweak probabilities using methods such as fixed limits (after X times, something always happens aka. pity) to ensure that the RNG feels fair to the player. This is especially important as dice have a tendency to feel streaky (rolling multiple low/high values consecutively).
Roll a random number
Generate a guess pool, with X options being correct
Generate a list of buttons, tagged if correct or not
Player selects an option, the dice is rolled and whether they are correct or not is revealed
Take 1: Pre-Rolled Guess Pool Generation
My initial design aimed to utilize a pool of guesses to control the randomness of the die. With each roll the player is presented a list of generated options, the amount of which grows with each stage.
This gave an adequate amount of control over the true probability of the player guessing correct. By varying the number of options presented and the amount of correct choices I could effectively set the probability of getting it right or wrong. Issues arose however when trying to implement a fixed limit, as the only way to ensure a result was by rigging the guess pool to contain only correct or incorrect guesses for the pre-determined roll.
Through testing, players would often go on streaks despite the variability in probability determined by the guess pool. This consequently caused a number of issues:
-
Pacing of stages was unpredictable, as going on a large streak would either put the player in an overly advantageous or difficult position. This resulted stages lasting a frustrating amount of time or no time at all, which left players with extremely varied experiences.
-
Fixed limit systems were too evident to the player, as forcing the guess pool to be of a single type became clear once the roll was revealed. For example, a pool of “Evens”, “Greater than 4” and “6” points painfully obviously at the answer being 6. This broke the illusion of rolling a die.
One upside of this iteration however, was the realization of how much I could get away with when manipulating the guess pools. While entire pools of correct choices were obvious, having 50% correct options or entirely incorrect pools slipped past player perception more than anticipated.
Take 2: Varied Guess Pool with Output Randomness
From this, I went back to the drawing board and determined a new system, which would ideally allow:
-
More direct control of the players odds
-
The ability to apply a fixed limit, progressive probability (making it more or less probable based on conditions) or any other weighting technique to improve player experience without it becoming overtly obvious
-
Direct manipulation of the result if desired (e.g. The die cheating, rolling a 12 on a 6 sided die)
The new system instead populates the guess pool with a list of randomly selected options and then the game works out if the option chosen is correct post guess. This directly address the issues I had with the previous system, allowing me to:
-
Direct and easy access to manipulate the probability of rolls, just set a percentage along with any required modifiers. This allowed control to:
-
Vary probability based on the state of a stage or stage number
-
Set fixed limits for being right or wrong, odd or even and high or low
-
-
Any answer can be right or wrong and then visually communicated as such. The player won’t think into why a number is chosen when they have the pre-prescribed expectation that a die is random.
The result of this process was a die that felt life-like, while ensuring enough flexibility in implementation to have true control over the game state to tailor the player experience.
Generate a pool of options to present to the player
Player selects an answer
Probability of being correct is calculated based on stage, pity or other modifiers
The game determines if the selected answer is right or wrong
Blueprint for determining dice results
Game Clarity Issues and the Process to Fix Them
Another persistent issue that Roll had during development was communicating the game state in a clear and concise way. A good example of this is the game’s progression system. Roll is broken into 6 distinct stages, each representing a part of an emotional spiral. At set NPC distribution targets (e.g at 20% red NPCs) the game transitions to the next stage. This in theory was good for the experience I was aiming to craft, however it became problematic when trying to communicate it to the player. In this section I’ll break down the initial solution I jumped to, the process I used to explore the problem space more effectively and the current in game solution.
Jumping the Gun
My initial strategy to tackle the issue at hand was to form a problem statement and construct a solution from it. Armed with the problem of “It is not clear that the density of NPC types causes stage changes” and a number of constraints, I got to work. These constraints were aimed at guiding my solutions toward my vision for the project, they included:
-
I didn’t want it to be a UI element. I thought it would detract from the player experience having a numerical or scalar tracker on screen.
-
I wanted the balance to be depicted in solid colors, with similar theming to the rest of the game.
With all this sorted, the solution I landed on quickly was to have a floating orb in the sky, split between red and blue. The percentage the orb is filled with each color represents the percentage of that type of NPC in the scene, scaled by the aforementioned density targets (i.e. if the target was 20 precent blue, the blue side is empty when at 0 and filled when at 20). When it fills completely with one color, the stage would transition. While this technically fitted the problem I had set out to solve it was not the best solution. Players didn’t look up at my floating orb, there was no visible connection between the NPCs changing and the orb, and having two colors displayed on the orb mean that the players goal in each stage was ambiguous.
Red and Blue NPCs
Floating Orb
Group Brainstorming
Full process layout
There Must be a Better Way
Upon reflection and discussion with my mentor, it became clear that I had skipped over a few essential steps in the design process. I hadn’t considered the potential side effects of the solution, alternative solutions nor considered the effort it would take to develop compared to other possible options.
They recommended that I hold a workshop with some fellow designers to assist with solving the problem. They guided me to hold the group session and then rank suggestions based on how well they fit the vision and the effort they would take. This would assist with culling ideas that may be too time consuming or too far out of scope. This led to me forming the following process:
-
List out issues that are currently present
-
Write down as many solutions for as many problems as possible, making sure to track that each problem is addressed by a solution at least once
-
Write down any new problems these solutions could create
-
Run a group session to brainstorm!
-
Present fellow designers with the problems, without the context of proposed solutions
-
Post-session, rate each idea on:
-
How well the solution fit with the vision for the design
-
How difficult it would be to enact that solution
-
-
-
Sort the new solution pool! Matching suggested solutions with my own or creating new solutions born out of group suggestions
-
Filter out actionable solutions, with time and effort estimates
The Results
Going back to the drawing board I presented myself with the same problem, “It is not clear that the density of NPC types causes stage changes”. This time around I came up with two solutions:
-
When an NPC changes type, they spawn a floating ball that flies to the orb in the sky. When it makes contact, the orb changes color to reflect the new NPC distribution
-
Add a UI bar to the HUD which scrolls along a gradient. When NPCs change, it shifts toward one end of the gradient.
An immediate issue the first solution raised was the game was beginning to use a lot of “orbs”. The current iteration of shooting also used a basic spherical object, so there was the potential that these elements could become confusing in tandem.
The same problem was then presented to a group of 3 fellow designers, without the context of my prior attempts at solving it and without my above proposed solutions. This resulted in the following suggestions:
-
Having a more clear transition when NPCs change state, so it is clear to the player that these transitions are happening
-
Add a meter to the UI that fills up as the stage progresses
-
Add a vignette to the screen that darkens as the stage progresses
-
Clearly state the conditions in which the stage changes occur so players can be on the lookout for them
From these solutions, the 4th one strayed outside my vision for the project (I would eventually change my mind on this). The others however fit what I wanted for the project and were reasonable to do technically. Solution 2 and 3 also backed up my second solution, giving further validity to the idea.
The group solutions and my own were then combined into a final pass, consolidating them into a final actionable plan:
-
Implement a UI element that fills up/down based on the percentage of each NPC type. The hope was that players would associate the changing of NPCs with the UI on the HUD.
-
Add a transition to NPCs, to show when they are mid transition between states.
The other proposed solutions where kept in mind if the proposed solution didn’t work, but where lower in priority as they would take more time to prototype or could potentially raise further issues.
The final version of the project ended up including all the solutions brainstormed above as I tackled the aforementioned problem as well as some other issues that arose in development.
Added UI Element
Added Vignette
A Crash Course in Unreal
More coming soon!