作者：Lisa Brown

风险消减对游戏设计师来说是重要的一个方面。当你构思出一个游戏点子时，你必须能够批判地看待它，且根据以往的经验和知识来回答：这个点子真的有意思吗？它能很好地融入游戏整体吗？它会增加挫败感还是乐趣？我们有没有使它运转良好的资源？能够回答这些问题对任何游戏设计师来说，都是有至关重要的。

然而，总有那么个时候，固定路径的钟摆也会甩得太远。想法的理论问题可能会吞噬你的时间。你可曾有这样的经历：在一个讨论会上，你正在谈你的武器设定想法，你开始分析这个想法的潜在问题，且将分析深入到了特别细致的程度？

你不断、反复、再次争论，在其他武器存在的背景之下，新设定会不会有趣、会不会无聊、会不会太难、会不会无用，等等。然后，可能当这个想法真正投入执行和测试时，你发现，你一度担忧的理论难题压根儿就没有出现！

理论难题的症状

如果你可以觉察到什么时候风险消减开始变成一个可能无法投入实际运用的理论难题，然后你放弃在争论上花太多时间，那么你就让每个参与工作的人都省下不少精力了。怎么知道你是不是撞上理论难题了呢？以下是我个人的经验：

1、当讨论开始变成兜圈子：两个人的合理观点恰好与另一个观点相反，且提出“如果”情形，使讨论在两种观点之间来回摆动。

2、当成员开始担心一些特定的情况，好像是将想法当成临床病例一样观察，而不是放到某个构思如何在游戏的背景下发生。

3、大多时间，这些理论难题都会在早期出现，也就是想法还很新鲜、还没有投入游戏中执行的时候，但你对事态将如何发展已经有了很现实的预感。

以上这些棘手的难题经常出现，却很难理解。我将列举几个在第一人称射击游戏《抵抗3》（ Resistance 3）制作过程中遇到的理论难题作为分析案例，这些难题消耗了我们不少脑力时间和精力，到最后却根本没发作。

Resistance 3-boat level(from g4tv.com)

案例1：破冰

让我们先回顾一下我们的老朋友——《抵抗3》中的小船关卡。一开始，领导交给我一个靠这个关卡“畅销世界”的目标，另外，影响游戏的一个重要剧情是Chimera将整个星球冰封。我就想：“好吧，现在这个星球比平时冷多了，我们在水上，所以可能得来点冰。哈，如果小船被冰所困，而你可以往冰上射击，以使小船更快地前进，这比较酷吧。”

因为那时我还是一个初出茅庐的设计师，所以我不太清楚我们的破坏系统是怎么运作的，我在团队成员中辗转，希望求证这个想法的可行性。我首先找的是我们小队的场景美工，这家伙过去也做过破碎物，不过看似他觉得我的想法太搞笑，所以我一直等啊等，直到我们找到引擎编程师来主持这场关乎物理学的争论。

现在，他认为这个想法是可行的，但还是有顾虑，因为它看起来非常不切实际。毕竟，如果冰足够厚，小船其实会卡在冰上，也没有办法用枪射击冰以把它变成块状，因为子弹只能削去一点冰面罢了。我的小队开始想出一些反论，所以相关讨论就变成以下情况：

“那是外星武器，所以火力足够破冰了。”

“那人类的武器怎么样？”

“可能只有某些武器可以破冰吧。”

“我认为这不太实际，玩家会认为这很愚蠢……”

……

这时，我知道我们落入俗套了。这个理论难题是，这种情况是不符实际的，所以玩家不会接纳，且这才是所有人的关注焦点所在。我们本来可以花上一整周的时间讨论怎么让这个想法变得实切或者这个现实主义难题是否真的那么重要，但我们甚至从来没有抽时间尝试，看看这个想法是否有趣。我的内心直觉告诉我，玩家可能并不关心打碎东西之类的现实主义。我本可以使用我作为设计师的权威，说：“只管做！”但对我来说，在继续下一步以前，整个团队共同考虑这个想法是非常重要的，所以才会有以上讨论的发生。

我提议成员们给我两天时间来收集模本并进行全员观察测试，看看大多数人是不是真的觉得这个想法太不可思议，如果是这样，我们就再进行一次解决现实主义难题的讨论。另外，如果我们所争论的问题确实不成问题了，我们就可以执行它了。我的提议有以下意义：

团队的其他所有人都跳出争论圈，在测试仍在进行时，解放脑力，把注意力放到其他事情上。

给我一个机会来观察这种交互作用是否有趣、是否值得一试（我的人格过滤网网眼太大，所以对于有趣的事物，我从来不会说“我认为有趣，所有人都会有同感！”）

收集关于“非现实主义”理论难题的数据资料，帮助说服那些忧心重重的人，总比我的一己之见强：“相信我，会好起来的。”

