獨立遊戲設計流程:從概念到寫碼的13個步驟

作者:Thomas Henshelll 譯者ciel chen

《Archmage Rises》是一個模擬真實的、活生生的世界的神奇模擬遊戲。在這裏,時間的流逝、人物隨着年齡的增長走向死亡,怪物肆虐。由於它是一個真實模擬遊戲,世界和遊戲人物會對玩家的所有選擇做出很現實的反應。我們的5人團隊做它做了大概有3年。

流程

步驟一,瞭解來源材料(或者說從瞭解“爲什麼”開始)

我們很幸運《Archmage Rises》受到遊戲網站Pen&Paper的RPG版面啓發,得到了大量可使用的資源。這一步並不是“Y系統的X特點很酷,我們也用它”這樣的套路——這種套路簡直是災難。這樣做會讓玩家產生什麼樣的情緒?玩家的具體感受會如何?覺得它靈巧、強大、聰明、有智慧、可以掌控之類的嗎?我們怎樣才能把這些感覺融入到我們的遊戲中;這個步驟是我們下了苦功夫爲前提基礎的:我們用了數百小時去玩和讀取各種遊戲資源。所以說步驟一是基於我們已經知道了自己想要做的是什麼樣的遊戲,而不是去尋找新的遊戲類型來做。
新想法並不都是好的,因爲畢竟他們沉澱的時間不夠長——就像雞湯一樣,原料必須在小火慢燉很長一段時間,才能烹調出香濃美味的雞湯。你要有本質特徵——這就是我們要強調的:本質特徵。

management thumbnail(from gamasutra.com)

management thumbnail(from gamasutra.com)

步驟二,分析他人的成果

既然現在你問了爲什麼,那就該深入地去了解每個人都做了些什麼。這讓你瞭解一些事情:

那些起作用的內容故事如何運作的?

在實踐過程中一些你可能未想過的新主意

你從沒思考過的問題和考慮。比如說——作爲參考的遊戲未必符合你所喜歡遊戲的標準,如果你不喜歡它,你要知道你不喜歡的原因。

在我們的遊戲中、D&D、探路者、D20都有土地所有權規定,尤其是在《A Magical Medieval Society》當中。像《Pirates》和《Pillars of Eternity》這樣的電腦遊戲就有土地所有權的存在;還有Sid旗下名氣比較小的《殖民擴張》也有。我不喜歡《pillars》,不過我很喜歡《Pirates》,不過我希望還能有更多這類的遊戲。

步驟三,25分鐘的頭腦風暴

我在不知情的情況下懂得了時間管理法(Pomdoro Technique)的技巧。如果你苦於想不出好主意或者相反地你在太多主意之間掙扎不知所措時,我發現這個技巧非常有用,通過它我們可以完成一些事,可以不斷前進。

花25分中的時間進行頭腦風暴,想盡一切你可以所能想到可以放在遊戲中最棒的內容——然後用你最快障礙最小的方法去選擇。對有的人來說,可能是一張黃紙、或者記事本,而我更喜歡XMind,因爲它的使用簡單又自由。

25分鐘足以讓你進入一個“好的思考狀態”,5分鐘是不行的——不過也足夠製造“良性壓力”(是的,有這麼一種東西),它讓你把核心想法沉澱下來心無旁貸,因爲時間在流逝!

嗷,對了,頭腦風暴的最好方式是獨自一人做,然後再把筆記和其他人的作比較,這樣更有效率。

在我頭腦風暴的最後,我列出了一些特徵,這裏是部分內容:

工人的任務

工人和奴隸的不同

被抓來的奴隸之間的比賽

改造土地的魔法

加強工人生產效率的魔法

季節性事件

不同的土地有不同的操作,有的收入隨機有的收入穩定

短線/長線思考——砍伐森林既得先進,不過這會造成浪費資源。

你的列表或長或短都不重要,你寫出來的都是你自己的想法——你的潛意識已經給你了一些對你來說真正重要的東西了。如果你的列表很短,你就會發現這個方法的功能並不如你想象中的好,或許是你不夠愛它把。那就回到第一步,或重複,或放棄。

我把這個列表稱爲特色列表,儘管這很讓人困惑,因爲它們是單個特性中的子特性。希望這樣說你們能懂。

步驟四,寫出簡潔的規則

