原作者：Andrew Dotsenko on Mar/4/16
以下文章內容，除經另行註明，係由Gamasutra社群的成員所著。
其中表達的想法與意見為該作者所有，並不代表Gamasutra及其母公司。
我們喜歡談論設計理論。市面上有很多關於系統設計、使用者體驗、敘事、或新型課金方式的演說。但身為一名設計師，為了要將自己的想法放進遊戲裡面而需要和其他人溝通互動時，我們時常會忽略從設計到實作中間的過程。
這一切都要從一個問題開始：＂為什麼有些遊戲就是比較好？＂我的意思是，整體上比起來是更好的。
雖然只有兩個範例，但你可以看出趨勢，對吧？
而這兩組有什麼特別的呢？它們都有著不同的類別、平台，不同的目標群、和市場。它們之中有一點是相像的：玩家體驗的品質。換句話說，這些遊戲是好遊戲因為他們有著良好的設計！
這種品質的關鍵是什麼？點子？或許吧。來看看這些遊戲...印地安納瓊斯風格的冒險遊戲、殭屍電影遊戲、通俗奇幻遊戲、通俗科幻遊戲...老實說，我沒有看到什麼從根本上不一樣的全新點子。
所以說，或許，他們有著特別天賦異稟的人創造了這些優秀的設計？說得好。但遊戲產業充斥著優秀人材，並且以個人層級來說有著最高品質的作品。除此之外，如果我們看看比方說離開暴雪(Blizzard)的人，通常這些人不會馬上做出另一套全新的魔獸爭霸(Warcraft)或暗黑破壞神(Diablo)。
或者是，也許啦，是某種特別的行銷方式？市場上也有很多遊戲品質沒有那麼高級的公司在財務上很成功。
若我們深入一點研究暴雪和頑皮狗(Naughty Dog)的檢討報告，我們或許會注意到這兩間公司在製作文化和遊戲設計的很多方面上有著很驚人的相似度。或許，這就是我們想發掘的秘密？製作文化就是關鍵所在？
這就是我這篇研究的濫觴。我下一個問題是：＂什麼樣的製作文化可以作出成功的創意產品？＂事實上，我不是第一個問這問題的人。遊戲設計就其本質和過程而言，和創新採用(Innovation Adoption 編註：詳見羅傑斯創新擴散理論)的過程極為相似。而創新方法在其他產業已經是個被多方研究的主題了。
我研讀了很多關於創意和創新的東西，然後收斂至兩個靈感來源，更精確來說是兩本書。
我的第一個靈感來源是一本叫做＂天才集合體(Collective Genius)＂的書。
這本書對成功創新公司的製作文化進行了大規模的研究，像是皮克斯(Pixar)、谷歌(Google)、或IBM，以及為何它們在創新方面能全面性地成功。而這份研究指出成功的創新永遠都是關於人以及他們彼此之間如何互動。這不只是和才能有關，還和才能的適才與否有關。
你可以在這裡看Linda Hill將書本精簡化的TED演說(編註：17分鐘有中文化的演說，很建議看。但用Chrome有可能無法開字幕)。
以下就是這些原則：
- 創意摩擦—利用多樣性和衝突，在討論中創造出大量點子的能力。
- 創意靈敏度—結合科學方法和藝術流程，並透過探索式的學習過程來測試及精煉想法的能力。
- 創意決斷力—可以結合不同的想法和方式，來產出一個全新解決方案且完整決定的決策能力
你不覺得看起來很眼熟嗎？你會在很多成功創意產品的檢討報告中看到這些原則的應用方式。若你曾經有過將一些有創意的想法在團隊中成功實行的經驗，那你使用的就是這些原則，至少是不正式的（很多狀況下是不正式的）。
當我們在談論關於創意想法時，另一件很重要的事就是要瞭解如何克服路上的障礙。我第二個靈感的來源是一本叫做＂Creative People Must be Stopped (暫譯：必須阻止創意人材)＂的書(以及相關的Coursera課程＂Leading Strategic Innovations In Organizations 暫譯：組織中的重要策略創新＂)。
這本書是關於創新的成功之道，但我發現裡面很多東西和我在做設計工作時很相似，也就是你有時會感覺到全世界都在合力阻止你實踐想法。這本書列出了最常見的此類型限制和克服它們的方式。
這讓我想到我下一個問題：＂我們能夠將適當的原則給制度化後用在遊戲設計上嗎？＂我們的設計和遊戲在不同的專案之間或許都是全新的沒錯，但其中包含的＂人的因素＂卻非常相似。我們能學到這是怎麼運作的？然後再學會要如何克服嗎？
在遊戲產業將近12年以來，我有著很多相當不一樣的經驗，有時成功有時則否。在我做完研究並獲得全新的知識後，我開始分析我之前所有的遊戲設計和製作經驗。然後我得到一個有趣的結論：當我把事情做對時，這個過程就和這兩本書的內容非常相似。所以，我從我的經驗中集結了幾個適當的原則，找出幾個在遊戲設計中最常見的限制(或障礙)，並且找出克服這些障礙的方法。
這就是我的遊戲設計骨架誕生的由來。從許多方面來看，這是將我所有遊戲設計實務經驗系統化的產物。你也可以稱之為我的遊戲設計心態。
骨架包含三個階段：
- 設計—設計原則和設計師的個人限制
- 溝通—溝通原則和團隊合作限制
- 實作—設計實作和驗證原則，技術和流程限制
設計
我們的第一個階段是設計的建立。而我想要從或許是任何設計流程以及我所有的骨架中最重要的事情開始談。
 |
