作者：Jon Shafer

人们总是会好奇为何一款游戏会被认为是拙劣之作。当然了，有一些原因很明显，如游戏的步骤太过简单；出现过多重复内容；或者玩家只是觉得无趣但却很难说出为什么。

这些都是非常现实的原因，但它们也都是源自一个共同的问题：即设计师在游戏开发过程中缺少侧重点。也就是说未能明确游戏开发的优先次序是导致一款游戏失败的核心原因。

设计师和项目领导必须尽量投入更多时间为游戏中的特定功能（甚至是整款游戏）设置目标。

也许你正在设计一款策略游戏的战斗系统。而这时候你是希望这一战斗系统像第二次世界大战中德国发起的闪电战那般快速且轰轰烈烈，还是像第一次世界大战西线战场那样更侧重防御？而最终哪一方获得了真正的胜利？是拥有更强大的战略技巧那方，还是拥有较强防御军队那方？或者是率领着正确的部队投入战斗的那一方？

近战部队与远程部队哪种更合适？玩家应该注重防守多少比例的部队？是应该依赖单一类型的部队还是混合部队？

这是设计师在明确任何一个细节或者编写代码行前需要问自己的一些问题。而随着游戏设计的进行，设计师们需要弄清楚更多问题。

当你在后来渐渐迷失自我时（是任何人都可能遇到的瓶颈！），试着在自己的脑中寻找前进的方向，并努力回想自己曾经针对于这些问题所寻找到的答案，你便有可能获得意想不到的结果。就像在战场上，没有计划的战斗终将只是去送命。

Focusing(from poker-babes)

在独立游戏开发领域没有哪些开发者能够为项目投入无限的时间和金钱。有限的资源也就意味着你需要为自己明确一个有限的目标，如果你什么都想尝试，最终只会创造出一些不甚完整的游戏功能。

不仅如此，几乎游戏开发中的任何一个环节都需要你投入比预期更长的时间（游戏邦注：作者个人的经验法则是，根据你自己最保守且“有效的”估计然后在此基础上增加三倍便是你所需要投入的实际时间）。

通常情况下你的第一份游戏草稿总是不如意，而完善它的最佳方法便是不断地进行迭代。而你需要投入更多时间进行迭代，并且如果你想维持基本的缓冲空间，就需要在做出决定时保持足够的自律。

我在过去几年所设计的一些不甚满意的功能都具有一些共同点，要不就是我未能投入足够时间，要不就是我过度专注于功能的开发从而迷失了方向。

“只要关注那些重要的内容便可，”这句话还真的是说来简单做起来难；因为很多情况下我们总是只见树木不见森林。当我们在制作游戏时总会设定一份很长的待办事项列表，但是当你致力于某一功能时你却很容易踏进一个误区，即选择先完成那些相关且非常简单的内容，而不是专注于执行这一时刻本该完成的任务。

迄今为止，对于任何一款游戏来说最重要的特征便是乐趣，所以你也希望能够尽快让自己的游戏具备这一特征。而这时候如果你受到那些简单任务的诱惑，你的游戏也就很容易就此夭折。所以一定要明确一个具体的目标，并始终坚持这一目标而进行发展，不要因为那些简单或具有吸引力的内容而分心。

你需要反复地评估这些目标，确保它们始终能够反映你对于游戏的想法。要知道，没有目标而盲目地前进或者无视已经完成的内容都是游戏开发中的大忌。

这种类型的工作流程经常被人们与所谓的“瀑布式”以及“敏捷”项目管理模式联系在一起。瀑布式模式也就是你在一开始便规划好一切，然后严格执行这些规划完成任务。

而敏捷模式则是先制定一个较为粗糙的计划，并且每隔几周制定出一些细节内容，然后使用这些“时间表”去评估任务的进程以及合理性。相比之下我更喜欢敏捷模式，而游戏产业中也多支持这种模式，但是这种模式要求我们必须拥有足够的能力，并进行孜孜不倦的管理才有可能取得最后的成功。

管理不善的话，敏捷模式也有可能将你带进上述提到的误区中，即忽视甚至完全放弃高级别的目标（并且通常都是无意的）。实际上，敏捷开发比瀑布模式更加需要注重明确优先次序，毕竟你肯定不希望自己的项目因为忽略或远离高级别目标而栽倒于此。

但是这也不是说我们不能改变高级别的目标，因为高级别的目标应该根据不同发展而保持最佳状态。也许你会发现你非常喜欢的一种功能其实一点都不有趣，这时候你就需要对此做出自我反省；仔细研究，并想出一个新的目标。你最不希望看到的情况应该就是自己陷入漫无目的的深渊中吧。

《文明》之父Sid Meier便始终专注于完善自己的游戏，很多人都想知道为何Sid能够做到如此，也就是他有何秘密武器。其实他只是比别人更擅于捕获游戏中的重点内容。他精湛的技巧更是体现在只要花1至2周的时间便能够完成原型创造。而这也体现出他不会将多余时间浪费在那些不必要的功能中。

还有一些需要明确的内容是，Sid在过去几年间丢掉的游戏原型也是难以计量的，主要原因也是是他不满意这些原型。如果Sid Meier在游戏上的安打率都这么低，那么其他多数游戏遭遇失败的现象就更在意料之中了（它们一般都没有经过多次迭代测试）。

