[翻譯] 成功的秘訣：專注
本文翻譯自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)
推
04/12 19:46, , 1F
04/12 19:46, 1F
推
04/19 18:58, , 2F
04/19 18:58, 2F