| 點子 --> 文件 --> 製作 --> 遊戲 --> 玩家 |
圖片中的每個東西看起來都沒問題吧？我們生成我們的點子，製作遊戲設計文件，往製作邁進，然後遊戲上線(GM: Golden Master)。但很常發生的是玩家並不高興。我們這個策劃中少了一個非常重要的元件。
這個元件就是玩家體驗。
 |
| 體驗 V 點子 --> 文件 --> 製作 --> 遊戲 --> 玩家 |
在資訊業和遊戲業中，我們喜歡思考如何使用花俏的生產模式。每個特製的模式各自都有漂亮的文件格式、完美最佳化的程式碼、或是潤飾至極的內容。但這些很酷的模式時常不能合體成一個好遊戲。不管你的文件、程式、或內容多好；那些都還不是你最終的成品。遊戲是一種體驗，誕生於玩家開始與其互動的那一刻。
而這才是我們真正的賣點。不是軟體，不是光碟或包裝 — 而是互動。這就是這個骨架的主要目標 — 要如何在通往優秀遊戲設計並打造高品質互動體驗的路上過關斬將？現在，既然我們已經制訂好目標了，那麼就可以開始往優秀遊戲設計之路邁進了。
先假設我們有幾個不錯的玩家體驗的點子。那我們要如何將它們融入設計之中呢？首先，我們必須知道設計有什麼樣的類型。市面上有很多種分類和方法，但若從組織的觀點來看，我會將遊戲設計分類為兩種主要的類型：巨觀設計(Macro Design)和微觀設計(Micro Design)（我用了2002年Mark Cerny在他的＂方法＂演說中提到的頑皮狗內部術語）。
每個設計類型都有他的目標和抽象化層級(Abstraction Level)。
 |
| 抽象 體驗的點子 巨觀設計 微觀設計 具體 微觀設計 |
任何的功能都是從巨觀設計開始的，也就是以較高的視野在適當的抽象層中敘述玩家體驗這件事。巨觀設計應該要在實作之前就被創造出來，並且在實作階段中只能有非常少的變動。巨觀設計沒有固定的形式：創意簡報、一頁設計書、你設計的關卡和玩法列表表格、等等。
巨觀設計是你＂什麼？＂問題的解答。你在做什麼遊戲／功能，以及什麼是你的最終目標。
第二種設計類型是微觀設計，這種設計將功能的細節都寫下來並且將所有的技術限制和極端狀況都考慮在內。
微觀設計是你＂如何？＂問題的解答。你的功能要如何運作？限制為何？
通常來說，微觀設計是在實作期間創作出來的，並且可能在功能製作時會有許多迭代改變。這通常是怎麼發生的呢：你做了一個文件，做了功能的第一個迭代，發現運作起來不如預期，更新文件，做了功能的第二個迭代，然後繼續下去。
如果我們觀察這兩個設計類別的關係，我們可以很輕易地發現，設計的絕大部份在於微觀設計。大部份的製作階段中，遊戲設計師不是＂生產創意＂，而是回答團隊中像是＂這要怎麼運作＂這類的問題，而且是在製作階段中做這件事，不是之前(順帶一提，這也是為何遊戲設計很難從遠端來製作的原因)。
執行是遊戲設計的一切！和你想到什麼沒有關係，而是你最後完成了什麼。而且就本質上，遊戲設計是活的且迭代的過程(這讓遊戲設計和創新採用的的流程很類似) 。
讓我們看看這兩種設計類型的細節以及這兩者的過程會碰到什麼樣的障礙。
巨觀設計
關於巨觀設計很重要的一點是，巨觀設計實際上非常費時並且因為錯誤所造成的代價極大。這樣說吧：這個佔整體20%的設計造成的重大錯誤佔整體的80%。
這再也稀鬆平常不過了，而且我一次又一次地看著團隊試著要在巨觀設計階段＂節省時間＂。他們想要跳過＂沒用的官僚過程＂，馬上就開始進入製作階段，或是將巨觀設計交付給菜鳥設計師：＂讓菜鳥發揮他們的創意吧，我們有更重要的事要做。＂結果呢，巨觀設計沒有被精雕細琢，抽象層級不正確(太虛幻不實或太鉅細靡遺)，並且不同的團隊成員會有不同的解讀。團隊對最終目標會沒有清楚的方向，這會造成遊戲範疇上的嚴重問題。
大體上來說，在巨觀設計上投入大量心力的目的是為了要減少風險。根據Amy Jo Kim這篇很棒的演說指出，創新成功的其中一個原則是＂事先提出重要的問題＂，而這也是為什麼我們需要高品質巨觀設計的原因。你必須達成的要點就是＂透明化＂。在你的最終目標如水晶般透明之前千萬不要結束巨觀設計階段。
有三種方式可以幫助你達成好的巨觀設計：
團隊的全力參與
再提醒一次，＂事先提出重要的問題＂。你需要在創意、技術、和內容方面的全部知識和專業，然後你需要知道該問什麼問題的人在身旁。
適當的抽象化層級
確保巨觀設計的敘述能以統一且不會被大量誤解的方式將你的點子傳達給你的團隊。如果你團隊內對於巨觀設計沒有大致相等的理解的話，這可能代表它太抽象而無法清楚表明這點子。如果你有一大堆關於某些技術細節實作的問題的話，那代表你的巨觀設計講得太細了，團隊會卡在討論這些無關緊要的細節而無法達成一個高度的遠見。
 |
