Rogue-like and Level Design

Level design in roguelike games is an entirely different endeavour then creating levels in much more traditional, linear games. This is due to a variety of factors, that I’ll explore further below.

To ground this exposé on designing levels in a roguelike game, I’ll use as an example the game we’re developping at iLLOGIKA, Subaeria.

First things first, what is Subaeria? Subaeria is a puzzle action oriented rogue-like game.

It's a 3D third person game where you cannot directly kill the enemies. It uses Julius Caesar’s famous phrase: Veni Vidi Vici as its core gameplay. The player enters a room, examines it then makes his move and conquers it.

The rules of Subaeria are the following:

I'll look into the lessons learned in designing this procedurally generated game on the side of level design.

Pure randomness is bad.

Humans by nature are lazy. That’s alright, each time we do an action, we spend energy. We feel more hungry and tired. Therefore, we must find shelter and hunt for food. Not everyone has time for that. To be fuel efficient we always look for shortcuts.

Level design follows the same rule. As a level designer we can use a spawn point system. You select a position in the level and the game will place enemies there. You can leave the selection of enemies to the system. Why do I need to choose when the computer can do it for me?

Well, random systems don't care about making a fun game. It's important to find the frustrating combination of enemies and make sure it doesn’t happen. It's better to have less variations and make sure they are fun, then have a lot more where the player is simply in pain and agony.

What to keep in mind when building a level.

When building a level, keep in mind the minimum requirement the player must have to be in that level. In our case, the skills available to the player are using a charge system. Skills are actions picked up randomly throughout the game, they give the player different abilities, like controlling robots or becoming invisible, depending on what skill is picked up. Each use of a skill costs one charge, once the charge reach zero the player loses the skill. The system makes it impossible to predict which skill the player will have on hand, if he gets any. Consequently, for Subaeria each level has to be beatable with only movement.

However, it was still important to keep one or two skills in mind when building a level. That way we could build a level favoring the use of those skills even if it was still possible to beat them with only movement.

Another problem we encountered was: we cannot know if the player has already encountered another situation like this in a previous level. The solution we chose to counter this with was to keep the puzzle aspect low in difficulty. In other words, we didn’t create any puzzle that needs three or more steps to be solved. It also helps with the pace. It’s hard to have fun when robots are chasing you and you have no clue on how to beat this room.

Use your tools to keep things under control.

Random is the baseline of any rogue-like game. It’s true, it’s fun to play the same game with a different layout! But for testing it’s horrible. For example: In the level 1B, there are 4 robots.

Each robot can be of 4 types each. Level 1B can be used in 3 different environments with unique level art. Still with me? Just for the fun of it, let’s add some weapon sets for the robots, 2 to 3 each. Level 1B is now the equivalent of more than 50 levels (Poor QA are going to have a lot on their plates).

In a 2D game? It’s still simple. In a 3D game involving physics? A little stub on a corner can bring unseen headaches. At first it was hard to test each possibility.

When creating our level we used spawn points and enemy pools. At the beginning, we had no control over them. Once two robots were in the pool we had no way to choose which one will be selected.

To test a certain combination we had to restart the game until we were blessed with luck and found the configuration we wanted to test. However, the programming team came forth with some magic code that allowed us to cheat the system and set the configuration we wanted to test without requiring any changes beforehand. This way we were not afraid of making a clerical mistake.

Otherwise we would have had to keep track on paper (or the like) to reset every level after each test. It was a great help to be able to make adjustments in real-time without fearing the possibility of losing them after the next test.

As a conclusion I would say that since you don't have a great control over the path of a player in a rogue-like game (compared to a linear game) you must keep on your mind that you don't know what the baggage of the player is when designing levels.

In a game, generally you want to warm up your player with the easiest challenges of the same type along the way before feeding them the hard one. In a rogue-like, it's possible that your player will not encounter every possible challenge in a single game. He can even encounter a challenge type only near the end game. Making it harder since he wasn’t able to warm up before hand.

In those conditions, reduce the expectations you have for his skills and knowledge. Keep things simple and make sure every situation is fun!