作者：Danc

我恰好同时具有艺术师和设计师的技能，所以我时常会发现自己尝试为某些满是程序员的团队构建游戏创意原型。正因为如此，我总是在寻找更适合这种特殊团队组成的游戏开发技术。

下文我将阐述某个极为轻量级的原型塑造过程，使用的报是我很钟爱的报事贴便签。

最初的想法：我与程序员（游戏邦注：也可以是艺术师或UI设计师）坐下来商讨如何测试新的游戏玩法。通常，这些想法都出现于当天夜间或上一周。

报事贴便签设计：我草草地在报事贴便签上总结了我们的讨论。上次，我们讨论过后又复查了一遍，所有内容都显得很清楚。这个总结并没有包含细节内容。总的来说，它只是用于提醒我们所忘记的内容。

构建：程序员和艺术师离开后便开始构建便签列表上的物品。这个阶段可能需要2个小时或2天时间。我鼓励他们用富有创造性的方法来解决问题，如果某些内容毫无意义，他们也会告知我。

测试：当报事贴标签上的大部分物品完成之后，我把他们都召集起来，共同测试这些物品。我们还会请某些首次与机制互动的玩家来测试3-4分钟。

检查：随后，我们讨论我们观察到的测试结果，把值得改善的地方编写在另一张报事贴便签上。

重复或停止：这些过程一直重复，直到我们耗完时间或放弃。有时我们在每项测试和实验中花上1天时间，有时是两天。我们将实验当成是与时间博弈的任务。

评分：最后，根据下述标准对游戏玩法实验进行评分。

保存：保存代码，将些许选择的便签内容记录在包含“实验列表”的文件中，然后我们继续前进。即便是来自失败原型的大量代码通常也会在将来的游戏玩法实验中再次使用。

postits(from lostgarden)

评分系统

令人欣喜的是，评分系统很简单。目标在于快速对实验进行分类。

A：这些实验很有趣。玩家开怀大笑，通常展现出的是我们想要看到的情感。如果存在疑问，可以询问“是否有趣？为何有趣？”之类的问题。

B：这些实验中存在有趣的迹象，你认为可以让玩家表现出你想要看到的情感。但是，还需要投入更多精力来让玩家理解其中的乐趣。

C：毫无乐趣，实验失败。

趣味性的组合

这个方法中我最喜欢的方面是，最后你会得到一个游戏设计想法的组合。团队不再因一个或两个未证实有效的机制而承当所有的项目设计风险，用这种方法后团队就有了数个可以作为基础来构建已被证实有效的趣味性想法。有些人不适合玩这类游戏或者因某些其他的原因而无法成为目标用户，这一点并不奇怪。你可以失去少数玩家，但最终产品仍然会很有趣。应该从大部分玩家的角度来思考游戏设计。

与这种方法相对立的是采用指定“设计文件”方法，你被迫采用文件中未被证实有效的主要游戏机制。即便是对多数经验丰富的设计师而言，50%至80%的做法都将可能是完全失败的。你精心润色的每个未被证实有效的机制最终都会耗干预算和你作为设计师的名声。你可能会听到诸如“我们花3个月的时间开发这个想法，难道这还不有趣？”之类的评论。

基本观察

以下是我在构建原型时观察到的内容：

失败的实验发生次数很多。如果你发现C级实验发生的概率是50%到80%，别为此感到惊奇。团队中的每个人都必须注意，并非所有的实验都会获得成功，但是学习过程仍然是很有价值的。

自行设计是个至关重要的技能：每次咨询和分析可能都只会持续10到20分钟的时间，你需要在离开众人时怀揣着重要的便签，上面满是有效却容易实现的改变。你应该在这段时间内有大量的想法并对游戏机制有更深的理解，这些你才能在短时间内理解并应对大量尖锐的评论。如果你做不到，很可能就不是很适合担任游戏设计师。

倾听很重要。并非所有的解决方案都源于设计师。团队中的每个人都会有绝妙的想法。作为设计师，你的职责就是将所有的想法（游戏邦注：包括设计师和他人的）融合并为原型的下个阶段服务。

你需要程序员：如果没有程序员在构建原型时投入精力，那么原型就无法成形。你可以用纸张来设计原型，但是这种方法对许多机制并不合适，尤其是某些涉及时间和界面的机制。

高级观察

这些是某些相对难以理解的高深观点，但是却可以帮你免去大量麻烦。

介质游戏机制较难构建原型：将多个游戏玩法相联系的系统通常较难进行测试。它们通常需要耗费更长的时间（游戏邦注：需要数小时而不是数分钟），而且通常需要在游戏核心玩法已经很有趣的情况下才会有效。

构建可轻易链接游戏玩法实验的介质游戏架构：多数成功的游戏拥有团队可在找到新趣味点后便将其加入的架构。多数FPS中使用的线性“关卡——故事——关卡”样式就是个例证，《Mario 64》中使用的“集成许多子关卡”也是如此。所有这些方法都可以让你插入独立于其他游戏玩法实验的新实验。如果你没有此类的架构模式，你可能碰到的情况是，有趣的新系统会破坏你已经构建起的其他玩法。

整合游戏玩法实验是个难题：如果我找到了新的有趣武器和有意思的敌人AI，将这两个结合起来就不是个普通问题。新武器可能要在老AI中才能发挥效果，但是在新AI中完全无法起到应有的作用。所以应该整合一整套全新的实验。

