Escape

Escape is a surreal labyrinth game developed by Timo Kaul, Marcus Held and me during the course of the elective subject “Game Development” at our university.

The player’s goal consists of breaking out of the labyrinth by finding hidden levers within the level that open the exit. The game is set in a gloomy cavern supposed to create a constricting atmosphere underlined by scary sounds like clanking chains or frightening screams. The general message of this scenario is: “Sometimes one has to overcome his limitations, fears and sorrows to gain real freedom”.

Level Design

From a technical standpoint the most interesting part of Escape is it’s nonlinear level design. If the player leaves element A in forward direction he/she reaches element B. But after returning may find him/herself entering element C. While this creates the impression of surrealism, confusion and inconsistency, the game is 100% deterministic. If the player ends up in element B again and leaves backwards, he will always proceed to element C.

This level mechanism can be mathematically described as a graph. Every node represents a level element. Each level element has 4 edges (forward, backwards, left, right) which point to other level elements. Many scenarios are imaginable: An element connected to itself would result in an infinte hallway. Or one could design a curve that looks perfectly straight after turning around.

Technical Details and Implementation

Coming from different software development backgrounds we considered Java a good compromise everyone could get started with quickly. There was however a certain unease about using that language to develop a 3D game.

Nevertheless we decided to give the JMonkeyEngine a try, as it seemed to be a very convenient tool for building a true cross platform game within a short timespan. It turned out our assumption was correct.

The biggest hurdle was the implementation of our abstract level design into a three-dimensional game world. One cannot simply load the whole level into the game engine’s scene graph, because there are unnatural jumps and overlaps that prevent the level from being displayed thoroughly. So we developed an algorithm that determines, based on the players position and viewport, what part of the level is to be displayed at a time. This algorithm must be called whenever the player moves or changes the viewing angle.

Responsibilites within the Team

While Timo’s main task was the creation of textures and 3D models, Marcus and I focussed on the implementation of the game’s logic and graphics. We all participated in the recording of the sounds which I have mixed and cut afterwards.

Conclusion

Given the short period of time and limited manpower we are satisfied by the outcome of the project. There are two issues left unsolved. The first results in unshaded walls due to a problem with the way our textures got rendered by the engine. The second is a graver one, as it pertains the algorithm for rebuilding the scene graph. The algorithm itself works but it is not always triggered at the correct spots, which results in the level not being rebuilt properly. In the worst case, the player falls into void, because there is no floor underneath. When playing the demo, one can avoid that by going back and forth to trigger the rebuilding process, whenever the level is rendered faultily.

Future development is not currently planned as we are all occupied by other tasks and the whole project was limited to the duration of the lecture. But we consider releasing the whole game under a free licence to encourage others to join development. I will promote this on my blog, as soon as we decide to go that route.

Demo

A playable demo is available for download. As mentioned above it contains bugs, but should be fine enough for demonstrating our ideas and concepts.