| 透明度 |
要如何增強透明化？這裡有個方法曾幫助過我。利用＂電梯簡報＂技巧：
- 以四個句子(或少於)的方式寫下你的想法。想像你只有約30秒的時間能闡述它。
- 在這四個句子中，應該要能很清楚地理解你的點子的本質。
- 如果你無法清楚地寫成四句以內 — 你的點子很有可能不太好，砍掉重練。
將巨觀設計視覺化也會很有幫助(小樣本、草稿、故事板、或動畫)，這樣的成本和時間花費都更高，但可以讓你更容易達到透明化的效果。文字很容易被誤讀，圖像被錯誤解讀的機會小太多了。
原型
光做個好的文件可能不太夠。你腦中建立了一個互動體驗的點子，但文字和圖片並不能夠互動。為了要達成降低風險的目標，你或許需要個原型。而且要做好這個點子會在原型階段敗下陣的準備，縱使這個點子在紙上看起來屌爆了。
另一個人們很常會問我的問題是＂什麼時候要停止巨觀設計？我們要如何得知它已經準備好了？＂老實說：看狀況。有時候是管理者做決定，有時候則是整個團隊。每個專案都會有不同的限制和期限。
但我這有個通用的做法：三次迭代原則(廣告業的人們很常用這招)。通常來說，如果做了三次迭代後你的點子還是不夠好，那可能代表它打從一開始就不夠好了。這是原型的另一個重要功用：它讓你可以投入大量的心力實作這個功能之前，在早期就先砍掉爛主意。原型是創意靈敏度的一部份，精煉和衡量不同點子的能力。
微觀設計
透明化和視覺化的支援在微觀設計中同樣重要。但有另一個要點：微觀設計是關於這是怎麼運作的敘述，不是其大概輪廓的敘述，所以要盡可能鉅細靡遺並且不能有機會讓人誤解。你必須將所有的細項和極端狀況都考慮進去，並且要做好準備，因為要搜集所有必要的資訊及驗證這些資訊時會很困難且會花費非常多時間。
如同巨觀設計，常見的問題是＂我們什麼時候要停止微觀設計然後開始製作？＂我會這樣說：在你將微觀設計交付給你的團隊之前，你必須要有80%的把握知道這功能是如何運作的。在這之後，你需要繼續支援並更新你的微觀設計。如果你的團隊需要更多細節的話，你要根據團隊的需求來做更動。
時間點
微觀設計是迭代過程並且會持續變更，所以時間點非常重要。微觀設計最常見的問題之一就是當團隊需要它的時候它卻還沒有準備好，這會造成設計瓶頸。
因為微觀設計的迭代本質，要事前撰寫好詳盡且能縝密的文件是沒有什麼道理的(若你寫的話，那有很高的機率你得重新寫一遍，然後稍後再重新驗證一遍)。
設計師走在團隊前的距離要剛剛好：
- 這讓設計師能預先看到更多潛在的極端狀況和風險，同時設計師和團隊還記得所有已經寫下或未被寫下的功能細節。
- 這樣所得到的回饋品質會好上許多。你會去詢問人們他們現在正要去實作的的任務內容，而不是什麼假設性的功能。結果就是你會得到更具體的回饋。
- 這節省文件撰寫的時間。寫出好的文件非常費時，而若你和團隊同步並且有適當的回饋時，你的文件迭代次數會更少。
設計限制：功能蔓延(Feature Creep)
最主要和最常見的設計限制之一以及範疇問題的主要來源就是功能蔓延，你的專案擁有的功能比你需要的還多並且還要更複雜。有兩個原因會造成功能蔓延，這兩者都和人為因素有關。
第一個原因，當團隊無法內部認可時。結果就是對功能沒有一個清楚的想法，然後就會變得更加複雜，而它的設計就會試著要把所有的意見都採納進去，而且這些意見的優先順序糟糕透了。這會造成＂委員會制設計＂效應(編註：Design by committee 就是參與設計的人多嘴雜，但卻沒有一個領導者統一方向)。
第二個原因，當團隊...就是喜歡某些功能時，它們會變得比其它功能更互相均等。這很常會和錯誤的預估一起發生：通常＂炫炮＂功能的預估完成時間比實際少1.5 ~ 2倍；而＂無趣＂功能的預估完成時間會比實際多2 ~ 3倍。
功能蔓延可能會讓你專案的複雜度呈指數攀升並毀了你的範疇。
所以要怎麼處理功能蔓延？最主要的原則就是＂少即是多＂(Less is More):製作少量但品質很高的功能是更好的選項，而且不要害怕刪除掉不好的功能。當你的設計中沒什麼東西好刪時，這個設計就OK了。但還有一個重要的問題：要怎麼刪？要怎麼定義你需要什麼功能？有兩個主要的因素：功能價值和功能優先度。
功能價值
第一個準則就是功能的投資報酬率。
 |