這有點像編寫僞代碼的過去軟件技術。重點是它讓你去有邏輯地思考你的特性列表。列入“季節事件”,好的具體是什麼事件呢?什麼類型的土地會被哪些季節影響呢?讓自己儘可能地精確。Word文檔中的文本比代碼或者圖形要少83倍,這是一個可以進行迭代、刪除、修改的地方。

在我的土地所有權中,我做了個文本列表,寫出了我想要的土地類型,包括寶石礦、亞麻田、大理石菜市場、綿羊牧場和牲畜圍欄。不幸的是,着一些最後都沒有用上,所以我現在把它們寫在這裏還是和難過的。我喜歡這些注意,但是當我看到我的列表時,我知道這對玩家來說太複雜了,他們還跌弄懂木棉花、亞麻、食物等作物的區別。但是我還是把它們留在那裏,然後繼續下一步。

別研究得太用力了,這些都還要改的

步驟五,將概念轉化爲現實(在模型中)

現在可以看看你的新特性會是什麼樣子的了。編程者藝術萬歲!該行業也被稱爲“灰拳”。你想在2d或3D板塊看到你創造的特性。些“拖放工人在地面上”很容易,但是當你需要在屏幕上顯示所有不同的土地類型(圖標呢?文本呢?清單呢?)以及不同類型的工人(僱工、奴隸、建築工),重大問題來了:

我把工人名單放在哪裏好?

我要如何才能立馬知道一塊土地是在運作還是沒有的?(工具提示並不是一個滿意的回答。)

有那麼多的問題在這一步蜂擁而出。那些34種我認爲最棒的土地類型?是的,它們沒法以任何可理解的方式放在屏幕上,相信我,我試過了。:-)

爲了快速便捷地修改模型,我是用的是balsamiq3。

剛開始有點醜有點嚇人,不過這只是剛開始。

當你把那個不平衡得嚇人、又擠又醜的模型完成的時候,就是進入下一個步驟的時候了。

步驟六,把模型扔一邊,重新開始。

在60年代經典書籍《Mythical Man Month》上講了有關軟件開發的內容,Fred Brooks這樣說道:“你構建的東西是用來扔掉的。”

現代思想也有跟他一模一樣的說法——Lean Startup就說到過基本同樣的內容:快速失敗、吸取教訓、換個方向、繼續前進。

原理就是——第一次做事,你會犯很多錯誤,但是你不會再在這些錯誤上犯第二次。這也就是爲什麼我總是要拼兩次宜家傢俱的原因(真不是故意的我保證)。從實踐中習得的經驗是無價之寶。對事物的二次看法終究比初次的要好。所以就直接跳到對事物的第二次概念版本,把初概念永遠忘掉。

我覺的沒有必要重新再進行一次頭腦風暴,不過也許你還是會這麼做。我不喜歡讓壞主意攪壞了好想法,所以我開始會在Word文檔中用全新的頁面開始,並且在Balsamiq建立一個新的空白模板。我也試着不去參考之前的工作內容,因爲如果我想不起來的東西那它明顯對我來說沒那麼重要。這是我用來過濾想法、努力追求遊戲本質的一個小技巧。

還記得愛迪生和燈泡燈絲的故事嗎?你現在知道到底是什麼讓燈亮不起來的了把。所以就把所有的經過實踐驗證的經驗教訓攢在一起,你就擁有了一個超級厲害的第二次概念了。

步驟七,把初稿(第二次概念版本)展現出來獲得反饋

現在你有了規則和引以爲傲的遊戲模型。它還能變得更好嗎?不能!因爲它是你汗水和努力的結晶,它是完美的化身。

現在把它展示給團隊(或者只是一名團隊成員,這取決於你對初稿的自信程度了),然後他們會告訴你這份初稿的一切不對勁的地方。

我們的技術做不了這個

這個東西我得花很久的時間才能寫出來

太醜了

太讓人困惑了

這裏太複雜了/太簡單了

真是一羣混蛋!如果他們知道你所想的一切他們會明白這份初稿有多贊。

但是他們不知道你所知道的東西——玩家也是一樣。

這就是爲什麼他們的反饋總是偏向正確的。如果那些積極參與遊戲製作、比任何評論者或者玩家都要懂這款遊戲的人都明白不了你所謂的這份初稿好在哪裏,那他們就幫了你大忙了,他們讓你避免犯下一個巨大的錯誤。

步驟八,修正、迭代、再修正