游戏原型(from gamasutra)

上图是我的游戏原型。那时我没有办法弄到玩家射击临时冰层的反馈，所以我只能利用敌人，当敌人被击杀时，冰层破碎，冰块会沿着路径滑行。

一个黑盒原型测试之后，我开始要求随机人群检验整个冰层射击比特。以防万一。我确保让各种各样的人（游戏邦注：包括美工、编程人员、人力部成员等等）去做测试。他们都玩过之后，我就问他们一些问题，如“有没有什么怪异的地方？”

第一批玩家回答，奇怪的地方在于，小船只是冲进开阔水面中间的冰层中。大疑惑背后往往隐藏着小疑惑，所以我调整了原型，让小船做出正在努力通过一个被冰包围的狭窄空间的样子，但小船失算了，所以卡在冰层中动弹不得。这样一来，大疑惑好像解决了。

如我所料，大多数玩家并没有觉得有什么异常，许多人还认为“破冰解船”非常有意思。当针对性地提出用枪射击能否破坏冰层时，大多数玩家的倾向是“当然！”，至少一个人说：“当然啦，那是很实际的事。”

至少一名玩家确实指出：“用枪射击那么一大块冰不是很现实，但那是游戏，我并不在意。另外，打破东西很有趣。”

最后，我将我的成果展示给全体成员，我们的一致结论是，我们曾经激烈讨论的问题到头来居然不成问题，然后我们就在制作破碎冰块的工作上继续下去了。同时，因为我有了现成的原型，我当天就能把它整合到关卡设计中。哈哈，真是一石多鸟啊！

玩家看到船边缘的扁平的冰川会产生挫败感，所以我们把冰川调整成柱状。实际上，这种柱状冰川比较不合理。(from gamasutra)

案例2：船

这个案例并不是发生在我们团队的争论，却是我庸人自扰的结果。

最简单的游戏操作空间？当蓝色区域在前甲板时，感觉最好(from gamasutra)

在制作前期，我对船本身的操作空间作了实验。我查阅了不少船的参考资料，还做了实体模型并投入游戏中运行。一开始，我发现当船舱在前部时，会让人产生一种不知所往的感觉。如果把船舱搬到后方，作为遮挡物，释放前甲板的空间以观察前方，这样感觉就好多了。

对我来说，我的带小后舱的船很“靠谱”，很“船样”，然而，当我开始寻找这个样式的真船时，我犯难了。无论是长是短，真正的船是不会长成这样的，至少根据主题，我们需要的船不是这样的。我很迷茫，好像我确定我已经看到一幅画面，上面有一艘带空旷前甲板和后舱的船，但无论我怎么找，都是无功而返。

我开始陷入真正的忧虑中。如果真实的船看起来不是这样的，那我也不能一意孤行。我是不是应该想出一个使船舱在前部的操作空间的方法？但是不行，不太靠谱。我在这种布局不切实际的船上浪费了这么多时间。我向我的团队成员倾吐了我的悲剧，然后我不确定是谁（可能是我的领导）建议我向概念设计师求助。

我把我的问题告诉了其中一个概念设计师：我急需一种船舱在后面的船，但是现实的船是不会长成那样的，救命啊！！这位设计师安慰我不必担心，他拿走了我的实体模型。就在当天，他就把一幅船舱在后的船的初稿返回给我了，看起来完全就是真正的船啊！

真是伟大的魔法！

如果我意识到自己的困境时就直接去找概念设计师帮忙，我本可以为自己省下许多时间和精力的。我以后会吸取前车之鉴的！最后，所有游戏测试员都立刻意识到“这就是一艘船！” 虽然我确定如果Boaty McBoatswain船长玩了我们的游戏，他会说“不存在这样子的船，”但对于大多数玩家，这艘船已经够逼真了，能满足他们的空间感。

我的概念设计师画出来的“拖网渔船”，大概就是在某一刻我脑中所闪现的船的样子。

看看我的“顶上带小卖部的大棺材”怎么被设计师变成船的(from gamastura)

结论

现在，以上两个案例都是关于绊倒我们的相似难题。“有时候，我们认为事物在真实渲染游戏中的表现应该非常现实主义，但其实没有必要。”但本文的精髓不在于此！理论难题不总是与现实主义相关，也可能是关于物品过弱过强，或者玩家会不会接纳带有某种功能的系统，又或者玩家会不会因为某种游戏元素而拒绝做某事。

我们得到的教训是，有时候，一种想法在理论上看似存在重大问题，但当你以现实的眼光看待这个相同的想法时，结果这个难题根本不构成威胁。技巧在于，学会尝试某事，这样会比讨论更能节省大量时间。毕竟，如果你给每一次讨论的想法都制作一个原型，那肯定效率低下。

