Project Wannabe, Ongoing

Project Overview & Responsibilities

Project Wannabe is a first-person shooter that is inspired by Doom Eternal's fast-paced arena-style combat and flexible AI. I was brought onto this project as a Technical Designer. Currently, I am responsible for prototyping new player abilities and AI.

What I'm doing

Simplified existing systems to be easier for designers to use.
Created combat AI to fit contend with player mobility while in the air.
Scripted and designed player mechanics alongside VFX artists and other designers.
Provided level designers with gadgets to spice up gameplay
Problem solved technical issues for team members throughout the duration of the project.
Wrote onboarding documents to setup source control.

Gameplay Contributions

Weapon Changes

I worked on a handful of weapon mechanics during my time on Project Wannabe. These mechanics were the swords Thunderstrike ability, the rifles Pulse Blast, and the shotguns Freeze Bomb.

The Thunderstrike is an ability that provides the player with resources such as health and ammo. It does this by increasing the amount of said resources that spawn upon an enemy's death. For the experience of the ability, I was aiming for something along the lines of Destinys' Fist of Havoc Ability, the weight of the impact and landing effect on enemies being the two things I wanted to replicate.

The version that matched the references

Here is the clip used for reference

When working with the VFX artist for this, I drew a diagram of what the mechanics experience was and gave him the reference video that I was using to make the motion and feel of the mechanic. From there I made the first iteration of the mechanic with the above concepts in mind. The second iteration contained tweaks to the amount of resources that were being dropped from enemies as well as the addition of the VFX which you can see below.

First iteration with no VFX

To add weight to the ability, I gave the player some air time between when they launch and when they land. I wanted to emphasize the power of the landing so enemies that are killed dissolve and fly away from the player. This was done so that the player could see a direct cause of them killing something with their ability as opposed to just killing an enemy regularly.

Death animation

During an internal playtesting session we received feedback that players were getting frustrated when they died. Not because of their unfortunate passing, but because their death was unclear. They still have full control of their character then suddenly their character snapped back to a checkpoint with no indication of why.

Old death state

There's no communication to the player for what has happened aside from the HUD disappearing. So I set out to fix this. I knew before making this that I wanted to have multiple points of clear feedback to the player that they died. So I settled on: Removing the arms from the screen, the camera falling to the ground, a camera fade to black and a UI pop-up.

Encounter System Updates

When I joined the project the encounter system required heavy scripting to setup. This created a larger barrier to entry to use one of our core content creation systems, which not greatly slowed production for various reasons. My goal was to eliminate that scripting making encounter design done fully in the viewport.

To start I dug into the framework setup by my lead. I aimed to remove scripting setup from three actors: triggers, doors and enemy spawners. I added an interface event to all interactable blueprints (doors for example). To call this event I added a instance editable array to all triggers, when triggered, the interface event is called in all actors in the array.

The result of this change is massive decrease in the time spent to setup these actors. This first gif shows me setting up button to close two doors. This took 24 seconds to setup using the old system.

This is a second gif showing me setting up the exact same things. It takes me four seconds and requires no usage of blueprinting what so ever.

Spawners were the next thing I dealt with. Prior to my changes, spawners needed to be told to spawn enemies via scripting. My solution for this was to rework the combat manager to handle the spawning of enemies, and I wanted to give designers more control over the encounters so I added waves to the manager as well. The result of this change is that designers were able to create deeper encounters with less complexity.

You can see the impact of this change below, setting up an encounter using blueprints takes about one minute. Then in the following gif you can see me setting up the exact same elements in half the time.

This is how encounters were setup prior. It takes about one minute

This is how encounters were setup after my changes, it takes about 30 seconds