作者：Lewis Pulsipher

这是有关游戏设计的一个重要主题：你是否在设计一款游戏还是只是随便拼凑了一个内容？创造性是游戏设计的组成部分，但是它只占整体游戏设计的10%。剩下的几乎都是关于工程：你需要明确问题和适当的解决方法，执行解决方法，测试这些解决方法的结果等等。科学方法是包含于测试中，工程则是包含于解决方法中。有时候才会出现灵感与创造性。

不要猜测

游戏设计绝对，或者不应该是关于反复试错。我正在使用年轻时非常流行的一种方法：猜测什么是可行的然后观察结果。将这种方法称为“猜测与核查”，因为现在似乎存在有关这种形式的科学方法，即试错法。但事实上，这就是猜测。而游戏设计并不是关于游戏猜测（尽管在其它创造性或工程行动中，你有时候也能够幸运地猜对某事）。

让我们使用一个来自入门编程班的例子进行说明。我曾因为一位大学老师生病了而代替他去为新手们上了一堂编程课。在计算机领域，虽然很少人会成为程序员，但是所有人都需要学习一些编程知识。因为班上的学生已经有正在编程的简单内容，所以我只需要在课堂上到处走走提供适当帮助便可。

我们都知道编程是非常有逻辑性的，所以并不能遵循K12的教育方式。当编程不能有效进行时我们能给予的最恰当的回应便是明确编程流，找出哪里出了问题，改变程序，并测试解决方法。在游戏设计中也是如此。我们创建原型的主要目的便是识别问题并测试解决方法。这包含了一些直觉性，而解决方法也包含一定的创造力，但从更大程度来看还是关于逻辑。

而除了尝试去识别为什么程序不能有效运行外学生们还能做些什么呢？他们只能进行猜测，并根据自己的猜测去改变编程，然后再次运行去查看结果。如果这种方法不可行，他们便会猜测其它方法。他们会使用传统的试错法，进行猜测然后核查，当然他们最终会因为结果不可行而受挫。所以比起猜测我希望告诉他们去明确编程的逻辑性与流。

游戏设计亦是如此。有些人并不像我所说的这样设计游戏，但其实这才是最有效的方式。当然不同人会有不同的设计方法。即比起逻辑有些游戏设计是源自设计师的直觉。但这也仍然是关于假设与测试：如果你正有条理地使用自己的脑细胞在设计某些内容，我便希望你不只是完全依靠于自己的灵感。

灵感是不可靠的

灵感是非常不可靠的。“当灵感到来时我们会觉得它非常美妙，但作家自己却需要为没有灵感的其它时候买单，等待灵感的时间总是非常漫长。”灵感既会到来也会离开。如果你能够更多地将游戏完善看成一个工程问题，你的效能便会更大地获得提高。

有些人可能会认为比起工艺，游戏更像是艺术，如果你也抱有这种想法，你便会想依赖于灵感与直接去设计游戏。所以我们会说你不是在设计游戏，而是在创造游戏—-尽管当你拥有一个可游戏原型时游戏就会变成一件工艺。如果你做得不错的话可游戏原型真的会很有效。你并不能朝墙上扔游戏设计去看看它是否具有粘性，这便是试错法会使用的方法。但事实上这却是一种非常糟糕的解决问题的方法。

为什么人们要这么设计？

当我在创造本文的视频版本时我并未意识到猜测与核查方法如此普及。不幸的是游戏玩法的改变导致更多人去使用试错法。

当我还是孩子时（即50多年前），我会去寻找那些需要通过思考才能获得成功的游戏，那也不是什么抽象游戏。最经典的便是象棋和西洋棋，不过它们都过于抽象了。我需要的是一些更现实的内容。最终Avalon Hill的战斗游戏弥补了我的需求，还有之后的《外交》。

随着电子游戏的出现，比起脑力工作，游戏更多地倾向于运动技能。不管你有多聪明，如果你不能拥有快速的反应能力和灵活的手眼配合，你便不能有效操控一款电子游戏。

此外，电子游戏更倾向于单人玩家益智游戏，即通常只存在一个正确的解决方法。所以很少会有关于人类对手的替代品。

