DarkShot Arcade
- Team Size: 1
- Project Duration: 2 Months
- Engine: Unreal Engine
- Platform: Windows
Project Overview
Twin stick shooter build on top of a premade framework in Unreal Engine. Requested deliverable was a twin stick shooter which adhered to the preexisting technical architecture.
Responsibilities
- Creating new game mode on top of existing framework
- Creating character on top of existing framework
- Creating weapon on top of existing framework
- Creating enemy on top of existing framework
Concepting
The game mode was inspired by the game Darkwood. Particularly, its nighttime home defense sections. The player experience during these sections is scary, claustrophobic, filled with a strong fear of the unknown.
To recreate this, I heavily limited player information via darkness, only providing a small flashlight and passive point light around the player for information.
Technically, I first experimented with various methods of implementing vision obfuscation. Starting with a shader combined with a render target to hide everything outside of the player’s LOS.
I scrapped this as it required too much overhead for the project, settling for a simpler solution which fit with the scope of the project. That being a directional light for the flashlight and a point light for the passive vision cone.
After testing, feedback was positive, so I proceeded with gameplay sketching to create the core gameplay loop, which I defined in a 3-step cycle listed below.
See: Players see enemies spawn before they become hidden by the darkness.
Scout: Player tries to find and protect themselves from the approaching enemy.
Shoot: Player finds enemy or the enemy finds the player and combat occurs, with either the player or the enemy dying.
To support the player experience, I gave the player a pistol with a cooldown between shots. This was done to make the player feel vulnerable and underprepared.
For the main enemy, I took inspiration from the Weeping Angels from Doctor Who. Specifically, the core idea of an enemy who responds to being observed, leading to the creation of the Crawler. An enemy which slows down while observed by the player.
To tie this all together, I created a core gameplay sketch combining all elements I had designed and combined them into snapshots of gameplay to showcase a full gameplay loop. With a positive response from stakeholders, I proceeded with implementation.
Recreation of DarkWood darkness within Unreal Engine, using directional light for a flashlight combined with a point light inside the player to simulate the passive vision around the player from the source game.
Implementation
For implementation, I started with the flashlight. I decided to separate the systems using math to create a cone to cover the visual area of the flashlight. Within this cone, I send a message to hit actors that they were visible, slowing down the Crawler while they were visible.
The Crawler would receive this message, write it to it’s blackboard. Which would them cause a switch to be triggered in it’s behavior tree to swap to a lower movement speed, this was done to also allow for other behavior to be added while visible allowing for further expansion of the system
The first technical issue is that my cone ignored LOS; it went through walls and other objects because it was not a trace. To resolve this, I added a line trace between the centre of the player and the centre of the enemy to trigger while they are visible, which would return true if there were no blockers between the player and the enemy, and false if not. Resolving the LOS issues.
Afterwards, to facilitate testing and iterating in a stable environment, I created a gym to test enemy AI and any iteration I created. From this, I iterated on the keyboard and mouse aiming. Prior to the targeting, the reticle would follow the character player during movement. I changed this, making it separate, allowing the player to orbit their reticle without moving their mouse. Making aiming more comfortable.
Second, I iterated on the AI, making its turning and pathing smoother, adding proper velocity scaling for turning, and allowing for smoother movement around corners.
First Implementation of all element: enemy, weapon, vision, score and the core loop
Showcase of gym environment I created for testing and iteration, I used this environment to improve mouse and keyboard aiming and Crawler AI.
Level design
The Level design was built with one core element in mind: No matter the location of the player, they should not be able to get a complete overview of the play space.
I kept the design light, to reduce variables for in the iteration cycle due. To this end, I placed 3 rectangular cubes in the arena to serve as LOS blockers and playtested the lit-up version, which got a positive reception but was flagged as challenging and difficult due to the high enemy density.
As shown in the video, the enemies were numerous and fast. As a remedy, I added a couple of balance measures to assist the player: I increased their movement speed, gave a lower cooldown on their weapon, removed the start and stop delay to turning and changing direction and added a stagger to enemies when they are struck.
However, feedback reported the game was still difficult. Combined with the fact that darkness was not implemented, which would increase the difficulty further. To remedy this, I further reduced the enemy spawns and changed their spawning, making it timer-based. With the timers set to link up every couple of cycles, creating a wave cycle with highs and lows of enemy spawns.
I then started with variable testing of various variables throughout my game, enemy health, enemy speed, player speed, fire rate and more. To create a comprehensive overview of what each variable’s effect was on the gameplay and the player experience, I used this to create a balance bible, as I called it. This was useful throughout my entire project, allowing me to quickly respond to any balance-related feedback by tweaking the appropriate variables.
I finalised this phase by making the game playable via the main menu of the project, which I used to start distributing builds to playtesters to gather playtest feedback.
First version of the play space of DSA, the cubes serve to prevent the player from getting a complete view of the play space while also serving as dangerous areas. The player spawn is placed in the center with the enemy spawners placed on the outer edges (Skull folder icons)
Showcase of first iteration of the level in a lit environment, along with balance changes to reduce the difficulty of the game.
Showcase of second iteration of level, with lower spawn rates and darkness, I also made the game playable via the main menu allowing for build testing.
Iteration
Iteration cycle started with addressing player frustrations: Players were confused where enemies appear, players were frustrated enemies can appear next to them, game was difficult causing frustration.
To address spawns, I updated the enemy spawners to spawn Niagara particles illuminating the enemy at the moment of their appearance before fading away, providing the player with a snapshot of where the enemies are coming from.
Results from playtesting were highly positive, with playtesters reporting the game felt fairer, and they felt in control. Frustration with enemies spawning in close proximity to players remained. To resolve this, I added an exclusion zone around the spawners in the form of a circular check. If the player is present in the circle, the spawner will become inactive, resolving this problem.
Testing continued, and various changes were made in response to feedback, mainly a reduction in enemy speed to allow the player to have more leeway and response time.
However, one dominant strategy arose during playtesting, resulting from the addition of spawners becoming inactive when close to them; players would hide in corners of the play space for safety. This decreased the players’ enjoyment and the player experience due to the player obtaining a constant feeling of safety, which would lead to boredom and eventual frustration.
Unlike prior issues, I did not resolve this via tweaking variables; instead, I introduced a new mechanic, the motion-based flashlight. A simple solution which would shrink/grow the players’ light cones in accordance with their movement.
The initial implementation was met with a mixed reception, with primary feedback being split down the middle for the mechanic being too punishing and not punishing enough. I decided to agree with both sides, making the mechanic more punishing by lowering the minimum flashlight size and requiring extended movement to trigger the grow effect, while making it less punishing by adding a greater grace period before the shrinking effect triggers.
Showcase of the new enemy spawn visuals and balance changed made in response to playtester feedback.
Showcase of the dynamic flashlight size system to counteract the corner camping dominant strategy which started occuring.