| 高報酬 | | 主打功能 | 策略目標 | 短期-----------------------------長期 | 修飾 | 有疑慮 | 低報酬 |
高報酬率的功能有更高的優先度。如果你有多餘時間的話，你可以將功能做得更精細。
第二個準則是功能的風險。
 |
| 高投資 | | 承諾執行 | 賭博 | 短期-----------------------------長期 | "放手做" | 實驗 | 低報酬 |
低風險的功能有更高的優先度，而有時候你或許會有時間做點實驗。
這兩個準則可以結合成一張功能價值表：
功能優先度
依重要程度，功能可以被分成核心功能、支援功能、和異種功能：
 |
| 核心玩法機制 支援功能 異種功能 |
- 核心玩法功能 — 這些創造出玩家的主要體驗，玩家在絕大多數的遊戲時間和核心功能互動
- 支援功能 — 那些支援核心功能的功能
- 異種功能 — 讓遊戲添增多樣化的功能
投注於強化功能的心力要依據它們的優先度來做分配。所以，既使有個功能含有極高價值的潛力，但卻不是你的核心功能，或許你應該不要花太多的精神在上面。
如果你想知道更多細節的話，你可以聽聽Patrick Plourde怎麼說(編註：刺客教條2的設計師)。
設計限制：無意識的無能
下一個往優秀遊戲設計的障礙是無意識的無能。這在設計師之間很常見並且會導致數種問題：
- 錯誤的風險評估 — 特別容易在菜鳥設計師身上發生，因為他們無法預測到他們創意背後潛在的後果。
- 過時的知識 — 對於那些不會英文...或是不夠好奇的設計師來說非常常見。
- 倚老賣老 — 相反的，這很常發生在老鳥設計師身上，當他們開始在新的類型或平台並且試著使用過往經驗的標準流程設計時發生。
要怎麼處理無意識的無能呢？解決方案就是團隊的意見回饋。玩玩＂去問設計師＂這遊戲吧：盡早對設計提出意見，越多意見越好。要求從設計師那裡得到透明化的答案，直到他給你為止。
設計限制：抄襲
承認吧，我們都喜歡抄襲。這通常看起來更沒有風險並且是個已實證過的設計，而且抄襲來的功能似乎更容易＂兜售＂給團隊和利益關係人。
但這其中隱含著陷阱：
- 現實中，有很多的因素會對最終的設計決定造成影響，而你可能不知道你競爭者的所有限制和狀況。結果，抄襲來的功能無法運作在你的產品上。
- ＂偷懶的設計＂和忽略細節敘述而寫下像是＂就像XXX遊戲那樣＂或＂照市面上的標準做法來做＂這樣的做法或許很吸引人。但這種情況的風險可能會對你專案產生致命的影響，你只是還不知道而已。
抄襲並不一定就是不好。玩家遊玩過程中碰到的障礙越少越好，而標準做法是個不錯的方法，尤其是在3C產品或介面設計上。為了要適當地抄襲功能，你必須解構它，瞭解它在你的競爭者的狀況下是怎麼運作，然後將其打造成一個全新、根據你的狀況和限制的功能。這也是基礎遊戲設計知識對你來說特別有幫助的時候。
回到我剛剛所說的，一切都是為了玩家體驗，這很重要所以記好了。不論你的功能創新與否，重要的是它是如何建立起玩家體驗的。
溝通
讓我們接著談談溝通吧。最首要也最重要的原則是＂errare humanum est＂(人非聖賢孰能無過)。人類是不完美、有偏見、且通常不太聽別人講話。最糟的是：你沒有其他人選，而且你不能改變人的本質。還有(你不會相信的！)你身為一個設計師也並不完美。你無法知道所有的事物，而且無法事先規劃好完整且鉅細靡遺的遊戲遠景。
分享設計
所以，既然每個人都不完美的話要怎麼辦呢？和你的團隊分享設計！你的團隊是由擁有不同經驗的聰明人所組成的，若你讓他們有機會參與的話，可以讓設計的品質顯著改善。原因是，在實作階段的人們會知道更多對於設計師來說不是那麼明顯的細節。他們可以補足你的視野並幫你的設計抉擇達到更高水準。分享設計的一大優點是你的團隊會開始責無旁貸，這現在是他們的設計了，並不只是某個人的點子而已。這是創意摩擦的關鍵原則，大量的內部點子。讓工匠們自由發揮！
跨領域合作
分享設計的另一大部份是跨領域合作。任何的設計抉擇都包含＂謎題的不同組成物件＂。從不同領域集結人手：科技、藝術、創意 — 並讓他們參與找尋解答之旅。將你的功能進行實作的人會知道每一塊＂謎題組件＂，然後可以明顯增加設計的品質。最後的結果可能會讓你嚇一跳，並且擁有遠超乎你想像的高品質。這樣的合作有時候看起來就像是變魔術(而且他們還是自己決定所有要做的東西)。
衝突
創意磨擦的關鍵元件就是多樣性和衝突。分享設計和跨領域合作讓你擁有多樣性，但要他們之間沒有衝突是不可能的。我不想要太深入地探討衝突學，只是想在最重要的事情上多加著墨。在專案中有三種類型的衝突：任務導向(Task)、流程導向(Process)、個人導向(Personal)。
對需要創意的產品來說(像是遊戲)，小型或中型的任務衝突可以看成是件好事。特別是當你集合了從不同領域來的人，而他們開始爭論任務完成的方法時。大量的小型和中型紛爭是團隊還活著並且在乎專案的好徵兆。
流程衝突在早期可能會是個好事。一般來說這是你增進你的運作方式的好機會。但如果你在後期還有很多關於流程的爭論的話，這可能會導致嚴重的溝通問題，甚至是個人衝突。順帶一提，永遠不要針對個人！
統整後的決定
設計師在溝通階段最終的目標就是找出統整後的決定，也就是將團隊中不同想法和方法結合為並最佳解答。統整後的決定是創意決斷力原則的其中一部份。你的團隊同樣有著創意的潛力，別太貪心了，好好運用它吧。
溝通限制：文件
文件呢，它們：
- 很快就會過時
- 很難保持在最新的狀態
- 人們不太去讀它們(而且不想讀)
文件也可能會是專案碰到瓶頸的來源。要怎麼解決文件問題呢？讓它們好消化。通常人們一次不會閱讀超過一頁的東西。所以不要讓文件超過一頁！下方的圖片展示出這樣的問題在其他產業是如何解決的。
無法將文件做成一頁或是要描述的東西很大？將它拆成幾個＂可消化＂的區塊。通常人們不需要全部的文件，只要可以解答目前重要問題的一部份就好。所有之前提到的＂透明化＂原則在這都適用：清楚、精準的文字、圖像的支援。以我的作法來說，複雜的微觀設計製作文件最棒的格式之一就是Excel表格 + 樣本。
但你知道嗎？我有個壞消息：這完全沒有用。我一直都將我的設計文件視為主要的溝通工具並且很注意品質(我甚至可以驕傲地說我曾經有個文件的意見回饋是＂這是我讀過最棒的設計文件之一＂)。但人並不完美(而你，身為設計師也並非完美)。
這代表：
- 你永遠不會有100%正確的文件(你會忘了一些東西，或是將來會出現全新未知的技術限制)。
- 就算是最棒的文件，人們也不會去讀它，而且也不想讀(你會得到＂超讚文件＂的回應...然後團隊還是不會去讀！)。
- 除此之外還有很多種溝通的管道(郵件、通訊軟體、直接溝通、等等)讓團隊可以在做小型決策時使用。
結果就是你永遠會被人家指責＂文件過期＂(在任何狀況下都不要有會完全過關的錯覺)。
所以呢，解決方案是什麼？嗯，我們首先要承認問題存在。我們熱愛使用＂敏捷式開發(Agile)＂、＂SCRUM＂、＂看板管理(Kanban)＂、和其他＂有彈性＂的方法，但我仍然會碰到一種要我們將設計＂拍板定案＂或是在某個時間點我們甚至應該＂凍結＂設計的意見。而解決方案在某個專案中出現了：我們可以將文件當做程式碼一樣來處理，像是活著的東西而且或許會有臭蟲。如果你的文件和實際上的行為不一致的話，那就是一個可以開在臭蟲追蹤表中、可以修好的bug。現在，你甚至可以用KPT來衡量你文件的品質以及你有多勤勞地更新它們。
像我之前所說的，設計就是你完成了什麼，你創建了什麼樣的玩家體驗，而不是你的文件。文件只是個幫助你溝通設計的工具。而這個工具不是用大理石雕刻而成的，它應該要有彈性並能適應專案的改變。這又要提到另一個除了文件外，可以用來幫助你溝通設計的神奇設計師工具。你必須直接溝通。
以兩種方式運作：
- 工程師不瞭解你的文件？再解釋一次。重寫文件，然後再問工程師一次。
- 不瞭解這功能是怎麼運作的？去問設計師。然後再問一次。
遊戲設計是個基於持續不斷的溝通和蒐集意見的活生生的流程。從直接溝通得來的意見會比其他方案快上許多。現實中，許多設計抉擇是團隊在工作場所討論產生的結果。如果你的工作環境能讓你進行直接溝通並且你能坐在關鍵成員附近的話是再好不過了。快速的意見回饋是創意靈敏度和創意衡量過程的關鍵。
若你是遠距工作的話，那最後一點關於直接溝通的要點會對你很有用。有個叫做三次澄清規則(3rd Clarification Rule)的東西：如果一個問題在三次郵件往返中沒有得到解答，馬上打電話。否則你的郵件串會長到近乎無限。一個小時的直接溝通可以解決的問題會比長達兩週的郵件串還來得多。如果郵件沒用的話，馬上去獲得直接的意見回饋吧。
溝通限制：專家的恃才傲物
有時候設計會被＂專家意見＂給卡住。很更多時候，你身為一個設計師會發現身處於一種情況，當你要求工程師實裝一個看起來再明顯不過的功能時，會得到一個＂這根本不可能＂的回答，而且一點說明的理由都沒有。
這可能是害怕要扛起責任。通常的狀況是這個工程師對於這個功能的某個部份沒有專門知識。或就只是純粹懶惰。特別是當這個功能既無聊又費時的時候。是的，人們並不完美。而且有時候是在非常明顯的方式展現不完美。在某些狀況下，這可能是個人問題(這功能很無聊，而這工程師本身也不喜歡你)。或甚至是政治關係(可能會發生在你和一個遠距外包人員工作時，而這人想要錢多事少的情況；我曾經遇過因為這狀況導致專案死去)。結果呢，你的某些功能會沒來由地被卡住。
這種狀況要怎麼辦呢？請記住，這幾乎永遠不可能像是火箭科學那樣需要專家提供完整的說明。在大多數的情形中，專家會害怕潛在的風險(個人的或專案上的)以及高估了這功能的複雜性。回答專家的疑惑是為了要蒐集這個問題更多的資訊。這可以讓專家更有信心，或是克服＂懶惰病＂(你需要告訴專家這個問題沒有這麼複雜)。要堅持，詢問問題並且從＂專家意見＂中把事實給分割出來。將焦點移到你想要什麼而不是要如何做，這樣也很有效。如果有真的風險的話，那專家可以提供你另一個能達成預期結果的方法。
溝通限制：＂不是我們的創作＂
人們喜歡創作全新的事物。設計師想要做他們＂夢想中的遊戲＂，工程師不喜歡其他人寫的程式，美術師想要畫他們想畫的東西而非被要求畫的。這都和我們的商業目標相衝突。
這本身就是個大議題，但我想要談談某個我很常見到的特別狀況。如果你有個要求很多的發行商或顧客，他們非常明確的需求讓＂創意＂沒有任何發揮的空間，那罹患＂不是我們的創作＂症候群的團隊可能會覺得客戶的回應是在對主導權進行宣戰。你很有可能曾經聽過這樣的話：＂我們只做客戶要求我們做的，絕對不要加自己的東西進去。＂
老實說，這問題很難解決(特別是如果你的首席工程師階層的人有＂不是我們的創作＂症候群)，但有時候將玩家視為一個基準點可能會有所幫助。改變焦點到玩家身上，並且就玩家的價值角度來評估所有＂革命性發明＂的想法(設計觀點的透明化和功能價值衡量表也可以幫上忙)。也許你更可以使用標準解決方案並且轉換團隊的創意力到某個更合適的地方去。
這很有可能無法醫好＂不是我們的創作＂症候群(人並不完美，而且不會改變)但可以幫助你說服團隊，利用標準解決方案來讓他們可以用相同的時間為玩家創造出更多的價值。
溝通限制：利益關係人的意見回饋
我想每個人都記得收到利益關係人(Stakeholder)意見回饋當下的感覺：
- 利益關係人不瞭解你的專案
- 利益關係人的意見互相矛盾
- 強迫你去做比原本講好的還要多的工作
以上都可能毀掉你的範疇，而且被罵的會是你。
記住一件重要的事，你是被不完美的人類給評論的。利益關係人也是不完美的人，他們有限的眼界以及基於該眼界的評斷並不代表他們很差勁。
解決方案就是和利益關係人多溝通，並且解釋你所下決定背後的邏輯點。利益關係在許可你的工作內容後也承擔著風險，而且當他們不瞭解某些事的時候，他們通常會選擇最安全的選項。額外的資訊可能會減少他們的＂危機感＂。
你同時也可以善加利用利益關係人有限的眼光！從我的經驗來看，提供幾個對你來說還可接受的選項給利益關係人會是個好方法，但要留點空間讓利益關係人們能參與(你甚至可以提示他們你認為什麼解決方案最合適)。很多時候，你會得到可以接受的解答，同時利益關係人也很高興他們專家級的意見真的有幫上忙。
關於利益關係人的最後一點：注意隠藏的利益關係人，這些人不能幫助你批准你的設計，但他們可以說不。專案上可能會有一些人不是正式的利益關係人，但可能因為某些原因阻擋你的設計(流程、技術、等等)。試著在早期就找出這些人是誰然後取得他們的意見以避免突如其來的鳥事。
實作
好了，以下是我們最後的一項挑戰。但在我們講下去之前，我想要你知道一些關於玩家的真相。不管你有多少的問題，你所有和範疇、資源、期限、任何事情有關的問題玩家都不在乎。對玩家們唯一有價值的東西就是他們個人的體驗。
 |
