作者：Livio De La Cruz

在过去几年里，我至少看过3个让人印象深刻的迭代过程解释，并且大多数都太过复杂而难以落实行动。直到我阅读了Jesse Schell对于该过程的描述，我才开始相信自己最终能够理解它，不过当我真正尝试着将其应用到项目中时，我却觉得这并不适合自己。我尝试着在不同媒体中进行设计，但出于各种原因，我并不能将平常的设计观点带到长期游戏项目上。

当我越深入探索这一问题时，我越发意识到自己对于这一过程理解的浅薄。我学习了许多有关这一过程的表面细节，使用方法以及为何它能发挥作用等。但是我却并不能真正理解为何这一过程是基于这种方法进行设计，或者我们该如何在某些环节出现问题时纠正它。

我最终尝试着设计了一个适合自己的全新开发过程而回答了这些问题。我尝试着创造新方法，所以我并不惊讶自己能够到达理想中的迭代开发过程。而在这个过程中，我也终于搞清楚为什么这一过程是有效的。所以我决定将这一实践当成本篇文章的前提，而结果便是专注于设计（而非使用方法）去教授开发过程的指南。换句话说，这是关于我在开始这一项目前所阅读的指南般的内容。

介绍开发过程

我认为关于开发过程的大多数讨论似乎都被定职位一种业务或科学观点，即让人们感到困惑不已。而我反倒对这一话题的实践性更感兴趣，并且我想侧重于你是如何将这一知识与自己的工作整合在一起。

如果你不知道如何观察自己的工作流程的话，你便很难去思考开发过程。当你能够更清楚自己是如何实践以及如何解决问题，你便可以在实践过程中完善效率与效能了。更重要的是，你可以开始学习如何使用全新工作流程，并学习如何使用新工具。

你应该很熟悉这一工作流程或过程，因为这是大多数人在第一次尝试创造游戏时所面对的“默认”过程：

1.决定你想要做什么（设计），

2.明确如何做（计划），

3.实践并完成（执行）。

许多业余游戏项目经常会出错的一环在于，人们总是希望自己的付出能够具有成效，所以他们会飞速完成前两个步骤而尽可能快速进入执行阶段，可能对于他们来说这才是“真正的”工作。但是这一常见的问题只会让开发者感到分心，因为在一开始你可能根本就不会使用到这一过程。这一特殊过程便是“瀑布模式”，这在软件工程世界中非常有名。

尽管这看起来是一种直观的执行计划，但是“瀑布模式”似乎并不能有效支持大型项目。大型项目总是要求更多设计和计划，而这些过程将阻碍真正的设计工作。你可以在执行后再完善设计过程，而当你预先设计了所有内容后，你便需要创造出上百种有关怎样的设置可行的假设。当你开始进行假设时，你便不能再设计游戏了，你只能对此进行幻想。

有些人通过在最后添加一些额外的步骤（游戏邦注：从而挪出一些时间去修改执行阶段中所遗留下来的问题）而修改瀑布模式。但这么做却是徒劳，因为它根本不可能解决这一设计过程中的内在结构问题。为了真正解决这一问题，我们需要设计出全新的过程。

设计过程

糟糕的工作流程有可能无形地摧毁一个项目。而设计这些过程的前景也实在让人堪忧。幸运的是，我们只对这一讨论的实践面感兴趣，所以我们无需过多担忧在描述过程中所体现的精确性。这也是为何我们的“瀑布模式”过程描述与你在维基百科上找到的内容不一致的原因。

如果我们将设计一个全新过程，我们就需要先明确该过程需要具有怎样的核心特征。首先我们需要解决“瀑布模式”所具有的最大缺陷，并鼓励人们采取有帮助的设计视角。接下来我们必须根据开发游戏所需要的时间和资源而确保该过程是现实的。最后，这一新过程必须能够与“瀑布模式”的直觉性和吸引力相抗衡，否则它便会因为拥有过多需要遵循的规则而让你迷失自我。

“瀑布模式”之所以如此吸引人是因为其整个过程可以概括为一个简单的步骤：

1.在最终完成前一直致力于其中。

尽管这一模式非常模糊，但这却是人们在选择“瀑布模式”时所经历的思维过程。你可以将这一描述当成剩下过程所围绕的“主题”，因为过程的每一部分都是直接源自这一基本计划。

