這裡是有感於遊戲直播大神羽毛後續想做遊戲，結合之前也有王老菊做遊戲的事情，想從自己這些年創業和從業的一些經歷和見聞聊聊，盡力給點建議。這裡“主播”代表了一類行業內有夢想也小有經濟積累的人，我個人也見過少數一些單機遊戲創業的人符合這個敘述，但有相似情景（有一套房的錢但不投資、買房或者潤）的其實不多。話題展開計劃了2篇，這一篇偏向技術開發，後一篇偏向項目管理。
個人覺得開發方面B站的Games101系列課可能是基於3D項目溝通的基礎。全看懂不指望，但是如果看完了一點沒法懂，那基本也告別做3D遊戲了。記得王老菊的項目初期開直播講過一個2D遊戲的45度角碰撞判定問題，當時給我的感覺是那麼簡單的問題如果還不能快速弄明白，繼續開發的風險是很高的。不過這一篇裡不會談到人員構成的問題，更多還是說說開發用的工具和知識本身。
另外，做3D需要的知識維度是遠高於2D的，如果沒信心拿捏3D場景開發，用2D畫面做一個《Tunic》那種遊戲也是很優秀的。而且3D引擎當然也可以開發2D遊戲，所以用不用3D商業引擎是一個綜合考慮的事。（這裡提到的多種觀點由於篇幅限制，只能提出一個引子）
1 引擎選擇
引擎選擇實際上還要參考合夥的程序員的技術儲備。這裡假設主流引擎都可以選擇，那麼我認為中小型項目還是應該選Unity ，儘管現在使用前需要詳細瞭解不同版本的收費策略（新的按下載數分成方案是從較新的幾個大版本才開始）。
這個建議主要是基於以下幾個考慮：
——當前國內的Unity開發者比較多，技術分享也比較充分
——3D引擎可以做2D項目，反之則不然
——Unity的編輯器一定程度上可以擴展成自定義地圖編輯器和動作技能編輯器
Cocos或者Godot作為輕量級開發引擎是完全合格可用的，而Unity反而有選擇哪個版本才是穩定版本的問題；但是對於要開發中型規模關卡的項目來說，這些2D引擎開發一個完全自定義的關卡編輯器的代價會大很多，因為幾乎要從編輯窗口到各種預覽功能都要從頭搭建。
對於Unreal，我的觀點是不追求極致畫面質量的就沒必要用。這個引擎中小型遊戲開發者社區人數相對比較少，如果不上Epic獨佔其實也沒有價格優勢。
（圖中為大河劇《怎麼辦家康》中的德川家康源力擊敗真田幸村的橋段。實際上把想法變為現實是非常難的，做遊戲更是如此）
2 原型階段注意事項
如果是第一款產品，原型階段既要驗證團隊也要驗證玩法，其實是挺重要的。這種原型並不類似機核暴造活動的那種規模，因為活動中的項目突出一個點子的展示，有可能做完就丟一邊不管了；而實際產品需要預留的框架擴展空間要更多一些，不能說從原型到正式開發代碼要全部重構，那就白做了。
這裡以類似《空洞騎士》或者《Tunic》這種規模的項目來作為標的，那麼能開發這種程度的遊戲的程序人才其實是很多的（雖然可能都被大廠收編也不好找，這個另說）。商業引擎裡往往提供了模塊化的初始包（Package），可以相對容易地從一個類型化的遊戲開始搭建——例如第三人稱箱庭玩法，在Unity就有3rdPersonController（第三人稱控制器）
控制器模塊，也有完整的範例演示供參考；類似的攝像機跟隨模塊，也可以用CinemachineVirtualCamera（虛擬攝像機）組件來搭，可以實現一些例如緩動跟隨、規避障礙、切鏡頭、軌道鏡頭等常見功能，整個Cinemachine模塊也適合製作各種Cutscene（轉場特寫動畫）。
在其上，如果要實現戰鬥模塊，就需要一定的功能開發編程了。雖然也能找到對應類型化的第三方素材，但是擴展起來就會相對費勁。只用第三方庫也能實現一個類似《Tunic》的戰鬥系統，但僅僅是那樣的動作要素太簡單太生硬了。
例如做一個近戰判定為主的遊戲，如果要實現取消硬直、時停、魔女時間這樣要素，後續還想拓展一些豐富的動作要素，至少需要從角色的動畫狀態機管理、攻擊特效管理、碰撞盒運行與檢測這幾個模塊都自己從零開始搭。
如果是做一個第三人稱射擊遊戲（TPS），原型階段要驗證的重點則轉到鏡頭設置、槍械功能開發（如模擬彈道、後座力、開鏡、紅點、熱成像等等），其次則是場景比例尺，敵人AI等等——動作遊戲敵人AI可以稍微笨一點，以捱打為主，相對射擊遊戲敵人AI就更復雜——這裡的AI只是有限行為樹的常規俗稱，不是最新意義上的“那個AI”。不同類型遊戲的原型，關注的細節截然不同，但往往都不容易。
渲染開發方面，引擎的素材庫能提供一些基礎的大眾化視覺效果，但如果要追求更風格化渲染（如卡通渲染、CRT顯示器風格、劍戟片濾鏡等），最好在這個階段進行驗證，因為這會改變一些美術素材的製作規格。如果遊戲從鋪量開發期再修改渲染風格，可能大量的貼圖需要重繪，代價就非常大了。
這裡再提一個往往不容易注意的點，就是邏輯幀與渲染幀，前者負責計算判定之類的，後者負責視覺表現；有的遊戲類型需要兩者是同步的（要卡一起卡），有的遊戲類型則是2者獨立比較好。單機遊戲要求不高的情況下，兩者的時間片長度往往也是對齊的，這就會導致低幀率判定幀時間略長的問題，例如FS社遊戲常有的“越卡判定越寬”這類情況。
另外，“遊戲是否要支持聯機”這一點也需要在原型期開發並驗證。因為一旦要做一個聯機遊戲，要在設計、架構、性能上考慮的事情就不止翻倍這麼簡單了——例如做成聯機邏輯幀獨立的重要性就會大大提高了。聯機原型可以稍晚於單機原型，基本上動作性越強的遊戲聯機越難做好，要考慮應對延遲的解決方案等等。如果覺得用引擎方提供的聯機服務可以接受（延遲、費用之類），至少也要在這個階段跑通聯機的原型。如果聽了機核遊戲開發節目帕斯亞那一期，就知道中途改聯機其實是很難的，像很多出名的小規模遊戲如《饑荒》，它的聯機版也是後推出的。
（圖中展示了Unity中編輯一個平臺跳躍遊戲的例子）
3 重視工具——編輯器開發
假設原型階段順利完成，團隊要基於一個高完成度的原型開始開發了，這時候就需要開發編輯器了。以小團隊關卡型戰鬥遊戲為例，至少需要一個戰鬥技能編輯器和一個關卡編輯器。引擎中的編輯器往往是基於它提供的一些接口進行擴展開發的，原則上是儘量用方便的方式實現可視化編輯。由於主流的3D引擎是商業化的，而主流的2D引擎是免費的，免費但是功能少導致在2D引擎裡做方便預覽的編輯器會更加困難。
3D引擎的編輯器往往是基於引擎內的窗體和編輯場景進行擴展開發的，這樣的好處是“可視化編輯”、“所見即所得”。當然這是理想狀態，有些定製需求可能引擎功能不支持，但最終也能覆蓋絕大多數將可視化狀態轉為配置數據的需求。
對於戰鬥技能編輯器而言，最基礎的應該是一個可以逐幀預覽並編輯“角色動畫+特效+碰撞盒”的工具。編輯器應該包含一個可以拖動的時間軸，上面可以存儲預覽關鍵幀的數據信息、過渡幀的插值及視覺效果。進一步可以做帶入受擊方的編輯功能，如打怪浮空等，需要在編輯狀態下能放木樁怪；如果打擊感中要涉及頓幀（俗稱的“卡肉”），還要能編輯並預覽頓幀的開始結束幀。這些細節如果不能可視化編輯，就必須從填配置數據開始，然後每次都運行遊戲調試，那效率會非常低。
對於關卡編輯器而言，由於引擎本身自帶基礎的場景編輯預覽模塊，自定義編輯器主要是面向一些觸發器或判定數據的快速編輯存儲。例如遊戲內有爬牆功能，那麼需要編輯爬牆判定範圍和上牆下牆的判定點；又比如遊戲內有沼澤，需要對進入沼澤區域的角色進行速度降低並觸發中毒，那麼編輯時也要能劃分出這個沼澤的判定範圍；再比如有些遊戲可以進入水體，需要入水時有跳水動作並進入游泳姿態，則進出水體的範圍也需要配置判定（《之狼》裡有邪道繞開了這個判定，就實現了天上游泳）。這些還只是3D探索遊戲裡一些基礎的功能配置，如果遊戲還有定製化的特殊需求，例如需要能全地圖針對任務進行尋路導航，還需要烘培（Bake）尋路網格並配置連接點等等。
值得一提的是，當場景複雜度上升後，大量精力會被分配在編輯場景的塊劃分上——這裡的塊還可能是一類廣義模塊的劃分，例如流式加載的分塊、渲染用的加速結構等。對於大場景的高效渲染（也是遊戲媒體提到的“優化”的主要方面）本身也是一個可以無限複雜的課題，即使全依賴中間件也有巨大的學習成本。針對中小團隊來說建議就是——控制規模，場景一次加載，儘量別涉及到這一類進階問題。
4 用面向對象的思考方式去設計開發
儘管面向對象開發不是運行時性能最高的架構方案，但確實是到目前為止最適合把功能需求轉化為程序的方案。雖然很基礎，但對於非計算機軟件專業的製作人和策劃來說，仍然是一個需要學習的功課。
簡單來說，一個遊戲世界的設計應該是基於歸納、抽象之後的很多個類（Class）在實例化後運行的結果。例如一個敵人可能就有這樣的繼承鏈條：遊戲物體——可受擊物體——自帶AI物體——人類目標——拿槍敵人，那麼具體邏輯也是這樣逐層搭起來的，共性做在基類裡，特性做在子類裡。基於這種思想，遊戲設計的功能就更應該是整體性的，類似先設計一個世界，再考慮世界按規則運行的事情。當然沒有人能一開始就設計一個完美的遊戲，設計上的迭代是不可避免的，所以一開始設計的結構越好，擴展越容易。
例如遊戲內每個單位都有自己的生命值，如果後續要引入“共血條”的敵人，其中一個方案就是在敵人類型基礎上插入一級“敵人群組”的類型；又比如一開始單位的生命值只有一條，後來要引入多條生命值（這裡不只是表現，還有一些階段轉換之類的觸發器功能），也需要擴寫“敵人”這個類上的生命值定義與功能。
有了這個理解基礎後，就能理解為什麼在項目開發一段時間後，再引入一個全新的對象（和已有的很多對象有交叉邏輯），就可能會產生開發週期問題，或是從根本上就是很難實現。舉個可能不恰當的例子：比如另一個世界的《之狼》，在做完了場景鉤繩系統之後，覺得這個不錯我們想讓它也能鉤怪或移動到怪前面，這就是一個破壞性很大的需求；如果是像《匹諾曹的謊言》裡一開始就設計了這個功能，充分考慮了遊戲內單位可以進行的空中位移情況，則沒有問題。
（神之天平是一個玩法完成後視覺元素全部翻新的例子，類似的做法不奇怪，但是週期這麼長的確實少）
5 先提高功能完成度，再優化和打磨
假設人員能力在線，那麼遊戲開發到了階段性的整合期就可以開始驗證了。這時更要區分哪些細節不應該糾結——畢竟人的精力是有限的。個人認為重玩法的遊戲應該先驗證玩法，例如不能玩一關有趣玩10關就吐了；重視覺風格的遊戲則應該保證其獨特視覺風格的可行性，例如不能靜態的時候很好看，實際玩起來光汙染。前者更偏遊戲關卡數值設計，後者更偏美術設計。
如果做的是一款“倖存者Like”遊戲，那麼完全可以從沒有任何美術資源僅有遊戲邏輯的狀態就進行關卡調試，運行單位的美術資源可以都用臨時資源替代（如原型小人、膠囊體等），主要驗證關卡節奏可可玩性，並逐步填充戰鬥設計；相應的美術資源，在定好性能指標後可以在單獨的製作管線開發。
如果是想實現類似《女神異聞錄5》那種很靈動的動態UI效果，則需要儘早整合一版遊戲內的其它美術素材（渲染風格、角色動畫等），在3D場景的攝像機轉場出也要接入相應的設計，才能實現場景動畫過渡到UI動畫比較平順自然。當然這個屬於一類高級追求了，小團隊面臨可能更多是視覺可行性問題，例如想做一個同屏殺100個怪的遊戲，為達到這個怪數量進行渲染調整和性能優化（例如之前的怪太寫實了模型面數太多，則可以做得低面數一點，或轉向更風格化的渲染以減少特效粒子數等）。
總的來說，一款遊戲首先是一款軟件產品，最低要求是功能保質保量的完成；可能實現出的結果不達預期或者還有提升空間，但很多時候還是應該先把內容都做完再優化打磨。除非團隊是像《戴森球計劃》那種有經驗的團隊，否則不要想著做到特別完美再上線——能以類似Early Access模式進行發售也是一個產品自我檢測的好機會。
（圖中的是我認識的杭州一個小團隊開發的《湮滅線》，目前的完成度很高但是項目週期也非常長，是一款優秀的死亡細胞Like遊戲）
結語
有少數遊戲是針對一個細節無限打磨，不考慮在一定時間內完整做完的。這可能是製作人對這個特性執念太深，或是這個特性過於誘人；如果後續的經濟來源還能有保證，這或許也是一個方案，但這就太反軟件工程思維了，個人是非常不提倡的。著名的眾籌遊戲《星際公民》就是這樣一個例子。
受制於篇幅所限，寫得還是太粗放，如果提出的關鍵點能引發思考和注意，也就足夠了。下週如果有空會更下期，談談項目管理。