作者：Alistair Doulin

你可曾玩过未留下深刻印象的游戏？这些游戏可能缺乏选择、深度、曝光度或趣味性。今天，我想讨论的是为何许多游戏缺乏获得成功的关键成分，以《Dawn of War II》（游戏邦注：下文简称“DOWII”）和《战地：英雄》为例。最后，我会让你以此判断你的游戏是否是那种无法给人留下深刻印象的游戏。

有限的选择

Sid Meier曾经说过：“游戏是一系列有趣选择的集合体。”这便是那些游戏之所以未让人留下深刻印象的根本症结所在。事情就是这么简单。缺乏足够有趣选择的游戏注定要失败。下面我将深入剖析某些具体实例，这样就可以更加深入地了解这种较为抽象的情况，保持你的游戏朝着正确的方向发展。

实例研究1：Dawn of War II

Down_of_War_II(from wallaperweb)

《Dawn of War》是款很不错的游戏。它延伸出了《Company of Heroes》系列作品，巩固了Relic全世界最佳RTS游戏开发商的地位。游戏很棒，拥有着大量的选择和紧急行为。《Company of Heroes》取得了进一步的发展，增加了许多领域的深度，同时简化游戏中的其他部分，产生更为清晰丰富的体验。但DOWII却将游戏过于简单化，从而出现了以下两个核心问题：线性的技术树；单位类型不足。

附注：应当注意的是，我并没有将基础建筑列为核心问题。尽管无基础建筑可能会让少部分RTS市场狂热分子离开游戏，但是还不足以摧毁你的游戏。基础建筑可以用几近相同的技术树来替代。当这种抽象化被固定之后，问题就产生了，因为玩家在发展中没有可选择。

Relic向我们提供了大量技术树的资料，却只是为了愚弄我们。但是这根本就不是技术树，而是像蛋糕那样层层堆叠！这款蛋糕上存在的问题是，每场游戏都完全相同。FPS世界将这种设计称为“rail shooter”。我觉得用“Rail-Time Strategy”还形容这款游戏的做法还更为恰当。

第二是核心问题是单位类型的缺乏。而且，这又是一种选择的不足。这里萌生出的主要问题是缺乏偶发性。在单位类型的数量如此之少时，根本没有深层次战略存在的空间，更不用说偶发性的游戏玩法。

技术数的有限选择减少了战略选择，有限的单位选择减少了战术选择。限制其中之一可能会带来问题，但是两者都受到限制肯定会让玩家感到大为不满。

实例研究2：战地：英雄

Battlefield Heroes(from forum.i3d.net)

该游戏的核心问题是缺乏偶发性。《战地》系列游戏最大的卖点是游戏的沙盘性。设计师手工构建的体验的FPS游戏感觉很棒。更棒的是沙盘式游戏，你在玩游戏的多数时间里都会碰上新鲜和令人兴奋的时刻。由于对选择的限制过深，《战地》散失其偶发性，而且还未在游戏中添加精心构建的游戏玩法体验。

游戏中的兵种类型过少，而且各兵种之间的差异不大。设立兵种的核心想法被削弱，所以选择变得无足轻重。各兵种的优点和缺点也被弱化。难道这种设计的目标是为了让游戏更容易平衡？因为兵种如此之少，所以拥有过于强大的兵种可以算是灾难性的事情，那么最安全的办法就是让各兵种彼此之间很相像。

那么，复杂性是解决方案吗？

很显然，给这些游戏添加大量复杂内容并不能够解决问题。关键在于在过于复杂和选择不足之间找到合适的平衡点。而且，应该注意的是，复杂性和选择并不一定是对立的。通过制作某些游戏玩法和用户界面中精巧的选择，你可以在不产生令人反感的复杂性的前提下添加大量的选择。

自动化简单选择是个为玩家减压的绝妙方法，可以让他们只需要去做有趣和有意义的选择。

《宝石迷阵》就是款在这方面做得很好的简单游戏。无论你是否喜欢这款游戏，世界上喜欢这款游戏的玩家多达数百万。这款游戏特别容易上手，但是当你继续玩下去时就会发现其中的复杂性和深度。玩家所做的事情很简单，就是交换宝石的位置。但是，位于这种简单玩法之上的深度正是吸引玩家不断在游戏中投入时间的原因所在。这便是深度游戏可玩性抽象化成最简单界面和玩法的完美例证。

解决方案

较少的选择和深度是否就意味着更容易开发、平衡和测试呢？这种削减能否解决那些开发耗资数百万美元的游戏的问题呢？不能。削减游戏开发成本有两个方法：简单化和改善游戏制作方法。如果有合适的人群而且游戏开发过程恰当，我们无需投入数百万美元就可以制作出很有深度的游戏。灵活的开发是减少游戏成本同时形成高质量游戏的绝妙方法。先把注意力集中在让游戏变得有趣，然后决定需要花上多少金钱在游戏发布前对其进行润色。

在尽量短的时间内完成核心游戏的制作，测试和平衡可以在项目初期就开展。因为润色的时间较长，所以这会减少许多难以平衡的选择带来的风险。

为减少成本而将游戏简单化，这就如同改变游戏可玩性使得程序员能够更容易地将游戏制作出来。这是个完全错误的想法。选择和趣味性应该成为驱动游戏开发的因素。

以下是些许简单的测试，你可以用当前正在开发的游戏进行尝试：

1、找些从未玩过你游戏的人。

2、让他们开始玩你的游戏。

3、让他们每次在游戏中做出选择时说“选择”这个词。

4、记录他们做出了多少次选择，包括游戏中各个不同部分的选择数、玩家在每分钟游戏中的选择数量等等