该主题的简单性是推动这一过程无形化的主要原因。我们之所以希望工作流程是无形的是因为，如果不这么做，它就会变成工作中的一个组成部分。就像面对一个精心设计的用户界面，如果我们能够使用一个简单的开发过程，那便无需多花时间进行思考了。如果你之前曾经面临过较复杂的过程，你便会知道即使在非常时期也很难回到简单的过程中了。这是我在实习过程中频繁遇到的情况，尽管我对自己遵循的过程充满信心。

所以现在我们知道需要围绕一个简单且直接的主题去设计全新过程。因为主题可能与我们的目标相关，所以在接下来的内容中我将侧重对于典型设计师工作流程的理解。

迭代循环

当你致力于任何以设计为导向的专业中，不管是视觉图像，音乐，电影，写作等等，你都会发现这一工作流程通常会简化成两个简单的步骤：

1.执行你的理念，

2.评估你的理念，然后回到步骤1中。

这两个步骤的过程便是迭代循环（游戏邦注：不能与“迭代开发过程”相混淆，后者是针对于软件开发）。对于任何特定项目，设计师在创造出最后作品前都需要多次经历这种循环。每一次循环都称为一种迭代，而当你完成更多迭代时，最终作品将会越完善。

这与我们在学校中学习写散文时，老师会要求我们多打几份草稿再开始写文章是一个道理。在这个阶段你已经学会如何写文章了（第1步），但是你还必须学会找出文章中的缺陷（第2步），并想出如何修改这些缺陷（回到第1步）。

但是我们并不一定总是要遵循着这一迭代过程。举个例子来说吧，如果你正在写一篇散文，你可能只需要阅读自己写下的一个段落，然后只需要移动其中的几行内容。每次当你执行这样的动态编辑后，你只需要完成另一个迭代便可，而这通常不会超过1分钟。

直到你精通了第2个步骤（游戏邦注：即掌握了客观评估并批评自己的设计的能力）后，你才能真正的像一名设计师那样思考。大多数充满抱负的设计师似乎更希望在创造游戏后再做出所有创造性决定，所以他们的工作往往充满不确定性与各种假设，就像是他们都认为所有人在最后都会喜欢上自己的游戏。但是较为严格的设计师便会更加谨慎。因为他们有寻找自己创作缺陷的习惯，所以他们会花很多时间去思考最终作品会出现什么差错，从而让自己可以在问题真正出现前做好应对准备。

这也是为何迭代循环有时候会被描述为降低风险的过程。基于这种描述，之前的两个步骤将出现颠倒：

1.找到设计中的潜在风险（评估），

2.尝试着缓解风险，然后回到步骤1（执行）。

这一描述比之前的描述更加广泛。因为最初的描述将自己局限在游戏中，而最新的描述更明确地考虑到了可能影响游戏的外部元素。

举个例子来说吧，在对于迭代循环的首次描述后，设计师将问如下问题：“这一小小的改变是否会影响游戏感受？”或者“这种程度是否像我所期待的那般有趣？”而基于新描述，现在的设计师也许会问：“玩家是否会觉得这一机制太过困惑？”“我们是否具有合适的技术能够运行这一功能？”，甚至“我们是否能够保证在六个月内发行商并不会遭遇破产的危机？”这些风险都将影响着游戏设计，因为在游戏设计中的任何一个点上你都能够进行创造。

有些人认为这种设计观点太过压抑，因为它意味着你总是着眼于糟糕的一面。但事实上，这种观点所创造的主要情感是客观的，而非悲观。基于同样的方式，科学家将支持大量的怀疑论去更好地理解世界，设计师则必须基于现实，否则他们便不可能真正面对游戏并不有趣的真相。换句话说，比起逃跑，如果你真的在积极寻找的话，你便能够更容易去接受那些让人不快的信息。

迭代游戏开发

如果能将迭代循环无缝地应用于游戏开发中自然再好不过了，但不幸的是我们面前摆着一个巨大的难题。就像我之前所提到的，你只能在执行设计后才能对其进行评估，但是对于那些未能遵循迭代循环的游戏，你便需要投入更多精力去执行它。如果你不够小心的话，你便有可能只是浪费大量的时间和资源去落实一次的迭代——这时候的你就像是在遵循“瀑布模式”似的。

也许唯一的解决方法便是节俭地对待迭代循环的使用。比起理所当然地进行每次迭代，设计师必须尝试着压缩每次迭代的费用并提升其价值。

