作者：Erin Robinson

如果你正同一个团队合作开发游戏，那么清楚地交流设计愿景是必要的。那么，要如何呈现自己的设计愿景呢？

对于游戏系统的描述，最著名的方法是编写游戏设计文件。但是，我比较偏向于更富视觉效果的方式，所以分享了以下5种可替代游戏设计文件繁琐文字同时又可交流设计愿景的方法。

1、图案

意向结果图案最能够总结你的设计目标。上周五我将以下这幅图发送给我的团队，展示我们将在接下来90天内于游戏《Gravity Ghost》中构建的系统：

Color Planets(from gamasutra)

即便你偏爱快速制作原型，然后进行迭代的设计理念，在每个阶段你也还是需要一个迭代润色游戏的目标。可视化目标能够让团队专注于重要的内容，避免设计师添加无关紧要的内容。不要低估这种图片给成员每日工作带来的灵感——我就将自己的原始草图黏贴在自己身旁的书写板上。

2、幻灯片（PPT）

如果你的游戏设计需要移动部分内容来解释设计愿景，那又怎么办呢？不要担心。演示软件是呈现游戏动作次数的绝妙方法。以下是我去年为某个教育游戏设计的Powerpoint文件。

PPT(from gamasutra)

最终的演示文稿包含了将近70张幻灯片，用来展示游戏玩法中的各个阶段。我针对每个动画进程条和分数的增加制作了新幻灯片。制作组合这些幻灯片耗费了我大约两个下午的时间，但与6到7周的开发循环周期相比，这个时间并不算多。

3、流程图

这是我让自己所有游戏设计学生做的事情。发明这种方法的人并不是我，我最先是从Steve Swink处学到的。流程图（游戏邦注：这类似于思维导图）背后的想法是，写出游戏所有的基本成分以及它们之间的相互关系。下面我们以《吃豆人》为例。

先写出游戏中所有的名词，通常情况下这是通过美术资产呈现的元素。

《吃豆人》名词(from gamaustra)

然后，将这些名词用合适的动词连接起来。这便是玩家在游戏中做的事情。

加上动词(from gamasutra)

接下来，写出各名词间的高阶关系。这些不一定会是玩家的直接控制，但是它们确实会让游戏变得更加有趣。注意那些增加游戏得分的动作以及在游戏中吞噬的不同目标。

更多动词(from gamasutra)

我希望这可以让你了解，即便是《吃豆人》这样的简单游戏也有如此复杂的内在框架。如果你尝试为自己的游戏绘制草图，要注意那些与其他成分没有连接的节点。游戏中的所有内容都要有存在的理由，绘制流程图有助于剔除那些不重要的内容。

以下是《Gravity Ghost》的流程图（游戏邦注：作者将游戏中某些关键功能进行了模糊化处理）：

《Gravity Ghost》流程图(from gamaustra)

尽管看上去比《吃豆人》复杂，但并没有多余的元素和成分。图片上半部分的相互联系有助于解锁游戏中随后的进程。

4、原型

交流愿景的最可靠方法是呈现可玩的内容。以下是《Gravity Ghost》早期原型的屏幕截图，游戏结合了基本几何、些许简单脚本和单个美术通道。

prototype(from gamasutra)

游戏感觉非常奇怪，控制方案还不完善。但是，游戏确实极具挑战性，玩起来也很有趣，首个测试者的着迷程度着实令我感到震惊。我不仅有了个可玩的原型，而且还知道了哪些内容需要提升。

你或许会认为自己的编程技能不足以制作出游戏原型，但是请记住：制作最基础可玩状态的原型并不需要许多编程经验。我学习Unityscript后两个月就开始构建《Gravity Ghost》。除此之外，我的编程经验仅限于在学校时学了一学期的Javascript，我几乎已经忘记这些知识。网络上有许多现成的可利用资源，另外别忘了，你还可以向好友求助。

5、模仿

模仿原有游戏的设计方案是呈现个人设计愿景的简单方法。要注意参考排名前100的付费iPhone应用，但不要抄袭。

展示游戏设计文件

如果你必须使用大量文字来解释游戏系统，那么可以在必要的时候随时使用图片。用可视内容和文字均可呈现自己的想法，提供充足的信息会让人们更了解你的想法。

以下是《Gravity Ghost》的截图，我将其称为“说明文件”，它并非真正的设计文件，因为我们并没有更新。该文件罗列了游戏的整体内容，我制作这个文件的目的是要将其发送给程序员。幸运的是，它实现了自己存在的目标，我找到了一个愿意为这个有趣世界效力的程序员。

