Lukas Čižauskait ė
Game Designer
System
Personal
8 Weeks
Unreal Engine
TARGET AUDIENCE
KEY FEATURES
PLAYER EXPERIENCE
A top down twin-stick shooter that was created for experienced genre players. The game is targetted towards players who are competitive and skill expression oriented.
Because the target audience are competitive and skill expression oriented players, the design included:
-
A simple score and multiplier system;
-
Weapon and movement abilities that encourage aggression and tension;
-
Simple VFX and effects to reward the player’s aggression;
-
A leader board for sharing scores.
When creating an experience dedicated towards a certain audience, it’s important to establish what key elements to focus on.
The design prioritised these key requirements:
-
To facilitate competition, there should be a way to track progress compared against others;
-
To facilitate skill expression, progress must be achieved through higher skill;
-
To facilitate a power fantasy, the look and feel of the game should portray brutality.
DESIGN PROCESS
During this project, key skills developed:
-
Extensive research on game features;
-
Concepting with a clear player experience in mind;
-
Balancing player abilities;
-
Creating and balancing enemies;
-
Using blackboards for enemy behaviour;
-
Creating simple debug tools;
-
Play testing with a target audience in mind;
-
Iterating based on play testing feedback.
The project followed a simple structure:
CONCEPTING
RESEARCH
IMPLEMENTATION
ITERATION
CONCEPTING & RESEARCH
PROPOSAL
The proposal that was set after concepting was further defined using a feature spec document to break down the intentions and implementation of features.
Sketching
CONCEPTING
INFLUENCE ON DESIGN
To create a strong and concise concept many sketches were used for quick definition of mechanics and paper play testing.
Early sketching on paper allowed for:
-
Quick idea exploration which can be easily discarded;
-
Defining a simple core.
Core validating
CONCEPTING
KEY FEATURES
INFLUENCE ON DESIGN
To make sure that the core will work in engine, it is important to validate the mechanics in comparison to the player experience. For this a Zubek model and Onion Diagram were integral.
These diagrams helped with defining:
-
Possible gameplay interactions;
-
A clear core for the game;
-
Player experience to look out for during testing to validate them.
Furthermore, the diagrams used for breaking down the workings of the features helped implement them into the engine.
Core validating
KEY FEATURES
INFLUENCE ON DESIGN
Research was used during the entire development process to gather information about specific features and how to make them clear or interesting. To further define mechanics that lead to experiences - Zubek models and Onion diagrams were used.
RESEARCH
As one example, Hotline Miami was used to explore satisfying brutality and how it was achieved. The findings helped define the score appearance and VFX of the game.
The findings included:
-
Flashy VFX and Score Showcase;
-
Brutal difficulty results in a balance of frustration and satisfaction;
-
Quick reset allowed for continuous action.
IMPLEMENTATION
IMPLEMENTATION
Enemies
As an example, the shooter enemy works as follows:
-
Loads/Reloads the gun;
-
Moves in range of the player;
-
Fires amount of bullets and runs away to reload.
There is an additional behaviour on a spline that was used in testing, but it was found that a more dynamic movement for the enemy was more interesting to predict.
The enemies were implemented using a simple behaviour tree that determines the behaviour of the enemy using an enumerator variable.
Player Abilities
IMPLEMENTATION
The player has two abilities: a shotgun and a powerful dash.
When implementing the shotgun, it was made to be a child of an already made preset for weapons within the template with a short range and high knock back.
For the dash, here is how it works:
-
First, the player dashes, setting their invincibility frames;
-
A collision sphere that is otherwise inactive - activates to detect enemies in the radius.
-
If an enemy has been detected and they are red - kill instantly, increase multiplier, reset dash cool down. Reset collisions.
-
If not - activate cool down and reset collisions.
Debug
IMPLEMENTATION
Using a debug menu helped test abilities and different weapons.
The menu was implemented using simple UMG widgets and exposing variables to the different buttons.
In retrospective, an excellent addition to the menu would have been specific player movement variables and a save button to collect different versions of the player’s movement to test it in different scenarios. This is the approach I now attempt to take in future debug tool creation.
PLAYTESTING & ITERATION
Overview
INFLUENCE ON THE GAME
Play testing influenced:
-
The character controls and metrics;
-
Ability cool downs, knock back and score balance;
-
Ease of use within UI elements;
-
Recognising and reducing pain points.
PLAYTESTING
Play testing was used early on to validate both functionality and fun of the game with relation to the target audience. Within the video you can see the weekly stages of development.
ITERATION EXAMPLE
ITERATION
Iteration would occur after enough evidence had been gathered to prove a conclusion. Whether it be about the scale of the player or speed of an enemy - the goal was to gather at least 3 points of similar feedback from players within the target audience.
During multiple play tests a pain point kept coming up for the player: having to slow down and hold the trigger to line up the dash.
This was a break in the flow of the player, especially when just wanting to smoothly flow from enemy to enemy.
Iteration: instead of having to hold down the trigger to activate the dash, instead the player would only have to tap the button.
RETROSPECTIVE
The creation of this game had taught me a lot about initial concepting and layering features on top of a strong core. This directly influences all of my projects to this day as I use the same strategies of keeping track of gameplay layers and their effects. Within the implementation I found myself striving towards clear polish and early polish due to time constraints.
If I were to tackle this project again, however, these would be the main changes:
-
I would experiment more within the engine itself when simple features come to mind as knowing the constraints could’ve sparked new ideas;
-
I would have researched with clearer questions written down and relate them to either the exploration of mechanics or the player experience;
-
I would have made my own movement for the character rather than relying on the Character Component present in Unreal for further control of the combat.
-
Added more debug tools and variables.