这便推动了快速原型理念的形成。举个例子来说吧，你想知道的便是一个特定的机制系统是否有趣，然后你便可以尽快创造出该系统的粗糙原型。编程是测试设计最缓慢的方法，所以“纸上原型”便成为了设计师创建系统模型的最常见方法。

那些熟悉游戏经典创造方法的读者也许会注意到，这开始有点像是迭代开发过程了。这是否意味着我们已经到达了设计导向型游戏开发工作流程的问题了？到达这一点的方法能够提供一个我们一直在寻找的完美主题，即以单步骤过程呈现出来：

1.遵循通常设计过程，但却不会将迭代当成理所当然的事。

迭代开发过程是否真的这么简单？尽管从表面上看来这是个很大的发现，但是将它带进你的工作流程中才是实现该过程的关键。比起有意识地思考如何才能有效地遵循过程，你应该在自然且直观地遵循过程的同时专注于工作中。

还有很多方法能够将这一主题划分成更具体的步骤系列，你将找到最适合自己的一种方法。但因为我们正在强调迭代的不足，所以我们关于迭代循环的第二种描述是：

1.找到一些最重要的风险并去缓解它们（评估），

2.明确缓解这些风险的最快速方法（计划），

3.落实行动，然后回到步骤1（执行）。

你也许会注意到这就是迭代循环，但在中间带有一个额外的步骤能够提醒我们不要浪费时间。为了确保我们能够按照适当的顺序解决设计问题，第1个步骤得到了修改。举个例子来说，你肯定不希望自己花许多时间为一个功能创造纸上原型，但是最后却发现在下一次迭代中这一功能太不现实而不能有效地在代码中执行。这是一个很容易犯的错，特别是当你因为一些极具吸引力的次优设计问题而分心时。

关于如何有效管理迭代还有许多需要学习的地方，但是最重要的还是你需要确保每个迭代都具有合适的理由。如果你曾经发现自己是因为“应该”这么做而创造原型的，那么这种迭代便具有误导性并会浪费你的时间。所有迭代都必须受到合理的好奇形式的启发，而不是基于过程本身。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Deconstructing the Iterative Development Process

by Livio De La Cruz

This post actually started out as a retrospective for the game I’ve been working on for my internship/independent study with Riverman Media. At first I was planning to write on everything I’ve learned during this semester, almost like a postmortem for a project that isn’t over yet. But such a post would have probably ended up being a loose collection of small tips, and I prefer to use this blog to explore deeper topics. So I decided to write on the biggest and most confusing problem that’s been bothering me all semester: how to properly use the iterative development process.

In the past few years, I’ve seen at least three memorable explanations of the iterative process, and most of them were too complicated to be practical. It wasn’t until I read Jesse Schell’s description of the process that I started to believe that I finally understood it, but when I tried to apply it to this project, it just didn’t feel like design to me. I have experience designing things in several different media, but for some reason, I felt like I was having trouble migrating my usual design perspective to a long-term game project.

The more I explored this problem, the more I realized how shallow my understanding of this process was. I had learned a lot about the surface details of this process, how to use it, and why it worked. But I didn’t really understand why this process was designed in the way that it was or how to fix it when something went wrong with it.

I eventually answered these questions by trying to design a brand new development process that would work for me. I was basically trying to reinvent the wheel, so it was little surprise that I arrived at the iterative development process as my answer. But along the way, I was finally able to wrapped my head around how this process is really meant to work. I decided to turn this exercise into the premise for this post, and the result is a guide that teaches this development process by focusing on its design rather than how it’s used. In other words, it’s the kind of guide I wish I had read before starting this project.

Introduction to Development Processes

Most discussions about development processes seem to be tailored to a business or scientific perspective, which tends to make them unnecessarily confusing, in my opinion. I’m much more interested in the practical side of this topic, so I’m going to focus mostly on how you can relate this knowledge to your own work.

It can be pretty hard to think about development processes if you don’t already know how to observe your own workflow. Once you can see more clearly how you work and how you solve problems, then you can start improving both your efficiency and effectiveness when working. More importantly, you can start learning how to use new workflows, much in the same way that you can learn how to use a new tool.

Here’s an example of a workflow or process that you’re probably familiar with, since it’s usually the “default” process that most would people tend to use when they try to make a game for the first time:

1.Decide what you want to do (Design),

2.Figure out how to do it (Plan),

