Cyberheisters is a first-person shooter – set in the city of Cyberpunk, a city that is booming with technology. The players must navigate the tightly packed city in acts of thievery to complete contracts given to them. These acts of thievery are the focus of the objectives – for example, find the code to unlock the vault, or defend the bank for X number of minutes whilst the money is being extracted. These maps are linear, much like Vermintide and Left 4 Dead. Players will be met with an opposing force – known as the Lethal Reactive Force – that will attempt to disrupt the player’s progress by fighting tactically in large waves. Within the force are special units in the game – enhanced enemies that can bring a unique gameplay twist that adds an extra layer to gameplay.
This piece focuses on the prototyping stage for Cyberheisters. Paper prototyping is a cheap and effective method to test gameplay features and mechanics to see how they match with the designer’s expected user experience outcome. This playtest in particular focused on gameplay feel and mechanics:
- How strong will our units be?
- Are the special units interesting?
- At what rate should enemies spawn?
- Do they spawn at a rate that the designers expect them to?
- Can they become overpowering?
- Do players feel good from overcoming these hurdles?
- At what rate should chests spawn?
- Do they spawn consistently to supplement the player’s progression?
- Can the player have too many items?
- Are some items too strong?
Forming these questions are important in streamlining data that is collected in each playtest. It is important to focus on one question at a time, as to avoid any dither in the results. Three playtests were conducted for each iteration with a total of nine playtests performed. The final ruleset and materials required to play the game are below; a brief summary of the prototype will be explained in the following passage as well.
To see all versions of this prototype, please read the master document – other materials will be necessary as well (supplied at the bottom of the page to avoid clutter).
Overview of the Prototype
With these questions in hand, it was time to create the prototype. To try to simulate the FPS environment, ideally the player should have some form of interface to interact with. Additionally, a list of all possible actions in the game have been listed (See: documentation above). Only the necessary actions for testing have been addressed given the questions that need answering.
The paper prototype is a two-player game. One person plays as the player, whilst the other person plays as the game master. The player starts with a character sheet, that acts as the interface for this game. They are also presented with ten rooms which they are tasked with traversing through. For each turn, the player may choose to move to the next room or scavenge the area for consumable items.
Enemy encounters are calculated per-turn, where each turn simulates an arbritrary duration of time that players would take to perform actions. If an encounter should occur, the game master places enemy units into the player’s interface, where the assortment of units that are being spawned are predetermined by the spawn tables.
The positioning of enemy units are important to the player; some items that can be acquired have a direct influence on the performance of such tools (such as explosives, that can attack multiple enemies if they are clustered together) – it is up to the game master to determine how the actors should be placed.
Battle is determined in a similar way to DnD; players choose who to attack, roll for a hit or miss, then roll for damage. The relevance of the Companion is then introduced. This actor acts as a second character that the player can manipulate. Despite being completely invulnerable to attacks, this unit can only perform basic actions – they are not capable of using items; they can only attack.
Reflection
- Finding a good middle ground for balancing was a big issue – it may work for some runs but then for others, a stroke of luck can make some moves become too overpowered.
- Finding playtesters can also be a trouble too, especially so when a single play session can last up to 40 minutes, making it a lengthy process when only minor tweaks are necessary. Due to this, oftentimes modifications were made on the fly.
- Translating these real-time commands onto a paper form was an interesting challenge; rather, a turn-based approach was taken instead. This may not have been necessarily the correct choice – experimentation is required.
- For future work, consideration would be taken into simplifying the ruleset even further – participants expressed that it was daunting and sometimes intimidating to be faced with pages of text when trying to understand the nuances of a game. Oftentimes, players had to re-read the rules before understanding them.
Appendices
Cyberheist – All Playtest Prototypes
Cyberheist – Overview + Prototype MASTER
Character sheet used ONLY for Prototype 1v1
Hoyung Ling 
Leave a comment