Fw: [翻譯] 成功的秘訣：專注

看板SLG (模擬遊戲)作者chenglap (無想流流星拳)時間12年前 (2012/04/12 20:37)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串1/1

※ [本文轉錄自 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)