3.Do it, and then you’re finished (Implement).

Part of what goes wrong with many amateur game projects is that people want to feel productive when they work, so they will often breeze through the first two steps in order to get to the implementation phase as soon as possible, probably under the presumption that this is where the “real” work is at. But this common problem is just a red-herring, because you really shouldn’t have been using this process in the first place. This particular process is known as the Waterfall model, and it’s actually pretty infamous in the world of software engineering.

While it may seem like an intuitive plan to follow, the Waterfall model just doesn’t support large projects very well. Large projects require a lot of design and planning, and this process practically discourages real design work from happening. You can only improve a design after it has been implemented, and when you design everything up front, you’re forced to make a million assumptions about what works. And once you start making assumptions, you’re no longer designing the game—you’re fantasizing about it.

Some people try to fix the waterfall model by adding a few extra steps to the end so that there’s some time left over to fix the problems that inevitably surface during the implementation phase. But this is like putting tape over a leak, since it doesn’t fix any of the structural problems inherent in the design of this process. In order to really fix this problem, let’s try to design an entirely new process to work with.

To Design a Process

It’s pretty scary how something as invisible as your own workflow can derail a project. And the prospect of designing such a thing can also be a little intimidating. Fortunately, because we’re only interested in the practical side of this discussion, I would argue that we shouldn’t worry too much about accuracy when describing processes. This is why my description of the Waterfall process may not match what you’d find on Wikipedia, for example.

So if we’re going to design a new process, let’s begin by figuring out the core traits we’d like this process to have. First, we’d like to fix the biggest flaw of the Waterfall approach and make something that encourages a healthy design perspective. Next, the process must be realistic in terms of the amount of time and resources that it takes to develop a game. Finally, this new process must be able to compete with the intuitiveness and attractiveness of the Waterfall model, or else it would take too much discipline to follow and leaves you feeling lost as you follow it.

The reason why the Waterfall model is so attractive is because the entire process can be abstracted into one simple step:

1.Work on it until it’s done.

Even though this description is much more ambiguous than the real thing, it more closely resembles the thoughts that people go through when they choose to use the Waterfall model. You can think of this description as the “theme” with which the rest of the process is designed around, because every part of the process stems intuitively from this basic plan.

The simplicity and elegance of the theme is what makes this process so invisible. The truth is that we want our workflows to be invisible, because otherwise it just becomes part of the work. Like a well-designed user interface, a good development process should be so easy to use that you don’t even have to think about it. If you’ve ever tried to follow a complicated, unintuitive process before, then you know how hard it can be to keep yourself from reverting back to a simpler process during times of stress. This is exactly what happened to me multiple times during my internship, despite the fact that I had complete faith in the process that I was following.

So now we know that we’re going to need a simple and intuitive theme with which to design our new process around. Since the theme will probably have something to do with our goal to encourage design perspective, the next section will focus exclusively on understanding the typical designer workflow.

The Iterative Cycle

When you work in any design-oriented profession, whether it’s in visual arts, music, film, writing, etc., you’ll find that your workflow will usually simplify itself into two simple steps:

1.Implement your idea,

2.Evaluate your idea, and then go back to step #1.

This two-step process is typically referred to as the iterative cycle (not to be confused with the “iterative development process”, which relates to software development specifically). For any given project, the designer will loop through this cycle dozens of times before arriving at a final product. Each loop through the cycle is called an iteration, and the more iterations you can complete on a project, the more it will improve.

