文/小黑
上一次講了遊戲交互設計師的項目職責，裡面提到遊戲交互規範的制定是一個大工程，所以今天專門講一下。
為什麼要寫規範
做產品的同學應該都沒聽過“產品設計需要寫[交互設計規範文檔]”這回事。
這是因為產品界面層級簡單、交互操作也簡單（當然大產品還是要交互規範的，例如淘寶這種大部頭），主要以流程圖表現為主，控件都已經有較通用的交互規範。
所以一般產品部門也不會安排專門交互設計師崗位，而由產品經理或UI設計師兼任。
於是乎不是很大的產品項目，控件規範、柵格規範等偏交互的規範會併入UI規範中一起說明，而不會單獨寫一份文檔。
這份UI規範中的[表單設計規範]
那為什麼遊戲就需要專門安排交互設計師，還要寫[遊戲交互設計規範]？
缺乏交互規範帶來的問題
在遊戲項目裡，規範制定和執行是成熟和不成熟項目之間一個明顯差別。
剛開始做遊戲的小團隊很容易忽略規範，覺得寫規範浪費時間，甚至把“規範”看成“大公司流程繁瑣的弊病表現”。
我在上一個遊戲項目的時候，大家都沒有制定規範的概念。
項目前期確實省下了寫規範的時間，但是內容慢慢增多了之後，就會發現缺乏規範指導產生了很多問題（附帶後來針對問題制定的交互規範），例如：
1.功能規劃不當
-項目開始時對功能內容沒有大體瞭解，也沒有合理的區域安排，有一個做一個，導致無法合理安排功能位置，反覆修改佈局又會導致開發部門的重複工作；
-功能主次缺乏規劃，導致功能設計時缺乏主次：核心功能設計不夠健全，非核心過於繁重（制定規範也能抑制策劃在需求策劃時突如其來的衝動）；
1對功能模塊進行緯度歸類後，設計時更明確應該將功能細化到什麼程度
2.代碼架構不完善
-圖層沒有合理歸類，層級間關係不清晰，導致新增圖層和舊圖層的邏輯衝突，層級上下關係錯誤，需要花很多時間一一調校（還不一定好調）；
規範層級間的上下關係，說明層級間、層級內的互斥、相容關係，然後定義清楚層級都包含哪些內容，能夠有效幫助開發部門整理頁面關係
-屏幕適配方案沒有安排好，導致開發時對齊等方式不準確，沒有辦法很好適配不同比例的屏幕；
項目中後期補的規範，只能按固定比例適配；所以項目前期一定要跟開發部門討論好適配問題
3.開發過程中組件複用不規範
-該複用的組件沒有合理複用（按鈕、彈窗、控件），導致需要重複開發（重複標註）的同時，還無法保持細節一致；以後也不好維護，迭代時需要每個地方單獨提出來修改，成本巨大；
清楚說明組件的交互方式、所用的地方、資源等，可以幫助開發部門有效複用
-因為沒有整理好控件，導致相似控件操作方式不一致，影響操作體驗；
4.缺乏規範記錄使對接過程中產生偏差
-項目中的每個職位都可能不止一個人承擔，每個人都有不一樣的想法，一旦缺乏標準，容易導致每個人做出來的東西都不一樣；
-項目持續時間比較長時，中間難免經歷人員的變動，在對接工作時很難完全對接到位，口頭傳述過程中也會產生偏差，經常遇到做到某個功能時，之前的負責人已經離職，新人無法瞭解當時的設計構思和規範，無法準確對接之前的設計內容。
我參加到上一個項目時，項目已經進行了2年多，人員變動頻繁，因為缺乏大家一起執行的的規範（不管是視覺規範，還是交互規範，還是開發規範），導致每個人按自己的想法去做，出了問題就按自己的想法去補坑。
越到了後期設計開發過程，問題越來越多，花在解決問題的時間比開發新功能的時間還多。
最後在迭代時，發現底層代碼不規範，想迭代想維護都變得很艱難。老闆不知緣由，項目推動不了，最後導致了前後端主程序離職。
遊戲已經做了三年多，老闆投入了太大成本不想放棄，卻無法繼續，項目和項目組都只能在那苟延殘喘。
所以，千萬不要為了省時間而忽略規範，對項目而言，這可能就是個生死攸關的東西。
產品和遊戲交互設計規範
之前講到遊戲與產品交互的異同，兩者的差異決定了交互規範也存在差異：
最直觀的一點，產品的交互規範拿過來就可以用，通用性很高；
但遊戲交互規範幾乎是針對遊戲量身定製的，而且不像產品，沒有什麼“通用規範”——在遊戲項目裡可以根據需求創造新交互，然後沉澱成規範。
另外，普通的產品交互規範，一般涉及的有[信息規範]、[信息交互規範]、[組件規範]（像Material design、iOS Human Interface這種就另當別論了）。
而遊戲的交互設計規範涉及到的內容要多不少。
規範怎麼寫
在上個遊戲項目梳理遊戲交互設計規範時，悲傷地發現網上並沒有什麼參考資源。
所以我從兩個方方面入手整理：
1.現在項目需要規範的內容；
2.依照交互設計流程：遊戲交互設計規範，就是對遊戲項目交互設計標準的制定，所以規範一定是貼近當前項目的內容和交互流程的，所以借鑑了交互設計的流程來梳理規範的框架。
先打開印象筆記，把想到的內容、提綱和可以參考的資料草草放上去。
內容差不多想完之後，再在Sketch上排版、梳理詳情。
規範寫什麼
1.[定義玩家]
遊戲玩法一般是由項目經理和遊戲策劃定義的，交互設計師做的第一步，是從玩法去分析遊戲面向的目標人群——
只有知道了我們是為什麼樣的一群人在設計遊戲，才能不至偏斜了設計方向。
理查德·巴特爾在1996年發表的文章《牌上的花色：MUD中的玩家》，提供了至今依舊受歡迎的遊戲玩家分類方式探索性格模型分類對遊戲設計的指導作用：
以我上次的MOBA項目（可以套入《王者榮耀》來理解）為例：
- 殺手型：在遊戲對戰中，通過擊殺對方英雄獲得成就感
- 成就型：以提升自身能力、達成遊戲成就為目標
- 探索型：享受英雄、天賦、裝備、技能的搭配，探索新遊戲方式
- 社交型：以遊戲作為社交手段，會在線上線下和其他玩家互動
對玩家類型的理解，可以告訴我們在這些讓玩家舒服的“點”上，應該怎麼去下功夫：
比如殺手型享受擊殺的快感，就在擊殺時增強視覺表現；成就型就給玩家一些“五殺”“超神”的稱號，讚美他，讓他享受。
2.[功能框架]
遊戲中的功能不會一次性做完，一般都有階段性的開發過程：例如前期用戶數量少時，以系統發送郵件為和玩家的主要溝通途徑，社交系統和商城系統暫且推後。
如果交互設計師最開始不清楚遊戲最終情況下會搭建多少功能組件，只是每個階段將新功能往現有的頁面框架上塞，就容易造成：
——沒位置放聊天輸入框了怎麼辦？先郵件按鈕往邊上挪一挪，放上去再說；
——塞完了聊天系統之後，下個階段要增加一個好友系統，好友系統按功能規劃來說應該和聊天系統靠在一起，但因為頁面佈局的原因無法安排進去，只能繼續挪其他功能來騰出位置；
——好不容易放了好友，又有組隊功能怎麼辦？
這個時候你會覺得頭都大了。
所以在最開始的時候，交互設計師就應該跟項目組（一般是項目經理或策劃組長）溝通，瞭解遊戲整體將搭建多少個功能組件，它們之間的關係是如何的。
一個合格的項目經理/策劃組長，也應該在項目初始有一個功能規劃圖。
拿到功能規劃之後，交互設計師要協同遊戲策劃，從遊戲項目需求、玩家需求等方面對功能進行規劃。
規劃方式可以從多個角度進行，舉個例子：
-從[功能間的關聯]將有邏輯關聯的功能進行歸類，在設計時注意給未來的功能預留擴展空間；
-從[重要性]和[操作頻率]出發，對功能的位置、常駐性進行安排；
-從[閱讀/操作]的交互特性去歸類信息和操作的佈局。
以上只是我自己考慮的一些維度，不是全部方式，也不一定適用於所有項目，請根據項目去尋找合適的信息規劃維度。
有效的信息規劃方式，可以使未來信息的擴展設計遊刃有餘，信息歸類明晰，界面規劃也井然有序。
3.[交互風格]
我們知道視覺設計有設計風格，例如“簡約”、“科技感”、“寫實”等。同樣的，交互設計也有自己的“風格”。
但這裡定義的“交互風格”，不單指交互操作上的風格，而是指整個遊戲帶給玩家的風格感受，包含視覺、聽覺、操作感受、反饋等整體給玩家帶來的感覺，即廣義的“交互”。
我們需要一個統一每一方面的方向，這就是“交互風格”。
把[做遊戲]類比成[講一個故事]：
策劃的工作是決定我們要講一個什麼樣的故事，是男孩獨自歷險的冒險故事，還是一個溫馨的動物一家親故事；
視覺則負責勾勒角色形象，繪製故事環境圖；音效負責製作背景音樂、角色配音；動效負責製作角色動作、特效渲染等；
這麼多人，每個人對這個故事都有自己的看法，容易造成每個人做出來的東西不協調，所以交互風格就負責定義故事的敘述背景和風格方向，從敘述背景定義講故事的鏡頭角度，從風格去引導細節的製作，讓構成故事的場景、人物、講話的風格、背景音樂等等元素保持統一風格；
舉幾個例子：
-《爐石傳說》的故事是[小酒館裡的棋牌對戰]，故事敘述背景是[小酒館]，故事風格是[復古科幻寫實]。
攝像頭聚焦在了[小酒館裡的對戰盒]，頁面間的切換都通過盒子的打開關閉、盒子內一層層的內容切換來表達；
視覺元素有復古的厚重質感，搜尋對手時擦著火花的復古轉盤，打開卡包或寶箱時充滿力量感的火花爆破；小酒館歡騰的背景音樂和人聲喧囂，點擊操作時復古的機械聲音——視覺、動效、聽覺、反饋——給玩家描繪著一幕生動的小酒館對戰場景。
-《星際爭霸2》的故事是[人族、蟲族、星靈在各種星球上相愛相殺的故事]，故事在[戰艦裡]發生，風格是[宇宙科幻寫實]。
所以星際的故事鏡頭在[漂浮在宇宙中的指揮船艦]裡，所以星際的界面背景大多是一片茫茫宇宙；界面對話窗口模擬指揮艦窗口；人物也多以半身來展示，因為半身最符合“指揮艦”窗口對話的距離感。
幽藍的視覺風格點綴科幻元素、角色對話窗口、人物和背景的景深襯托下的一個個前景任務窗口、在加載界面背景是宇宙星空，就像在船艦窗口向外眺望——就像一套語言，描述著對話星際爭霸世界裡的故事。
-《風暴英雄》的故事是[時空樞紐中的英雄群戰]，故事在[時空樞紐]發生，風格是[未來科幻]。
風暴設計的空間是一個未來感的“時空樞紐”，所有英雄都在時空樞紐中等待召喚。所以它的英雄大都是全身像角度，用以表達出空間的大小（跟星際的空間感對比一下你就能感覺出來了）。
風暴雖然也是科幻風格，但它想表達的空間比星際更抽象靈動，想給玩家保留想象空間，所以風暴相比星際少了很多裝飾性的科技元素，整體用幽紫的色調，加上抽象的地面和宇宙背景構造了一個空間。操作音效也用的是清冷乾脆的點擊聲響，而不是能讓你想象到自己在操作什麼機器設備的具象聲音。
我現在在網易做遊戲時，常聽到要求說“把這個界面做場景化設計”，所以看到很多遊戲都拼命堆積場景，似乎把每個地方都具像化就是一個好遊戲。
但把所有界面具像化成場景這種理解其實不夠準確。
“場景化設計”就像我的視覺設計師小夥伴常跟我提到的“設計故事”，不是簡單地用華麗畫面堆積成場景，而是用一套設計語言和設計細節，描繪出我們想給玩家呈現的“世界”。
它可以像《陰陽師》一樣，展示一個很大的式神的世界，每個界面都像在這個世界裡的一處遊走——後院、神龕、召喚屋、百鬼夜行、平安京、購物城；
也可以像《爐石傳說》一樣，就展示著小盒子裡的一方天地。
但相對來說，《陰陽師》用具體場景來拼出整個世界觀是比較容易的，也不需要太考慮場景間的銜接，只需要用相似的風格場景來表達即可，出來的整體也不會有什麼大問題，所以較多遊戲都是這樣處理；
像《爐石傳說》這種小場景內的設計，需要在一小方空間裡去融合表達，其實是非常需要功力的，所以才會被津津樂道。
經過如此多方面的打磨，最終完成的《爐石》成功的描繪出了一幕場景，幾個好友圍坐在酒館桌前，桌上擺著《爐石傳說》的棋盤盒子，桌旁火爐裡的炭火燒的正旺，酒館老闆正在忙著招待客人，桌旁的圍觀群眾正在聚精會神的觀賞著這場精彩絕倫的牌局，這一系列的能讓玩家獲得滿足感的視覺與聽覺設計最終讓Team5團隊自己都感覺到驚豔。
4.[頁面層級和交互邏輯]
快到了大家熟悉的[組件規範]了，但但在組件規範之前，還要定義頁面層級和頁面見的交互規範。
產品一般不定義頁面層級，因為層級相對固定和簡單：一般分為[內容層]、[頂欄/導航欄]、[彈出層]。
但遊戲不同於產品，它擁有更多更復雜的頁面層級結構，且每個遊戲可能還有需要特殊定義的層級。
且不論遊戲核心玩法頁面含有[地圖層]、[角色層]、[特效層]，光遊戲大廳這邊的層級就很複雜了。
就例如大廳導航欄吧，它可能有可能沒有，可能可以收縮可能部分可以收縮可能全部可以收縮，它的位置可能是橫的豎的也可能是彎曲的，它的表現方式可能是一排圖標可能是分散在場景裡的入口可能是……——每種不一樣的變化，都會導致界面層級規範的改變。
再舉上個遊戲項目為例子，相對來說它已經是個接近產品風格的、規整的大廳了，但例如彈窗本身因功能主次不同，就需要多劃分出層級來。
因為遊戲的界面多且複雜，所以不容易在最開始就定義完所有層級和層級間關係，需要跟著功能的增加，看需求往規範裡增加層級。
定義新層級時，要儘可能全面地考慮它和舊層級之間的互斥關係、優先關係等，以及定義層級的操作方式、數量、內容等。
層級交互
[1-層級]僅次於A1層
[2-操作]彈出後，背景用半透明黑色蒙版，屏蔽其他所有操作
[3-數量]N≤1——彈窗間為互斥關係，不允許兩個及以上彈窗同時存在：新彈窗打開後，舊彈窗自動關閉
[4-互斥關係]與B層為互斥關係：A層彈出時，自動關閉所有其他B層；且A層在的時候，不允許B層彈出新窗口
層級內容
有多級／多種操作的信息（設置）
當前操作核心任務（添加好友、創建自定義房間等）
在定義新層級前要明確跟開發部門溝通好能否實現這些關聯和邏輯。
確認定義完之後，也要同步告訴開發部門這些信息，什麼類型的頁面歸於什麼層級，讓開發部門在增加新頁面時可以有效處理頁面間的邏輯結構，避免出現各種頁面間關係混亂的問題。
5.[組件]
終於到了大家最熟悉的組件時刻。
組件這塊跟產品的組件規範差不多，基本就是把組件進行規整和規範。
但因為遊戲場景比較多，為了適配不同的場景，同樣的功能可能需要不同的表現方式，這個時候就需要進行[規範]和[表現]之間的平衡，而且是時常會遇到這個權衡問題。這時候就需要全面地考慮組件在界面中特殊化的價值，以及開發成本和維護成本。
這塊參考很多，我就不細說了（或者以後有空再講）。
6.[視覺/動效/音效]
前面在[交互風格]裡提到，交互規範應該定義整個遊戲的“故事”，由它來引導視覺、動效、音效、操作交互的細節。
因為視覺設計師一般在前期確定完風格稿之後，後期的視覺規範就只是通過風格稿擴展到字體規範、顏色規範、按鈕規範、彈窗大小規範這些細節的內容上，方便不同的視覺設計師協同工作。
所以交互設計師在前期制定視覺風格時，就應該積極參與其中。
動效和音效設計師一般也是在有需求時，通過自己的理解去進行動效配置和配音，但可能會缺乏對整個遊戲的感受性，無法準確表達出感覺。這個時候就需要交互設計師進行溝通配合。
-視覺
視覺規範一般包含了字體等。一般視覺規範有視覺設計師去進行撰寫和維護。
但在視覺設計這塊，什麼時候應該加一條線，什麼時候不加這種細節卻是難以把控到的。所以在上一個項目的時候，我也順便從交互設計的角度，對“點、線、面”3個方面制定了一個規範（主要是我們的視覺設計師沒有視覺規範文檔，我也順便做了視覺設計，也就順便寫了個操操的視覺規範文檔orz）。
舉之前定義“有形線”和“無形線”的例子：
-動效
在交互文檔中，我也定義了動效規範，什麼時候應該怎麼用什麼樣的交互動效。
我用Hype3來模擬動效，調整出最合適的時間數值和動效樣式，然後對什麼地方適用什麼動效樣式進行規範和描述。
-音效
這塊暫時沒有涉及到，也不是很清楚，以後瞭解了再來做補充。
7.[交互自查]
這塊是參考了產品交互的需求補充進來的。
交互設計中要細緻考慮的一個地方就是各種分支情況，但這些細枝末節的分支情況有時候容易被疏漏，所以需要[交互自查]來查漏。