Labyrinth

A game about being lost.

Labyrinth is a point-and-click/text adventure game where the player is an unknown dungeon, with no context as to how they arrived there. They are presented with endless hallways to travel down, and along the way encounter various characters who may help or hinder in their journey to escape.

The player starts off with a certain amount of lives and sanity. Sanity is reduced every time the player moves forward in the labyrinth, while lives are taken away when the player is attacked by certain characters. If either of these things run out then the player dies and has to start again.

Click here to enter the game >>>>>>

Context

Labyrinth was primarily inspired by games from the 90s and early 2000s, particularly PlayStation and early 3D computer games. I find that, as various tropes of game and technology design had not been truly established, there was a lot more experimentation in mainstream titles which led to many interesting aesthetic and gameplay choices which have influenced Labyrinth.

(left: Zork Nemesis by Zombie LLC, right: Myst by Cyan Worlds)

As a child I played a number of point-and-click adventure games, such as Myst, Zork Nemesis and The 7th Guest. Despite there being no immediate danger to the player at any point during a playthrough, these games were terrifying to me. This was in part due to the music and sound-design, which in all these cases created a foreboding atmosphere; but equally important to create a sense of fear is the gameplay itself. The nature of a point-and-click game means the player is only able to observe the environment through a particular, static lens. Consequently, there is often the feeling that perhaps there is a danger, but it is lurking somewhere off screen and you aren’t able to turn around and look at it. When you do decide to investigate, the game is taking you on a set path. You aren’t able to approach the potential danger on your own terms, you are instead being led to it. There is never actually anything there, but the feeling of being under threat persists throughout the game.

Another influential game was the PlayStation One title Kowloon’s Gate. Whilst I’ve never actually played Kowloon’s Gate, as it is a Japanese game that was never translated to English, I’ve watched playthroughs of the game online and read articles detailing its content. It was re-released for the PS4 in English but this version differs substantially from the original and removes some of the elements that initially drew me to the game. Kowloon’s Gate presents a fictionalised version of the now demolished Kowloon Walled City in Hong Kong. Like Myst and Zork, it is a point-and-click adventure game and thus shares many of the traits that appealed to me about those games. What sets Kowloon’s Gate apart however, is that it depicts a city which is densely populated and has a large number of characters to interact with. The other games I have discussed rely on the player’s sense of isolation to amplify the atmosphere created by their music and gameplay. Kowloon’s Gate manages to achieve a similar feeling of dread but in a densely populated urban environment. This is largely due to the unsettling visual design of its characters which makes the player feel isolated despite the number of other people around. There is a sense that the player is exploring a world that is entirely alien and perhaps even hostile. I wanted to recreate the feeling of traversing a world which feels established, but is completely unknown and unfamiliar to the player.

