創造一個優秀關卡的完整過程

作者:James Buckle

身處一支開發團隊意味着我需要更快速有效地工作。我創造了一個製作遊戲關卡的過程,並且該過程也適用於其他人身上。我是從作爲《幕府將軍2》的測試員便開始創造這一過程,那時候的QA團隊將爲多人遊戲和定製戰鬥設計一些地圖。我發現使用可行的遊戲玩法能夠幫助我更快速地創造出關卡,就像在《幕府將軍2》中,我只需要一個多小時便能夠設計出一張2平方千米的地圖。或許對於一名資深關卡設計師來說這裏的內容沒有什麼幫助。但如果你發現自己需要設計一系列關卡並且你之前從未做過這些事,或者你只是對我如何設計自己的關卡感興趣的話,你都可以從本文中找出答案。

瞭解規則

在我完成了《Captain Kaon》的簡單遊戲原型後,我創造了一個“初步可遊戲”關卡。這是關於一個嘗試着再現潛在的最終遊戲的垂直切面。關於團隊爲什麼要創造一個“初步可遊戲”關卡存在各種原因,但是在本文中我們將只專注於其中的一個原因。即比起同時輾轉於多個關卡中,專注於一個關卡並將其做好會更有幫助。

一旦你明確了樂趣與問題所在,你便可以在這個關卡上進行迭代並擴展。而如果你正同時創造多個關卡,你可能會浪費許多時間去維護它們。每次當你在你的關卡設計中發現一些問題,並且你需要使用一些全新規則時,你便需要貫穿所有關卡去使用新規則。這就像在一定間距內不會放置兩個同樣類型的內容或設置一個最小走廊寬度而爲遊戲玩法留出足夠空間一樣簡單。如果能在第一個關卡便明確所有這些規則的話,你便能夠避免之後繁瑣的重複工作。

使用初步可遊戲關卡我便能夠創造一組嚴格的規則和靈活的指南幫助自己之後的關卡創造。這是我在設計關卡時必須牢記的重要事宜,否則我將會在遊戲測試時發現一些基本問題並且需要浪費時間去解決這些問題。例如:

房間的邊緣必須鋪設三個更寬的磚塊以確保攝像機是連接着房間的邊緣。

玩家期待能夠與無人機對抗的區域至少應該是基於2×2的磚塊,如此玩家才能在此自由移動。

除此之外,我還能夠爲遊戲關卡創造一個技術要求清單。這是我在確保關卡第一次運行時需要經歷的一些步驟。雖然很多內容看起來很明顯,但這也是我們很容易忘記的內容:

設置一個玩家生成對象

設置物理屬性

在前端添加簡介

一旦你決定了你的指南和規則,你便需要在此進行迭代去創造可行關卡的變量。到目前爲止《Captain Kaon》將經歷42個關卡和19個任務,並且每個關卡都是不同且非常有趣的。而最棒的地方在於創造這些關卡是一個順暢且輕鬆的過程。

建立一個組件面板

伴隨着你創造關卡的規則,你還需要一個基礎組件面板。一款遊戲其實也是一個不斷升級的挑戰系列,並且這些挑戰都是伴隨着不同組件組合所創造的。讓我們舉個例子來說吧,假設存在一系列房間,每個房間中都有一個敵人。如果你只設置一種敵人類型,那麼很快的你的遊戲便會開始具有重複性。敵人是你用於創造關卡的一種組件類型。通過使用不同類型的敵人,基於不同數量和組合,你便能夠創造出不同的遊戲體驗。然後你可以使用其它遊戲玩法組件,如障礙或升級道具,並結合它們去創造更多遊戲玩法變量。

遊戲同樣也是一種視覺體驗。你需要將你的“最初可遊戲”關卡分解成不同的視覺組件併爲它們創造變量。最終你將擁有一個小小的組件面板能夠用於創造你的關卡。

電子表格

我創造了一個帶有關卡信息的電子表格,它讓我能夠追蹤自己所處的關卡設計和創造的不同階段。它還讓我能夠看到自己組合了什麼類型的關卡,而這能夠有效地阻止重複性的出現。

不管你在遊戲中添加什麼類型的關卡,你都必須避免它們都是相同的,或出現連續兩個相同類型的關卡。在《Captain Kaon》中我便添加了不同任務類型。在某些任務中你可以摧毀一些關鍵目標,偷偷執行一些任務,或者從基地中運載某些東西到其它地方。當我在規劃自己的關卡時,我始終確保不會連續出現兩個相同類型的任務。我同樣也設置了關卡所處的視覺環境,以防止頻繁出現視覺重複。

