獨立遊戲《Purgatory Ashes》的經驗與總結
1.引子
遊戲的靈感萌生於2015年，當時只有一些概念性的設計圖。
後來我利用資源商店的素材搭建了最早的原型。
遊戲的最終畫面：
早期以D.P作為代號進行開發，來源於兩個單詞的縮寫 Devil Prototype。
去年秋季我離開了當時的公司開始全職開發這款遊戲，鑒於遊戲的體量和一定的情懷原因，我選擇了線上開發的形式招募一些隊友
在群內發了一些信息以及一陣子磨合後，最終拉攏了3名小夥伴入夥，總共4人。
期間遇到了許許多多的難題，以及若幹未解決的問題。但最終仍然發布到了steam商店上
開發時間7個月左右。4月份解鎖：
http://store.steampowered.com/app/716060/Purgatory_Ashes/
並不算是合格的作品，但有許多內容可以寫一下。
2.關於合作
我本身有一定的C4D基礎，可完成一定的美術資源。甚至有一些偏執，例如之前開發的C2U工具。
眾所周知，線上合作的問題是不能及時給予反饋。但這個問題在這款遊戲的合作中並不是很突出。
最多隔一個上午或者下午就可以得到回復，真正最大的問題是拉不到合適的人。
所以這次合作的成員中，除了美術是專業美術以外，其他人則都是‘野路子‘。這一直是一個伴隨開發非常頭疼的問題。
到了後期基本上是我一個人在做，變成了其他人幫忙的形式。不過還算好，開發這款遊戲所花費的時間尚能接受。
而在網絡上不斷地組隊發廣告又是一件非常拉嘲諷的事情。雙刃劍吧。
2.一些坑
2.1 遊戲設計方面
傳統模式的弊端
我覺得對於獨立遊戲而言，做這類長關卡制的遊戲其實有點吃力不討好。只能說是這樣做情懷的比重更多一些。
與其做傳統模式的遊戲，不如把戰鬥節奏的把控，出怪間隙調整好，來設計一個純血宮模式的遊戲要來的好。
關卡比例問題
關卡設計上有個比較大的問題是大小比例問題，很容易造成場景過大角色過小的情況。控制好比例需要合理的參照物
特別是高度到角色腳部，腿部，肩部這幾個地方的參照物。有合理的參照物場景的大小才會感覺合理。
特殊的建築風格
一些古建築其實比較難做，棱角片數等都有講究，而現代建築都是方塊要好做很多。應當盡量避開這類建築風格。
室內室外空間的來回切換
盡量避開這類復雜的空間結構，遊戲中經常要用到一些本來就不合理的結構填充到關卡中去(比如憑空出現的跳臺,傳送臺)。
敵人AI的簡化
Unity這一塊比較常規的做法是用Behavior Designer來設計AI。建議是一上來不要設計太復雜的敵兵AI，特別是涉及需要‘黑板‘這種小隊邏輯的
否則會衍生出非常多的bug。所以不一定非得設計出強AI敵人，有很多變通的方法，例如通過一些特殊的技能來增加可玩性，一些彈幕類技能的釋放等等。
2.2 技術方面
優先考慮用混合樹 而不是 Layer
很多問題用同步層可以解決，但用混合樹也可以解決，而且更靈活。只需要指定一個float變量當成bool用即可。
特別是像變身系統，變身後的招式以及動畫狀態和變身前其實是有較大變化的，這時候用混合樹就更為合適。
手柄適配
統一鍵位的手柄適配使用InControl，這款插件能保證xbox,ps4,北通等手柄都是同樣的鍵位
但使用時需要勾選XInput支持，否則北通手柄無效。另外對於不支持InControl的手柄需要自行自定義鍵位來處理。
使用InControl還有一個鍋，就是PS4手柄沒有震動，但作者說這不是他的問題，這需要一個支持ps4震動的dll。
如果只上steam的話，可以模擬成steam控制器來解決震動問題。若是其他平臺則需要另想辦法了。
steam的成就及DLC
steam這邊使用Steamworks.net網上有很多教程，成就部分要額外調一下StoreStarts方法，否則不會前臺彈出，需要註意。
Steamworks.SteamUserStats.SetAchievement("ACHIEVEMENT_1"); Steamworks.SteamUserStats.StoreStats();
遊戲這次做了音樂DLC，在steam的庫->音樂目錄下可以查找到，DLC和項目本身共享一個目錄，如果是音樂文件steam會自動識別。
3.取舍還是死磕
如果你做ARPG你就要強化劇情部分，養成部分。如果做ACT你就要強化戰鬥部分。
獨立遊戲如果想把整體做好，就需要在核心模塊上做加法，其他部分上做減法。
而拿ACT來說，戰鬥部分又有以下3點可以取舍：
1.可以弱化AI邏輯，強化AI技能。避開小隊AI這樣難以調試容易出bug的內容。
2.敵人模型復用。例如身著盔甲的敵人，通過換武器變為法師，戰士，槍兵等。
3.優先考慮人形敵人，半身怪，漂浮怪物。這類角色在美術制作上會節省時間，且人形敵人的動畫可以復用。
4.通過改變不同敵人的組合讓戰鬥不至於枯燥。
其他部分，有這幾點可以取舍：
1.用文字對話配合程序驅動的演出來代替過場動畫。
2.考慮好關卡復用，關卡長度。
3.不要從技術角度/美術角度去決定做一個什麽模塊/場景，始終要放在策劃角度來下決定。
4.少不了HardCode，改成節點或者表來配置反而沒HardCode來的簡練。
4.結語
終於把這個坑給填上了。也算結束一事，有始有終吧。
以後應該也是往這個方向去做新的遊戲，不過什麽時候開始誰知道呢。
獨立遊戲《Purgatory Ashes》的經驗與總結