(left: The Silver Case by Grasshopper Manufacture, right: Kowloon's Gate by Zeque)

There were a variety of other games that inspired some of the aesthetic choices in Labyrinth. One of these was another Japanese PlayStation One game, The Silver Case. The Silver Case is a text adventure game that positions real-time 3D graphics alongside character art and dialogue text, with each element confined to its own window against the same background. This game plays with the idea of how the positioning and framing of elements on the screen can be used for tonal effect, and inspired the graphical presentation of Labyrinth. Also important is the PC game, Quake. In its original incarnation, Quake made use of a software-based renderer that gave the game a hazy lo-fi appearance; the effect is not too dissimilar from that of film grain or low-resolution video. Though a hardware solution was developed soon after the game’s release, I have a preference for the original software-based renderer as it introduces a certain amount of visual ambiguity into the image that aids in creating the game’s horror atmosphere. The game also had to make use of a limited number of onscreen colours. This meant that the game developers had to choose between either displaying a larger amount of hues, or displaying more variation within the limited amount of hues available. Quake takes the latter approach, and consequently the levels are predominantly varying shades of brown. Though this aspect of the game is sometimes retrospectively criticised, I think it goes a long way to create a dark and oppressive tone that was unique for the time and is still distinctive now.

While a general fantasy aesthetic was assumed from the start, as I thought it would be appropriate for a dungeon and I am a fan of the genre, the specific character designs drew from a variety of sources. This is because I didn’t want all the characters to appear too stereotypical. For example, the Flesh-eating Mandible was inspired by the low-polygonal enemy models of Quake, while The Collector’s appearance is reminiscent of the design of the Silent Hill 2 monster Pyramid Head. There were also some filmic influences, such as The Count’s design which was inspired by the classic German Expressionist film, Nosferatu. The inclusion of the Skeleton character, as well as other aspects of the game, is in part a reference to the quote by indie game developer, The Catamites, who describes games as being “a combination of the following indivisible elements: skeleton, red key, score thing, magic door”.

(left: Fallout 2 by Black Isle Studios, right: Quake by Id Software)

In terms of writing, my main sources of inspiration were old RPG games, in particular Fallout 1 and 2. These games have a comedic style of writing which generally doesn’t take itself too seriously and frequently breaks the 4th wall by talking directly to the player. I felt as though this tone would be appropriate for a game designed to be a short experience, which didn’t have time to establish a complicated or grand narrative. I also don’t have much experience with creative writing, and found this style came more naturally to me as the characters could speak in a tone that was relatively close to how I talk. While I didn’t want to squeeze a complicated narrative into the game, I wanted the world to feel like it had some kind of history and inner-workings that go beyond what the player is personally exposed to. As such, included in the dialogue are various references to things such as the great rat clans, or how the player is referred to as “the new mortal”. There is the sense that the world has an internal logic to it, but the player only ever scratches the surface of it.

Development

The game was developed using the three.js JavaScript library which I had some experience with as I had previously used it to produce a 3D art installation as part of an online exhibition. I was originally working on a different idea which would have had the player exploring an empty house, inspired by my work on the art installation. However, it quickly became clear that the level of detail required to create the house would stretch my limited 3D modelling skills and each room would take multiple days to complete. As a result, there would not be enough time to complete the house for the game. In addition, I had yet to determine the gameplay element.

Whilst working on this code, and recognizing that what I had from being a fully comprehensive game engine – for example, it didn’t include any vertical collision mechanism or a system for loading a large number of imported models, I had the initial idea for Labyrinth: an image of a dark dungeon hallway. The final look of the game actually reflects that initial idea fairly closely.

(early in Labyrinth's development)

I decided to create a randomly generated dungeon because I wanted the Labyrinth to feel like an endless descent. It was also important that the game was story driven, so that rather than just finding your way to the end of a maze you would actually have to complete certain tasks for characters before you are able to proceed. Using characters wasn’t something that I had considered for my other game ideas, but I felt the addition of people to talk to would give the player the impetus to keep exploring. I also felt that meeting people and having conversations would be more engaging for a short experience than trying to complete arbitrary puzzles or fight enemies. The random nature of when and what characters appear was inspired by the original Fallout games, which featured various random encounters that had a chance of appearing any time the player traversed the world map.

Once the idea of a dungeon was settled on, the question of how exactly to traverse it came next. Inspired by the aforementioned point-and-click games, I aimed to evoke a similar atmosphere that I felt was so strong with those titles. The maze is generated in a fully 3D engine, thus the game is not point-and-click by necessity, but rather by design. The player is presented with a dark hallway, and can see just enough to know that the hallway continues round a corner. This means that the path ahead is always out of sight, and therefore could contain anything. In this sense the game is assuming control of the player’s perspective to create a feeling of unease. The player is then only ever able to travel down the hallway with no option to go back or observe their surroundings; If there is any danger lurking off screen, then the player has no choice but to head straight towards it.

Whilst it was fairly easy to design a system that would endlessly generate right turns and left turns trying to incorporate crossroads proved to be difficult. The maze would be generated ahead of time so that it always appeared to the player that the path continued. However, if it wasn’t known which direction the player would go in, then I couldn’t know where to put the next path. I solved this issue by positioning the next maze section after a crossroads somewhere off screen, and then moving it to the appropriate position once the player had decided. Before the player decides, the back wall of the maze section containing the crossroads was made larger so that it appeared as though the path veered off in either direction. Despite the difficulty of developing this system, it was fairly vital to include points where the player could choose a direction as otherwise the game would feel like one long hallway, rather than a labyrinth with many different possible routes.

(the final look of the game)

For the look of the game, I was aiming to create something that was reminiscent of Quake’s software-rendered mode. Whilst this was mainly an aesthetic choice that harkens back to the games that had inspired me, it also introduces a certain degree of visual ambiguity to the image that add to the sense of unease about going forward. To achieve this, I made use of low-resolution textures and filtering that wouldn’t blur the pixels, and a post-processing pipeline that incorporated half-tone and pixel shaders to degrade the image. The final look is very close to the image I originally had for the game. Once the graphics were finalised, I then restricted the game window to a small space in the middle of the screen. This was inspired by The Silver Case, as I was interested in how its framing of the game window could affect the tone of the experience. In this instance, the small image surrounded by black reflects the dark emptiness of the Labyrinth while also allowing for it to be a less claustrophobic experience.

Originally the character portraits were meant to be gifs of animated 3D models, inspired by the graphics in Kowloon’s Gate. Whilst I had developed some experience with 3D modelling over the last few months, I quickly realised that trying to model and animate eight different characters as well as ending cutscenes wouldn’t be a viable option; As with the house environment, it was too ambitious a task for my skill level and the time available. The next thing that I looked into was using open source 3D models. I was not able to animate these models however, and they didn’t match the aesthetics I was interested in. To try and bring these models more in line with the look of the game, I had the idea to render an image of the model and then apply a dithering process to it, whereby a complexly shaded image could be represented using only two colours. I then wrote a program to recolour the images to match those used on the site.

(the original render on the left, the dithered image, recoloured image)

This worked fine for the skeleton character as it was easy to find a generic model to represent that, but I had a large cast of characters in mind all with particular visual designs. It would have been impossible to find models of the things that I was envisioning in my head. I decided to try applying the dithering process to drawings as this was something that I could produce fairly quickly with the help of my partner. I would make rudimentary drawings and discuss the design of the character with them, and they would create a much more refined drawing which we would then iterate upon until it was roughly in line with what I originally had envisioned.

(prelimnary sketches by myself and Ash, final illustrations and dithers)

I was really happy with how these images turned out. The final art style of the game probably ended up being more unique than it would have had I gone with the original plan.

Closing thoughts and future additions/improvements

There are various features that were not added to game due to time constraints. One of the more significant omissions is the lack of any kind of visual or auditory feedback for the amount of “Sanity” a player has. I had originally intended for the wall textures to change to something more monstrous when the player loses a certain level of Sanity, but didn’t have time to implement this. The same is true for character animations and different portraits and music for different states of emotions. These would have required a significant amount of time in order both to create all the drawings and adapt the fairly rigid dialogue system I had created for the game.

In general, the amount of time I had wanted to dedicate to sound and music was cut short because of how long it took to develop the rest of the game. The music and sounds were all added and created in a relatively short amount of time, despite the fact that it was the element that I was most looking forward to creating. This meant that a lot of the music consisted of textures I had already created, and also that the number of different sounds I intended to have in the game was reduced to just one music track for each character and ending. There are also some atmospheric sounds that play every time the player moves in the Labyrinth and closes a dialogue window which were contributed by my sibling. I’m still happy with the overall direction, which I think on the whole gets across the atmosphere that I was aiming to achieve, but would have liked to have spent more time making tracks that are more tailored to each character.

I had left this process to the end because it was the part that I had the most experience with and knew that I could make something fairly quickly, whereas almost everything else about making a game was new to me and took a long time to figure out. The dialogue system in particular I found very difficult to program, as I didn’t know how these systems work in other games. Whilst I managed to make something that works, the design is not very adaptable or modular which makes it difficult to make changes to it. I also dedicated a lot of time to the inventory system, which ended up being a lot more sophisticated than it needed to be for the game; it supports multiple instances of every object and assignable functions for each one when the user clicks on it. This was because the game was originally going to rely more heavily on the inventory aspect and different items would have been usable at various points throughout the game from the inventory menu. This was cut down due to both time constraints and changes in design, but it also meant that I had wasted a lot of time making an inventory system that was more complicated than it needed to be. The good thing about this though is that if I want to keep working on the game in the future, there is a system already in place that I can use to expand on the gameplay.

Lastly, there are also some minor adjustments that I would like to make which only came up once other people had tested the game. An example would be the system of pressing “I” to open the inventory. I implemented it this way as it’s a general standard in various RPG and adventure games that I play, but I don’t think it works particularly well for the less real-time style of this game. As the inventory is only there for visual feedback on what items the player has and how much sanity and life they have, it would have made more sense to have it always show at the bottom or to the side of the screen. This would also have allowed players to use items during dialogue rather than having to pick a dialogue option for them. Another improvement that I wanted to make was giving characters probabilities of appearing, instead of it being entirely random. While you can’t encounter the same character twice in a row, it’s possible to go back and forth between two characters that aren’t useful to you for long periods of time. I don’t mind this to a certain degree, because a big part of the game is about interacting with all the characters and I didn’t want to railroad the player into only encountering the characters that they need. However, the randomness could be curated more to avoid frustrating or repetitive situations. For example, encountering the same characters often could reduce their probability of appearing for a while, or going a long time without seeing the characters that you need to progress could increase the chances of those characters appearing.

Some notes about running the game

I developed this game on Google Chrome, and it’s fair to say that this browser is the one that will probably guarantee the most success when trying to play the game. It should work on other browsers though, and I have tested it on Firefox with moderate success. The only things to note are that the audio does not loop as seamlessly on Firefox and Firefox seemed to sometimes require multiple clicks in order to start the game. Due to the audio looping issues when playing on Firefox, I would say it’s an inferior experience and would recommend playing on Chrome if you can. I haven’t tested it on Edge or Safari, but based on past experiences with Three.js and Safari I would highly recommend staying away from trying to the run the game on there.

Another thing worth noting is that this game is really just a web page; as such, sometimes images for characters and other things will not always load instantaneously so if a character’s portrait or inventory item is missing then the game probably isn’t broken, it’s just taking a while. Once all these images are loaded into the cache, everything should appear relatively smoothly.

Lastly, due to my limited experience programming for games, the animation of moving in the labyrinth is tied to frame rate. To mitigate this, I wanted to cap the framerate to 30 and design the animations around that, but Three.js doesn’t really have an in-built method of doing this and the animations did not look right when I tried to cap it to 30. Instead, the framerate is roughly capped to 60 which should be fine for most computers, but if you’re running the game on a particularly slow device that can’t show the page at 60 frames then the animations will slow down somewhat. To get around this, the animations can actually be skipped if you click while moving. Even if the game runs fine, I imagine most people will end up eventually skipping the animations most of the time while playing.

If you are absolutely unable to play the game for whatever reason, then at the bottom I have included a download link for a zip containing everything you need to run the game locally on windows. The only thing that this will require which you may not have is a Python 3 installation, but this should be fairly easy to do from the command prompt. Included in the zip is a .bat file to setup a local python server and then open the page with the game on. Running the game locally should also virtually eliminate any load times or issues with assets not appearing instantly, so if that is a recurring problem or a slow internet connection is getting in the way of playing the game then running it locally may be a good option.

If all else fails and you are unable to run the game either online or locally, then I have also included some links to unlisted YouTube videos containing full playthroughs for each of the 5 game endings. These might be useful resources anyway if you are unable to figure out how to achieve all the various endings.

Links

Download the local version of the game here >>>>

Watch the full playthrough here (spoilers) >>>>

Credits

Game, music and art direction by Tom Drath

Illustrations by Ash Darling

Additional sounds contributed by Alex Drath