当你在玩一款敌对策略游戏时（通常都是桌面游戏），你不能只是猜测该做什么。而现在我们拥有许多单人玩家与合作型电子游戏，即玩家可以按照自己的意愿去扭转败局。许多玩家会尝试各种不同的方法去找出最有效的方法，然后使用该方法去迎接下一个挑战。他们只需要通过猜测与核查便可。但这却是非常荒谬的！相反地，有些游戏是伴随着在线帮助功能。如果某些内容不能有效运行，玩家将寻找最佳方法去“战胜”它，然后继续游戏。但这类心理是与你在设计一款游戏时的心理相反的。

此外，随着90年代末欧洲风格游戏的出现，我们开始进入平行竞争的时代，即玩家将尝试着去解决同样的谜题。尽管存在许多不同的解决方法，它们也仍然都是一些正确的解决方法。许多桌面游戏变成了谜题解决游戏。玩家将学习如何寻找解决方法，因为他们不需要再担心对手了。

在设计游戏的时候，你最好添加一个“保存游戏”的选择。因为你可以尝试你所设计的解决方法，而如果你发现它并不可行，你也可以回去使用之前的老方法。但这将耗费你许多时间。也许你拥有很多时间去猜测改变，但我却没有，那些为了生计而设计游戏的开发者也没有这样的时间。

同时你必须清楚总是存在最佳方法（游戏邦注：在益智游戏中便是如此）与需要在不确定的选择中做出决定是截然不同的，就像在经典的战争游戏中那样。比起解决谜题，游戏设计更多的是关于解决问题。在这里很少存在总是对的解决方法。

关于如何游戏的改变的结果便是，许多想要成为游戏设计师的人学到了设计游戏的错误方法和错误技能。当然并不是所有人都是如此玩游戏，但的确大多数玩家是这么做的。

用球击墙的方法

我已经看过有关用球击墙的方法。最近桌面游戏设计新人所创造的包含纸牌和分数的简单多人游戏（30分钟）便让一些新玩家进行测试。这款游戏在Kickstarter上获得了成功，但显然它还未真正完成。游戏中的大多数纸牌都是手写的。设计师并未在游戏中添加规则。我问他为什么呢？他的回答是，自己以6或7种不同方式去玩游戏，并且通过不断修改去满足支持者们，所以他才未添加任何规则。

也就是我们所看到的是一款在Kickstarter获得成功但却拥有未经测试的手写规则的游戏。而当他说自己正在尝试一个特殊规则时，我的反应则是当剩下的游戏还不稳定时你又怎么去尝试做出改变呢？你只是尝试着去改变众多游戏方式中的一种而已。当你开始测试游戏时，你所测试的是整款游戏而不只是你想要测试的那一部分。如果其余内容仍将继续发生改变，你又该如何去评估一个改变所造成的影响呢？

我的下一个问题是，你是如何记录游戏测试结果的？他回答道，他通常是记在笔记本上，但同时他也有台笔记本电脑并会在被淘汰出局时在上面做记录。可以指出的是这是一款包含玩家淘汰的游戏，这是现在很少游戏会使用的机制，特别是在一款30分钟游戏中，这同时也是一款计分游戏，但是他去并未使用任何计分设备，所以所有人都只能在自己的智能手机上计分。

虽然我说过像玩家淘汰等显著问题，但除此之外还有另一个问题。这是一款关于直接攻击其他玩家的纸牌游戏。游戏并不会限制你该攻击谁，如果对于玩家能够攻击哪些类别的对手的限制越少，玩家在任何时候能够发动最强攻击的对象将会是特定玩家而不是任意其他玩家。游戏中主要有5或6个玩家。当我在做其他事时我便不会去留意游戏。之后当我询问是否有可能攻击其中的leader时，我所获得的答案则是可以。看来这是一款关于攻击leader的游戏。我不知道设计师是否会认可我的这一形容。随后人们便可以提出有关攻击leader的解决方法，而其中的攻击周边玩家的方法将破坏这款最初在Kickstarter获得成功的游戏。

需要注意的是，为什么攻击leader是不可行的呢？因为这将消除游戏的策略型决策制定，玩家将只是去攻击leader。这会导致玩家在结束前都不希望自己成为leader。实际上考虑到游戏属性，这里并不包含决策制定。玩家可以选择自己最强大的攻击去影响其他玩家。我并不是在反对那些简单，甚至可以说是肤浅的游戏，它们同样也可以提供给玩家多样的选择以及像传统桌面游戏那样的“两难局面”。但这款游戏却并非如此。

