※ [本文转录自 GameDesign 看板 #1FXhyn0r ] 作者: NDark (溺於黑暗) 看板: GameDesign 标题: [翻译] 成功的秘诀：专注 时间: Thu Apr 12 19:40:29 2012 本文翻译自Jon Shafer部落格及Gamasutra上的文章"The Secret Sauce: Focus" 已经徵得原作者同意翻译。 原文连结如下 http://www.gamasutra.com/view/news/168279/ Opinion_Most_failed_games_suffer_a_lack_of_focus.php Opinion: Most failed games suffer a lack of focus http://jonshaferondesign.com/2012/04/10/the-secret-sauce-focus/ The Secret Sauce: Focus by Jon Shafer [Console/PC, Design] April 10, 2012 [In this piece reprinted with permission from Stardock producer Jon Shafer's blog, the former Civilization lead designer explains why a developer's lack of focus is almost always the core reason for a game's failure.] 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. 文明帝国的创造者Sid Meier总是这样地专注并且长时间耕耘着。就是这样他才成为公认 的大师之一。 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. 我们想知道Sid的秘密武器，今天就透漏给大家知道。他总是知道哪些特点是比较重要的 。而且可以在一两周内做出一个完整的原型。诀窍就是不要浪费力气在其他不重要的特色 上。 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? 我要告诉大家Sid曾经舍弃百多个那些不好玩的原型。假如Sid把那些都做出来，那些游戏 就会像我们知道架上失败的那一类。 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. 游戏唯一需要的就是那些完整且精练的部份，也就是那些从未被认为该移除的特点。 不要分散资源给那些会伤害游戏的特点上。 -- "May the Balance be with U"(愿平衡与你同在) 视窗介面游戏设计教学，讨论，分享。欢迎来信。 视窗程式设计（Windows CLR Form）游戏架构设计（Game Application Framework） 游戏工具设计（Game App. Tool Design ） 电脑图学架构及研究（Computer Graphics） --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 114.44.126.221 ※ 编辑: NDark 来自: 114.44.126.221 (04/12 19:40)

※ 发信站: 批踢踢实业坊(ptt.cc) ※ 转录者: chenglap (61.18.51.146), 时间: 04/12/2012 20:37:31