當你回到你的工作間,停止哭泣,接受所有所有所有的反饋,然後建立起對遊戲的第三版概念、第四版甚至到第十版。爲了保留住你最初的想法去解決指向這個最初想法的所有問題。這說起好像很容易,但做起來很難,這也是我爲什麼簡單地寫下了這些話但是卻沒有配圖的原因。

步驟九,展示第三版設計稿給已經膨脹的團隊看
你解決了反饋的問題,現在你再次有了知道驕傲的東西。說實話,這個版本是比前一個版本要好。如果沒有被逼得這麼緊你不會走這麼遠。既然我這麼想,我似乎還應該感謝他們的批評助我成爲一個更好地設計師了對吧。這麼想的話,我們真的是一個好棒的團隊噢!
算了吧!這隻會鼓勵他們下次變得更挑剔刻薄。加上他們承認了他們的作用的話,他們會自滿得收不回來。還是把這些成熟的想法放在心理就好了. :-)

把第三個版本的稿子呈獻給相同的人或者其他人。看看是否還有什麼可以填補的漏洞。也許這個版本的已經穿上了“防彈衣”,也或許你還是漏掉一些東西。

第四個版本的管理界面模擬,我們將在第11步看到會發生些什麼。

步驟十,修正、迭代、再修正

不可避免地,在展示給別人看之後,證明還是有些東西是需要改進的。幸運的是這只是一些微調。

步驟十一,把它送到美工那裏進行美術加工

這是,設計稿已經很牢靠到足以做出一個遊戲原型了——是時候看看在它在合適的顏色、背景、UI、按鈕等等的演繹下會有怎樣的遊戲效果了。

步驟十二,團隊最後一遍檢查

當最終的模型完成時,該和團隊進行最後一遍的檢查了。美工可能發現了他/她在實際下手去做之前沒有意識到的問題。我們根據需要進行修正、這裏一般不會是太大的變動。

步驟十三,分配構建任務。

有了一個展示遊戲特性在遊戲中應有樣子的模型,還有解釋功能和限制的簡要規則,是時候開始真正的工作內容了。

等等,什麼?!

是的,以上全部都只是準備工作,讓大家能有開發遊戲的可執行任務的準備工作。在Scrum中,你可以稱之爲故事(the story)。現在看看它在遊戲中是如何發揮作用的,看看它是否與你在第一步嘗試的那種感覺/體驗相匹配。怎麼樣,遊戲開發很棒吧?當然了!不過對意志力薄弱的人來說並不。

對於最後的幾個特性,我和團隊花了大概40多個小時的時間才製作出來。

以上就是我們做事的流程。這意味着,我們只會在確定了我的第三版(或以上)的遊戲設計稿纔會開始做美術和編程,我覺得這是可以節省時間的;我們只在有着經審覈過的可靠概念情況下才開始構建遊戲。所有的在過程中被拋棄的概念都是不值得嘗試的。這就有點像精子和卵子——他們大規模地進行競賽,但是隻有其中之一是值得構建成型的。

本文由遊戲邦編譯,轉載請註明來源,或諮詢微信zhengjintiao

STEP 1. UNDERSTAND SOURCE MATERIAL (OR START WITH THE WHY)

We’re lucky Archmage Rises is inspired by Pen&Paper RPGs because there is a wealth of source material to draw from. This step isn’t “feature X in system Y is cool, let’s chuck it in”. That’s a recipe for disaster. It’s deep thought about WHY in that system X is cool. What emotions does it elicit? How does the player feel specifically, is it: smart, powerful, clever, wise, in control, pushin-it, etc? How can we get that feeling into our game.

This step is also based on already having done the research: hundreds of hours of playing and reading a variety of sources. This step is about already knowing something exists that I want, not finding it anew.

New ideas are no good because they haven’t simmered long enough. It’s like making Chicken Stock. The ingredients have to boil under low heat for a long long time, then you have something potent and delicious. You have the essence, and that is what we are shooting for: essence.

For purposes of example let’s use what I was working on this week: Land ownership and management. Why? Because I think it is compelling to earn property in the world. That is a cornerstone of a medieval world. I think it helps ground and expand the experience of “being there”. It also provides another entirely different revenue source of gold.

STEP 2. ANALYZE OTHER’S SOLUTIONS

Now that you have a why, it’s time to dive into what everyone else has done. This will give you several things:

How something that actually works works

