作者：Danc

若你依旧践行或鼓励书写冗长的游戏设计文件，这将给团队和公司带来大麻烦。冗长设计文件体现和倡导一个错误世界观——制作游戏的最有效方式是创造固定编程标准，然后交由开发者落实。

大型游戏开发项目通常受此假设所误导。早期的资源预分配会打断挖掘游戏乐趣所在的探索性迭代过程。你不是通过游戏测试而找到令人愉快的体验，而是盲目完成某些无效书面幻想。但我们仍旧需要文件资料。为什么？

* 我们需要稳定的决策智囊团：团队包含众多人员，交流通常异步进行。没有集中文件，你只能进行片段交流，很多基于一对一沟通所做的决定不被多数其他团队成员认同。

* 我们需要共同的未来愿景：文章能够协助锻造下个游戏版本的共同愿景。在所有人都有不同坚定观点情况下，有人需通过清楚陈述下款作品内容引导团队。

Play-notes(from lostgarden.com)

设计日志

我目前正在做的是书写被我称作“设计日记”的东西。游戏设计是个探索循环过程，而非固定编程计划。设计文件应遵循此原则。

如何书写设计日志

1. 以某概念开始：设计日志的基础元素是最初概念。这是最初开始设计的粗略想法。这通常为2-10页，包含一定文本、图像和灵感，能够启动项目开发。我通常关注我们最初建模的核心互动循环。

2. 创建模型：设计日志是游戏操作版本的补充。在力所能及范围内，制作能够体验的内容。要摒除那些有违经验和直觉的图像、功能、情节等元素的设计。

3. 添加日常记录：在频繁操作游戏模型后，在设计日志中添加基于游戏概念的日常记录。这包含日常游戏注释，优先下步举措及想法。日常记录的目标是推动项目前进。你会不断试图回答“如何完善当前游戏？”这个问题。

4. 重复：每天或每隔1天，你都要添加新日常记录，这样旧记录就会滚动至屏幕下方（游戏邦注：和博客一样，新鲜内容总是置于顶部，而旧内容则置于底部）。

有关日常记录，我总是试图保持如下格式，但它其实相当灵活。

design-log(from-lostgarden.com)

* 标题：标题就是今天的日期。

* 游戏注释：这是设计师对每日工作日程的反馈。我会罗列今天运作顺利的内容和遇到的问题。对于每个遇到的问题，我总是试图寻找适当解决方案。

* 优先下步举措：若罗列的问题很长，我会排列它们的处理顺序。有时若积压工作很多，我就会制作这个列表。反应灵敏人士不妨把它当作当前积压工作列表。若你在某时刻不需要这部分内容，就不要添加它。

* 完成任务：工作完成后，我们会把它标记在文件中。有些团队会在日常记录中添加完成工作列表。而有人则会直接在文件中删除注释。

* 实验：重大疯狂实验通常会大大推动游戏进展。缺乏这种实验，你就无法最大化推动项目进展。

创建设计日志的工具

我个人喜欢在设计日志中使用Google Docs，以下是其优势所在：

* 及时沟通：能够多人同时编辑文件。我经历某些编辑高峰期，同时有3个人拼命添加和处理评论。这样可去传阅或者管理不同版文件的麻烦。

* 文本相关评论：大家能够评论特定文本内容。他们同时能够回应这些评论。这促使沟通瞄准特定细节，而不是简单挥手示意。这可避免大家不知所云地讨论，偏离项目核心话题的情况。

* 能够处理评论：一旦评论内容完成，解决方案重归文件中后，你就能够处理评论，将其隐藏。这保持文件整洁，让你获悉何时前进。

* 邮件通知：当有人添加评论，其他订阅文件的用户就会收到邮件。这是个回访机制，将团队忙碌人员重新带回文件中。

创建设计日志的糟糕选择：

* 微软Word：这是一款缺乏适当协作性的工具，通常形成上锁文件、覆盖文件和停滞交流的结果。虽然Word是独一无二的常用文字工具，但对游戏设计师们而言这仍旧是个糟糕选择。

* 邮件：邮件能够让你完美回应特定问题，但沟通思路会迅速分散。或者你会得到堆积成山的反馈邮件。在短期问题方面，它能够合理运作。就那些持续超过1周的设计项目而言，这种归档式只会让工作陷入一片混乱。

* 博客：无法将评论直接附于文本中是个主要缺点，因为其他人无法同时编辑帖子。很多开发者有创建开发者博客，但其更多像是一对多媒介，而非推动游戏发展的合作交流。偏好博客媒介的开发者需考虑这些颇具挑战性的问题。

有效使用设计日志的小建议：

* 一天内不要添加过多内容：设计师很容易在一天内就添加几十页注释和观点。这种信息量会让团队成员无法消化。最佳的阅读法则是确保日常注释能够在5分钟内读完。即便是大型团队，其一天完成的工作内容记录也不会超过1-2页，所以应该有所侧重地自我编辑或关注那些影响巨大的事项。在游戏设计上不要重视数量而忽视质量。不要通过文件“纸上谈兵”，不妨在团队成员间走动走动，想想项目的实际进展和问题。这样你的设计才会有所提高。

