Cyberdrome

Game Description:

Cyberdrome is a fast-paced, first-person cyberpunk action-arcade game in which the player uses a high-tech sword to compete in an underground fight club where people risk their lives for entertainment and fame.

Development Specification:

  • Role: Generalist Programmer/Sound Engineer
  • Engine: Unreal Engine 4.19.2
  • Development Time: 5 Months
  • Team Size: 15
  • Number of Programmers: 5
  • Published on Steam: Jan 1, 2019

Screenshots

Cyberdrome_ScreenShot_04
Cyberdrome_ScreenShot_02_UseThis
Cyberdrome_ScreenShot_05
Cyberdrome_ScreenShot_06
Cyberdrome_ScreenShot_07
Cyberdrome_ScreenShot_01

Responsibilities

  • Helped architect a modular design for the blueprint classes.
  • Refactored and migrated assets from the prototype project (uses UE4 4.17.2) to the production project (uses UE4 4.19.2).
  • Built a modular enemy system with interchangeable weapons and body parts (robots).
  • Built the functionality for a weight-based enemy spawning weapon, Area of Effect charged blaster weapon and a grenade launcher weapon.
  • Integrated VFX assets provided by artists. 
  • Built a telemetry system that stores gameplay data (json file).
  • Built a death visualizer that uses the json output from the telemetry system to visualize the player death locations in the UE4 editor as 3D coordinates.
  • Built a save game system that uses the gameplay data from the telemetry system to drive offline leaderboards.
  • Recorded (Sound Engineer) voice lines with the help of a voice actor. Created foley effects (Sound Design) for enemies. Created dynamic sound mixes in UE4.
  • Integrated footstep sounds and camera bob behavior.

Refactor and Migration of Assets

During the prototype phase all the player functionality was written in a single blueprint actor without thoughts of parallel working since the team had only a single programmer when they began. Once the prototype was approved, more programmers (including me) were assigned  to the team and the first task was to refactor all the code and move to a newer version of UE4 (4.19.2). Due to time constraints, completely beginning from scratch for the production project didn’t seem to be a good idea. Instead, the blueprint code base was refactored and the functionality was divided into components to enable smooth parallelism within programmers.

  • Created the target folder structure and document it.
  • Refactored the player blueprint and divided its functionality into components.
  • Communicated with the design and art team to choose the assets that were still needed from the prototype project.
  • Migrated the assets that were still needed and resolve the references.
  • Data drove the player blueprint using data tables.

Note: The Unreal Engine Blueprint below is interactive. Please feel free to zoom into individual aspects by scrolling the mouse. Hold right mouse and pan to move around. Zoom out to view the entire thing.

Enemies and Weapons

Given the time constraints and number of programmers, we came up with the idea to make the enemies modular such that weapons and body parts could be replaced easily. Since all enemies were robots, this system also helped the artists by decreasing the number of models that had to be manually created. The enemy data table contained the variables like speeds for each state, type of enemy, weapon carried, etc.. This made it easier for the designers to try out different variations and easily increase the variation among enemies.  

  • Built the Chaser class enemy and its weapon: Area of Effect charged blaster
  • Built the Summoner class enemy and its weapon: Weight-based spawner
  • Built the grenade launcher for the healer class enemy.
  • Integrated VFX assets provided by artists. 
  • Created foley effects and integrated them.

Chaser

Chaser is an enemy that charges at the player when it’s out of it’s weapon’s range. It has a charged blaster weapon that deals Area of Effect damage. It’s a state based enemy with the following states:

  • Alert: Moves towards the player’s position when player is not in line of sight (LoS). If player is in weapon range, transition to attack state. If player is in LoS and out of weapon range transition to wind-up state.
  • Attack: Randomly move to location around the player and start the attack behavior on the weapon. Repeat as long as player is in weapon range.
  • Wind-up: Prepares to charge when player is in LoS. Starts the wind-up VFX and chooses the location to charge towards. Once, the delay is done it transitions to the charging state.
  • Charging: Charges (uninterruptible) towards the player and deals damage with knockback to the player on hit. Turn on the charging VFX on start. Transitions to Cooldown state on reaching destination.
  • Cooldown: On completing the charge, the chaser transitions into a cooldown delay. All the charging VFX are turned off in this state. 
Chaser Behavior Tree
State Management (Blueprint)

Note: The Unreal Engine Blueprint below is interactive. Please feel free to zoom into individual aspects by scrolling the mouse. Hold right mouse and pan to move around. Zoom out to view the entire thing.

The weapon used by the chaser is a charged blaster that causes Area of effect damage. It has 3 stages: pre-fire delay, attack and cooldown. During it’s pre-fire delay the movement speed of the chaser is reduced. The blueprints for these behaviors are in the tabs below.

Summoner

The summoner is an enemy that spawns a limited number of enemies during its lifetime. This enemy uses a spawning weapon that chooses the enemy to spawn based on weights specified by designers. If the player kills the summoner before it spawns all it’s enemies, the score for the kill is calculated as a multiple of the remaining spawns. This weapon is also a 3 stage weapon that has a pre-fire delay, attack and the cooldown. This enemy uses a common behavior tree created for all enemies except chaser. 

Behavior Tree

Note: The Unreal Engine Blueprint below is interactive. Please feel free to zoom into individual aspects by scrolling the mouse. Hold right mouse and pan to move around. Zoom out to view the entire thing.

Healer

The healer is an enemy that provides a large health boost for the player when killed. This enemy uses a grenade launcher and uses the common behavior tree shown in the summoner section. Each grenade has an AoE damage with a knockback. This weapon uses projectile physics to predict the launch angle to attack the player. The launcher is a simple fire and forget weapon with a fire rate to delay individual shots. 

Telemetry System and Save System

The telemetry system was made to track playtest metrics and to find ways to improve the game using these metrics. We tracked a long list of metrics that include number of slash kills, dash kills, player death locations, number of enemies when the player died, etc.. This was made pretty easy because we had an event manager actor that contained the registry of all event dispatchers in the game. Binding to most of the events ensured tracking of telemetry data. Once the playthrough of a level is finished, the game writes all the data collected into a json file. 

Using the data generated by the telemetry system, I created a death visualizer that runs in the UE4 editor. This tool reads the death locations from the selected json files and places cubes in the world to represent death locations. This was used by designers to iterate on their levels. 

Initially, this data was only being tracked for gameplay iterations. Later into development we decided to display this data at the end of the level to show how well players did in each level. I implemented a save game system that stores this data sorted by total score per level. This data was used to rank the player for each level and this rank is displayed in the level select screen on the offline leaderboard. 

Personal Postmortem

Team Postmortem