好处

报事贴便签设计方法有如下好处：

能够应付大量原型化工作：设计师可能需要同时为多个程序员提供服务。这种方法很适合那些程序员多于设计师的团队，因为你需要在短时间内构建许多原型。

快速的失败既有趣又能让人吸取教训。你能够从每次失败中学到很多东西，而且在下次实验中就会更清楚哪些做法无法产生作用。

让劣质的想法很快消失。如果你有了具体的实验证明某些想法无用，那么就不会再去考虑这些想法。这样便可以节省下大量的时间和精力。

有趣的原型更有说服力：比起记录文件，有趣且可玩的疯狂想法的效能要高得多。

更容易组建团队：找到一个称职的设计师和一个称职的程序员通常都会比找到一个称职的程序员兼设计师要容易得多。能胜任两项工作的技能固然可贵，但是这种人才也非常稀少。组建团队还能够产生一个作用，就是可以交替训练你的设计师和程序员。你得培养出可以同程序员交流的设计师，以及可以提出某些设计想法的程序员。

廉价设计的价值

有人或许会经常听见以下消极评论：游戏设计是种廉价物。在任务庞大的设计过程中，持续涌现的想法也确实会带来些问题。如果你尝试将所有那些想塞进任务繁重的开发过程，这只会造成大量的浪费。每个设计都需要文件记录、概念设定、执行、测试和漏洞修正。

还有另一条路可循。轻量级创建原型方法会给你带来大量的疯狂想法，并只需投入中等成本便能将它们转化成分类良好的有效设计。事实上，并非所有想法都毫无价值，它们是供给优秀原型构建过程的必要燃料。每个想法都教会你些许东西或为你创造成功的机会。

让这个过程在项目开发之前便产生作用的方法是，构建轻量级的原型。除了我们的讨论之外，我还花时间编撰了两个设计文件：其一是为原型评分的简要列表；其二是整理一套暂时丢弃的报事贴便签。将不必要的加工带来的设计浪费降到最小。多数“编程浪费”都被划归为低成本的经验学习过程。

这些被抛弃的想法也并非毫无价值。它们只是在等待更能体现它们价值的项目而已。

结论

报事贴便签设计过程有可能在游戏开发中衍生出其他种形式。

如果你拥有一个设计师和程序员，可以尝试使用这种方法。相对于之前寻找程序员兼设计师的人并让他们尽力寻找趣味点来说，这是个极有用处的替代性做法。这两种方法都能够诞生出优秀的游戏。选择更适合你当前团队组成结构的方法。

这个过程确实需要些许成本，因为你需要至少两个人来寻找到趣味点。但是，采用这种做法得出的结果绝对会让你的成本付出物有所值。毕竟，将团队的时间花在发掘正确机制之上要比让程序员先待命然后朝错误的方向开发游戏要好得多。

最后要指出的是，这篇文章不是要阐述程序员、设计师、设计文件的职责，而是要说只有团队合作才能够做出正确的产品。其他的做法都只是自负的行为，而且是种浪费。

游戏邦注：本文发稿于2008年12月5日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Post-it note design docs

Danc

I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I’m always looking for better game development techniques that work well for this particular team mix.

Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.

Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.

Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn’t very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.

Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn’t make sense.

Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.

Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.

Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.

Rate: At the end, the gameplay experiment is rated according the scale below.

Save: The code is saved off, a few choice notes are recorded in a doc containing our ‘list of experiments’ and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.

Rating system

The rating system is delightfully crude. The goal is to triage experiments quickly.

“A”: These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask “Was this fun? How so?”

“B”: These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.

“C”: There wasn’t any fun. The experiment fails.

A portfolio of fun

One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don’t fit into the game or get abandoned for other reasons, that’s alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.

Contrast this with a prescriptive ‘design doc’ approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your ‘educated’ selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, “We spent 3 months of dev time on this lump of an idea and it isn’t fun?”

It doesn’t take very many expensive failures for the project’s perceived ‘design risk’ to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.

Some basic observations

Here’s a quick list of things I’ve observed when prototyping.

Failed experiments happen a lot. Don’t be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.

Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can’t, you likely are not suited to be performing the designer role.

Listening matters. The designer doesn’t need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
You need programmers: If there aren’t programmers dedicated to prototyping, the prototyping isn’t going to happen. You can drop down to paper prototyping, but it usually doesn’t prove out many types of mechanics (especially ones involving timing and interfaces.)

Advanced observations

These are some notes that are a bit geekier, but can save you large amounts of pain.

Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.

Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear ‘level-story-level’ pattern used by most FPS is one example. The ‘hub with many sub levels” used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don’t have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you’ve already discovered.

Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.

Benefits

There are some interesting benefits to the Post-it note design method:

Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.

Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn’t work.

Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won’t work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.

Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.

An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.

The value of dime-a-dozen designs (A brief aside)

One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.

There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.

The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the ‘programming waste’ is better classified as low cost learning.

Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized.

Conclusion

The “Post-it note design process” has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.

If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to ‘find the fun’. Both can produce great games. Pick the one that works best for your current team composition.

This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to ‘save your programmers’ so they can be off running really fast in the wrong direction.

In the end it really isn’t about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note. (Source: Lost Garden)