大家好，這裡是蜜糖，本文記錄了我這兩個月中游戲《想開了》開發過程中的感悟。

5月Booom之後，我們評估了demo的後續開發工作之後，選擇在Unity的Corgi引擎上進行開發。經過一個半月的趕工，總算是在cj上拿出一個勉強能玩的，一定程度上表達出我們立項想法的demo。

這裡想通過這篇文章記錄一下這一個半月的項目發展，文章標題或許有些矯情，但是：

大齡程序員
非遊戲相關專業
喜歡遊戲
只有下班之餘開發遊戲

如果你跟我的標籤有所重疊的話，或許文章中的內容和方法能夠對你有所啟發。

一、需要一個燈塔

只有有DDL才會有工作的動力。同時，只有有時間節點的約束，才能更好的識別製作內容的必要性做出取捨。成熟的項目管理人員“全都要”是危險且不成熟的，必須要認識到項目的核心競爭力在哪裡。

而在參加過Booom之後的當時，7月底的CJ簡直就是天生為我們設置的下一個DDL。

2個月時間，時間不會太長，方便進行中期規劃；也方便針對每一個人制定一個可以接受的工作量。

我們在Booom完成後，因為希望將遊戲改為銀河城的探索形式的遊戲，考慮到工作量的原因，所以切換使用了Corgi引擎來減少工作量，所以在這個基礎上，需要從熟悉框架為起點重新規劃所有的工作量。

我們在使用git作為代碼同步工具的基礎上，選擇使用騰訊雲文檔來進行輕度協同辦公的方式，開發部分的分工如下圖：

同時，添加了開始結束時間之後，當項目延期了之後，可以通過可視化的形式預估出延期內容，從而進一步保證項目的可控性。

其實這樣的任務拆分才是互聯網所說的OKR模式，我們的工作過程為了關鍵結果負責，本次我們的關鍵結果是CJ順利出展，而所有的項目代辦都是為了出展順利，但是出展並不是一個硬性的標準的，從高到低可以分為：

有完整敘事的DEMO
具有良好光影的DEMO
有完成玩法的DEMO
可以簡單動的DEMO
視頻
ppt

可以看出，我們最後的兜底內容可謂是十分的低了，所以心理建設其實很健康。而實際上我們的最終成果是2.5左右，在核心的關卡上加入了部分的效果，但是沒有進一步的優化。不過，已經能夠基本展示出我們的立項主題了，也同樣符合OKR內容完成60-80%的話，最後就會有一個不錯的結果。

一切都以燈塔為目標，成員開發內容延期是常見的事情，但在DDL時間點不斷臨近的過程中，不斷評估完成事項的重要性，調整工作內容的優先級。

二、神聖的卡拉鍊接著我們

比起大家的能力，我其實更關心信息傳達的有效性和通暢性。在此基礎上，由於原團隊由4人構成，指責為：主程、TA、美術、關卡策劃。

考慮到希望進行銀河城式的關卡設計，所以希望在1個半月中創建20個房間左右的地圖，所以這裡我們需要額外的關卡來同步設計。

為了可控性，我暫時是從粉絲群中邀請了兩位朋友來幫忙完成設計。因為在本次demo中，比起單個謎題的質量，我更關心的是謎題的類型再大地圖維度上的前後關係。所以只要是有希望家，對傳統的平臺跳躍類型有一定的認識，並能良好溝通的朋友，就可以完成計劃中的任務。

而為了大家能夠對整體的關卡有一個完整的認識，我進行了以下步驟。

1. 對關卡難度進行了定義：

我對關卡謎題的難易度進行了描述，從而拉起大家對於關卡謎題的認知。這樣在先進行信息同步後，後續如果難度超過了預期設計中的形式的話，由於已經預先對規定的關卡難度進行了描述，所以比較便於溝通對已經創建的難度。

ce：簡單謎題，核心判定在角色極限高度、極限距離的60%，即容錯40%，在連續的操作中由單個的能力、機關組成，連續操作數量不大於3次，例如連續蹬牆跳3次。作用：1、能力教學；2. 用來緩和謎題節奏，和ch、cm交替出現；3. 用於敘事。 cm：中等謎題，連續3-5次以及以下謎題容錯20%，或者1-2次單0%容錯的謎題，可以由兩種能力、機關組成。作用：1、單種、或者組合能力的驗證，應當主要以當前區域的能力做驗證； ch：困難謎題，連續多個0%容錯，或者某種快速切換的技能組合；作用：在boss戰前，所有boss戰中需要使用的組合，都是要通過至少一個ch組合進行驗證的。如果boss戰存在需要多種技能的組合，則需要讓玩家通過多種ch對應技能組合。 cc：挑戰謎題，隨便放開了設計，可以做場景外時差，但是cc挑戰必須要有對應的獎勵，可以是捷徑獎勵、可以是收集品獎勵、可以是額外的輔助能力提升（生命值上限、精力條上限等）作用：1、如果玩家能通過挑戰謎題，則默認以下情況：玩家已經對某一種組合十分熟練，可以跳過後續的能力驗證（也就是所謂的可以通過cc謎題設計捷徑）；2、可以在無關主線的部分通過cc涉及額外的支線挑戰；3. 隱藏房間、或者獨立房間中作為獎勵挑戰。

2. 對地圖進行編碼命名

這個其實是參考“銀河戰士”的官方手冊中的方式，對謎題、獎勵、動畫交互等位置進行編碼，這樣可以在為進行地圖設計的時候就進行地圖設計。從而在設計之前為全體同步地圖設計的調性。

