作者：Alexandre Delisle

roguelike游戏中的关卡设计与传统的线性游戏的关卡设计是完全不同的。我将在下文解释其中的原因。

为了描述roguelike游戏中的关卡设计，我将使用我在iLLOGIKA所开发的游戏《Subaeria》为例。

Subaeria(from duotegame)

首先，《Subaeria》是怎样的游戏？这是一款益智行动rogue游戏。

这也是一款第三人称3D游戏，即玩家不能直接杀死敌人。它使用了凯撒大帝的经典名言“我来，我见，我征服”作为核心游戏玩法。玩家将进入一个房间，检查它，然后移动它并征服它。

《Subaeria》的规则如下：

每个迷宫都是由随机房间所组成，并且这些玩家都与难度级别有关。

玩家可获得的技能和奖励都是随机选择的。

每个房间都必须拥有4个入口点。

与大多数游戏一样，基于更高难度级别将出现不同游戏元素。

我将进一步着眼于我从关卡设计中所获得的经验教训。

纯粹的随机性是不可行的。

人类具有懒惰的本性。这点并没错，每次当我们要采取某一行动时我们都需要消耗能量。我们会感到饥饿与疲惫。因此我们需要找到能够休息的地方并寻找填补饥饿的食物。然而并非所有人都有时间去做这些。所以为了补充能量我们总是会去寻找捷径。

关卡设计遵循的也是同样的规则。作为关卡设计师我们可以使用刷怪点系统。你可以选择关卡上的一个位置，游戏将在此设置敌人。你可以将敌人选择留给系统。为什么当计算机能够为我做这件事的失衡我还需要为此而费力呢？

随机系统并不关心是否创造出一款有趣的游戏。所以你必须找到令人沮丧的敌人组合并确保它们不会出现在游戏中。你最好避免添加太多变量并保证它们都是有趣的，否则玩家将只会因此感到痛苦。

在创造关卡时需要记住什么。

当你在创造一个关卡时，你必须牢记玩家在这一关卡的最低需求。就像在我们的游戏中，我们使用了收费系统去决定玩家可使用的技能。玩家将通过游戏随机选择技能，游戏会提供给玩家各种不同能力，如控制机器人或隐形，而这些都是取决于他们所选择的技能。玩家每使用一种技能便需要消耗一些钱，而一旦他们的钱变为零，玩家便会失去技能。在这一系统中玩家并不能预测自己能够获得怎样的技能。结果便是，在《Subaeria》中只要一个行动便可击倒每个关卡。

而在创造一个关卡时我们还必须牢记1或2个技能。基于这种方式我们可以创造一个支持这些技能使用的关卡，虽然玩家可能只要采取一个行动便可以将其击倒。

我们还遇到的另一个问题是：我们不知道玩家在之前的关卡中是否已经遇到过另一种情况。为此我们选择的解决方法便是确保谜题难度较低。换句话说我们并未创造需要3个以上步骤才能解决的谜题。这也能够提升游戏节奏。如果机器人总是追着你不放并且你找不到任何走出这个房间的线索，你便不会感到有趣。

使用你的工具去控制内容。

随机性是任何roguelike游戏的基础。的确，玩一款带有不同布局的游戏真的会很有趣。但是对于测试过程来说这却非常可怕。就像在关卡1B中有4个机器人。

每个机器人都拥有4种类型。关卡1B可以用于带有各种关卡图像的3种不同环境中。为了有趣，让我们为每个机器人添加2至3种武器组合。现在关卡1B便差不多拥有50个以上的关卡。

当我们在创造自己的关卡时我们使用了刷怪点和敌人池。一开始我们并不能控制它们。一旦两个机器人出现在敌人池中，我们便不知道该选择哪个。

为了测试一个特定结合我们需要反复游戏直至获得运气并找到我们想要测试的配置。而程序团队创造了一些幻码让我们能够欺骗系统并无需改变之前的内容去设置我们想要测试的配置。如此我们便不需要再害怕犯任何书写上的错误了。

另外我们还应该在每次测试后在纸上做记录以反复测试每个关卡。这能够帮助我们不用担心丢失这些信息并对其保持实时调整。

对此的结论便是，因为在roguelike游戏中（游戏邦注：比起其它线性游戏）你不能有效控制玩家的路径，所以你必须牢记当你在设计关卡时你并不知道玩家的行李是哪个。

在一款游戏中，你总是希望能在提供给玩家复杂挑战前用一些相同类型的简单挑战让他们热热身。而在一款roguelike游戏中，你的玩家有可能在一款游戏中不会遇到任何可能的挑战。他也有可能会在游戏快结束的时候才遇到挑战。

在这种情况下你可以减少对于玩家技能和知识的期待值。尽量保证内容足够简单并确保所有情况都是有趣的！

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

Rogue-like and Level Design

by alexandre delisle

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:

Each Labyrinth is made of random rooms chosen from a pool corresponding to the difficulty level.

The skills and bonuses available to the player are selected randomly.

Each room must have 4 entry points.

Like most games, different elements are made available only on higher difficulty levels.

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!(source:gamasutra)