也许存在一些些数学公式可以帮助你决定，什么时候该制作模型还是继续讨论，但如果有的话，我也不知道那是什么公式。在些之前，你就好好发现理论难题的症状，然后做出最明智的决定吧！（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Opinion: Theoretical Road Blocks In Design (And How To Circumvent Them)

by Lisa Brown

[In this reprinted #altdevblogaday-opinion piece, Insomniac Games designer Lisa Brown shares some tips for circumventing theoretical road blocks in design, using examples from her working on upcoming FPS Resistance 3.]

Risk mitigation is important for game designers. When you have an idea for your game, you have to be able to look at it critically and call on your past experience and knowledge to answer: Is this really going to be fun? Does it make sense as a part of the game we’re making? Is it going to be more frustrating than enjoyable? Do we have the resources to make it work well? It’s important for any designer to be able to do this.

However, there can come a point when the pendulum swings too far, and a theoretical problem with an idea might start eating up your time more than it should. Have you ever been in a meeting where you’re talking about, say, a weapon idea, and you start analyzing the potential problems with it and get caught up on a particular detail?

You debate and debate and debate about if something will be fun or frustrating or overpowered or useless in the context of other weapons, etc. Then, maybe later on when the thing actually gets implemented and tested, you find out that the theoretical problem you were so worried about doesn’t actually ever come into play.

Symptoms of Theoretical Road Blocks

If you can recognize when risk mitigation starts to turn into a theoretical road block that might not even apply in practice, and take steps to circumvent spending too much time in debate, then you can save a lot of energy for everyone involved. Here are a few symptoms that let me know when I may have hit a theoretical road block:

The debate starts to go in circles: two people have valid points that are counter to one another, and proposed “what if” situations seem to keep steering the discussion back and forth between the two.

People start worrying about really specific situations, as though looking at the idea in a clinical box and not in the context of how things really tend to play out in the game.

Most of the time, these road blocks show up early in the process, when ideas are still fresh and new and maybe things aren’t implemented in your game in such a way yet that you have a realistic feel for how it’s going to play out.

This is a tricky problem that shows up often but is difficult to grasp. I’m going to give a couple of examples of some theoretical problems that showed up for me in the production of Resistance 3, threatened to eat up a lot of mental time and energy, and which ended up not being problems at all.

Example 1 – Breaking the Ice

For my examples, let’s re-visit our old friend, the boat level of Resistance 3 (sorry guys, but until the game actually comes out, the boat level is all you get! Hooray for demos!). From the get-go, my lead gave me the goal of “selling the world” with the level, and one big story effect for the game is how the Chimera are cooling the entire planet. I thought, “Hmm, it’s colder than usual, and we’re on the water, so there’d probably be some ice. Hey, it’d be kinda cool if the boat got snagged on some ice and you could shoot it to break it up and free the boat more quickly.”

Since I was still pretty new as a designer, and had no deep understanding of how our destructible system worked, I went around to my team to see if the idea was even feasible. First I went to my pod’s environment artist, who had made breakable things in the past, and he seemed to think it was doable, so then we went to a programmer and asked him if he foresaw anything that could be tricky with the idea, and so on and so forth, until we got to the engine programmer who was responsible for wrangling the physics.

Now, he thought the idea was perfectly doable, but was concerned because it seemed very unrealistic. Afterall, if ice was thick enough that a boat could actually run aground on it and get stuck, then there’s no way that shooting at it with a gun would break it up into big pieces, the bullets would just chip off. My pod started coming up with counter-arguments, and the discussion went something like this:

“Well they’re alien weapons, so they’re more powerful and would break the ice,”

“What about the human weapons?”

“Maybe only certain weapons could break it”

“I just don’t think it’s realistic, players will think it’s dumb…”

etc.

At this point, I could see us falling into a rut. The theoretical problem was that the situation was unrealistic, thus players wouldn’t like it, and that’s what everyone was focused on. We could have spent the whole week arguing over how to make it realistic or whether the realism mattered, and never gotten around to trying it out to see if it was even fun to do. My gut instinct said that players probably wouldn’t care about the realism if it meant they got to break stuff, and I probably could have brandished my designer stick and said “just do it!” but it was important to me that the pod was on board with the idea before moving ahead with it, so this is what I did instead.

I proposed that they give me two days to whip together a prototype and test it with people around the office to see if the majority really did think it was too unbelievable, and then we could resume the discussion to solve the realism problem if so. Otherwise, if that issue wasn’t really even a problem, we could move ahead with it. This did several helpful things:

It let everyone else on the team detach themselves from the debate and focus on other things while the experiment was being run, freeing up brain cycles all around.
It gave me a chance to see if the interaction would be something fun and worth adding (I have a very broad personal filter for things that are fun, so I can never assume “I think this is fun, everyone else will too!”).
It gathered data about the “it’s-not-realistic” theoretical problem, which helped convince the person who was worried about it more than me just saying “trust me, it’ll be fine”.

[My prototype. At the time I didn't have a way to get a callback if the player shot the temp ice, so I used an enemy, and when they were killed, I "broke the ice" by having the pieces slide away along paths.]

One hacktastic prototype later, I started grabbing random folks to test out the whole ice-shooting bit. I made sure to get a variety of brain types to test it, just in case (artists, programmers, HR folks, etc). After they played, I asked them a few questions, including “Did anything about that seem weird?”

My first few players answered that it was weird that the boat driver just rammed into some ice in the middle of wide open water. Oft times a big confusing thing can hide a small confusing thing, so I adjusted the prototype to make it clear that the boat driver was trying to get through a very narrow space surrounded by ice, but mis-estimated and got stuck. That seemed to eliminate the big confusing thing.

As I suspected, most players didn’t think there was anything weird about it, and many thought it was fun to break up the ice and free the boat. When prodded specifically about whether shooting the ice with a gun would really break it, most players were like “sure!”, and at least one was like “of course, that’s very realistic.”

At least one player did say “well, breaking that big piece of ice by shooting it isn’t very realistic, but it’s a game so I don’t really care. Plus, it’s fun to break stuff.”

In the end, I presented my findings to the group, and everyone agreed that the problem we’d been debating ended up not really being a big deal, and we forged ahead with making the breakable ice. Meanwhile, since I had the prototype made already, I was ready to immediately incorporate it into the design of the level that very day. So many birds were killed with a single stone!

[The flat ice floes ended up being frustrating for players to see over the edge of the boat, so we changed it to a column of ice. This probably makes even less sense, realistically! Playtesters have yet to complain.]

Example 2 – Boat

My next example is not a debate that came up among my team, but a road block that I ended up creating for myself.

Simplest gameplay space ever? Play felt best when the blue area was the front deck and not the back deck.]

In pre-production, I was experimenting with the gameplay space of the boat itself. I was looking up lots of different boat references, mocking up rough models, and then getting them in game to run around on them and see how things felt. Early on, I discovered that when the cabin of the boat was up in the front, it felt in the way, like you couldn’t see where you were going. It felt much nicer when the cabin was in the back, making a pillar of cover and leaving the front deck pretty open so you could see out ahead what was coming next.

My little cabin-in-the-back boat felt very “right” and boatlike to me, but I ran into trouble when I started looking for real-life boats that were built that way. The long and short of it was, they don’t really make boats like that, at least not the sort of boat we were looking for, thematically. I was baffled, I felt like I was SURE I’d seen some image somewhere of a boat with an open front deck and the cabin in the back, but search after search was fruitless.

I started to get really worried. If that wasn’t a realistic way for a boat to look, then I couldn’t just force it. Would I have to figure out a way to make a gameplay space with the cabin up front? But no, it didn’t feel right. I wasted a lot of time fretting over the problem that the layout of the boat that I needed wasn’t realistic. I relayed my woes to my team, and I’m not sure who (possibly my lead) suggested that I go to the concept artists for help.

I presented the problem to one of the concept artists: I need a layout with the cabin in the back like this, but real boats don’t look like that, halp!! The artist assured me not to worry, took my little designer mock-up off, and within the DAY came back to me with an initial sketch of a cabin-in-the-back boat that, well, looked exactly like a real boat!

It was like sorcery!**

I probably could have saved myself a lot of time and energy if I’d gone straight to the artists upon realizing my predicament, and in the future I will know to do just that! In the end, all of the playtesters immediately recognized “this is a boat!” Although I’m sure that if Captain Boaty McBoatswain plays our game, he’ll say “there is no boat that exists that looks like this,” but for the majority of players, it looks enough like a real boat to satisfy their sense of place.

** My artist figured out the existence of the “fishing trawler,” which was probably what I was seeing in my brain at some point.

[How my "giant coffin with a concession stand on top" was transformed into a boat by the artists (sans about a billion iterations in between)]

Conclusion

Now, both of these examples had similar problems that were tripping u
s up. That being, “sometimes things don’t have to be as realistic as we think they do in a realistically rendered game.” But that’s not the real moral of this post! Road blocks don’t always have to do with realism, they can be about how something might be too over/underpowered, or whether players will be inclined to game the system using a particular feature, or if players will not be inclined to do something because of another game element.

The moral is, sometimes an idea can seem to have a big problem, in theory. But often when you look at the same idea in practice, the problem may end up being no problem at all. The trick is learning at what point trying something out will end up saving you more time than debating about it. After all, if you made a prototype for every point in every debate on every idea, it would definitely not be efficient.

Possibly some mathematical formula can be used to decide when you’re going to save time by forging ahead with a prototype over continuing the discussion, but if so, I do not know what it is. In the meantime, watch for the symptoms of theoretical road blocks and use your best judgement!（source:gamasutra）