Chester

Game Context

As part of the course Level Engineering we learned about plenty level design and planning strategies to create stage that evokes a meaningful player experience. For our final assignment we had to submit a vertical slice of our level prototype within a game concepted by our own. The working period was a little more than a month. 

Note: While game adamechanics, assets, sound effects, music and general atmosphere certainly add to the level design, they were seen as a bonus and not part of the assignment. We included them because of our passion for the project, but there was little to no time. Therefore everything but the actual level is placeholder.

In our top-down stealth game prototype the player controls a mimic called Chester. Summoned by accident by the king's alchemist in search of the philosopher's stone, it now seeks to unleash murder and chaos upon the kingdom's population.

To create the level we chose to work with Unity because we were already familiar with the workflow and had picked up Unity ProBuilder as part of the course. As our setting we chose a fantasy castle setting which, together with the camera perspective should feel like a tabletop miniature the player looks down at while playing. For the music and general atmosphere we decided on a gloomy but lighthearted theme.

While i focused on functionality and gameplay, stylistic refinements were primarily done by Challicy. Read their level presentation and insights here: [insert link]

First Blockout

The first blockout already had checkpoints, key enemy encounters, vantage points, tutorial messages and the end goal arrival planned out.

The extended level progression was planned to lead the player through areas of varying intensity.

Final Level

In the final level the defined level structure remained the same, but the miniature tabletop environment, player mechanics, enemies, animations and lighting were added for a satisfying result.

Supporting Player Types

The dungeon level is the very beginning of the game and starts of with the tutorial. The path is narrow and, while there is choice (e.g. hiding spots), not a lot of it is meaningful enough to make a difference in gameplay. To make up for that and to support different player types, the player is given complete freedom to approach the second enemy they encounter.

After seeing their first guard from their hiding spot in the previous room, a tutorial message (or footnote, as we came to call them) tells the player of the danger that enemies impose. This makes them aware of potential unseen threats in the room they are currently in.

The first choice the player can make without any consequences is looking around. The plateau they are on is safe and they can't be spotted, but powerful intel about the enemy's patrol cycle can be gathered from it. Also a second tutorial message can be found (and read by rotating the camera) while remaining on the plateau.

Head On

As the most straightforward choice, the player can simply walk down the stairs to meet their foe face to face. They have not learned the controls for attacking yet, making this decision a likely death sentence. We wanted Chester to be a game of outmaneuvering and strategic cunning, so showing the player that the mimic is not a brute fighter early on seemed important.

Daredevil

Even without a jump the player can reach unusual places using their environment. Dropping down the staircase leading upwards lands the mimic on an elevated platform. The guard, however is in direct sight, so the player has to be quick to reach them before getting seen.

Cunning and Pacifist

To make the player feel as smart and creative as possible, the intended/main path should be as unusual and crazy as possible (within the game environment of course). In this instance, the player can balance across a wooden beam to reach the guard from behind. This is also the safest path and gives the player enough time to react to the guard without putting themselves in danger. 

Of course the player can also make the choice to not combat the enemy at all, which is also featured as a valid solution to this room.

Playtesting Insights

After watching each other, friends and strangers play our first prototype, we discovered some issues and drew conclusions from them.

Mechanical Issues

• Enemies need to...
  • be a bigger threat
  • stick to their target
  • be more visible
• Sounds and animations make things more intuitive
  • Especially useful for abstract or strange concepts (e.g. mimic)
• Non-crucial mechanics do not need to be explained
  • Gives players the sense of discovery

As a solution, we...

1. increased the enemy speed
2. gave them a second (wider but shorter) detection cone
3. gave every character a white light to their feet
4. added as many sounds and animations as we could
5. left out tutorials for checkpoints and collectibles

Spatial Issues

We discovered a handful of areas in the level that were not 100% clear to all players and caused confusion. One of the most prominent we were able to fix is a chandelier blocking the view on a portcullis, which are important for the narrative. The simple solution was to move the chandelier to the side by a bit.

Development Tools

While working on this game both Challicy and me implemented tools that would help us with building the level and we could reuse for other projects.

Global Music Player

The GMP is a small library I wrote for playing music of a specific format. Our audio pipeline handles tracks consisting of an Intro file and a repeating Loop file. 

It comes with scriptable objects for easy configuration of these files and provides functions for Play, Pause, Resume and Stop. These all work self-contained and without raising errors, even on wrong configuration. For modular reuse I exported it as a Unity Package and was even able to do so in the same project, as I applied the same principle to sound effects. Additionally, I added an extra volume slider and a randomized replay to the sounds.

Modular Path Indicators

In our first level concept, I used modular path indicators to show the patrol rout enemies would take. My enemies' patrol points were defined by a list of vectors representing each patrol point. By giving the path indicators the same structure, I was able to simply copy paste an enemy's path and immediately achieve the desired outcome. The path indicators themselves are made up of multiple line renderers and circle sprites which duplicate and tile themselves along the defined path of points automatically.

Target Sensing

Target sensing is a script visualizing detection zones (e.g. of enemies) and firing an event when the player enters them. Again, script is entirely modular, so it would work with plug-and-play effort on anything that uses targeting. The event returns an updated list of targets every time the targets change or change order. A subscribed behavior can process that information and hook its own behavior onto it (e.g. heat seeking missiles).

Conclusion

Chester is based on an old idea I had and it was fun picking it up again and finally seeing it come to live in the context of this Level Engineering course. Unfortunately, we did not have time to realize all the ideas or feedback we had, but overall Challicy and me are very happy with the prototype and the insights we have gained working on it.

We would love to hear your thoughts of our demo and our workflow in the comments below! Or reach out to me on discord: thefifthking