拒絕“散漫”與低效 遊戲研發也需要一套設計規範
先說說寫這題目的緣由好了,又要說回建築業了,雖然建築設計業就像是個傳統產業,很多時候與甲方周旋往往是落入改圖地獄,但正因為這常年與甲方對弈的過程使得當年所處的建築設計行業有了一套相當成熟的設計規範體系。從小到三至五人的建築工作室,大到上百人的建築事務所/設計院都有一套自我熟練而迅捷的《設計規範》。這規範可以說是該團隊的核心價值了,而且難以被複制的工作制度,因為這都是各公司經年累月累積而來的成果,其他任何團隊都不見得適用。
設計規範的重要性
各公司的《設計規範》少到一張A1圖紙用以標示建築製圖各類規則,多到兩三百頁的設計規範報告書都曾經見過,這些規範的內容可以保證任何一員工(甚至剛入職的員工)只要參照規範規則繪製建築圖面,都可以將圖紙的完成度及繪製風格、規格達到相當九成的同步率。當然建築設計圖面還是有許多專業相關及法令相關的製圖內容並非可以輕易上手的,但只憑著規範便能保證製圖所產生的問題縮小到經驗上可把空的範圍。一家建築事務所可能只有一個建築師,卻可能同時接手十來個建築案,建築師並非每天有48小時的時間對所有案子進行創作,自然會接給資深的建築設計師推展個別專案,這時候如何保證所產出的建築設計帶有負責建築師的個人風格呢。沒錯,答案還是《設計規範》。在這些具有完善規範的建築團隊成員眼中,甚至”戲稱”建築師只需要負責簽字跟接案了,因為完善的體制可以讓建築師放心的出國度假,建築案的推展也不會有任何毛病,當年我待過的五人建築師事務所正是如此。
還是CAD時代的製圖
這其實就是建築設計行業高度工業化的展現,建築師只需要確認每個方案的方向是否符合期望,細節只要不脫離原則,根本都是交給屬下全權負責的。正因為如此,一個建築師才有可能一次掌握十來個專案。但在遊戲行業來說,一個製作人掌握兩至三個專案已經是相當了不起了,但在建築行業來說,一個專案設計師負責三到五個專案都是輕鬆平常,至於大專案只要是資深專案設計師也可能扛上兩到三個專案。很多人會說,隔行如隔山,不同行業不能比較,實際上在我經歷過這兩個產業後,發現許多原則性的工作方法及流程規範是可以共通外,最深刻的體驗是建築行業的工作強度確實遠遠的高於遊戲行業是不可否認的。遊戲行業在國內確實就是相當相當年輕的產業,以至於許多的工作流程依然停留在黑暗時代,僅有部分大廠或資歷深厚的公司有熟悉的工作流程,多數時候以遊戲業的標準說法就是「拍腦門辦事」。
迷霧中的試探
缺乏規範的情況也正是導致遊戲研發怠速推展的原因之一,我能理解很多時候是受玩家、渠道或甲方爸爸的干預導致一而再、再而三的改動與返工。但是啊,當年在建築行業負責的第一個別墅建築案可是一星期被建商翻案一次,持續了半年。並非個人能力問題而是期間御用室內設計師、地理師、股東會議、建築造價、土地劃分、違章違建林林總總各種奇葩人物事蹟一一出現,一直到了細部設計圖面完成了都還在小規模的翻案,圖量都是數十張起步的修改。由於工作流程上規範相當明確,即使建商無腦改圖,都不會讓建築圖面在反覆修改中產生誤差並且繪製更加敏捷,而建築師只需要負責確定交稿日期及參與開會,甚至再也無須作任何圖面的討論與決策,因為前期規劃設計的目標與原則都在可預期的範圍內。不過到了遊戲業,從各類從業人員的經歷心得,部分情況是決策者一手掌握大大小小事,小到道具投放或圖示位置。導致美術、策劃與程式往往是相互推託及不信任,因為他們都知道只要決策者一句話其他人說的都不重要了。這種狀況好似決策者能力真優秀啊,中國遊戲業一片光明,實際上決策者連休假五天去張家界玩都不可以,因為整個團隊員工會積累一大票內容等著他決策,導致幾十個人划著手機996地等著下班,然後喊著遊戲業高壓高工時真辛苦啊。如果強硬要某成員出來決策,就會引發一連串踢皮球、甩鍋的大戰,然後相互裝作不知情等鍋炸開,因為沒人知道會不會決策者回來後又修改,而且去郊外完還怕手機沒訊號呢,出國就更悲劇了。
工業化體制的推行
從建築行業的設計規範反思遊戲研發的工作流程,決策者理論上在製作過程中他可以非常悠閒地等待成果,“只要”他在前期規劃好遊戲所有模組的方向及目標即可,至於細節為何根本不需要他操心,因為大方向及準則明確的情況下,誰來做差異都不太大。比如期望玩家體驗N小時候達到十等,N小時內的關卡不可重複,個自負責人員就會想辦法產生匹配的關卡、數值與文案的內容了,這些自然都有套細節規範環環相扣,失誤率就被有效控制住了。決策者在製作過程中應該更進一步去規劃設計日後遊戲研發的新內容及方向才是,甚至提前製作大致規範與內容而非口述理想抱負,設計規範模板及表述流程都應該明確且嚴格統一,確保團隊成員都明白研發各模組的目標及功能,而且資訊透明流通、可反覆校正。這樣可以大幅度減少踢皮球及甩鍋的可能,因為製作模組都有既定的方針,圍繞著該方針前行就少有模糊地帶。但部分時候遊戲行業就是舉著火把,照亮著周遭十米內的範圍,所有人戰戰兢兢地向前,一旦走錯了路折返時踩到隊友的腳還要相互責罵。
有一種團隊很常見,但這種團隊的研發方向相當之明確,就是製作換皮遊戲的專案。很多工作內容不需要決策者參與,甚至這種專案還不見得需要決策者,因為製作方向就是抄襲XX遊戲,人家怎麼做就怎麼做就好,這種團隊也相當和諧善良因為沒什麼好爭論的,反正只要跟XX遊戲一樣就是好的,只要與XX遊戲不同怎樣都會被否決。乍看之下這樣的團隊好似非常具備工作規範,如果薪資相當優渥好似待上三五年都妥妥的,但它的核心價值本身就是最沒有價值的東西,因為它只能跟著別人背影前行。如果本身團隊的資金或人才不夠雄厚,還可能落後XX遊戲N年後只達到別人的六至七成效果呢。但是也不代表不會賺錢,這就是遊戲業讓人奮而嚮往之處,雖然概率越來越低,也希望必然要越來越低。
一看就知道,這是充版面的圖
結語
很多時候懷念建築行業的工作模式,雖然它可能相當勞累。對專案內部是一群有著共通專業術語的從業人員夜以繼日的規劃設計繪圖建模;對外依然能跟公部門、甲方爸爸或工地現場打交道與應酬寒暄,既要嚴謹又要圓滑,雖然壓力山大卻工作充實。遊戲行業雖然996聽起來惱人,也確實犧牲了相當多的個人時間,包括自我學習提升的機會,但回首工作內容可能相當空泛,因為整體工時長卻低效,原因就不累述,但是遊戲業的薪資卻是相當符合一線城市的期望值。有些決策者相當不重視設計規範,它們認為「思維」是最重要的,起因於這類人員並沒有接觸、學習過任何管理相關學門,在專案管理的系統思考學科中已經科學化地將專案的各類狀況解析並提出解決的方案了,也就是撇除人的因素,事情的因果是可以被量化的。而這些決策者其實擔憂的是一旦有了設計規範後,它們就可能輕易被取代,這也是這產業生嫩的地方。實際上設計規範只是保底機制,確保不會產生大誤差,而專業內容的延伸是難以被規範給定義的,除非「僅此而已」。想要有著基本效率推進的研發團隊就不能沒有設計規範,否則永遠都能怪罪給員工心思散漫,即使具有天賦的員工都可能顯得毫無助力,因為沒有目標的團隊任誰都註定是低效的存在。
作為設計規範題目的開端,想談談設計規範對於研發專案的過程為何重要。接下來會根據專案換皮到臨摹到再創造提出一點討論,這部分會拿自身臨摹遊戲UI介面的成果來說明設計過程到如何定義規範的內容,當然這篇文章只是為了開啟下一篇文章的引言罷了。
來自知乎專欄“巫師的遊戲場域”
作者:暴走的巫師
專欄地址:https://zhuanlan.zhihu.com/c_1093515218050813952
相關文章
- 遊戲研發的設計規範(三):場景型別化製作遊戲型別
- 拒絕遊戲創業遊戲創業
- MySQL 設計與開發規範MySql
- 開發也能構建UI元件設計規範UI元件
- 如何做到阿里雲 Redis 開發規範中的拒絕 bigkey阿里Redis
- 遊戲美宣,拒絕亂穿衣遊戲
- 遊戲研發的設計規範(二):成長的積澱——從臨摹到再創造遊戲
- 四大遊戲程式設計網站,邊玩遊戲,邊學Python,拒絕枯燥快樂程式設計遊戲程式設計網站Python
- MySQL資料庫規範 (設計規範+開發規範+操作規範)MySql資料庫
- 研發規範雜談
- MySQL資料庫設計與開發規範MySql資料庫
- 遊戲主機:拒絕逝去的“恐龍”遊戲
- 遊戲開發與設計遊戲開發
- 前端設計與編碼規範前端
- 軟體研發安全規範
- 《文明4》設計師Soren Johnson:挑戰4X遊戲設計規範遊戲設計
- Shell程式設計規範與變數程式設計變數
- Java併發程式設計---java規範與模式下的併發程式設計1.1Java程式設計模式
- 名片設計規範
- 遊戲文件與遊戲設計遊戲設計
- 設計模式 基本規範與基本原則設計模式
- 01 shell程式設計規範與變數程式設計變數
- MySQL 規範 (資料庫表設計規範)MySql資料庫
- 我們是做遊戲發行 (代理遊戲),調遊戲內部介面需要研發提供憑證,研發不給怎麼辦?遊戲
- 併發程式設計的12條規範程式設計
- MySQL 設計與開發規範,很詳細,你該注意了MySql
- JS程式設計規範JS程式設計
- API 介面設計規範API
- RESETful API 設計規範API
- RESTful API 設計規範RESTAPI
- PCB Stack設計規範
- React程式設計規範React程式設計
- Rest Framework設計規範RESTFramework
- python程式設計規範Python程式設計
- 做個清醒的程式設計師之拒絕工作程式設計師
- 遊戲UX互動框架規範遊戲UX框架
- 讓遊戲“活”起來! 一套框架搞定遊戲中的策略設計遊戲框架
- 遊戲互動設計規範怎麼寫? 一篇文章學會寫設計文件遊戲