This is why when you first learn how to write essays in school, you’re usually taught to write a couple of drafts before you’re allowed to create the final draft. At this stage, you’ve already learned how to write (step #1), but now you must learn how to find the flaws in your own writing (step #2) and figure out how to fix them (back to step #1).

The iterative process isn’t always followed so formally, however. If you’re writing an essay, for example, you might read a paragraph that you have just written, only to decide that you need to move a few sentences around. Every time you do this kind of on-the-fly editing, you have just completed another iteration, and it probably happened in less than a minute.

It isn’t until you master the second step—the ability to evaluate and critique your own designs objectively—that you really start to think like a designer. Too many aspiring designers seem to be more interested in making all of the creative decisions behind a game, and so their work tends to be careless and filled with assumptions, almost as if they believe that everyone will magically enjoy their game in the end. But a serious designer is much more cautious. Because they are in the habit of looking for the flaws in their own work, designers will spend more time thinking about what might go wrong with the final product, which allows them to consider many design problems before they appear.

It’s for this reason that the iterative cycle is sometimes described as a risk-mitigation process. Under this description, the order of the two steps is reversed:

1.Find a potential risk in your design (Evaluate),

2.Try to mitigate that risk, and then go back to step #1 (Implement).

This description is much broader than the first. While the previous description limits itself to what’s inside the game, this new definition more explicitly considers the external factors that could affect the game.

For instance, under the first description of the iterative cycle, the designer might ask questions such as: “How does this small change affect the feel of the game?”, or “Is this level really as exciting as I hoped it would be?” But with this new description, a designer may now also ask: “Will players find this mechanic too confusing?”, “Do we have the technology to make this feature work?”, “Do we have enough money to pursue a project of this scope?”, or even “Are we sure that our publisher really won’t go bankrupt six months from now?” All of these risks will affect the design of the game, because there’s no point in designing a game that you can’t build properly.

Some people think that this kind of design perspective is pretty depressing, since it means you’re always looking at the bad side of things. But in actuality, the main sentiment that this perspective brings is objectivity, not pessimism. Much in the same way that a scientist maintains a healthy amount of skepticism in order to better understand the world, the designer must also keep themselves grounded in reality or else they may never be able to face the all too common truth that their game just isn’t fun yet. In other words, it’s easier to accept painful information if you’re actively looking for it, rather than running away from it.

I personally find both descriptions of the iterative cycle useful. Too many design questions present themselves much more naturally under the first description, and it just seems like it’s more work to think of them as risks. Furthermore, not every design question might be easily turned into a risk. Sometimes you just get curious and you want to ask “what if?”

Iterative Game Development

It’d be great if the iterative cycle could be applied seamlessly to game development, but unfortunately, there’s a big dilemma that gets in our way. As I mentioned before, you can only evaluate a design once it has been implemented, but it takes so much work to implement a game that it’d be unrealistic to follow the iterative cycle alone. If you’re not careful, you could burn through most of your time and resources on just a single iteration—at which point you might as well be following the waterfall model.

Perhaps the only solution would be to become extremely frugal with how one uses the iterative loop. Rather than taking each iteration for granted, the designer must try to minimize the cost of each iteration while also maximizing its value.

This is where the idea of rapid prototyping comes in. If, for example, all you want to know is whether or not a certain system of mechanics is fun, then you should make a crude representation of that system as fast as possible. Programming is often the slowest way to test a design, and so it’s common practice for designers to build representations of their systems, which are typically referred to as “paper prototypes.”

Readers who are already familiar with how games are usually made may notice that this is starting to look a lot like the iterative development process. Does this mean that we’ve arrived at our answer for a design-oriented, game development workflow? The way that we’ve reached this point gives us the perfect theme that we’ve been looking for, in the form of a single-step process:

1.Follow the usual design process, but don’t take iterations for granted.

Is the iterative development process really this simple? While this may not look like such a big discovery on the surface, just having this one idea being at the center of your workflow is the key to making the process become invisible. Rather than consciously thinking about what you have to do in order to follow the process correctly, your thoughts are focused on your work while you follow the process naturally and intuitively.

There are dozens of ways to break down this theme into a more concrete series of steps, and you’ll probably find a way that works best for you. But since we’re emphasizing the scarcity of iterations, our second description of the iterative cycle seems like a good fit:

1.Find some of the most important risks to mitigate (Evaluate),

2.Figure out the fastest way to mitigate those risks (Plan),

3.Do it, and then go back to step #1 (Implement).

You may have noticed that this is just like the iterative cycle but with an extra step in the middle that essentially tells us to be really careful about wasting time. The first step has also been modified in order to make sure that we’re solving design problems in the correct order. For example, you don’t want to spend time making a few paper prototypes for a feature just to find out during the next iteration that it’s too impractical to implement in code. This is actually a pretty easy mistake to make, especially if you’re distracted by a low-priority design problem that’s fascinating enough to make you want to solve it.

There’s a lot more to learn about how to manage your iterations efficiently, but perhaps the most important thing that you can watch out for is to make sure that each iteration is made for the right reasons. If you ever find yourself making a prototype because you feel like that’s what you’re “supposed” to be doing, then that iteration is misguided and is more likely to be wasted. All iterations must be inspired by some legitimate form of curiosity, not by the process itself.(source:blogspot)