该设计师继续尝试了各种方法去看看什么方法最有效。对于我来说这便是一种试错法。这也说明了Kickstarter比起真正的游戏更加看重理念和目的。

“科学方法”/工程

现在让我们简单说说如何进行这部分的设计，即不只是尝试这样或那样的方法，也不是进行各种试错。我使用了详细的图解。这是一个工程设计过程。这同时也像项目管理，因为在项目管理中每一次你所做的事都与你之前做的有所不同。我便打算在这里讨论这一较简单的项目管理。

Plan-Monitor-Control-Replan cycle(from gamasutra)

计划是关于创造一款游戏直至拥有一个可游戏的原型。

执行是关于尝试这个原型，首先一个人，然后让其他人进行尝试。

当别人在玩游戏时，你应该观察他们是否按照你的想法在玩游戏，是否按照你的计划在玩游戏。

当你发现玩家并未按照你的计划在玩游戏时，你便会做一些事去纠正它们的做法，这便是控制。

成功调整后你将进行重新计划，即你将修改你的原型。然后你将回到执行阶段并再次尝试原型，你将不断在这个周期中循环着，直至最终创造出一款更出色的游戏。

我并不喜欢“迭代”这一词。没错，这的确是一个迭代过程，而虽然迭代这词经常出现在电子游戏中，但是它却只包含你所做的所有事情的一半内容。你是在进行修改与测试，而不只是反复游戏。这里也包含了科学方法。科学方法包含了通过观察与试验获得的种种数据以及对于假设的构想与测试。

而游戏设计不只是如此。与科学家不同的是，大多数情况下游戏设计师需要依赖于相对较少的测试。（游戏邦注：如今在电子游戏中我们可以看到一些“开放beta”测试，发行后的测试以及分析统计方法。）与科学家不同的是你将在设计中做出改变，并通过试验去观察结果。幸运的是这是一种可用性测试而非科学测试，而可用性测试通常都不需要大量尝试。我建议你能看看Nielsen Norman Group网站并浏览他们的文章。他们经常会谈论有关网页设计可用性，并且他们所说的的内容都能够有效作用于重视用户界面的游戏设计，特别是电子游戏设计重。我们的桌面游戏便拥有用户界面，但这些内容却在很早前便已经定下来了并且不会轻易做出改变。

类比

作为一个缺乏想象力的人，我通常不会冒险进行类比，但在此我还是想尝试看看。关于工程与试错法的问题可以与人们如何学习软件或家用电器或电子进行比较。而与大多数人不同的是我会去阅读各种手册。而令人惊讶的是基于这种方式你可以有效学到多少东西。但似乎大多数人都是浅尝即止。

基于工程风的游戏设计就像阅读指南那样，而试错法则像埋头去尝试某些方法。与大多数希望别人来教自己的人不同，为了能够了解一款桌面游戏我会尝试着去阅读规则。或许这可能会花费更长时间，但比起别人来教授，当我亲自阅读规则时我能够更透彻地去了解一款游戏。

我曾在Udemy.com上的“学习游戏设计”课程中讨论过测试和修改的过程，那里也有关于游戏测试的课程。而本文的要点是希望你能够遵循一个以解决你所明确的问题为重点的过程。你同时也必须清楚什么问题可能会出现，如纸牌游戏中的攻击leader，这也是我为什么要制作这么多视频去教授人们有关任何可能出现的问题的原因。

方法总是很重要，但除非你别无选择了，否则不要轻易去尝试试错法。直觉或灵感总是能够赋予你更多优势，但这并非我想要教授给那些有抱负的游戏设计师的内容。如果你认为游戏设计便是关于灵感，你便大错特错。你必须基于始终如一的基础去致力于某项工作，而不是寄托于那些随机跳出来的灵感。

作为一名老师，我希望人们能够清楚，“灵感”，“直觉”，特别是试错法并不是一种真正有效的好方法。

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

Are you designing a game, or throwing one together?: You can’t design a game as though you were playing a video game

by Lewis Pulsipher

