Project Havoc is a third person action arena game that pits a super-powered player against waves of enemies.
FORMAT
Engine
Unreal Engine 4
Team Size
Three
Development Time
Five weeks
ROLES
Technical Designer
Implementing A Wave System
Implementing All UI
UI Designer
Designing All UI
DESIGN GOALS
Create a HUD that serves an action-oriented game
Create a main menu that reflects the character and energy of the game
TECHNICAL GOALS
Create a flexible wave system that could be used and balanced easily for this project or any other
Experiment with animating HUD elements
Experiment with dynamic menu elements (character animations, camera pans, etc.)
UI DESIGN DISCUSSION
When designing the menu I initially experimented with a title logo that tried to incorporate the colors from all three of the player character’s main powers but after playing around in game a bit more it dawned on me that I could create three variants of the title, one for each color, and swap through them. Once I had that idea I combined that with the character model’s particles shifting, and playing a swap animation to create a main screen that has just about everything shift just as the player does in game.
To keep high energy I decided it was a good time to experiment with dynamic camera pans on the menu and created several sequencer-based pans for the credits, controls, and difficulty select screens with their content projected into the world to keep things “in the action”.
As for the UI, I wanted to avoid having big blocky UI occupying too much of the screen as you play so I employed a few separate tricks. The wave information initially shows up big, front, and center before fading out and back in at a much more subtle size. The power select display is hidden most of the time since the current power is pretty clear from the player character’s particles but it whips your newly selected power into place with rotation every time the power is changed, taking advantage of peripheral vision and color to make the swap more clear. Finally for health I opted for a numerical representation to give the player as much information as possible while still keeping the shape condensed (rather than a more drawn out bar). I also made sure the health shakes with every hit and gets increasingly red as it lowers to make sure that even in middle of battle a player could quickly gauge their health without having to read.
WAVE SYSTEM TECHNICAL DISCUSSION
With a goal of creating a wave system that allowed the rest of my team to easily tweak both wave content and implementation, there were a few different tactics I used to keep things fluid. I based the entire thing on a nested “Wave” and “Wave Set” pair of structs that would comprise a data table that could store all the possible wave sets any particular wave manager could spawn.
Wave sets contain whether they’re global and trigger after a delay or local and trigger using a trigger box, how long prep time between waves should be (if it’s set to be uniform across waves), whether the waves are named and should display their name, whether they contain enemy-pool based waves (randomly selected from the pool) or defined waves (with a deliberate flow of enemies to be spawned), and whether enemies can spawn in view of the player. Waves contain the number of enemies to spawn, how long the prep time between waves should be (if it’s not uniform across waves), how long the delay between each spawn should be, and the wave’s name.
To allow for maximum ease of set up, I get all the data table’s row names in the manager’s construct script and display them as an array so someone setting up the wave manager in a level doesn’t even need to open the data table to know what options they have for wave sets and has less of a chance of mistyping the string-based input that data tables require.
