The game was originally designed as a board game.

I wanted to make a game with a classic race to the end goal but a focus on logic and strategy rather than luck.

That is how I came up with racing to the end of a labyrinth while having to deduce where the invisible walls are.

However, in an analog board game, someone would still need to know the layout of the maze, and a pure game master role would be uninteresting, so I added a special player that knows the layout but has other disadvantages such as being allowed fewer moves.

As a theme for the game, I came up with the Devil challenging mortals to beat a hellish labyrinth in order to save their soul from damnation, so I called it Devil's Labyrinth.

I did not want players to gain too much information from other players' moves, so I decided that players would communicate their moves to the Devil in secret and the Devil would show only the final result of the moves to everyone.

To spice things up, I also added special actions such as swapping places with other players.

As a design document, I created a fake manual that would be edited as I make changes to the game design.

First, to try out the invisible wall mechanic, I made a simple digital prototype where I could traverse a randomly generated invisible labyrinth. The difficulty seemed appropriate and I enjoyed playing it.

The next step was creating an analog prototype fitting the manual in its current state. I created a basic paper prototype, met other players and explained the rules to them so we could try it out together. To assist my explanation of the core mechanic, I also showed them the digital prototype.

It turned out that the board game was overly complicated and tedious, but the digital prototype was enjoyable even in its basic state. Therefore, I decided to scrap the board game idea and instead develop it as a digital game.

The switch to digital resulted in many changes to the game design:

With this project, I wanted to challenge myself and put the knowledge of Java and Processing that I had acquired during my first semester to the test, so I decided to do everything from scratch in Java without external assets or libraries other than Processing.

Maze generation was simple:

For each line on the grid, I randomly determined whether it would be a wall or not, with the probability being adjustable.

Then, I used recursive graph search to find unreachable areas and removed a random wall in the border to make them reachable, repeating the process until the entire grid was reachable.

Finally, I iterated over all corners not on the edge and for any one with no adjacent walls, I randomly turned one of the four lines into a wall. It can be mathematically proved that this will never create unreachable areas.

See the full code here.

For me, the most interesting challenges were object oriented design, the settings menu and AI.

When I made this game in early 2019, I already had more than eight years of programming experience in various languages, but little experience with proper object oriented design. Previous object oriented projects in C++, Python and Java were usually simpler than this and since I am mostly self-taught, I was not aware of established design principles before studying Animation and Game.

This changed when I was taught design guidelines and patterns like the strategy pattern in my game development classes during the first semester, which strongly influenced how I approached this project.

For example, as I had learned to keep game logic and visuals simple, I placed all display behaviors in their own classes in a separate package and had the rest of the game only import certain display classes when necessary.

Also, inspired by the strategy pattern, I created only a single class for an AI-controlled player and made the various AI algorithms implementations of an interface that the AI player asks for its moves.

For game design reasons and as a challenge to myself, I wanted just about everything about the game to be customizable in a settings menu, which meant creating input fields, sliders, checkboxes and color pickers from scratch.

The color pickers, for example, were made by looking at other programs' color pickers and using my mathematical knowledge to infer a formula for which place on the screen would correspond to which color. This was used to create the graphics for the color pickers from colored lines and dots and to calculate the chosen color from the place the user clicks.

I also wanted the player to be able to change the window size and dimension. The latter especially meant that hardcoding the layout would be problematic. Instead, I created a Screen class that holds Screen Elements and calculates the layout from their parameters and the width and height of the game window.

I wanted the strength of the AI to be fully adjustable between being as weak as possible and as strong as I could make it.

Therefore, I came up with the following algorithms:

• Random: Randomly choosing any of the four directions for each step, without knowing anything about the game.
• Weighted Random: Also randomly choosing, but preferring moves that go in the direction of the goal with a weight of 3:1.
• Remembering Walls: Like Weighted random, except that when it knows that it just hit a wall, it remembers not to hit it again.
• A Star: It remembers walls from previous turns like Remembering Walls. Then, it uses the A* pathfinding algorithm to find the shortest path to the goal that does not go out of bounds and is not blocked by a currently known wall.
• A Star 4: Like A Star, except that it also remembers where there are no walls and uses this to infer additional walls from the rule that there must always be at least one wall at each corner.
• Bayes Star: On top of the A Star 4 algorithm, this knows about the dice rolls and position changes of the other players and uses Bayes' theorem to infer probabilities of walls in the other players' paths.

Each algorithm was assigned a spot on the slider and when the slider is set somewhere between two algorithms, the AI chooses which of the two to use each turn, with the probability depending on where the slider is set.

All algorithms were made from scratch, except for A Star, for which I looked at pseudocode to refresh my memory of the AI classes I took when studying mathematics.