有時候你必須基於宏觀層面去看待你的遊戲。你需要思考不同關卡間的體驗是如何發生改變。而在電子表格中瞭解這些情況便是一種不錯的方法。這同樣也讓你能夠基於任何順序去處理關卡,或者將其遞交給其他團隊成員,並確保在完成關卡創造時它們仍然能夠有效地組合在一起。

紙上計劃

不管何時當我開始設計關卡時,我總是能通過電子表格清楚地看到自己需要做什麼,然後我便會拿起筆和紙去寫下一個基本計劃。在此你並不需要使用一張完整的A4紙,因爲如果你使用的紙張空間越大,你便需要想出更多東西去填滿它。當我在設計《幕府將軍2》的戰鬥時,我便先繪製了一張一英尺的方形地圖,並且它最終將變成2千平方米的地圖。

開始時我會使用一根淺顏色的鉛筆(通常的粉色)去畫出一條抽象的路線,通常情況下這都是一條扭曲的線。而這條路徑將會組成關卡的基本框架,即從玩家的誕生點延伸到關卡目標。而這條路線主要包含4個要點:

它不能太直,這樣很容易變得無聊。

它不能太曲折且過度重疊。

它不能與你之前畫過的線相似。如此你便只是在重複一個關卡。

它不能原路折回,這會讓玩家迷失方向。

level(from gamasutra)

level(from gamasutra)

一旦你明確了玩家的前進方向,你便能在路線上標記一些關鍵功能點。從抽象意義上看,一個關卡便是玩家所做出的一系列決定。如向左走,撿起鑰匙,爬上樓梯。你需要思考哪些內容將出現在你的關卡的哪個部分。並準確地在路線上標記出這些點。

level2(from gamasutra)

level2(from gamasutra)

隨着框架的就位,你可以開始思考該在關卡的每個部分放置哪些組件。它們該如何分配,並且該如何進行彼此間的互動?你可以使用一支2B鉛筆去繪製這些組件並圍繞着它們畫出牆的輪廓。

level3(from gamasutra)

level3(from gamasutra)

這將提供給你一個基本計劃。但是在此之前你應該先在腦子裏運行一遍關卡。你可以着眼於紙上的內容並基於“最初可遊戲”關卡的運行而嘗試着想象它是如何運行的。從中找出問題所在。比起刪除一堆關卡內容,擦掉用鉛筆畫出來的線肯定輕鬆很多。

磚塊,組塊等等內容

當你第一次創造一個關卡時,你必須避免在創造出完整內容後才首次運行它。你已經將你的計劃寫在了紙上,並且你應該對它能夠創造出一個功能性強且可遊戲的關卡充滿自信。這時候的你將能更輕鬆地繼續下去並創造出一個完整的內容。但需要記得的是,即使一個理念在紙上看來很出色,但是當你開始執行它時它卻不一定還是那麼出色。你需要基於不同階段去創造關卡,並及時審查它們的功能性與樂趣。

我是在GameMaker上創造《Captain Kaon》,而關於關卡我使用的是內部編輯器。

我是通過tileset創造背景,然後使用無形的物理對象作爲碰撞對象。我遵循了自己在紙上寫的計劃並只放置了基本組件去構建關卡;我也因此得到了一個關卡的基本框架。這時候你需要再次開始思考玩家將如何玩這個關卡。如果你已經玩過你的“最初可遊戲”關卡,你便會清楚玩家角色及其敵人是如何移動的。你應該着眼於你正在創造的關卡並在腦子裏構思它是如何運行的。這將幫助你看清這個關卡所存在的潛在問題以及完善方法。這時候你應該將你的想法記下來,並親自運行關卡去驗證這些問題和方法。

測試與調整

一旦你擁有一個基本的關卡版本,你便能看到它是如何運行的。潛在問題是如何呈現出來?所有組件是否能夠有效運行?你需要儘早做好這些,如此你便能夠儘快找出任何根本問題並解決它們。當我在做這些時,我總是喜歡降低AI的生成率,並減慢危險出現的速度。而當我準備好進行測試時我會再次將它們放回原位。

如果你對功能的運行感到滿意,那麼關卡的創造便算完成了,你可以開始思考如何確定關卡的邏輯。玩家完成關卡需要經歷的行動序列是否仍然有效?是否存在任何內容會讓他們感到困惑或混亂?

基於一個功能性關卡,你可以開始一個遊戲與調整的循環。你可以想辦法在玩家體驗中梳理解決方法。邀請一些朋友前來遊戲並在旁邊觀看他們遊戲,觀察他們是否會做一些你並未猜到的想。甚至直到戲發行時你也可能仍在調整一些古怪的內容,

優化它並整合它

