有關roguelike遊戲的關卡設計

作者:Alexandre Delisle

roguelike遊戲中的關卡設計與傳統的線性遊戲的關卡設計是完全不同的。我將在下文解釋其中的原因。

爲了描述roguelike遊戲中的關卡設計,我將使用我在iLLOGIKA所開發的遊戲《Subaeria》爲例。

Subaeria(from duotegame)

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)