整個遊戲的關卡的排列主要是根據模塊的拼接串聯組成的。而對於一個模塊的定義為：

{場景:一位大寫字母}{房間:兩位數字}{模塊:兩位數字}{模塊類型:1、2位小寫字母}

例如: L0101ce

而我們對所有的場景也進行枚舉編碼，例如：蓮花池（Lotus）： L，混亂空間(Space)： S，火焰山(Fire)： F。

這樣，而模塊類型就是上文中的挑戰、以及其他的事件、動畫等類型。這樣設計後，就可以對地圖設計從而得到以下的流程：

這樣，就可以非常清晰的一定程度的規劃出來難度曲線，並根據規劃分片的將內容交付給不同同學的，進一步的也可以以迷題為單位追蹤開發進度：

3. 大地圖的交互設計

我心目中的地圖設計是可以一張地圖達到多次複用的目的，而這樣的設計很難通過文字描述傳達到夥伴心裡。所以，大地圖設計還是少不了的，我這裡選擇直接用雲文檔的“流程圖”功能來大概編輯出地圖：

但是心疼的是，這個圖片組件太多了，甚至還需要開vip，為了CJ忍了。

但是可以看出來，通過這種方式，我們可以通過房間的編號準確的描述出大地圖中房間在空間上的關係，並且我們可以在早期的時候就設計出一些預期中的交互。

比如上圖中的D02 會重複通過三次，第一次是在進入後，無法前進，需要通過D03、D04取得蹬牆跳能力；回去之後第二次通過D02繼續前進；當打完Boss之後返回後最後一次通過D02，這時因為具有Dash能力，所以可以快速的通過一些之前只能繞行的機關。

又比如D005有一個極難的驗證玩家能力的挑戰，通過後可以繞近路到達D08，但這裡的難是第一次通過時，如果已經通過具有了Dash能力了，那麼這裡的難度就會降低很多。

諸如此類，所以在設計每個房間的時候可以添加額外的文字補充，再配合大地圖的位置關係，可以在拆分進行關卡設計的同時，保持房間的功能性以及作用。

而實際上，在本次構建demo的時候，我們將龍宮地圖部分拆分為4份，並行進行地圖設計，然後在交叉試玩，再重新調整難度以及修復bug。

基於以上三個部分，將地圖的設計模塊化拆分，先進行邏輯定義，然後再實現定義，最後再用原本的需求進行驗收，從而讓關卡設計儘量符合最初的設計初衷。

三、有取有舍，交付為最

我永遠相信，我們的隊員是最棒的，但是我們的美術就是最棒的。

在CJ的時候有很多的人都是因為我們的海報而駐足停留的：

我們想走國風的的線路。

但是同樣的，還是具有工作量的問題，所以我們這次並沒有更換之前的格子的方案。而是繼續使用相對熟悉的格子方案，對世界進行拓展。

由於計劃中我們的劇情是具有8種場景的，而在demo種計劃使用其中6種，拋去之前已經完成的蓮花池地圖，我們仍然需要創建5個世界的地圖。

在總時間有限的情況下，我們判斷，格子的方案肯定不好，因為整體與水墨風格有些割裂，因為邊緣太過規整了，和水墨的形意有些出入。

但是考慮到時間的原因，以及主美大大比較忙，所以仍然採用的是原方案。

最終效果如下：

可以看出來，整體的風格是統一的。我們採用了相對可控的方案，並最後完成了目標。雖然馬賽克格子的方案不能說是對國風的一種很好的展示。實際上，在CJ展會上也確實有老師指出，方格的方案與水墨風格有些割裂，這個也確實是下一階段我們主要研究的一個方向。

但從結論上說，我認為當時的方案選擇，使我可以在有限的時間內完成一個完整的DEMO，而這個已經足夠完成我們的玩法驗證與風格展示了，從結果上來看，我很滿意。

四、葫蘆娃救爺爺

做遊戲，一個人的能量終歸是有限的。儘管你會覺得團隊協作的時候可能束手束腳，總會引入新的問題。但是，我認為這都是為以後當你需要擴大規模時的一種磨練。

而這種規劃、協調的能力，是需要鍛鍊的，同樣的，如果你可以積累規劃協調的案例，也更方便後續從事相關方面的工作。我本人之前是從事互聯網開發的，有一些協調管理經驗，但如即便你沒有這些基礎，我認為別害怕，嘗試的擔任隊伍的對接、協調工作，會對你收穫很大。

因為獨立遊戲，在初期我們往往是沒有足夠的資金支持的，所以註定隊伍中常態化是大家能力並不是齊平的，或者專業程度各自不一樣。比如我們的隊伍，其中4個人是工作老油條，不過不是遊戲專業的，也都是以兼職的方式來進行，而更有兩個是學生還未正式工作。

所以我們並沒有正經的遊戲的流水線經驗，不過我認為別怕，葫蘆娃救爺爺，爺爺最後也是救出來了。在這個工程中你需要切實關注的是兩個事兒：

你在積累團隊協同工作經驗。
你在做你喜歡的遊戲。

保持熱情，積累，當有一天你打磨好demo後，或許有機會擴大規模協調大家完成它。

最後

程序員就別指望什麼文筆了，但是這兩個月的過程中從頭開始學習框架並規劃劇情背景，完成的工作量還是挺大的。非常感謝隊伍中小夥伴的不離不棄。這次CJ也非常快樂認識了很多老師，很多人，同時還是要感謝機核和二七帶來的BOOOM，點燃了很多人。