游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

独立游戏设计流程:从概念到写码的13个步骤

发布时间:2017-10-19 10:22:43 Tags:,,

作者: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


上一篇:

下一篇: