雨季即將來臨。隨著近期的媒體記者會還有後續的所有活動，我們將釋放大量《潘達利亞的迷霧》（暫譯）資訊淹蓋你們。這段時間對《魔獸世界》而言是相當令人興奮地，我們非常期待新資料片的上市。但是…我們還需要一些時間。我希望先把話說清楚，因為這篇部落格文章的內容和《潘達利亞的迷霧》並沒有直接的關聯性。你在這篇文章中將不會找到任何關於《潘達利亞的迷霧》的公告，只有一些你不一定感興趣的理論性討論。如果你希望看到一些令人振奮的公告，你知道我會說什麼，「就快了」。
擁有多種傷害天賦的角色
我說過了這篇文章沒有直接的關聯性，因為我想要討論我們在《魔獸世界》還有《潘達利亞的迷霧》開發歷程中不斷掙扎的議題。有的職業擁有多種傷害製造天賦，而對於法師、術士、獵人、盜賊、戰士和死亡騎士而言，他們的傷害天賦並沒有非常清楚的近戰vs.遠程的區別。「這些職業扮演的是什麼角色呢？」這個問題不斷地浮出檯面。我認為這問題沒有正確的答案，而且在過去幾年間我們也數度改變原本的設計。再重覆一次，我並不是在暗示任何即將發生的事。基本上這項設計會造成許多種不同的結果。這個議題我們討論過很多次了，而根據玩家社群所回應出的強烈意見，我想你也會感興趣。
聖騎士可以從不同的天賦中選擇成為坦克、近戰傷害或是治療者，也可以依據團隊或是戰場隊伍來更換他/她所扮演的角色。透過雙天賦功能，他/她甚至能在同一天內扮演兩種角色。如果他/她的隊伍不需要額外的治療者，或是他/她想暫時卸下坦克的職位，他/她能很簡單的轉換成傷害製造天賦，不需要換另一個人物。術士就沒有這樣的樂趣。但是術士依然擁有三種天賦選擇。問題在於你應該依據情況所需在痛苦與惡魔天賦中做選擇嗎？還是因為你喜歡週期性傷害法術所以選擇痛苦系，或是你喜歡高傷害法術所以選擇毀滅天賦呢？還是說你會依據理論上哪種天賦在下一場戰鬥中會製造多1%的傷害而選擇該天賦呢？
當玩家們希望他們的角色強化的時候，會隨意丟出「缺乏設計方針」這類的意見。當然每個職業都有一個設計的方向；但是玩家們有時候總是會無法認同。我的論點在於即使我們爭辯哪種設計才是最佳方案的時候，並不表示完全沒有設計方針。分清楚這項特點是非常重要的。想當然爾我們對於目前的傷害製造天賦設計方針便是：天賦選擇應該依你的喜好而定。但這也不表示這就是最完美的方針，或是這個方向永遠不會改變。一定會有我們可以嘗試的設計方針。
【方案一】所有天賦在任何情況下傷害量都相近
如果你的傷害製造量和特效型技能不論在哪種天賦下都是一樣的，那麼你便能選擇你所愛的天賦。或許你喜歡法師冰霜天賦中的特效型技能，或是你喜歡狂怒戰士的技能迴圈，那麼你便能選你所愛。如同我先前所說，我們已經使用這個模式一段時間了，其中多少有點成效。這個方案的挑戰在於「任何情況」這個詞上。我們能將所有的傷害製造天賦對於訓練假人所製造的傷害量調整到相近的數字，而就目前而言的確實是這樣。不過實際的戰鬥中我們的目標可不是訓練假人。額外的怪物能讓週期性傷害天賦增加傷害。一大堆的額外怪物能讓擁有強大範圍傷害的天賦增加傷害。在必須跑位的戰鬥中，跑位的距離和頻率都會造成傷害製造量的上升或下降。即使傷害製造量只相差了1~2%(即使只是理論上傷害會比較高，甚至會比他們熟悉的天賦所製造出的傷害來的低)，許多的玩家依然會轉而使用傷害量最高的天賦。喜歡火焰天賦的法師如果被迫轉為秘法天賦的話可能會感到很沮喪，但是另一個玩家可能對於能在不同的戰鬥中嘗試不同的天賦感到高興。
我們在死亡之翼的脊椎的戰鬥中看到某些團隊採取多數相同職業的原因在於，戰鬥中某些階段需要大量的傷害爆發，在這種情況下冷卻時間一分鐘和兩分鐘的傷害技能便出現了差異。儘管我們能將每個天賦的範圍vs.單目標傷害調整到相近，但我們也無法確保每一種傷害天賦在各種不同時間長度的傷害爆發階段都能製造出相同的傷害量。這在數學理論上是近乎不可能的。還是說我們必須依照當前遊戲版本的狀況，以當前的團隊套裝數值測試團隊副本中每一場的戰鬥，並且調整每一個職業的機制呢？這意味著大幅度的改變，而且我認為如果你用哪種天賦在戰鬥中的表現都一樣的話，便失去了一些實驗與理論推算的樂趣。這個方案的結果很平衡，但是否就缺乏了遊戲的深度和趣味了呢？這樣會好玩嗎？
【方案二】每個職業都有擅長的領域，而每種天賦將對應不同的狀況
在這個方案中，我們將在各天賦中加入擅長的領域。舉例來說，秘法對單體目標的戰鬥相當在行，而火焰則是範圍傷害。類似的設計概念已經存在於遊戲中，但我們試著不要做得太過頭。如果你只喜歡法師的其中一種天賦，或是非常不喜歡轉換天賦，那麼你可能會無法接受這個方式。
而且我們也不希望將首領戰鬥的模式侷限在固定比例的範圍vs.單目標戰鬥、跑位vs.定點戰鬥和爆發vs.持久戰等等。這在競技場或是戰場中也是很難琢磨地(例如傷害爆發與機動性在PvP都是很重要的)，因此在這些狀況中可能僅有一種接受度較高的天賦。
【方案三】你會為了特定的效果性技能而轉換天賦
如果採用這個方案的話，玩家們可能會為了某個特別的法術技能而切換到某個天賦。同樣地，這個想法也存在於目前的設計中。死亡騎士可能會想要在某場戰鬥中使用穢邪天賦的反魔法力場。獵人可能會為了團隊所缺乏的特定增益效果而切換成野獸控制天賦。法師可能會在適用燃火的場合轉為火焰天賦。德魯伊可能會在需要颱風的擊退效果時轉成平衡天賦。這類的概念可以延伸很廣。如同方案一所述，並不是每個玩家都希望轉換天賦。如果你喜歡生存天賦，你可能會厭惡為了給予某人增益效果而轉為野獸控制。如果法術技能的擊退效果過於強勢，便會限制你的團隊組合。甚至連一般的休閒公會都被迫要練一堆分身角色，或是為每場戰鬥找許多玩家當作團隊的後補。假設當前版本的團隊副本中沒有任何一場戰鬥能讓戰士的能力充分發揮，那麼戰士們可能會感覺自己像拖油瓶，但是要確保每個首領的戰鬥都能讓各種天賦有所發揮卻是件相當累人的工作。
比較極端的例子便是傷害製造一般的特效型天賦，但是他的特效技能和其它的職業配合下卻能帶來強化的效果。這是《燃燒的遠征》的模式，像薩滿和暗影牧師在團隊中的角色便是為其它單純只能製造傷害的職業強化傷害製造(像是戰士在當時也是被視為單純傷害職業。) 在《巫妖王之怒》中，我們改變了這項設計。讓各種不同的團隊增益效果能平均分配，讓團隊副本隊伍(還有一些耗時比較長的地城副本)的組成更有彈性。我們知道暗影牧師們希望在傷害製造上能更有競爭力，而不是只扮演強化其它人的角色。即使在現在我們還是經常看到某些職業希望強化某個天賦中的特效型技能，讓他們能夠更容易找到隊伍。
【方案四】不論是PvP或PvE都有一個最適合的天賦
這是《魔獸世界》最原始的模式(《燃燒的遠征》之前)，我們了解有些玩家能夠接受這個模式回歸。在這種模式中，武器、冰霜和敏銳(當然還有其它天賦)的設計初衷便是以PvP為考量，而其它像狂怒、火焰和戰鬥等等的天賦則是以PvE為考量。PvP天賦可能有較佳的機動性、生存或是傷害爆發能力，而PvE天賦則在6~10分鐘的首領戰鬥中有較穩定且持續的傷害。從那時候起《魔獸世界》改變了很多，在團隊或地城副本中已經沒有幾個讓傷害製造職業站著不動便能解決首領的戰鬥了。
機動性、生存和傷害爆發能力在某些戰鬥中是相當有用的，有時候靠著其它的職業更能製造出更高的傷害。(俗話說的好：死人是沒有傷害的。) 另一方面，如果三個天賦中一個是PvP另一個是PvE，那麼對於純傷害職業而言另一個天賦不就沒有存在的意義了嗎。(用來升級的天賦？別鬧了，這一點都不有趣。)再者，《潘達利亞的迷霧》中天賦樹的設計很直接地將同個職業PvP天賦中的特效型技能轉換成三系天賦都能使用的技能。如果這個方案可行，之後你就可以用冰霜天賦進行團隊副本，或是用秘法天賦進行PvP的同時還能使用以前只有冰霜法師能用的控場和逃脫技能。如果你是個熱愛PvP的秘法法師，或是個熱愛PvE的冰霜法師，這是非常棒的。如果你對於將PvP和PvE天賦分支這種較簡單(也比較容易平衡)的設計沒什麼意見的話，第四個方案便不會讓你感到驚艷。
【方案五】別設計複合型傷害職業
這是最具爭議性的模式，可能也是需要最多改變的模式。這意味著我們可能永遠都不會採用它。你可以針對完整性爭辯說，職業本來就不應該設計多個天賦來扮演相同的角色。在這個模式中，武器或是狂怒天賦必須移除一個，並且用其它的天賦代替(箭術？治療？)。術士和其它單純角色的職業將需要大規模的重新設計，才能變成近戰型的術士坦克。每種職業都變成複合職業。最困難的決定變成你想要用遠程或是近戰的方式來玩你的職業（像是德魯伊或是薩滿）。
這個想法用設計的角度來看是非常優秀的，因為他解決了「純傷害職業的傷害量，應該要比複合職業高多少才能彌補他所缺乏的泛用性」這個問題。但是仔細思考後，便會發現其實優秀的設計通常不是最實用的(我能以這個主題編寫一整篇部落格文章)。如果你能穿梭時空回到《魔獸世界》上市以前，方案五其實是值得深思的，但就目前而言絕對不是輕易便能達成的。更別提當那些易怒玩家們發現我們暗地裡大幅度改變了他們的角色時受到欺騙的感覺了。我試著不說出「絕不」這個詞，但是這個模式不該用在一個行之已久的成熟遊戲上。我提出這個方案只是為了文章的完整性，而且我認為某些玩家也會提出這點。
那麼哪一個才是最好的模式呢？
我知道才怪勒！毫無疑問地，基本上我認為以上的模式都不是最好的模式。所有的模式都各有利弊，或許有玩家們能提出讓上述五種模式變得更好的修改建議，甚至能創造出全新的模式。就像我所說的，我們還沒決定要採用哪個方式。如果我們能得到針對各方案的充足建議，我們可能就會想出更好的方法。另外我們將會鎖定這篇部落格的留言回應功能，希望玩家們將你們的迴響發在這個討論區塊中。請記得就連我們都無法確定這個問題會有絕對正確的解答，因此在你回應的時候也請記得這點。
※「鬼蟹」Greg Street 為魔獸世界的首席系統設計師。他持有狂野打擊致命一擊傷害的世界紀錄…至少會保持到測試開始前。
本文轉載自官網（原文連結）