5、如果玩家遇到障碍就给他们提供帮助。

完成测试后，看看你得到的结果。你需要注意的是他们在整个游戏时间中的选择和预想选择的对比情况。如果有较大的差异，为何玩家不做出选择呢？要如何解决这个问题？

以其他成功和不成功的游戏为目标进行测试，然后将结果与你自己的游戏进行比较。

游戏邦注：本文发稿于2009年5月15日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Is Your Game Underwhelming?

Alistair Doulin

Have you ever played an underwhelming game? It might be a lack of choice, depth, emergence or fun. Today I’m going to discuss why many games lack that key ingredient to succeed, giving specific examples of how Dawn of War II (DOWII) and Battlefield Heroes (BH) both miss the mark. I’ll finish up by giving you an exercise to find out whether your game is underwhelming.

Limited choices

Sid Meier once said “A game is a series of interesting choices”. This is the root cause of underwhelming games. It’s as simple as that. Games lacking enough interesting choices are doomed to fail. I’ll dive straight into a couple of concrete examples then we can move out to a more abstract look at the situation and general ways to keep your game moving in the right direction.

Case Study 1: Dawn of War II

Dawn of War (one) is a great game. It spawned the Company of Heroes series and solidified Relic’s position as one of the best RTS developers in the world. It was elegant, with plenty of choice and plenty of emergent behaviour. Company of Heroes took that to the next level adding more depth in many areas, while simplifying other parts of the game to make a cleaner experience. DOWII tried to take the simplification too far with the following core problems: Linear tech tree; Not enough unit types.

Side Note: Notice I didn’t mention base building as a core problem. Having no base building is a sure way to piss off a small, fanatical, part of the RTS market; however it isn’t enough to ruin your game. It can be replaced with a tech tree that serves almost an identical purpose. The problem arises when this abstraction is then hacked back so there is no choice in the progression through the tree.

Just to mock us, Relic gives us a huge printout of the tech tree. But it’s not even a fraking tree; it’s just got tiers, like a cake! The issue with this cake is that it’s the same every single game. There’s no point even having this cake if the player isn’t given the choice. The FPS world has a name for it, rail shooter. I guess the best way to sum it up is “Rail-Time Strategy”.

The second core problem is the lack of unit types. Once again, there simply isn’t enough choice. The major problem here is the lack of emergence. When there are such a limited number of unit types there’s no room for deep strategy, let alone emergent gameplay.

Limited choice in tech tree reduces strategic (high level) choice while limited unit choice reduces tactical (low level) choice. Limiting one or the other is problematic, but limiting both is a sure way to under whelm.

Case Study 2: Battlefield Heroes

The core problem with Battlefield Heroes (BH) is the lack of emergence. One of biggest drawcards for the Battlefield series has been the sandbox nature of the game. Playing an FPS where a designer has scripted a hand crafted experience can be great. Even better is playing a sandbox game where something new and exciting happens most times you play based on the small building blocks set out by the designers. By limiting the choices too far, BH lacks this emergence without replacing it with a heavily structured gameplay experience.

There are too few class types and their differences feel superficial. The core idea of classes has been watered down so the choice really doesn’t matter any more. The strengths and weaknesses of the classes are also too watered down. Is this to make the game easier to balance? When there are so few classes, having an overpowered class can be disastrous, so the safest option is to make them all very similar to each other.

So complexity is the answer?

Obviously, adding a bunch of complexity to these games isn’t going to solve the problem. The key is finding the right balance between too much complexity, and not enough choice. Also, note that complexity and choice are not necessarily opposites. You can add large amounts of choice without adding overwhelming complexity simply by making smart choices in gameplay and UI.

Automating no-brainer choices is a great way of reducing the burden on the player and leaving them to make only interesting, meaningful choices.

Bejewelled is a great example of a simple game that works really well. Love it or hate it, it’s enjoyed by millions of people the world over. It’s a great example of a game that’s extremely simple to understand, but gains in complexity and depth as you continue to play. The player is simply swapping one gem with another, that’s it. Yet layered on top of this is such great depth that players keep playing it for hours. This is the perfect example of deep gameplay that is abstracted into the most perfectly simple interface.

Is it a cop out?

Is having less choice/depth easier to develop, balance and test? Is this cut-back going to solve the problem of games costing millions of dollars to develop? No. There are two ways to reduce the cost of developing games. Make them simpler, or get smarter with how they are made. With the right people, and the right processes in place to develop games, we can achieve deep, emergent games without blowing millions of dollars. Agile development is a great way to reduce the cost of games while still producing extremely high quality. Focus on making the game fun first and then decide how much money needs to be spent to polish the game up before it is released.

By having the core game created as soon as possible play testing and balancing can begin very early in the project. This reduces the risk of many choices being difficult to balance as you have longer to make it work.

Making a game simpler to reduce cost is like changing the gameplay to make it easier for the programmers to implement something difficult. This is the wrong way around. Choice and fun need to drive the development of your game.

Check your game, right now

Here is a simple exercise for you to try on your current game:

Find someone that hasn’t played your game before, ever.

Sit them down in front of the game and get them to play

Ask them to say “choice” every time they make a choice in the game.

Keep a record of how many choices they make, either for each different part of the game, or grouped per minute of gameplay

Help the player if they get stuck, this isn’t a focus test

Once finished, have a look at your results. What you want to see is a good distribution of choices throughout the entire time they were playing. If there are large gaps, why wasn’t the player making a choice? How could this be resolved?

Try this exercise yourself on other successful and unsuccessful games and compare with the results of your own game. (Source: Doolwind’s Game Coding Blog)