| ＂這種生物敢攻擊的東西可以塞滿整座羅浮宮©＂ |
玩家就像蜜獾一樣 — 嗐咪嚨毋驚。這相對你所付出的來說似乎不怎麼公平，但你就是會被如此評斷。而你在實作階段的目標並不只是將功能實作就好，而是建立並打磨玩家體驗。
迭代、遊玩測試、回饋
遊戲設計和創新採用的流程非常相似，而且沒有許多迭代過程的話是做不好的。設計在實作時會成為一個以探索為主的流程是幾乎無可避免的。做好你的設計會失敗一次(甚至兩次或三次)的準備，從錯誤中學習，這是很自然的過程。
你在探索的過程中最好的學習工具就是遊玩測試。你創造了一個互動式的體驗，而遊玩測試是看到你遊戲真實面的唯一機會。你可以寫出一堆很花俏的文件和擁有很猛的科技，但在遊戲設計中，你只能相信你能與其互動的東西。遊玩測試是創意靈敏度原則下的一大部份，也是你衡量你創意的另一個工具。
遊玩測試回饋
當然了，有的"大型"有組織的遊玩測試會利用社會科學的方法和"正式"的報告，但我想談的是在小規模測試中可以很有用的方法。
先說一下遊玩測試的意見回饋：不要太相信人說的話。你的測試員是人(而我們都知道人是不完美的)，並且在改良你的遊戲上可能有非常怪異的點子。如果你問測試員他們會想要改進什麼東西，有很大的可能你會聽到他們最近玩過的兩三個遊戲中的東西。或著，你會聽到最客氣及正面的回應，因為你信任他們並給了他們最重要的任務 － 測試你的遊戲，而人通常不想要忘恩負義。
你必須看他們在你的遊戲中真正做了什麼。你必須看到玩家的內心：看看是什麼樣的互動使人感到有趣並投入，以及是什麼樣的互動會引起種種的情緒反應。所有遊玩測試員的回饋都是他們互動體驗的反射。
另一個小秘密：實際上，你不需要很多人(順帶一提，＂正式＂的遊玩測試不需要太多人)。一個包含8個測試員的小組就可以找到80%的問題了(當然，更複雜的問題或許需要花更多的心力來解決)。
造假
即使在所有的遊玩測試之後，你遊戲功能的設計還是會因為許多的原因而在實作階段失敗(在許多案例中並不是因為這些功能不好)。你或許會瞭解到你的設計在現有的技術或時間限制下是無法做出該有的品質被的。請記住，你的目標鎖定在玩家體驗上，找出另一個方法來實作這個遊戲功能，或是砍了它。
而這裡有另一個小秘密：造假。玩家並不會看到你的後端運作。很多案例中，你並不需要高深的技術來為玩家做出特定的體驗。真的，你不需要為了一個可以用簡單腳本就能達成的目標而寫個複雜AI，你不需要在沒人會看到的地方繪製細緻的貼圖，你不需要在對遊戲體驗上沒什麼重大影響的地方撰寫複雜和＂公平＂的數學公式，諸如此類。如果你做不出某些東西，就造假吧！
實作限制：彈性少
實作階段最主要也最大條的限制就是彈性低。好像你需要等上一輩子來檢查某些設計變更一樣(舉例來說，每當你移動一個桶子時就要花上六小時來等待編碼並測試這關)。正當某些糟糕透頂的工具竟然連CTRL+Z這功能都沒有，同時這編輯器的作者說＂你應該可以在沒有CTRL+Z和地表圖層的狀況下完成你複雜的關卡設計吧？＂之時(我的真實經歷)。或著是當你要做個小小的規格變更時，卻要經歷一連串的官僚流程。像這樣的事情會阻礙設計和最佳化的流程。
快速測試
快速迭代是優良設計的關鍵。最完美的狀況就是設計師可以不透過軟體工程師就可以馬上看到變更的結果。填加新數值、跑編輯器、檢查變更、再次迭代直到你得到想要的結果。遊戲設計是個以探索為出發點的學習過程，如果你想要有個好的設計的話，你所有的流程和工具都要能集中在盡可能減少迭代的時間。你越快能進入可玩的階段你就能完成越多的迭代，你的設計也就更加完備。
最終的玩家體驗會在最佳化的階段，在你測試玩家和遊戲互動時浮現出來。互動的體驗品質是從最佳化的過程精鍊出來的，而迭代時間短可以讓你更快進入最佳化階段。
遊戲設計骨架
讓我們試著統整一下我們所學到的東西：
- 玩家體驗就是一切。遊戲，身為一種體驗，誔身於玩家開始和其互動之時。
- 主攻透明化。知道要做什麼設計(微觀或巨觀)，選擇適當的抽象化層級並且在你的最終目標沒有如水晶般透明前不要動工。
- 遊戲設計就是在於執行。這和你有什麼點子無關，這是和你最後做了什麼有關。
- 人是不完美的。他們會犯錯，他們有偏見而且他們不擅長聆聽，而你不能改變這點。但你可以學會克服人的不完美。
- 和你的團隊分享你的設計。他們知道許多實作的細節，而這會讓他們置身其中。
- 簡化文件並且直接溝通。清楚、不囉嗦的文字、輔以圖像。越快得到回饋你就能越早評估這點子。
- 玩家才不屌你。玩家只在乎他們的個人體驗，而這就是你的作品會被評估的方式。
- 只相信你能夠與之互動的東西。迭代、遊玩測試、蒐集回饋。去看看人們在你的遊戲中做的事。
- 盡快測試以達到更好的設計。你越早能進入可以遊玩的階段，你就可以做出越多的迭代，你的設計也會更好。
- 遊戲設計的重點就在於人。幾乎所有遊戲設計執行的方法都是在於由創造出不完美流程和計劃的不完美人類之間的互動。你不能改變人的本性，但你可以學會如何克服它，並獲得成功。
額外資源：
‘Collective Genius’, Linda Hill, Greg Brandeau
‘Creative People Must Be Stopped: 6 Ways We Kill Innovatios’, David Owens
(Coursera) Leading Strategic Innovations In Organizations
(D.I.C.E. 2002) Mark Cerny, THE METHOD
(TED) Linda Hill, ‘How to manage for collective creativity’
(GDC 2010) Designing Assassin’s Creed 2
(D.I.C.E. 2010) Naughty Dog Presentation
(GDC 2010) Among Friends – An Uncharted 2: Among Thieves post-mortem
(GDC 2012) The Last 10: Going From Good To Awesome
(GDC 2015) Hearthstone: How to Create an Immersive User Interface
(GDC 2014) Hearthstone: 10 Bits of Design Wisdom
(GDC 2013) Through the Grinder: Refining Diablo III’s Game Systems
(GDC 2010) Blizzard Design Philosophies
翻譯：XDorz87
校訂：MilkReaver
沒有留言:
張貼留言