Possible new ideas on implementation you may not have thought of

Problems/considerations you hadn’t thought of. For instance, the reference game doesn’t have to do what you want to do well. If you don’t like it you have to know why you don’t like it.

In our case D&D, Pathfinder, D20 have rules for land ownership especially in A Magical Medieval Society. Computer games like Pirates and Pillars of Eternity have land ownership in them. So does Sid’s lesser known game Colonization. I don’t like Pillars implementation, I really like Pirates but wish there was more.

STEP 3. BRAINSTORM ALONE FOR 25 MINS

I accidentally follow the Pomdoro Technique without even knowing it. If you struggle to come up with ideas, or conversely struggle with too many ideas, I find this technique very helpful to get stuff done; to move forward.

Spend 25 minutes brainstorming everything you can think of that would be awesome to have in the game. Do it in your tool of choice, whatever is fastest and presents the least barriers. For some it may be a yellow pad of paper, or notepad, I prefer XMind cuz it’s easy and free.

25 minutes is long enough that you can get a “good think” in, 5 mins is useless. Yet it is short enough in that it creates “good stress” (yes there is such a thing). It forces you to get the core idea down and nothing more, because time is ticking away!

Oh, and the best way to brainstorm is to do it alone first, then compare notes with others. Much more productive.

At the end of my brainstorm I had a list of features. Here are just some:

assignment of workers

workers and slaves vary

races of captured slaves matter

spells to terraform

spells to enhance worker productivity

seasons matter

different kinds of land behave differently, some random some steady income

short/long term considerations – chopping down forests for immediate cash but becomes Waste

It doesn’t matter how long/short your list is. Whatever you got is what you got. Your subconscious has provided you with what is really important to you. If your list is pathetically short, you now have a clue this feature isn’t as good as you thought or you don’t love it enough. Go back to Step 1 and repeat or abandon.

I call this list of stuff a feature list even though that is confusing since they are sub-features of a single feature. Hope it makes sense.

STEP 4. WRITE OUT CONCISE RULES

This is a bit like the old time software technique of writing pseudo code. The point is it forces you to think logically about your feature list. For instance “seasons matter”. Ok how exactly? What land types are affected by what seasons? Be as specific as you can. Text in Word is 83x cheaper than code or graphics, this is the place to iterate, drop, revise as much as you can.

In my land ownership I made a table in word and wrote out all the land types I wanted. It included gem mines, flax fields, marble quarries, sheep pastures, and livestock pens. Unfortunately none of that made the final cut and it makes me sad right now to write them here again. I loved those ideas, but once I saw my table I knew it was too complicated for the player to care the difference between planting cotton, flax, food, etc. But I persisted and kept it all in there for the next step.

Don’t study this too hard, it’s all going to change.

STEP 5. VISUALIZE IT (IN A MOCKUP)

Time to see what your new feature will look like with a mockup. Hurray for Programmer Art! Also known in the industry as “greyboxing”. You want to see your feature idea in 2d/3d space. It’s very easy to write “drag and drop workers on land” but when you suddenly have to show all the different land types on the screen (icons? Text? Lists?) and different kinds of workers (hirelings, slaves, constructs) important questions come up:

Where do I put the list of workers available?

How can I immediately know a land is being worked or not? (tooltip is not a sufficient answer. I’m looking at you Paradox!)

Tons of problems come out of this step. Those 34 land types I thought were so great? Ya they don’t fit on a screen in any comprehensible way. Trust me, I tried.

To make fast easy to modify mockups I use Balsamiq 3. The guys at Balsamiq live and breathe software mockups: They even provide recipes on their website so you can make a quick dinner and get back to designing mockups. Awesome!

It’s ugly and horrible, but it’s a start!

When your terrible lopsided, crammed, ugly mock up is done it’s time for the next step.

STEP 6. THROW IT AWAY, START OVER

In the classic 60’s book Mythical Man Month about software dev, Fred Brooks states:

“You build one to throw away.

— Fred Brooks

Modern thought, like that of Lean Startup, says essentially the same thing: fail fast, validate learning, pivot, move forward.

The principle is the first time you do something you make tons of mistakes you wouldn’t repeat. This is why I always build my Ikea furniture twice (unintentionally I assure you). The learning from doing is invaluable. The second version of everything is always better than the first. So let’s jump right to V2 and forget about V1 forever. I miss you copper and gem mines!