一旦你對關卡的運行感到滿意,你便可以開始擔心它的外觀了。在創造一個真正吸引人的關卡時,優化它的外觀是非常重要的一步,如果缺少了這一步,你的遊戲便不會完整。不幸的是你也需要爲此花費更多時間。就拿我來說,爲了執行這一步,《Captain Kaon》關卡的開發時間增加了一倍,即從2天增加到了4天。如果你在一個關卡中優化了更多內容,你便必須在剩下的關卡中優化更多內容。

而合理安排優化時間卻是一個很容易被遺忘或低估的方法。作爲計劃一個任務的常見法則,你應該將任務一分爲二。第一部分是計劃和執行,第二部分則是修改和優化。明確你需要花費多長時間進行計劃與執行,然後再思考需要多長時間進行優化。

一旦完成了關卡創造,你便需要將其帶到遊戲中,並讓其他團隊成員嘗試它並提供有價值的反饋。我便遇到過需要手動複製關卡並使用腳本去執行它的情況。這將在你的關卡和能夠提供給你反饋的人員之間創造一道障礙。所以你必須確保團隊中的所有人都能夠直接切輕鬆訪問到你的關卡。

本文爲遊戲邦/gamerboom.com編譯,拒絕任何不保留版權的轉發,如需轉載請聯繫:遊戲邦

Level design; from paper to screen

by James Buckle

Being a dev team of one means I need to work quickly and efficiently. I’ve developed a process for producing my levels that will hopefully be useful to someone else out there. I first developed it back when I was a tester on Shogun 2, when the QA team got to do some map designs for multiplayer and custom battles. I found it helps me quickly produce levels with viable gameplay, for Shogun 2 it took me a little over an hour to design and create a 2km2 map this way. There might not be anything for an experienced level designer to learn here. But if you find yourself having to design a bunch of levels and you haven’t done it before, or you’re just interested in how I design my levels, I hope this is useful.

If you’d like to see the fruits of my level design labours you can have a go on the Alpha build of Captain Kaon, there is a download link to the latest version on my Greenlight page available via the web, or on the Steam App.

Get Some Rules

After I had made a simple prototype of the game that would become Captain Kaon I made a ‘first playable’ level. This is a vertical slice of the game that tries to represent the potential final game. There are lots of reasons why a team does a ‘first playable’ level, but for this blog there is only one thing to focus on. It’s better to work on one level and concentrate on making it good, than to juggle several levels at once.

Once you figure out where the fun is and spot problems, you can then then iterate and expand on this level. If you’re building several levels at once you will have to waste a lot of time just maintaining them. Every time you figure out something with your level design, a new rule that needs to be applied, you will have to go through all your levels and apply it. It could be something simple like not placing two objects of the same type within a certain distance of each other, or having a minimum corridor width that allows enough space for gameplay. It’s better to figure out all these rules on one level first, otherwise you’re just redoing every level all the time.

Using my first playable I was able to establish a set or rigid rules and flexible guidelines for creating levels. These would be important things that I would have to bear in mind when designing the levels, otherwise there was a risk that playtesting would expose basic problems I would have to waste time fixing. For example

The edge of the room must have a border of three tiles to ensure the camera does butt up against the edge of the room.

Areas where the player is expected to fight drones should be at least 2×2 tiles in size to allow the player to manoeuvre.

In addition to this I was able to create a checklist document of technical requirements for the level to function in the game. These were steps I would go through to ensure the level ran first time. They were mostly obvious things that were easy to forget about, such as:

Place a player spawn object

Set the physics properties

Add the briefing and hook up to the frontend

Once you’ve determined your guides and rules you have something to iterate within to produce variations of working levels. So far Captain Kaon has 42 levels across 19 missions, each one different and fun. But the best part, creating them was a fluid and painless process.

Building a component palette

Along with your rules for building a level you need a palette of components to build it from. A game is a series of escalating challenges, each built with a different combination of these components. Imagine a series of rooms, each one has an enemy in. If you only have one enemy type to place in your rooms, your game will rapidly become repetitive. Enemies are one type of component you use to build your levels. By taking different variations of enemies, in different quantities and mixes, you will be able to build different gameplay experiences. You can then take other gameplay components, such as obstacles and power ups, and mix those in to create further variations in gameplay.

A game is also a visual experience. You need to break your ‘first playable’ level up into different visual components and create variations of these as well. In the end you’ll have a nice little component palette from which to build your levels.

The evil of spreadsheets

I created a spreadsheet with level information, it allowed me to keep track of which stages of designing and creating the levels I was at. It also allowed me to see what kinds of levels I was stringing together, which was important in preventing repetition.

Whatever types of levels you have in a game it’s important that they aren’t all the same and that no two of the same type are consecutive. I have several different mission types in Captain Kaon. In some you are destroying key targets, some are sneaky recon missions, and in others you could be carrying stuff to or from your base. Within each of these there are sub-mission types. When I planned out my levels I ensured that no two missions of the same type followed each other. I also set which visual environment the level will take place in, too prevent too much visual repetition.

