My work

Over the course of the initial 14 weeks of development, I whiteboxed and prototyped 7 different levels. The levels ranged from small, medium, to large levels with different set-ups. Some were very open, some were very confined, some had long corridors, some no corridors at all. This was very much a process to discover the possibilities within level design, and the core gameplay as a whole.

This ultimately resulted in a level that presented the core gameplay of Heist Night in the best manner. This is also the level that shipped in the IndieDB build

Many months after release, myself and 2 other designers revisited the game to develop additional levels after the good reception.

An even more elaborate explanation of the process can be found hereor by downloading the file located above.​

With each level I designed, I started with a key design principle or 'USP'. What makes this level different from the rest?Although levels would be iterated upon many, many times, the core principles of these usually remained.

With one of my levels, I wanted to facilitate more vertical gameplay. The idea that one player could stalk the other from above, but movable space is limited, creating a risk at the expense of having a very good overview of the area.

While working on these level, I learnt and applied a lot about designer level art passes, guiding the player, and affordances. The main questions I asked myself were:

How do I visually guide the player through the level's design?

How do I present all viable options and paths the player can take?

​​

Staircase blends into the floor colour

Seperate from floor through patterns

Stepping stone effect + visual contrast

is this still obvious if you squint your eyes?

​Using the custom heatmapping tool developed for Heist Night, I identified potential problems with the level. Areas that were barely used, what paths most players took, and win/lose ratios.

One of the main things I iterated upon were:

Placement of exit goals

Placement of objective treasures

Amount of paths in and out of an area.

Graphics & shader implementation

I implemented and adjusted a number of graphics and shaders for Heist Night to make the game look visually interesting. The main goal was to make the game not look like it was made using Unity3D.

I implemented different anti-aliasing methods. The player can choose which AA they prefer. The temporal anti-aliasing (TAA) is based on Playdead's open-source TAA implementation.​

​One of the things we always wanted in Heist Night but weren't able to due to time-constraints was volumetric lighting, especially to be used for the Guard spotlights. We used Unity´s built-in lighting implementation instead, which weren't really clear.

The underlying reason for wanting to implement volumetric lighting was so that the Thief player could see the Guard approaching around the corner, and decide to go the other way if wanted. The light shaft is also aligned with the detection FOV of the Guards, which generally provides clearer signposting as to where both the Thief can walk without being seen. It also helps the Guard players (from top-down) orient their Guards.

Multiplayer Game Design & Balancing

Balancing was a major part of Heist Night because of its asymmetric nature: the game had to be fair on both sides.

I approached balancing in a very pragmatic way; identifying the key aspects that drove Heist Night gameplay systems, making the levels around those, and then testing them. A lot of these were discovered through just "playing the game and seeing what happens":

For about 95% of development, the guard player always had 3 guards to control. Each guard was selected using the numerical keys 1,2, and 3. Players were struggling to select the correct guard to move a lot of the time. One day, I secretly deleted 1 guard from spawning. This made selecting the guards into a binary setting: "if I didn't select the right guard, then I know I am one button away from the correct guard."

The guard needed some indication as to what room the Thief was currently in.

The treasure can never be in the same room the Thief player spawns in.

The escape door can never be in the same room the treasure is in, and can never be in the same room the Thief spawned in.

I wrote an entire playtesting journal (as part of a ludology course) that goes even more in-depth into this. You can read it here (* beware of long-winded, flowery English) (I got a 9 for it, so I guess it's not too bad.)