6月1號-3號參加了完美世界舉辦的上海站GameJam。本場的規則是在48小時內，做出一款主題爲“萌”的遊戲，最後所有隊伍分別演示。我們團隊一共6人，我名義上是隊長，實則後勤部長（笑）。隊伍成員都沒有實際遊戲項目經驗，也基本上是第一次參加GameJam。而我更是一個接觸遊戲引擎才一個月的新新手。我們大都抱着見見世面、膜拜大佬的心態參賽的。最後作品居然很幸運地獲得了上海站前三的成績，難以置信。
才華橫溢的策劃大佬，對這次遊戲的設計感悟作了很好的總結：2018完美世界中國年輕一代遊戲創意大賽(Game Jam組)的作品展示，願意的來？ - 和浪的回答 - 知乎 https://www.zhihu.com/question/279712395/answer/411142801。遊戲通關視頻和下載鏈接那裏都有，大家可以先移步過去看一下我們的遊戲“找回春天”。
從結果上說，GameJam更注重創意和玩法，美術和程序都是表現形式。只要你能將創意表現出來，玩法實現出來。我認爲有一些小bug、小瑕疵是完全可以接受的。但從過程上說，我們團隊有許多做得不夠好的地方。這篇文章的目的，就是談談整個團隊48小時開發過程中的不足。只有將失誤提煉成經驗，我們才能成長。
第一點，開發進度控制做的不好。時間回到在6月3日早晨8點，離比賽結束還有6個小時，隊員們都意識到進度控制出了問題。我們之前在關卡打磨和人物技能的優化上花費了太多時間。其中我大概花了整整12個小時，想把角色攀爬做到完好。除此之外，我們還做了一些可有可無、不必要的功能，而很多必需的組件都沒來得及做，比如：角色死亡重置、關卡間攝像機變換、開頭和結尾的動畫等等。這意味着賽程已過去7/8，一個可玩的版本都還沒有出來，每個人的壓力很大。我們立馬進行調整，所有的工作都按優先級排序，先做重要的。臨近比賽結束，終於趕出來了第一個可玩版本。但時間有限，直到最後我們現場演示時還有一點小bug。
現在看來，我們應該採用敏捷開發模式。先做最重要最基本的組件，得到一個１.０版本。在此之上進行快速迭代，每次迭代增加一些新的功能。這樣的好處是，任何時刻我們手上都有一個可玩的版本。可以隨時體驗、測試、提交。由此收集到的反饋信息，還可以幫助新版本進行調整。
第二點，分工不當。隊伍裏一共有三個程序員。比賽開始時預想的分工是：我做人物控制、另一個程序做動畫部分、主程負責場景搭建和剩下的工作。這裏存在不少問題，首先任務沒有完全分解到個人。動畫部分的編程和美術是耦合的，場景搭建與美術和策劃都是耦合的。其次是任務量分配不均。我一開始以爲自己只要專心人物操作，所以花了很多時間做攀爬，時間浪費了。另一個程序要等美術的動畫，所以一開始只能和主程一起做旋轉操作，相當於兩個人做一件事，時間浪費了。主程由於要負責場景搭建，所以有很大一部分時間都在和策劃一起打磨關卡的擺放和參數。到最後有很多重要的組件已經來不及做，由我們趕工頂上。分工的問題主要是由於我們經驗不足，對每個人的能力，整個項目的工作量都沒有很好的預估。
第三點，溝通有時候不到位。多人合作的項目中，溝通一定是極其重要的。在遊戲開發中還存在跨界的溝通：美術與策劃、策劃與程序、美術與程序。凡是溝通，都需要特別注意。舉一個比賽中的例子。隊里美術大佬最初畫的“夏天”關卡的背景圖，與關卡初衷的感覺上有偏差，整圖需要重畫。原因在於美術並沒有參與我們對遊戲設計的討論，所以他只能按照自己對夏天的感覺來創作。這裏就是任務交付時溝通上存在問題。之後策劃找到了美術以前畫的沙漠風景圖，讓美術儘量按照這個感覺來畫。最後成品的效果大家都很滿意。
GameJam是大家坐在一起，有什麼事情可以直接面對面交流，溝通成本已經很低了。哪怕這樣溝通還是會不到位。我常常感覺到，溝通的損耗無法避免，我們所做的只能是儘量將損耗降到最低。兩個人的大腦，就像機制不完全匹配的譯碼機和解碼機。發送者用他的大腦把想法編譯成文字，通過嘴發聲，再經由空氣傳播，到另一個人的耳朵，接受者再用大腦來翻譯接收到的文字。且不說環境嘈雜對聲音接收的影響，光是不同人千差萬別的語言習慣、各自大腦的主觀思想，都能讓想法在傳遞過程中“變味”。人與人靠說話來溝通想法，是如此的不可靠。所以在溝通重要任務時，一定要儘可能把話說完整，包括這個任務的前因後果，可能出現的場景，潛在問題等等。不要嫌麻煩，因爲冗餘信息能幫助對方理解你的意思。說完後，要確認對方是否真的理解。
第四點，測試不足。這幾乎是必然的，因爲我們基本開發到比賽最後一刻，沒有時間留給測試階段。但是哪怕我們有足夠的時間，也不一定能把所有的bug找出來。我們腦子裏沒有一套完善的測試流程，所以很難測試覆蓋到項目的整個邏輯。比賽過程中，我們想加入一個功能：當玩家超過一定時間沒有進行操作，遊戲角色就會發出叫聲。這個功能最後只寫成一個半成品：不管是否操作，角色每隔5s都會叫一下。然後因爲優先級太低，就被我們捨棄，但是代碼忘記刪了。隊伍裏的所有人在試玩最後版本的時候，都沒有打開電腦音量，沒有發現這個半成品組件還在持續發揮着它的功能。所以最後演示時，遊戲角色每5s都會刺耳地叫一下，“滴滴滴”、“滴滴滴”、“滴滴滴”…直到結束。所以一定要注重測試。
最後總結一下。“每個編程人員都是樂觀主義者”——《人月神話》。我們這48小時的程序開發，基本就是反覆上演這句話：“預估一個重要的功能很容易，打算最後再做，結果發現實現起來很複雜”，“第一天做好了功能，好像進度還不錯，結果第二天出bug”等等。這次GameJam的經歷，讓我深刻意識到軟件工程管理裏學問很多，比我曾經設想的還要多，所以要學習的知識還有很多。
在文章末尾，我要感謝團隊裏的每位小夥伴。雖然開發過程中存在一些不足之處，但第一次合作能達到這樣互相交流和配合，已經很不容易了。大家都熱愛遊戲開發、想把遊戲做好，和你們一起合作是非常快樂的一件事。能認識你們，是這次比賽最大的收穫。