It’s important to take this kind of macro-level look at your game sometimes. You need to think about how the experience changes from one level to the next. Keeping track of it in a spreadsheet is a great way to do this. It also allows you to tackle the levels in any order you like, or spread them around the team, and ensure they all still come together when they’re finished.

Paper planning

Whenever I start designing a level I get a basic feel for what it needs to do from my spreadsheet, then I get a pencil and paper to draw out the basic plan. You don’t need to use a whole A4 sheet for this, the more space you have, the more you will try to fill it. When I designed Shogun 2 battles I started by drawing a one inch square for a map that would end up 2km across.

I start by using a light coloured pencil (usually pink) to draw an abstract flow line, essentially it’s a wiggly gesture line. This path forms an underlying skeleton to the level, going from the players spawn point to the levels objectives. There are four important things with this flow line:

It can’t be too straight, straight is boring.

It can’t be too wiggly, windy, and over-lapping. It needs to flow.

It mustn’t look like one you’ve already drawn. You’ll just be repeating a level.

It can’t double back on itself, the player could get lost.

Once you have an idea of the direction the player will be going in, you can start marking points on the flow line for key features of the level. In an abstract sense a level is a series of decisions that the player makes. Walk left, pick up key, climb ladder. You need to think about what, and where, these will be on your level. Mark these out evenly on the flow line.

With the framework in place you can start to think about which components you’ll put together in each section of the level. How will they be arranged, how will they interact with each other? Using a nice 2B pencil you can draw in these components and then draw the wall outline around them.

This will give you the basic plan that you can sit in front of an editor with. But before you do that, you should run through the level in your mind. Look at your piece of paper and try to visualise how it will play, based on how the ‘first playable’ level played. Try and spot problems. It’s a lot easier to erase a pencil line than delete a bunch of level content.

Tiles and blocks and other things

When you first create a level it’s important that you not try to create the entire thing before you run it for the first time. You’ve got your plan on paper and you should be confidant of it producing a functioning, playable, level. At this point it would be easy to just plough on and create the whole thing. But remember, great ideas on paper aren’t always great ideas when you execute them. You need to build you level in stages, checking each for functionality and fun.

I’m making Captain Kaon in GameMaker, for the levels I’m using the internal editor. Some people have used GameMaker to create a level editor for their games, which seems like a pretty smart thing to do. If I’d thought of that I might have tried doing it as well.

I build the background from a tileset and then use invisible physics objects as collision. I follow the paper plan and construct the level placing only the most basic components required; this gives me the bare bones of a level. At this point you need to start thinking, again, about how the player will play the level. If you’ve played your ‘first playable’ level enough you should have a feel for how the player character and enemies move. You should be able to look at the level you are constructing and build a picture in your mind of how it plays. This will give you an idea of potential problems and improvements. But don’t make them yet. Write your thought s down on a pad, you need to run the level and confirm them.

Test and Tweak

Once you have a basic version of a level you can see how it plays. How do the potential problems pan out? Are all the components hooked up and working correctly? You need to do this early so you can find and fix any fundamental problems. I usually like to reduce the spawn rates of the Ai and slow down the speed of the hazards when I do this. I then dial it back up once I’m ready for playtesting.

If you’re happy that the functionality works and that the level can be completed, you can think about how the level logic holds up. Does the sequence of actions the player has to go through to complete the level still make sense? Is there any point they might become confused or disoriented?

With a functioning level you can begin a cycle of playing and tweaking. Find little ideas to tease out improvements in the players’ experience. Sit some friends down and watch them play the game, see if they do anything unexpected. You’ll probably still be tweaking the odd thing right up until release.

Polish it up and plug it in

Once you’re pretty happy with how the level plays and feels you can finally worry about how it looks. Polish is an important step in creating a level which is alive and engaging, without it your levels will be sterile. Unfortunately it will also massively increase the amount of time it takes to create your level. In my case it doubled the time a Captain Kaon level took from 2 to 4 days. This can mean you’re creating a rod for you own back. The more you polish one level, the more you have to polish the rest.

Factoring polish time into your game is an easy thing to forget or underestimate. As a general rule for planning a task you should divide it in two. The first part is planning and executing, the second is fixing and polishing. Figure out how long it will take you to plan and execute and then add it again for polish.

Once your level is done it needs to be properly plugged in and accessible in the game, for the sake of the rest of your team and their valuable feedback. I’ve worked in situations where levels needed to be manually copied and then executed by fiddling with scripts. This creates a barrier between your level and the first people who can give you feedback. Your level needs to be immediately and easily accessible to everyone on the team.(source:gamasutra)