遊戲互動設計規範怎麼寫? 一篇文章學會寫設計文件
為什麼要寫規範
做產品的同學應該都沒聽過“產品設計需要寫[互動設計規範文件]”這回事。
這是因為產品介面層級簡單、互動操作也簡單(當然大產品還是要互動規範的,例如淘寶這種大部頭),主要以流程圖表現為主,控制元件都已經有較通用的互動規範。
所以一般產品部門也不會安排專門互動設計師崗位,而由產品經理或UI設計師兼任。
於是乎不是很大的產品專案,控制元件規範、柵格規範等偏互動的規範會併入UI規範中一起說明,而不會單獨寫一份文件。
這份UI規範中的[表單設計規範]
那為什麼遊戲就需要專門安排互動設計師,還要寫[遊戲互動設計規範]?
缺乏互動規範帶來的問題
在遊戲專案裡,規範制定和執行是成熟和不成熟專案之間一個明顯差別。
剛開始做遊戲的小團隊很容易忽略規範,覺得寫規範浪費時間,甚至把“規範”看成“大公司流程繁瑣的弊病表現”。
我在上一個遊戲專案的時候,大家都沒有制定規範的概念。
專案前期確實省下了寫規範的時間,但是內容慢慢增多了之後,就會發現缺乏規範指導產生了很多問題(附帶後來針對問題制定的互動規範),例如:
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.[互動自查]
這塊是參考了產品互動的需求補充進來的。
互動設計中要細緻考慮的一個地方就是各種分支情況,但這些細枝末節的分支情況有時候容易被疏漏,所以需要[互動自查]來查漏。
作者:小黑
專欄地址:https://zhuanlan.zhihu.com/p/33559087
相關文章
- 遊戲關卡設計方法論(實踐篇)-關卡規劃文件怎麼寫?遊戲
- 程式設計師如何寫好一篇技術文章?程式設計師
- C語言程式設計規範——名稱縮寫C語言程式設計
- 【遊戲互動】手遊適配設計遊戲
- 遊戲文件與遊戲設計遊戲設計
- 手遊UI互動動作設計研究:縮放、書寫、旋轉UI
- 編寫資料庫設計文件資料庫
- 遊戲UX互動框架規範遊戲UX框架
- 遊戲關卡設計文件遊戲
- 好程式設計師分享Css詳解bem書寫規範程式設計師CSS
- 《文明4》設計師Soren Johnson:挑戰4X遊戲設計規範遊戲設計
- [譯] APP 動效設計,看完就會!(Material Design 設計者撰寫)APPMaterial Design
- 移動端UI設計規範模板參考以及設計規範的好處UI
- 名片設計規範
- 程式設計師寫簡歷時的技術詞彙拼寫規範備忘錄程式設計師
- 程式設計小記-程式設計規範程式設計
- 遊戲互動設計中的抽獎感受研究遊戲
- JS程式設計規範JS程式設計
- API 介面設計規範API
- RESETful API 設計規範API
- RESTful API 設計規範RESTAPI
- PCB Stack設計規範
- React程式設計規範React程式設計
- Rest Framework設計規範RESTFramework
- python程式設計規範Python程式設計
- 【軟體設計】專案設計流程規範
- 作為遊戲設計師,能從動森的設計中學到什麼?遊戲設計師
- 介面自動化指令碼設計規範指令碼
- Google 是怎麼設計遊戲手柄的?Go遊戲
- 電商遊戲專題03-互動設計篇遊戲
- 遊戲基礎互動:【建立目標】和【落地設計】遊戲
- 談遊戲世界互動設計帶來的「意外之喜」遊戲
- 知識沉澱 | 遊戲互動設計經驗分享遊戲
- MySQL 規範 (資料庫表設計規範)MySql資料庫
- java遊戲開發雜談 - java程式設計怎麼學Java遊戲開發程式設計
- Greenplum索引設計的規範索引
- ios12設計規範iOS
- Restful API 的設計規範RESTAPI