tinydoc(from gamasutra)

希望上述内容对你的游戏设计有所帮助！（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

5 Alternatives to a Game Design Doc

Erin Robinson

If you’re building a game with a team, communicating the design vision in a clear manner is essential. So what does a game design look like?

The most well-known way to describe a game’s systems is by writing a Game Design Document. But I much prefer to work visually, so here are 5 ways you can communicate your vision without resorting to long blocks of text.

1) Illustration

Few things can sum up your goal like an illustration of the desired result. I sent this to my team on Friday, showing the systems we’re going to be building in our game Gravity Ghost for the next 90 days:

Even if you’ve embraced the philosophy of rapid prototyping and iteration, at each stage you need a goal to iterate towards. A visual goal can focus the team on what’s important, and help the designer avoid the temptation to add extraneous features. And don’t underestimate the daily inspiration such an image can provide – I’ve tacked up the original sketch right next to my scrum board.

2) Slide Show

What if your game needs moving parts to explain what’s going on? Not to fret. Presentation software is a remarkably easy way to present the actions of a game in sequence. Here’s part of a Powerpoint I made for an educational game contract I worked on last year.

The final presentation had nearly 70 slides illustrating steps in the gameplay. I made a new slide for every animating progress bar and score increase. It took me about two afternoons to put together, a small amount of time compared to the 6 – 7 week dev cycle ahead.

If you’re lucky, a series of mock-ups like this can do more than explain your goal: it can energize and inspire the team to do their best work. These particular mini-presentations were popular enough that sometimes a few of the senior faculty would sit in on our meetings. The goofy placeholder art and the informal nature of the presentation invited questions and discussion. It was a real boost for everyone – and reminded us that we were making something fun.

3) Flowchart

This is an activity I have all my game design students do. I didn’t invent this – I first heard about it from the wonderful Steve Swink. The idea is to diagram all the basic components of your game and visualize how they interconnect. Let’s take Pac-Man as an example.

Start by writing out all the game’s nouns. Most likely these are the components represented by art assets.

Then connect those nouns with the appropriate verbs. This is what the player does in the game.

Next, write out any of the higher-order relationships between various nouns. These aren’t necessarily in the player’s direct control, but they do serve to make the game more fun. Note the many actions that add to the game’s score, and how eating has many different purposes in the game.

I hope this helps to illustrate how even a ‘simple’ game like Pac-Man has an elegant underlying framework. If you try diagramming your own game, watch out for nodes that don’t connect to anything. Everything in the game should have a reason to exist, and this is a good way to cull the things that aren’t important.

Here’s the Gravity Ghost flowchart (with some exciting secret features blurred out):

More complicated than Pac-Man, but nothing too unwieldy. The interconnections in the top half of the image help to unlock progress later in the game, finally unlocking…well, you’ll just have to wait and see.

4) Prototype

One of the surest ways to communicate your vision is to make it playable. These are screenshots of an earlier build of Gravity Ghost, a game assembled from basic geometry, a few simple scripts, and a single art pass.

The game felt very strange, and the control scheme left a lot to be desired. But a game that’s really challenging can also be really fun, and I was amazed by how much the first playtesters got into it. I now had not only a playable prototype but a sense of what needed to improve.

You might think your coding skills aren’t up to snuff, but please take my word on this: you don’t need a lot of programming experience to make something playable in its most basic state. I started building Gravity Ghost about two months after I started learning Unityscript. My only other coding experience had been a semester of Javascript in school that I had mostly forgotten. There are plenty of resources online for this sort of thing – but don’t forget that you can hit up your friends, too.

Cloning

One easy way to demonstrate your design vision is to steal it from a game that already exists. Keep a close eye on the top 100 paid iPhone apps, and simply copy the most successful… just kidding. Never do this. Every time you clone a game an angel smacks a puppy.

Illustrated Game Design Doc

If you absolutely must explain your game’s systems using large blocks of text, use a visual aid whenever possible. Challenge yourself to present your ideas both visually and in words – people tend to learn better when given redundant information. For some more reading on the subject, check out Stone Librande’s excellent slides about One Page Designs.

This is a screencap of what I call the Gravity Ghost “spec doc” – not a true design doc, as we’re not updating it. The spec doc outlines the entire scope of the game in a broad sense – I created it to show to potential programmers. Luckily it served its purpose, and I found a programmer willing to dive into the fun world of radial planet gravity.

That’s it for this week. Hope it’s been useful! You can keep up with the action by following me (or the official Gravity Ghost account) on Twitter. (Source: Gamasutra)