| Role: | Game Designer and Scripter |
| Team Size: | 3 members (with a Level Designer and Creative Director) |
| Dev Time: | 5 months (PC VR Arcade version) + 8 months (Standalone VR version) |
| Engine: | Unreal Engine 4 |
| Genre: | VR Multiplayer FPS |
| Players: | 1-4 players |
Gameplay Videos
Game Systems
I share the design credit with the Creative Director and scripted / programmed all aspects of the game.
Below, I highlight few game systems with their design journey and implementation choices and the difference between the Arcade vs Consumer version of the game systems.
Consumer Version
Design Goals
As the game is meant to be accessible to new players, the main goals were to
a. Introduce new gameplay challenges over the whole course of the game
b. Introduce classic enemy archetypes from the zombie genre and translate them to be fun in Virtual Reality
c. High replayablity for competitive players
Game Structure and Flow
Design Goals
a. Average level playtime of 5-10 minutes.
b. Add 4 gameplay levels as an initial bundled version with the Omni One product.
c. Add level-specific leaderboards for replayablity.
Implementation
The core game flow involved
– Main Menu
– Multiplayer Lobby
– Level Selection (voting process)
– Level Intro sequence with a voiceover and imagery
– Level Gameplay
– 3 level zones with a time limit per zone, before which the zone is contaminated
– Boss fight in the final level zone for a memorable conclusion
– Score Summary and Leaderboard submission
– Return to the Multiplayer Lobby
Enemy Design
Archetypes
Added 7 enemy types that allowed for varied gameplay challenges to fulfil the genre fantasy over the course of 4 levels, with one special enemy added in each level. The enemies were implemented with unique behavior trees and animation blueprints. The enemy health values were stored in Data Tables and accessed based on several variables: Enemy Type, Player Count, Level Number.
| Enemy Type | Special Behavior |
|---|---|
| a. Zombie (Standard) | Target the closest player with less than ‘n’ current enemies. Can climb up / down level areas. |
| b. Crawler | Crawl towards the player and stand upright and sprint when in specific range of the target player |
| c. Exploder | Slowly move towards the player and when in specific range range, sprint to the player and explode dealing AOE damage. |
| d. Shreaker | Spits out poisonous projectiles from range at a higher vantage point |
| e. Brute | Tank unit that charges towards the player and does high melee damage, stops and restarts. |
| f. Juggernaut (Standard) | Boss enemy type that has both close, medium and long ranged attack patterns. Close range: Melee Attacks Medium range: Jump to do AOE Damage, Charge towards the player to get to close range Long Range: Throws a rock projectile that does AOE Damage |
| g. Juggernaut (Infected variant) | Reskinned with visual improvements to the mesh material and particle effects for all attack move sets. |
Wave Spawner Data Table
In the wave spawner data table, each row was had wave spawn information for each level of the 4 levels.
For each level,
a. There are 3 wave entries, one for each of the 3 gameplay zones.
– Bot Class : Sets the type of zombie to spawn in this entry
– Spawn at interval : Allows for the enemy type to spawn in every ‘n’ zombie units as a default interval
– Spawn at specific time array : Allows for a one-time spawn of a zombie type after ‘n’ units. Multiple such one-time spawn times can be set in the array. This allows for special zombie units such as the Exploder to spawn in at the earlier of the level for a memorable effect, in addition to the regular interval set.
– Spawn at once: This allows for multiple enemies of a type to spawn in at once, for more intense situations.
– Max amount of type : This allows special zombies types to stop spawning after a certain number were spawned in.
b. Additionally, there are wave specific variables that can be adjusted.
– Max bots alive at a time : This was necessary to limit the total number of zombies on screen for both level specific difficulty balance and optimization reasons.
– Time Limit : This set the gameplay time in each zone before which, the current zone becomes contaminated and players are force to move to the next zone.
Weapon System
Melee System
Melee Damage: Balancing the feeling of being too powerful vs powerless
We were faced with the challenge to balance the experience between one melee swipe ending up killing all zombies VS having to keep swiping several times which felt less powerful.
Solution:
a. The Melee swing deals max damage to the first 2 zombies hit i.e. one hit kill which feels satisfying and powerful
b. Subsequent hits deal lesser damage and a stagger which allows the zombies to surround the player and overwhelm them in time if they don’t move.
Weapon Types
Introduced 9 guns and 3 melee weapons.
As the player had a weapon in either hand, that allowed for varied weapon combinations for interesting gameplay.
Created a system to introduce these weapons in the form of Weapons Caches which held two weapons.
Each weapons cache is spawned in, from a random selection of spawn locations at runtime. This randomization encouraged player movement and replayablity due to the map feeling different every time.
Weapon Mods
As there were only 9 gun types and even less in the initial levels, when players encountered the same weapon type they already had equipped, there was feeling of disappointment.
Development time didn’t allow for weapon variations with attachments to add more variety to gameplay within a specific gun type.
I added in a simple mod system to give players reasons to find variations of weapons of the same gun type to adjust their playstyle. This greatly affected the player experience even with the limited 9 gun types.
Ammo System
Design Goals
As the arcade version had infinite ammo and automated weapon upgrades, we wanted to move to a more consumer focused design for the Omni One version.
a. Ammo as a scarce resource to introduce tense gameplay when running out of ammo.
c. Balance the effectiveness of various weapons.
c. Encourage player movement in the map to look for ammo pick up locations.
d. Add simple and intuitive pick-up interaction choices for the player.
Failed Iterations
a. 3 ammo types (Light, Heavy and Special) to use for 9 guns.
This required adding the information of 3 ammo pools, one for each ammo type and the need for them to be communicated to players on the HUD and communicating which weapons required which ammo type. This ended up being complex to players during gameplay, which resulted in some player frustrations.
b. When players reloaded with the magazine having some ammo left, the ammo would be lost as each reload consumed a magazine.
This led to players who planned ahead with early reloads before an encounter would be punished for it and affected novice players with lesser ammo due to incorrect reloads. Additionally, this resulted in players having to run around for ammo more than was desired.
Final Design
a. The magazine pool stored on the player for each weapon was changed to be stored as an ammo pool.
This way, early reloads could prevent players from losing collected ammo. This led to better pacing of gameplay due to the collected ammo lasting for a longer duration and kept players in combat longer.
e.g. Reloading an Assault Rifle with 5/32 left in the magazine only consumed a max of 27 (32-5) ammo to refill it and a minimum of how much was left in the ammo pool.
b. We simplified the 3 types of ammo boxes to a generic ammo box which refilled the ammo pool for a specific weapon. Now, players felt that the system was more intuitive and any ammo box always refilled the weapon’s ammo pool to it’s max.
e.g. Picking up an ammo box with a specific hand that held an Assault Rifle, refilled the ammo pool stored for that weapon to it’s maximum of 256/256 and also the currently held weapon’s magazine.
Interactive Object Spawn Manager
Added an interactive object spawn manager that was level specific, which allowed customizing the spawned number of Weapons Cache, Ammo Cache, Health Pick-ups (Small, Med and Large) and collectibles. Additionally, to allow for level specific weapons, the individual weapon types and number that could spawn in the level was set here. This allowed certain weapons to only spawn in later levels to give a sense of progression.
Endurance Mode
Design Goals
a. Add a challenge run mode for competitive players to test their endurance
b. Add randomized perks that give players reasons to play again
c. Add a separate leaderboard for competitive players
Level Perks
I came up with few options for perks that would allow for interesting playstyles and gave associated bonuses to make them compelling. Once the player completed a level, they would be notified of the perk applied to the next level.
Initially, there were plans to have a lot more gameplay variation to add replayablity. Here is an example of an initial design, some of which were prototyped.
However, the scope of the feature was reduced to a more simplified version which still had a focus to encourage different weapon use.
Arcade Version
Design Goals
As the game is meant to be accessible to all players, the main goals were to
a. Create the sense of being overwhelmed by lots of zombies and trying to overcome them and live up to the genre power fantasy
b. Keep the player mechanics and upgrade systems simple and understandable to non-gamers
c. Vary the gameplay experience at short intervals to keep the experience memorable throughout
d. Ensure the scoring system encourages competitive play using leaderboards
Enemy Design
Basic zombie archetype
Used a single zombie archetype in large numbers on screen to create the genre power fantasy.
Zombies are pooled to reduce the cost of spawning and destroying actors
a. Players could run through zones to trigger enemy spawns and run away to a different zone. This caused imperfect gameplay pacing and optimization issues. So, adding pooled enemies added to ensuring the zombies would be reallocated near players when necessary.
b. However, this added an additional cost of ensuring proper re-initialization of zombie attributes, associated behavior trees, animation states and optimizations such as ticking on the Actor and Actor components such as skeletal mesh (animation), and widget components
Zombie player targeting with Behavior Trees
a. Zombies immediately target the closest player but have several conditions on which they switch to a new target
b. At certain time intervals, they check to find a player greater than “x units” closer than its current target while having a line of sight to them
c. They also switch to a different target when shot by another player who is within a certain range
d. After spawning, if a zombie is outside a certain range of a nearby player for a duration of time, it gets de-spawned and is returned back to the spawn pool to be spawned in a better location
Zombie Spawn Zones
a. Each zone keeps track of players and zombies currently within the zone
b. Spawn rate of zombies is determined by player count, zombie count with a flexible structure variable with an array of rates that are pre-setup
c. The last 20s of each half defaults to the max rate for active spawn zones and players are given Dual Miniguns for an intense finish to the round
Weapons System
Weapon Upgrade System
I implemented an upgrade system to allow players to automatically switch their weapons to more powerful ones up to 14 weapons based on certain conditions – either Time based or Kill based.
Time-based vs Kill based weapon upgrades for players
We tried both systems but decided that the Kill based system offered an improved player experience after playtesting.
Pros:
a. Increased competition amongst players in a multiplayer session to reach the max weapon upgrade cap
b. Added replay value to reach the final upgrade.
c. The upgrade pacing was determined by players and they loved the increased player agency.
Cons:
Bad players were stuck with a weapon for far too long before which they could upgrade their weapon to a better one.
Solution:
This required us to have dynamic detection of player performance and adjust the required kill thresholds for all weapon upgrades. So, an easy progression tier was added that would give the novice players a similar power fantasy.
Handling weapon progression edge cases
Kills past the required number for the current weapon upgrade ended up counting towards the next weapon and undesirably reduced/skipped the usage of the next weapon entirely.
We chose not to count the additional kills with a previous weapon, past the required amount for the present weapon upgrade. So kills from a specific weapon only count towards weapon progression if the player is currently holding the same weapon used for the kill.
i.e. Let’s say a grenade launcher kills a group of 10 zombies.
If the kills required for the next weapon upgrade is only 5, the weapon upgrades to the next one but the 5 extra kills do not count towards the next upgrade.
Solution:
a. This required logic for the enemies to keep track of what weapon and player killed them
b. The player state checks whether the weapon used for that particular kill has already been upgraded and if so, ignores the increment request.