This is a vital topic in game design: are you designing a game or you throwing one together? Yes, creativity is part of game design, but it only amounts to about 10% of the whole. The rest is more or less engineering: you identify problems and propose solutions, implement the solutions, test the results of those solutions, and so on. Scientific method is involved in your testing, and engineering is involved in your solutions. Occasionally inspiration and creativity are involved.

Just Say No to Guessing

What game design definitely is not, or at least should not be, is trial and error. I’m using the meaning that was prevalent when I was young: guessing what might work, and then checking to see if it does. I now call it “guess and check”, because there seems to be a notion today that trial and error is a form of scientific method. No, it’s guessing. Game design is not a guessing game (though as in all other creative or engineering endeavors, sometimes you get a lucky guess).

Let me use an example from a beginning programming class to illustrate. While I was a college teacher I substituted for a teacher who was ill, in a programming class for beginners. Many the people were not going to become programmers, but everybody was required to learn some programming, which made good sense in a computer department. The students in the class already had a program to work on, a simple one, so I walked around trying to help in general, as their programs didn’t work.

This is not surprising. Programming is very logical, and people often are not taught logical methods in K12. The proper response when the program isn’t working is to figure out the program flow, identify where it went wrong, change the program, and test the solution. It works the same way in game design. Much of the purpose of playing a prototype is to identify problems and test solutions. This includes some intuition, and the solution might involve some creativity, but mostly it is logic.

But what did the students do rather than try to figure out why it wasn’t working? They just guessed, changed the program in accordance with their guesses, and compiled/ran it again to see what happened. If that didn’t work, they guessed something else. They were using traditional trial and error, guess and check, and they were frustrated, of course, because it wasn’t working. I tried to show them how to figure out the logic and flow of the program rather than just guess.

Game design ought to be the same way; some people won’t do it that way but I think it’s the most efficient way, and it’s the way that I like to teach people. Certainly different people have different design methods. Some design more from the gut than from logic. But it still involves hypotheses and tests: if you’re actually designing something you are primarily using your brain in an organized way, I hope, and not just relying on inspiration.

Inspiration? Not Reliable

Inspiration is not very reliable. “Inspiration is wonderful when it happens, but the writer must develop an approach for the rest of the time . . . the wait is too long.” (Leonard Bernstein, the composer and conductor – and writer.) Inspiration comes and goes. The more you treat the modifications of your game as an engineering problem, the more efficient you’re going to be.

Some people may think of a game as art, rather than craft, and the more that you think of it as art, the more you might be inclined to rely on inspiration and intuition. So we might say that you’re not designing a game, you’re creating a game, though it’s mostly craft once you have a playable prototype. A playable prototype is going to change a lot if you’re doing a good job. Game design is not throwing things against the wall to see if they stick, which is what trial and error and error amounts to. It’s “try this and see what happens. Then let’s try that and see what happens.” Some things might happen better than others, but it’s a terrible way to solve a problem.

Why Do People Design This Way?

When I did the video version of this piece, I had not realized why this guess-and-check method might be common. Unfortunately, changes in game playing have led to much greater use of trial-and-error (guess-and-check) than in the past, and to puzzle-solving rather than problem-solving.

When I was a kid (more than 50 years ago) I searched for games that required you to think to succeed, but which were not abstract. The classic games such as chess and checkers were just too abstract, I wanted something that represented, modeled, some (possibly fictional) reality. Avalon Hill’s wargames finally filled the bill for me, followed by Diplomacy (for more than two players).

With the advent of video games, gaming became a matter of athletic skills more than brainwork. No matter how well you could think, if you didn’t have the reflexes and hand-eye coordination needed, you’d not be good at most video games. Video games were athleticware, not brainware.

Moreover, video games tended to be single-player puzzles, where there was an always-correct solution, owing to the inadequacy of the computer opponent. There was no substitute for human opposition.

When you play an opposed game of strategy, a game you can lose – which is usually a tabletop game – you cannot afford to simply guess at what to do. That’s the road to Loserville. But now we have so many single-player and co-op video games, games where you can save the game at will. Many players try lots of different choices to see what works best, saving each one, and then use the best to move on to the next challenge. They don’t have to figure out anything, they can just guess-and-check. In the extreme I know of someone who, finding a chest with random contents, will open it, save it, open it again, save it, and so forth, dozens of times, in order to get the best result. Ridiculous! Alternatively, some play games with online help open. If something isn’t working well, the player will look up the best way to “beat” it, and continue. But it’s these kinds of mentality that are the opposite of what you should be doing when you design a game. These mentalities amount to “throwing things against the wall to see what sticks.”