* 对于较大型团队，可以考虑制作若干日志。我们一个项目通常都有一个设计日志和美术日志，这能够合理区分讨论话题。我特意选择同小团队共事，所以我很好奇这个理念如何在工作任务繁重的团队中得到运作。

* 确保多方交流，而不是单人独角戏：根本来看，良好的设计是个持续沟通过程，而不是个人独立行为。通过谈论设计内容，每个人都能够吸收设计，将其变成自己的观点。没有沟通和交流，你得到的不过是毫无意义的文字。

优点

这些是我从设计日志模式中发现的优点，它们也是任何良好设计过程所具备的特性。

* 真实性：设计日志主要基于上个工作内容，能够避免设计师周旋于自己幻想出来的东西，从而脱离项目的实际情况。

* 可操作性：每天都有一些我们能够完善的内容。鲜有完全基于理论而不具操作性的内容。

* 共同参与性：每个人都能够参与其中，给予评论和建议。设计注释通常具有引导评论和提示想法的作用。

* 有所侧重：这不是个链状维基百科。设计文件自始至终都有清晰思路。即便是新成员，你也能够处理文件，读懂游戏发展故事。

* 新鲜感：日志最顶端的内容通常是最近工作的总结。陈旧内容就会降至文件底部。这能够确保文件具有阅读价值，促使你创建动态发展的文件。

* 灵活性：你掌握的设计动态情况越多，就越能够轻松把握最有发展潜力的内容。对很多团队来说（游戏邦注：特别是试验生产阶段的团队），设计日志能够取代积累工作和任务列表。

更重要的是，游戏设计日志符合设计性质：这是逐步发展游戏设计所具有的根本属性。从本质来看，这是一种反馈你所制作内容的功能性产品。你试验新内容，你调整原以为能够运作的内容，获得双倍回报。设计并不仅是个执行计划。设计是个灵活过程，是源自于团队协作的结果。这是玩家、机制、团队、人才和设计的连锁反应。其出发点很关键，但无法完全决定最终结果。

在动态发展世界中，无人问津的设计手册毫无立足之地。而设计日志非常符合趋势，它能够帮助开发者避免过多注重完成预定功能。积极的设计日志可以促使开发团队借鉴杰出游戏开发过程中的迭代精神。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Game Design Logs

by Danc

If you still practice or encourage the outdated practice of writing long design documents, you are doing your team and your business a grave disfavor. Long design docs embody and promote an insidious world view: They make the false claim that the most effective way to make a game is to create a fixed engineering specification and then hand that off to developers to implement feature by bullet-pointed feature.

Great game development is actively harmed by this assumption.  Pre-allocating resources at an early stage interrupts the exploratory iteration needed to find the fun in a game. A written plan that stretches months into the future is like a stake through the heart of a good game process. Instead of quickly pivoting to amplify a delightful opportunity found during play testing, you end up blindly barreling towards completion on a some ineffectual paper fantasy.

Yet, there is still a need for documentation.  Why?

* We need a persistent repository of decisions: Teams include many people and conversation occurs asynchronously.  Without centralized documents, you end up with a fragmented conversation where many decisions made in one-on-one conversations are lost to the broader team forever.

* We need a shared vision: Documents also helps forge a common vision of the next iteration.   In a situation where everyone has strong and varied opinions, it is essential that someone can lead the team to by unambiguously stating what comes next.  Apparently even God needed documentation.

Design logs

What I do now is write a little something I call a ‘design log.’ Game design is a process of informed iteration, not a fixed engineering plan that you implement.

The form of your design documentation should flow from this philosophy.

How to write a design log

1. Start with a concept:  At the very bottom of the design log is the initial concept.   This is the rough idea started the design in the first place.  These are 2 to 10 pages long and contain just enough text, images and inspiration to start development.  I usually focus mine on the core interaction loop that we want to first prototype.

2. Build the prototype:  Design logs exist as a supplement to a working version of the game.  Make something you can play as soon as humanly possible.  Kill graphics, features, plot or anything that gets in the way of making a game you can react to on a tactile and experiential level.

3. Add a Daily Entry: After substantial fiddling with your prototype, add a daily entry above the concept to your design log.  This contains daily play notes, prioritized next steps and ideas.  The goal of the daily entry is to move the project forward. You are constantly trying to answer the question “How do we improve the current game?”

4. Repeat: Every day or two, you add a new daily entry and the old ones eventually roll off the bottom of the screen.  Much like a blog, the fresh stuff is at the top and the old stuff is at the bottom.

For the daily entry, I try to keep to the following format, but it is really quite flexible.

* Heading: The heading is today’s date.

* Play Notes:  These are the designer’s reaction to the day’s working build.  I list what worked well and issues I ran into.  For every issue that’s raised, I try to come up with a reasonable solution.