I don’t find it necessary to re-brainstorm but maybe you do. I don’t like bad ideas to cross contaminate good new ideas, so I start with a fresh page in Word and a new blank mockup in Balsamiq. I also try not to refer to the previous work because if I can’t remember it it clearly wasn’t very important to me. It’s a little trick I use to filter the ideas and strive for essence.

Remember Edison and the light bulb filament? You now know what doesn’t work. So gather up all that validated learning you just got and make a super awesome V2. Or V3, V4, etc.

STEP 7. PRESENT FIRST DRAFT(V2) FOR FEEDBACK

Now you’ve got rules and mockup you are proud of. Could it be better? No! Because you sweat and toiled over it and it is perfection incarnate.

Now show it to the team (or just one team member depending on confidence level) and they’ll tell you everything that is wrong with it:

Our tech doesn’t support that

It’ll take too long to implement this

It’s ugly

It’s confusing

It’s overly complex/simple

What a bunch of jerks! If only they knew everything you knew then they’d see how clearly awesome it is.

But they don’t know what you know. And neither does the player.

This is why their feedback is more right than wrong. If people who are actively working on the game, who know it better than any reviewer or player ever will, “don’t get it” then they’ve done you a great service and saved you from making a colossal mistake.

“Seek First to Understand, Then to be Understood

— Habit #5 Stephen R. Covey

Never defend: seek to understand. If someone says it is too complex ask why questions until you get something actionable. Perhaps the font is too small, or the list box shows 20 items when if it was only 8 at first it would be more easily assimilated. If they say they don’t like something provide them with “what I was trying to do here was X…” That’s not defending yourself, that is sharing your goal and maybe they can how suggest how you could better achieve that same goal.

STEP 8. REVISE, ITERATE, REVISE AGAIN

When you get back to your workstation, and after you stop crying, take allllllll that wonderful feedback and make V3 or V4 or V10. Keep to your initial vision but achieve it by solving the problems they pointed out. This is easier said than done which is why I simply wrote the above sentence and didn’t provide a picture.

STEP 9. PRESENT V3 TO EXPANDED TEAM

You worked through the feedback problems and now you have something you’re proud of, again. And truth be told, this version is better than the previous one. You wouldn’t have gone this extra mile if you hadn’t been pushed so hard. Now that I think of it, I should probably thank them for their criticism and helping forge me into a better designer. Come to think of it, this really is a great team we’ve got here!

Nah! It will only encourage them to be more critical next time. Plus acknowledging their efforts makes it that much harder to take all the credit once it is released. Best to keep these mature thoughts to yourself.

Present v3 to the same person and maybe some others. See if there are more holes that can be poked in it. Maybe it’s bulletproof, or maybe you missed a few.

V4 mock up of the Management screen. We’ll see what happens at step 11.

STEP 10. REVISE, ITERATE, REVISE AGAIN

Inevitably something will come out of showing others that can be improved. Your lucky if it is only minor tweaks.

STEP 11. SEND IT TO ART FOR AESTHETICS

It’s solid enough for a prototype. It’s time to see how it will actually look in game with the right colors, backgrounds, UI, buttons, etc.

Goodbye programmer art!

STEP 12. FINAL TEAM REVIEW

When the final mockup is done, it’s time to review with the team. The artist may have found problems he/she didn’t realize until actually working with it. Revise as necessary, usually there aren’t big changes here.

STEP 13. ASSIGN TASK FOR CONSTRUCTION

With a solid mock up showing what the feature should look like in game, and concise rules explaining functionality and limitations, it’s time to let the real work begin.

Wait, what?!

Yep, this was all just preparatory work to have an actionable task for someone to do on the game. In SCRUM you’d call it a Story. Now the hard work of seeing how it plays in the game, and seeing if it matches the feeling/experience you were trying to get at in step 1.

If not, well time to iterate! Yeehaw, isn’t game dev awesome?! Of course it is! But certainly not for the faint of heart.

For the last couple features put into production it has been about 40 hours of work including my time and the teams.

The process above is how we do things. It means we aren’t doing art or coding on something until it is V3+ which I think saves us time; we are building only solid vetted ideas. All the ideas that died along the way probably weren’t worth doing anyway. It’s a bit like the sperm and the egg, many start the race but only one makes it to construction. Construction is it’s own magical process.And with that awkward illustration, I’ll bid adieu!(source:gamasutra.com