你需要牢记：游戏中最重要的内容是那些遵循目标并不断完善的东西。出色的游戏理念不会只停留在绘图板上，如果不能好好实践这些理念，稍微好点的结果是只能创造一些不相干的内容，但是最糟糕的情况则是会给游戏带来一些不必要的伤害。

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

Opinion: Most failed games suffer a lack of focus

by Jon Shafer

People often wonder why a bad game is bad. Sure, there are always obvious clues… it might have poor pacing. Or it might be extremely repetitive. Maybe it’s just not fun, and you can’t quite figure out why.

These might all be very real issues, but they nearly always stem from a single problem: a lack of focus somewhere in the game development process. The failure to establish clear priorities is nearly always the core reason for a game’s failure.

It’s crucial that the designer or project lead sit down and spend as much time as necessary to establish what the goals are for a particular feature (or the entire game, as the case may be).

Maybe you’re designing a combat system in a strategy game. Do you want it to feel fast and dynamic like the German blitzkrieg of World War II? Or more of a brutal defensive slog like the Western Front in World War I? Which side wins? The one with the best tactical skill? The one fielding the best-supplied army? The one who simply brings the right type of units to battle?

How important are melee units compared with ranged units? What ratio of units should most players be fielding? Should it be possible to lean heavily on a single type of unit, or should a mixed force be required?

These are just a few of the dozens of questions a designer should ask himself before fleshing out a single detail or writing one line of code. And as the design comes together, hundreds more questions should be asked and answered.

When you’re lost in the woods several months or years later (and trust me, you WILL be), racking your brain for the best direction to go, looking back on the answers you came up with to these questions will be more helpful than you can imagine. Just as in war, no plan survives contact with the enemy.

Focus is also critical when it comes to actually making the game. Producers are often maligned (what do those folks do, anyways?), but it’s often painfully clear when a poor one is helming a project.

Even in the indie space, there are virtually zero developers out there who can afford to spend unlimited time and money perfecting a game. Finite resources means you need finite goals, because if you try to do everything it’s just going to end in a tragic mess of incomplete features.

Not only that, nearly every aspect of game development takes (much) longer than expected (my personal rule of thumb is to take your honest-to-goodness, genuine, ‘best’ estimate, then multiply the time required by three. This works much more often than I’d like).

The first rough draft for a game is nearly always terrible, and the only way it gets better is through iteration. But you need time to iterate, and the only way you’re going to preserve that essential buffer is with extreme discipline when deciding what does and does not get worked on.

The features I’ve designed or programmed over the years which I’m least happy with are always those that were either 1) I didn’t have a lot of time to work on them, or 2) I was so deep into developing a feature that my sight of the endgoal grew hazy.

While it’s easy to say “duh, just worry about what matters,” it’s one of the many situations where it can become nearly impossible to see the forest for the trees. The todo list when making a game is always miles long, and when you’re working on one feature it’s easy to fall into the trap of knocking out a few related ones just because they’re easy, instead of staying focused on implementing only what is absolutely essentially at that time.

By far the most important trait a game can have is that it’s fun, and you want to get to this point as soon as possible. Being frequently derailed by low-hanging fruit can be catastrophic in this mission. Don’t get distracted by what’s easy or shiny. Establish goals and stick to them.

Make sure to also constantly re-evaluate these goals and make sure they still reflect what you want from the game, but the greater sin by far is pushing forward without a target, or a lack of respect for the ones already in place.

This kind of workflow is heavily tied into the debate (if you can really call it that) between the so-called ‘waterfall’ and ‘agile’ project management models. For those unfamiliar with these terms, the basic theme behind waterfall is that you plan everything out at the beginning, then execute on the finished plan.

Agile on the other hand is more about having a rough plan and only figuring out the details every few weeks or so, and using each of these ‘milestones’ to evaluate progress and course correct as necessary. I’m a big proponent of the latter, as are many in the games industry, but it requires capable and tireless management to be successful.

When poorly managed, agile can also easily fall into the trap I talked about above, where the high-level goals of a project become fuzzy and might be completely abandoned – often unintentionally. In fact, in agile development, strict prioritization is even more critical than in waterfall, simply because you don’t want a project darting here and there with little regard for what the high-level goals are or how close/far away they are.

Once again though, this isn’t to say that high-level goals should not change, because they should when it’s appropriate. Maybe you find out that a feature you were really excited about and thought was going to make the game… is actually no fun at all. Well, it’s time to do some soul-searching. Go to a park and stare at the clouds for a spell, and come up with a brand new endgoal. What you don’t want is to ever be in a situation where you have no goal at all.

Civilization creator Sid Meier is one of the best ever at keeping focused and only spending time on whatever will do the most to improve the game – and it’s no coincidence he also happens to be one of the greatest game designers ever.

People wonder why Sid is so good at what he does, and this is his secret weapon (sorry Sid!). He’s better able to get at what’s important in a game than anyone I’ve ever known. He’s refined his craft to the point that he can produce a mostly finished prototype in a weekend or two. This is only possible if you’re wasting zero time on non-essential features.

Something else important to point out is that Sid has thrown out dozens, if not hundreds of prototypes over the years because, well, they just weren’t very good. If Sid Meier’s batting average on games is that low, is it any surprise that most games (which go through much less iteration) which actually end up on store shelves fail?

If you remember only one thing from this article, take this to heart: the only parts of a game which matter are those that end up fully implemented and polished. Good ideas that never make it off the drawing board, or – worse – don’t get the love they need are at best irrelevant, and at worst can do irreparable damage to your game. (source:GAMASUTRA)