Further, with the advent of Eurostyle games in the latter 90s, we entered the era of parallel competitions (which I called “contests” in my book Game Design), players all trying to solve the same puzzle. Even though there were usually several different solutions (“paths to victory”), they were still always-correct solutions. Many tabletop gamers became puzzle-solvers. People learned to look for the solutions, because they didn’t need to worry about the opposition. Some games coming out of the Euro style transcended this, but most have not.

In designing a game, you do have, in effect, a “Save Game” option. Because you can try a solution you’ve devised, and if you decide it doesn’t work, you can go back to the old way of doing it. But this takes a lot of time (one playtest often isn’t enough to determine the success of a modification). Maybe you have lots of time to waste guessing at changes, but I certainly don’t, nor does anyone who wants to design for a living.

Furthermore, knowing that there’s always a best move (as it true of puzzles) is quite different than having to decide among uncertain alternatives, as in a typical wargame. Game design is problem-solving far more than puzzle-solving. There is rarely an always-correct solution in game design.

As a result of these changes in how games are played, many people who want to become game designers have learned the wrong ways of doing things, learned the wrong set of skills, to design games! Obviously, not everyone plays games this way (I don’t, even when I play a video game), but the majority of gamers do.

Illustration of Throwing Against the Wall

I’ve seen the throw-against-the-wall method dramatically illustrated. Recently a beginning tabletop designer had his simple, multiplayer, 30 minute game, which involved cards and scoring only, playtested by players new to the game. The game had already been successfully Kickstarted but clearly it was far from done. Most of the cards were handwritten (not even computer-generated) for example. He also made the error of playing the game without having any rules with him (to test the rules as well). I asked why? His response was, he played it six or seven different ways, and was also changing it to satisfy backers as well, so he didn’t bring the rules!

So here we had a game that was already Kickstarted and the rules writing wasn’t being tested. When he said he was trying out a particular rule change my reaction was, how can you try a change when the rest of the game isn’t stable? You’re only trying to change one of those half-dozen ways to play. When you playtest, you playtest the whole game, not just the part that you’re experimenting with. If the rest of it keeps changing, how can you evaluate the effect of one change?

My next question was, how are you recording the results of the playtest? He said he usually had a notebook, but not today, but he did have a laptop and he took notes after he was eliminated. (Yes, he played in the playtest, worse, without rules at hand. Bad Idea.) I can point out here that it was a game with player elimination, which is not desirable nowadays, even in a 30 minute game, and it was a scoring game yet he hadn’t bothered to bring the scoring devices, so everyone scored on their smart phones. This is just sloppy. You’ve got to test the actual game, not substitutes!

I’ve talked about some of the obvious flaws like player elimination, but there was another one. It was a card game of direct attack on other players. There was no overall constraint on whom you could attack; the lesser constraint involved categories of who you could attack that is, your strongest attack in your hand at any given time could only be aimed at some of the players rather than any of them, depending on their characteristics. They had about five or six players in this game. I didn’t watch the game much as I was doing other things. I asked afterward if there was a strong tendency to attack the leader, and the answer from the players was, yes. The game suffered from leader-bashing. I’m not sure the designer actually recognized the term when I used it, and only had a glimmering of why it was undesirable. People then started to suggest solutions to the leader-bashing, but the first, only allowing attack on adjacent players, would have pretty drastically changed a game that’s already Kickstarted! (I’m often critical of Kickstarted games because of the nature of the audience, but I’m really offended by the idea of Kickstarting a game that is so far from complete.)

As an aside, why is leader bashing undesirable? It takes the strategic decision-making out of the game, you just attack the leader. It makes people want to sandbag (if they can), they don’t want to be the leader until the very end. In fact, given the nature of the game, there was virtually no decision-making involved. You picked your strongest attack that could affect someone in or near the lead, and that was it. I’m not opposed to simple, even shallow, games, but they should still give players viable choices, the “horns of a dilemma” of traditional board games. This one didn’t.

