×
hh

“Horde Havoc" is a casual puzzler with real-time strategy mechanics where you sacrifice a horde of willing Orcs to solve problems your way

Platform PC
Genre RTS/Puzzle
Engine Unreal engine 4
Role Gameplay, level and sound design
Team size 12
Time 4 weeks

Contributions

Level design - Village

<h3>Collaboration</h3>
  <p>I began work on this level by <b>using a map created by our artists</b> as a jumping of point. This helped with inspiration and <b>sped up my workflow.</b> The <b>collaboration with the artist</b> made me look at the mechanics in a new way and <b>inspired the levels segmented structure.</b>
  </p>

Collaboration

I began work on this level by using a map created by our artists as a jumping of point. This helped with inspiration and sped up my workflow. The collaboration with the artist made me look at the mechanics in a new way and inspired the levels segmented structure.

<h3>The First Obstacle</h3>
  <p>The player is <b>shown the bridge and the route forward</b> blocked by wooden logs. This usually leads to players <b>burning the bridge</b> as they attempt to set the logs on fire, <b>making the fire less accessible.</b>
  </p>

The First Obstacle

The player is shown the bridge and the route forward blocked by wooden logs. This usually leads to players burning the bridge as they attempt to set the logs on fire, making the fire less accessible.

<h2>Encouranging Experimentation</h2>
      <p>At the start the <b>players actions determine the possible solutions</b> for the next obstacle. Since the player can <b>self-sabotage</b> it felt crucial to have additional solutions and paths forward.</p>
      <p>The addition of more paths also helped the level <b>feel less rigid and encouraged experimentation.</b> The gameplay feels open ended and players interact with the level in different ways.</p>

Encouranging Experimentation

At the start the players actions determine the possible solutions for the next obstacle. Since the player can self-sabotage it felt crucial to have additional solutions and paths forward.

The addition of more paths also helped the level feel less rigid and encouraged experimentation. The gameplay feels open ended and players interact with the level in different ways.

Level design - Village to Castle

<h3>Two kinds of players</h3>
  <p>During playtests <b>two different groups of players</b> were identified, <b>the methodical player</b> who inches through the levels using one Orc at a time and <b>the action oriented player</b> who selects all or many and sees what happens. <b>This level is aimed at the action oriented player.</b>
  </p>

Two kinds of players

During playtests two different groups of players were identified, the methodical player who inches through the levels using one Orc at a time and the action oriented player who selects all or many and sees what happens. This level is aimed at the action oriented player.

<h3>Chaos and control</h3>
  <p>In this level we introduce a new mechanic, <b>the flaming arrow.</b> The arrow spawns in two set locations but the landing is random within a set range. This gives way to chaotic, high action gameplay.
  </p>

Chaos and control

In this level we introduce a new mechanic, the flaming arrow. The arrow spawns in two set locations but the landing is random within a set range. This gives way to chaotic, high action gameplay.

<h2>Strenght in numbers</h2>
      <p>Since this level is designed to be reactive I made the Orc pool the biggest in the game. This further allow players to experiment with our mechanics while minimizing the need to restart.
      </p>
      <p>Included in this level is a “secret” alternative route not explicitly shown to the player, only found if the player explores the map. To use it the player must be able to use the oil mechanic effectively.
      </p>

Strenght in numbers

Since this level is designed to be reactive I made the Orc pool the biggest in the game. This further allow players to experiment with our mechanics while minimizing the need to restart.

Included in this level is a “secret” alternative route not explicitly shown to the player, only found if the player explores the map. To use it the player must be able to use the oil mechanic effectively.

Prototyping

<h2>Prototyping</h2>
      <p>Pictured is my attempt to make an idea many in the team were excited about, filling a hole with corpses of Orcs to create a “meat-bridge” the other Orcs could cross. This small mechanic turned out to need more work than we felt was warranted and the trap instead became the Saw-trap!
      </p>
      <p>Another mechanic was the heating of metal. The idea was that an Orc on fire would stand on the piece of metal long enough for it to heat up and change color to indicate this. Then other Orcs would jump when they ran on it, since it’s hot, thus involuntarily clearing gaps or other obstacles. This idea instead became the catapult as a catapult needs less or no explanation and also would work with less actions from the player.
      </p>

How pits became saws
Pictured is my attempt to make an idea many in the team were excited about, filling a hole with corpses of Orcs to create a “meat-bridge” the other Orcs could cross. This small mechanic turned out to need more work than we felt was warranted and the trap instead became the Saw-trap!

