缺陷與出路——乙個遊戲開發者的反思
編者按：
這篇文章脫胎於乙個叫《遊戲人成功學》的系列文章，它是作者長期身處遊戲開發行業、親歷遊戲行業痼疾後不吐不快的隨筆。世界上的任何事情都是這樣， 當乙個人對某個事物了解越多，他也就越能清晰地看到這個事物的缺陷。編者報道遊戲行業也有數年時間，覺得作者這篇文章雖然有過於「專業」的嫌疑，但比起那 些行文淺顯、美化遊戲行業、特意以「玩家」為物件談論遊戲行業本象的文章來說，這篇文章對我們的讀者和遊戲玩家也更有意義。從刊物的角度說，盡最大可能展 現、記錄這個行業的方方面面，本來也是**份內的責任。以上就是我們選登這篇文章為本期專題的原因。
由於原文涉及到的專業術語很多，我們對之進行了幅度較大的修改，以期能使讀者更好地理解本文。
「遊戲開發成功論」？
我曾寫過幾篇類似《給進入遊戲行業新人的八個忠告》的文章，被個別朋友吹捧了幾下之後，自己頗有點傳道育人的 成就感。但後來仔細琢磨，發現應該被教育的恰恰不是新人，而正是如我一般或比我高大睿智的所謂的老人、前輩、製作人和領導。新人終究有超過一半的機會通過 試用期，但勤奮刻苦的中國遊戲製作人們所領導的上百家開發公司，窮多年之力，到今天為止，真正成功的產品仍寥寥無幾，其中世界級的產品，數量等於零。對比 可見，老人、前輩、領導和偽高手們比新人更需要教育。有了被教育的覺悟，首先做的是反省和自我教育，本文即是乙個從業有些年頭的冒牌高手——我的幾點零碎 感悟，希望能以點博麵，給讀者少許啟發。
是為序。
一、從d&d看遊戲的底層設計
把乙個所謂的遊戲意義上的偉大創意在遊戲產品上付諸於實現的前提，是所有的設計應該符合遊戲工業設計規範。
——龍雲峰《eee&lumines: design for business》
這是我第一次看到有人這麼明確且重視地提出遊戲工業設計規範。在中國遊戲發展這麼多年的情況下，到2023年才由乙個入行不久的「準老人」提出，對於所有在職的「老人」和「大師」們，都是一種絕妙的諷刺。
可 能很多玩家都奇怪，為什麼乙個國產遊戲會拖期再拖期呢？為什麼拖期之後出來的卻是個bug不斷的半成品呢？為什麼一款網路遊戲開發到後期，連畫面風格都要 做出調整呢？遊戲開發目前幾乎所有專案的癥結，歸根結底都與遊戲設計的架構和流程有關。其實玩家們不知道，在國內遊戲專案的程序中，下面這些糟糕的狀況經 常會出現：
1）專案中期發現，如果編輯器支援乙個特殊功能將能節省美術1/3的工作量；
2）做到第25個月發現所有美術風格相比某遊戲已完全落伍，不得不重做；
3）你和所有的人都知道遊戲有什麼功能，但沒有人能說出遊戲為什麼好玩；
4）乙個程式的離職導致全部渲染底層需要重寫；
5）你的mmo內測中，發現玩家只要1星期就能練到100級，而這是遊戲的最高端別；
6）遊戲最終版本與提案書對比，只有不到30%的功能得以實現。
這些只是幾個我曾經聽到的例子，而很多更加荒誕的情況都在不斷上演、不斷重複。我曾經跟乙個在做專案管理的朋友說過，我們一直在重複你們過去曾經犯 下的錯誤。似乎所有團隊都必然要交這樣或那樣的學費，可悲的是更多的人交了學費仍不反省，仍然採取僥倖態度忽視遊戲初期設計的作用。也因此，我們今天看到 的國產遊戲成功者仍然寥寥無幾。
要避免後期開發中的混亂局面，在遊戲設計的初期，就需要首先建立軟體工程規範化的概念。什麼叫軟體工程？它是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它有三大要素。
1.目標：生產具有正確性、可用性及開銷合宜的產品。
2.過程：生產乙個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。
3.原則：是指圍繞工程設計、工程支援及工程管理在軟體開發過程中必須遵循的原則。
遊 戲軟體的開發與其他軟體開發相同，都要符合軟體工程的規律。遊戲的最根本本質是乙個軟體，文化產品只是軟體完成後的附加屬性——很顯然的，opengl不 僅能用於開發主視角射擊遊戲，也能開發工業cad軟體甚至遠端醫療軟體。商業軟體的系統分析是針對使用者實際的特點，來決定使用者的現實需求如何能在軟體開發 中實現，而遊戲軟體的開發也是同樣的道理。一款遊戲是否能順利開發完成，取決於它的結構是否符合軟體工程規範，這是降低遊戲開發難度和專案複雜度的前提。 因此，我將遊戲設計符合軟體工程的要求，定義為遊戲工業設計規範的乙個基本條件。
而這對現在的中國遊戲人而言，無疑是乙個非常苛刻的要求，或許 更有人會說這在目前的國內遊戲行業也是個空想。但我們不妨仔細研究一下d&d這種老牌的桌面遊戲規則吧！它至少符合乙個嚴格的軟體工程所需要具備 的基本特徵。仔細研究d&d，你會發現，所有的物件，通過基本屬性、天賦、適用規則等（內涵構件）進行定義；通過規則操作，如魔法攻擊（介面）進 行相互作用；通過模板、種族、職業（類關係）進行衍生和統一。由於設計者將本來錯綜的遊戲世界高度概括成數位化的規則（生物/人造/自然物件的基本屬性和 基本屬性作用規則），因此在面對整個遊戲世界這個巨大的複雜系統時，d&d具備幾乎無限的擴充套件能力，可以適應不同科學發展度，不同文化的背景設 計。
理論上，構建乙個虛擬的世界，它的基本要素越是高度概括和定義的，那麼底層設計工作的重用性就越高，擴充套件性也越大，同時，由於每次依靠本 層次控制項和規則構成往上乙個層次時都可能與最初的設想有極小的偏差，因此最終層次的表象控制就越難。如果我們把當前的宇宙視為乙個遊戲專案，那麼，上帝至 少在設計之初將「夸克」視作最底層的材料，而我們看到的整個世界都是由幾種基本的「夸克」構成的（看來上帝的美術工程師很省工）。由於層次非常多，這個世 界最後的面貌很可能與上帝的提案書差距非常大。當然，上帝可以在最高層直接新增規則來更改這個差距。
d&d代表了目前遊戲設計能夠高 度概括到的極限（或許《進化》能打破這個紀錄，還沒有看到遊戲，不知道具體情況）。我們做遊戲設計，沒有必要做到這個層次，只需要抽象到玩家看到的具體控 件的下面一層就可以。例如mmo中有設計紙娃娃的需求，裡面有襯肩，那麼，我們只要比常用的做法更進一步，將襯肩再向下乙個層次，分為貼圖風格、形狀、特 效種類、特效顏色4個基本控制項，那麼，只要每個控制項做少量幾種就能組合成很多種類的襯肩，這樣規劃可大量減少美術的工作量。而常規做法只能是乙個個襯肩去 建模和繪製。
概括和定義底層是遊戲設計對商業需求分析後最簡單的乙個步驟。在分析商業需求過程中，我們可針對各個方面抽象出類似的關鍵問題：
1）npc、怪物、boss和玩家角色是否屬於共同的類？如果是，這個類如何定義？其子類如何定義和區分，基本屬性、骨骼、模型、紙娃娃、動作是否通用？各子類是否有必要定義各自的子類？這些所有定義對於美術和程式工作的影響何在？
2）職業、種族作為通用模板如何對上述的類中的物件進行作用，其作用是否與子類的定義相關？
3）作為場景設計的需求，有多少建築物件以構件組合方式可以作出變化？如是，組合需要支援多少種風格？有必要單獨設計的建築有多少？
4）有無可能以一種統一的公升級規則操作基本屬性來控制所有的平衡？
這種問題還有很多，根據遊戲型別的不同，進行設計時的需求也有很大變化。
遊戲設計符合軟體工程的要求，需要專案負責人有基本的軟體工程知識，並有相應領域的專家加以配合。很多boss和leader喜歡拿到提案書就開始督促手下人幹，事實上，如果給大家幾個月的時間實現乙個規範的工業設計，就能避免以後無數的問題，節省大量返工的成本。
前面說到的是遊戲開發這個專案的初步設計問題，接下來我想談一下我對於遊戲設計過程具體管理的看法。
遊 戲工業的理想狀態，應該是流水線生產、精益生產、個體創造的結合，在策劃階段、遊戲架構階段、試生產階段、測試階段需要採取不同的策略，從而最大程度降低 風險、降低成本及控制開發時程。注意「面向過程的管理」這個精益生產的實質，正是遊戲開發未來所必須追求的目標，也是實施遊戲工業設計規範所不可缺的部 分。長久以來，遊戲業內的管理是「面向人的管理」或「面向目標的管理」，甚至有的連目標管理都沒有，而不用說進行真正的過程管理。
肯定有讀者會 說：誰說中國遊戲開發沒有過程管理？沒有月表麼？沒有開發計畫麼？沒有工作日誌麼？我要說的是，並不是表述了過程就可自認為進行了過程管理，也不是每天跑 去問程式進度如何就是做了過程控制。「面向過程的管理」包括非常多的技巧和細節，這需要管理者去研究、規劃和控制。
二、專案開發中的混沌和秩序
我們可能都聽說過這些說法：「你不可能不勞而獲」「覆水難收」或「天網恢恢，疏而不漏」。如果這些諺語對你說來不算陌生，而且在日常生活中你也反覆有過這樣的親身體驗，那麼你就懂得了熱力學第一定律和第二定律。
——《熵：一種新的世界觀》
三、遊戲設計的量化問題
我們談過了遊戲開發過程中面臨的諸多問題，但這裡還有乙個基本問題是——是不是所有開發工作都能被量化？
很多遊戲從業者都對此問題持否定的態度。遊戲產業是乙個創意產業，創意和藝術創作怎麼能被量化？所以就有很多號稱牛人所寫的文章、接受的採訪，大談遊戲開發管理的難度，主要根據是，設計工作/藝術創作無法被量化。
真是這樣麼？
在長度度量衡沒有被發明之前，我們可以猜想，人類只能使用簡單的表述來說明距離或長度，例如「高」「很高」「遠」「很遠」「非常長」等，在現代人看來， 這種表述「十分不量化」，但在當時的人類認知中，長度應該是無法量化的，因為缺乏一種單位標準，可以使得不同的人能對長度進行同樣精確、相同認知的表述。 這裡，我們可以看出，至少在數學概念的量化上，需要「單位標準」的確定作為前提。
在上面的例子中，一旦加減法被發明出來，度量衡就會出現，人們會定義長度的單位和換算方式，此時長度就變為可量化單位了（看到這裡，會不會覺得《文明》系列中的科技缺了不少？）。
所以，認為遊戲開發工作不能被量化的遊戲開發牛人們，要麼是對遊戲開發工作根本不懂；要麼就是對其他行業的研究成果視而不見，坐井觀天；有更多的混子們覺得「不能量化」是糊弄投資商和boss最好的擋箭牌。
大家可以去google查查「量化管理」，這已經是專案管理學最基本的概念，但居然還有這麼多遊戲業的牛人、老人嚷嚷無法量化，只能說悲哀，這行業的現狀讓人欲哭無淚。
關於如何「量化」的攻略不管是在網上還是網下都已非常多了，也非常系統了，這裡且不多說。大家去搜尋一下，注意多看廣告和**的，人家本質上也是創意產業……看完以後你保證有抽那些「無法量化」牛人的衝動。
在整個遊戲開發設計過程中，沒有乙個階段是絕對無法量化的，不過存在乙個量化成本的問題。因為量化需要度量，度量過程需要建立標準、對比標準，對於很多 無法用數字表述，必須借助統計甚至拓撲來表述的量化目標來說，這個操作過程的成本很高。所以在遊戲最初設計的階段，也就是量化成本最高的階段，不必使用「 量化」的概念去管理和操作。但在後續開發中，必須將程式、美術等工作都做到量化管理，這是使遊戲成為工業化生產的前提，也是我們進行規範的前提。
乙個開發者的全域性思考
我最近要開發乙個需求，就是統一改一下ui標註，專案採用了元件化，標註是放在底層元件中的，供其他元件共用。需求開發前，我認為我要做的準備如下 1 ui要給我統一的標註 2 本需求涉及到多個元件庫，所以我需要多個元件庫的許可權。準備工作做完之後我就開始開發了，開發過程比較簡單，之後就是交付ui同學驗收。...
ghost與盜版 乙個軟體開發者的歷史
接觸ghost是96年的時候，那個時候還在研究所做系統整合。ghost的介面風格一如20年前的樣子，沒什麼變化。97年我在專案中就用到了ghost，背景 金融系統解決千年蟲的公升級，我們去乙個貧困縣部署，我是運維的負責人。遇到乙個問題 unix系統和資料庫，要70多張3.5寸軟盤。而康柏的軟碟機不知...
多人共用乙個蘋果開發者證書
當多人開發時，如果已經申請了幾個開發者證書和發布者證書，蘋果就不允許再建立了，頁面新增的地方被灰化了，所以不可能每個人都建乙個開發證書，這時候需要共用乙個證書了。其實一般在我們的證書介面中應該只有乙個開發證書，乙個發布證書，沒必要生成那麼多的證書，證書一般在過期之後才會重新新增。如下 方法一 rev...