To continue with this egregious example, what we have in this designer is a case of somebody throwing things against the wall to see what will stick. He tried to playtest the game in various ways to see what seemed to work better. It seems to me to be trial and error in the undesirable sense. It also helps show that Kickstarter is often about ideas and intentions rather about an actual game. He had a little bit of the art for the actual game for a small number of the cards and that looked quite good, and probably helped the Kickstarter a lot.

“Scientific Method”/Engineering

So let me talk briefly about the proper way to go about this part of design, not just trying this and that, not throwing things against the wall. I use a fairly detailed diagram and a simpler version. This is an engineering design process. It’s also something like project management, because each time in project management you’re doing something that’s rather different than what you’ve done before. I’ll discuss this simpler project management diagram here.

The Plan is about you creating the game to the point where you have a playable prototype.

Execute is playing a prototype, first of all solo, then other people.

While a game is being played, you Monitor whether it’s doing what it’s supposed to do, whether it’s going according to your plan, the vision you had in your head.

Control is when you monitor something that isn’t going to plan, you do something to fix it, to make it work the way you want to.

Successful changes go into the Replan, where you modify your prototype. Then you go back to Execute and you play it again, and you keep going round and round on that, gradually making your game better.

I despise the word “iterate”. Yes, this is an iterative (repetitive) process, but the word iterate, which is often used in video games, must be one of the ugliest words in the world, yet only covers half of what you’re doing. You are modifying and testing, not just playing again and again. The scientific method is involved. To be termed scientific, a method of inquiry must be based on gathering observable, empirical and measurable evidence subject to specific principles of reasoning. A scientific method consists of the collection of data through observation and experimentation and the formulation and testing of hypotheses. (Wikipedia)

Game design is lot more than that, though. Unlike scientists, in most cases you have to rely on relatively few tests. (Nowadays in video games we see “open beta” testing, and testing after release, in order to increase the sample size and use statistical methods of analysis.) Unlike the scientist you’re making changes in the design, an actual product, as well as experimenting to see what happens. Fortunately, this is usability testing, not scientific testing, and usability testing does not require a large number of trials. I strongly recommend that you check out the Nielsen Norman Group’s website at alertbox.com, and read their articles. They are talking about web design usability, but most of what they say applies to game design, especially video game design where user interface is very important. We have user interfaces in tabletop games, but they have over many centuries settled down and don’t change rapidly.

An Analogy

Being a literal-minded person, I don’t venture into analogies much, but I’ll try one here. This question of engineering versus trial and error (guess and check) is comparable to how people learn software or home appliances or electronics. Unlike most people I read the manual. It’s amazing how much you can learn that way and it’s far more efficient. But what most people do is a just dive in and try things, or they simply remain ignorant. I read the manual and find out all you can do (if it’s a good manual) that most people who just dive in and try things are not going to figure out.

The engineering style of game design is like reading the manual, the trial and error style is like diving in and trying things. It’s much less efficient, but it is easier, just like not reading the manual is easier, and we can apply this to games. I would rather read the rules to a tabletop game in order to learn it, unlike most people who would rather be taught. It may take longer, but I miss less when I read the rules and understand the game better when I read the rules, if they’re good set of rules, than when somebody teaches me.

I’ve discussed the whole cycle of testing and modification in my “Learning Game Design” course on Udemy.com, and there’s also a course just about Playtesting. The major point to make here is that you follow a process that relies on solving problems you’ve identified. You also have to know what kinds of problems might occur, like leader bashing in a card game, and that’s why I make so many of my videos to educate people about those possible problems.

Method is important, and trial and error (guess and check) is poison unless you have no choice but to use it. If you rely heavily on intuition or inspiration, more power to you, but that’s not something that I want to teach aspiring game designers. If you think it’s all about inspiration, I think you’re dead wrong, any more than getting ideas is all about inspiration. You have to work at something to do it well on a consistent basis. You can’t hope to be bailed out by random flashes of brilliance.

As a teacher I want people to understand a good, efficient method: “inspiration,” “intuition,” and especially trial and error (guess and check) are not good, efficient methods.

Design a game, don’t guess at it!（source：gamasutra）