How hot-metal became catapults
Another mechanic was the heating of metal. The idea was that an Orc on fire would stand on the piece of metal long enough for it to heat up and change color to indicate this. Then other Orcs would jump when they ran on it, since it’s hot, thus involuntarily clearing gaps or other obstacles. This idea instead became the catapult as a catapult needs less or no explanation and also would work with less actions from the player.

Audio

I designed and implemented our audio

Sound Like a Horde

Instead of going the traditional RTS route of having one sound play when marking one or many units, I made every Orc spawn a sound when marked. This set-up use lots of voices but really add to the feel of them being an unruly horde.

Orc Movement

I tested and scrapped footsteps because I immediately reached voice starvation and I also felt I didn’t have time to implement switches for different terrain.

Instead I opted to have the Orcs say some gibberish when walking and to continually play these noises during movement. The blueprint is set up to stop spawning new audio when in range of the target location but allows current sounds to continue until completion.

Boulders

In this blueprint I handle SFX behaviour for the boulders. They can travel at different speeds, collide with stuff and also, in one level, bounce!

In this version I start the rolling sound when the boulder spawns then control the volume and pitch of that sound with a float I get from the boulders vector length. The impact sound is triggered by a circle collider whose radius is only a tiny bit bigger than the boulder itself.

<h3>Wwise Sound Design</h3>
      <p>I chose to use Wwise since my use of big audio pools felt easier to handle through a middleware compared to Unreals internal audio tools.
      </p>
      <p>I had to work with lots of different attenuation, as the camera had a zooming feature. I set up a base attenuation that worked with different zoom behaviour for groups of sounds and made use of Wwise real-time-parameters to connect audio to scripted behaviours in various blueprints.
      </p> <h3><b>Parameters</b></h3><p>A good example of my work with parameters, the boulder behaviour! I used two parameters to control the volume of the rolling sound, one that works with a bool, turning the volume up/down depending on if the boulder moves at all. The other parameters are connected to the movement speed, set by the boulders Velocity vector length. Using this i control the pitch and another volume instance!
  </p>

Wwise Sound Design

The sounds heard are a combination of my own private recordings and royalty free audio, recorded and mixed in Logic.

I chose to use Wwise since my use of big audio pools felt easier to handle through a middleware compared to Unreals internal audio tools. I had to work with lots of different attenuation, as the camera had a zooming feature. I set up a base attenuation that worked with different zoom behaviour for groups of sounds and made use of Wwise real-time-parameters to connect audio to scripted behaviours in various blueprints.

Parameters

A good example of my work with parameters, the boulder behaviour! I used two parameters to control the volume of the rolling sound, one that works with a bool, turning the volume up/down depending on if the boulder moves at all. The other parameters are connected to the movement speed, set by the boulders Velocity vector length. Using this i control the pitch and another volume instance!

Auto Fade Workaround

I couldn’t get the auto fade feature in Wwise to work with blueprints so my solution was to set up fade of my own on every blueprint that could burn. Not very fun to do but the result was that no jarring audio cuts were present in the game. The fade is 0.9 sec long and lerps the volume from max to inaudible.

<h2>Auto Fade Workaround</h2>
<p>I couldn’t get the auto fade feature in Wwise to work with blueprints so my solution was to set up fade of my own on every blueprint that could burn. Not very fun to do but the result was that no jarring audio  cuts were present in the game. The fade is 0.9 sec long and lerps the volume from max to inaudible.
</p>

Visual scripting

  <h3>Timing and Usability</h3>
        <p>When I created the smasher trap in the Village level I focused on timing, giving the trap a pattern that is easy to follow but with violent, sudden movement. <h3>Timing and Usability</h3><p>I used the Timeline node to execute everything going on with the trap.
  The update pin coupled with a float track controls the movement of the trap, an event track executes audio and another event track toggles the kill collider on and off.
  </p>

Timing and Usability

When I created the smasher trap in the Village level I focused on timing, giving the trap a pattern that is easy to follow but with violent, sudden movement.
I used the Timeline node to execute everything going on with the trap. The update pin coupled with a float track controls the movement of the trap, an event track executes audio and another event track toggles the kill collider on and off.

Several Solutions

As we were tasked to allow for “emergent gameplay” I implemented several ways for the player to manipulate the boulder. Players usually explore the trap door and find one way to open it and the funneling rock placed in the middle of the hill works both to lower the threat from the boulder and to signal safe passage.