* Prioritized Next Steps:  If the list of issues is long, I’ll call out the order in which they could be tackled.  Sometimes I’ll work to create this list, if the backlog has gotten large.  For those agile folks out there, think of it as a Just-In-Time backlog. If you don’t need this section at a point in time, don’t add it.

* Tasks accomplished:  If work has been done, we mark it on the document.  Some teams add a new list of work accomplished to the daily entry.  Others just cross off notes directly in the doc.

* Experiments: Big, crazy experiments that move the game forward in big steps.  Without these, you cannot leap to a better local maxima.

Tools for creating a design log

I personally love using Google Docs for my design logs.  Here are some of the advantages.

* Real time conversation:  Multiple people can edit the doc at the same time.  I’ve had some very high bandwidth editing sessions with 3 people all adding and resolving comments like crazy.  No more passing documents around or managing versions.

* Comments tied to text:  People can comment on specific section of the text. They can also reply to the comments.  This keeps the conversation focused on specific details instead of hand waving.  No more long rambling thread that diverged from the original topic long ago.

* Ability to resolve comments:  Once a comment thread is finished and the resolution incorporated back into the doc, you can resolve it and hide it away.  This keeps the document clean and lets you know when it is time to move on.

* Email alerts: When someone adds a comment, other users subscribed to the doc get an email.  This acts as a re-engagement system that brings the very busy people on the team back to the document.

Some tools are poor choices for creating design logs:

* Microsoft Word:  The lack of decent collaboration tools results in locked files, overwritten files and stagnant conversations.  Word is the single most used writing tool, yet it remains the worst possible choice for working designers.

* Email: Email lets you reply to specific issues nicely, but the thread of the conversation seems to splinter off rather rapidly. Or you get the counter productive ‘epic email thread’. For short term issues it works reasonably. For designs that live longer than a week, email designs turn into an incoherent mess.

* Blogs:  I’ve been trying to get blogs to work as design spaces for years.  The inability to tie comments directly to text is the major failing as is the inability for others to edit the post simultaneously.  Many developers create developer blog, but most feel like one-to-many medium instead of a collaborative conversation that moves the game forward.  Consider these issues a challenge for those of you who love blogs.

Some tips for using the design log effectively

* Don’t add too much in a single day:  It can be tempting for the designer to add dozens of pages of notes and ideas in a single day.  This just overwhelms the team.

A good rule of thumb is to keep the daily notes to a level that can be read in 5 minutes.  It is uncommon that even a large team will be able to accomplish more than a page or two worth of work in a day, so self edit and focus the writing on things that will make the biggest impact.   When it comes to design, there are no awards for quantity only quality.  Instead of pouring out a giant missive, take a walk and consider what really matters.  Your designs will improve.

* For larger teams consider having a handful of logs. We have a design log and an art log for one project and that splits up the discussion nicely.  I intentionally work with small teams, so I’d be curious to hear how the concept works with production heavy teams that traditionally have difficulty iterating on and evolving their design.

* Make sure you have a conversation, not a monologue: Ultimately, a good design log is an ongoing conversation, not the rambling of an isolated individual.  By talking things through together, everyone internalizes the design and makes it their own. Without this conversation, you just have meaningless words on a page.

Benefits

Here are the benefits I’ve noticed of the design log approach.  These are attributes you should look for in any healthy design process.

* Real:  The design notes are heavily based off the last working build.  This reduces the tendency for the designer to wander off into la-la land imagining cool systems that don’t tie back to the game you are actively growing.

* Actionable:  Each day there is a list of improvements that the team can work on next.  Very little about the design is theoretical.

* Communal:  Everyone can jump in and comment and make suggestions. The design notes often act as a lightning rod for directing comments and prompting ideas.

* Focused:   This is not a spaghetti wiki.  There is a clear thread of intentional design from the bottom of the document all the way to the top.  You can approach the document as a new team member and read the story of how the game has evolved.

* Fresh: The topmost items on the log are always new insights based off new learning from the latest build.   Stale items fall to the bottom of the doc.  This ensures that the document is meaningful to reads and encourages you to create an always living and evolving document.

* Agile:  As you learn more about the dynamics of the design, you can very easily steer towards the most promising opportunities.  For many teams, especially ones in preproduction, a design log can replace backlogs and task lists.

Most importantly, the game design log fits the nature of design:  It is an essential quality of a game design that it evolves over time.  At the heart is a functioning product used by real people who have real reactions to what you’ve built.  You try new things.  You trim experiments that you imagined would work but didn’t.  You double down on the delightful surprises that you could have never predicted upfront.  A design is not plan of execution.  A design is living process that grows a result organically from the journey that team takes together. It is an alchemical chain reaction of players, systems, teams, talents and design.  The starting point influences, but cannot fully define the end result.

There is no place for a dusty design tome in such a dynamic world of evolution.  On the other hand a design log fits. It helps remove the oppressive emphasis on completing preordained features.  Day-by-day, an active design log encourages the team to embrace the iterative spirit of great game development.（Source：lostgarden）