為期兩個月的團隊項目完成了，我們的游戲也已經發布。在這個名叫KOFLive的小游戲里，我們集成了五個真人角色，每個角色有拳腳基本招數以及三個小招、一個大招，硬值、防御、集氣、雙人對戰、人機對戰、練習模式等格斗游戲的Feature基本上全部實現，并且做出了比較炫目的特效。無論從目前的下載量還是用戶反饋來看，游戲的效果都達到了我們的預期，也算不枉這幾個月的一番心血吧J除了這些，整個項目的教訓也是顯然的。如果說閱讀《夢斷代碼》使我們對"軟件難做"有了感性認識，自己親自參與到一個軟件工程項目中才讓我們對這一點有了切身體會——不過，只要群策群力規劃得當，一個軟件項目總歸不是難于登天的。我們愿意把我們做這個項目的經驗教訓與大家分享，希望對軟件開發人員能有一些小小的幫助。
- 項目的選擇
一個好的項目方案是成功的關鍵——它不僅能讓你的團隊得到更多的用戶，更能讓隊員們在開發過程中充滿動力——試想，沒人愿意為一個"Hello World"工程付出太大精力，同樣也沒人愿意做一個根本不可能實現的功能：這中間的平衡需要好好掌握。另外，在選擇項目時你提出的第一第二乃至第三方案，都很有可能是別人已經做爛掉的東西，這就要求我們在選擇項目時，要有足夠的觀察力，并做足夠的市場調研。
現在想想，我們的隊伍在項目選擇上，做的不夠好：一是對項目的選擇規劃重視程度不夠，表現在提出的備選方案太少，全隊六個人僅僅提出了三個方案以供篩選，這是很不好的一點；二是最終選擇的項目（鏈接請看這兒）最重要的Feature實現起來難度太大。整個開發流程中，我們對游戲的愿景可以說有三個階段：
- 一開始，我們不想做太Trivial的項目，更不想基于別人已經做爛了的技術去完成項目。所以我們選擇了在這個游戲里加入圖像處理的部分：用戶輸入一張全身照片，我們程序做圖像分割，再將分割出的身體各個部分拼接成人體拳打腳踢的各種動作。做的時候才發現，別說拼接，以現在的圖像處理技術，自動識別人體胳膊、腿等具體部位都很難，何況在此基礎上進行圖像分割了；
- 之后調整計劃，將目標鎖定為識別人臉，即識別出人臉并將其加載到游戲內置的人物模型上。這個也比較不現實，因為游戲中大部分時間人物都是以側臉呈現的，即使我們實現了人臉識別并分割的技術，將其加載到這樣的一個模型里也比較難看，這一階段的博客請看這兒；
?
- 這一階段才是比較現實的：做一個真人角色的搏擊游戲，當時我們定下的目標就是"在去除人臉識別的前提下，將游戲的手感做到最好"。事實證明，這是最合適的目標：可以吸引大量用戶（我們的下載量和用戶反饋證明了這一點），又有適當的難度，是我們努力拼搏四周可以達成的；
-
所以，"程序員是天生的樂天派"這個說法還是很符合實際情況的。另外我們組沒有做過圖像處理的組員，在MSRA我們也需要做實習工作，同時三名主力Dev還因為學分問題不得不選修清華姚班開的一門操作系統，在這么繁重的壓力下去實現一個圖像處理界都沒有研究透徹的Feature，實在是不夠現實。其實，在項目開始之前，我們不是沒有就難度問題咨詢過相關的專家，不過可能是不愿打擊一群毛頭小伙的滿腔熱情J 他們并沒有直接告訴我們這個技術的可行性。所以，奉勸大家在選擇項目時，一定要有足夠好的市場觀察力，肯花時間去好好調研，并要清晰認識自身能力、時間、優先度等客觀條件，最好將每一步都仔細規劃好，做到"大膽假設，小心求證"J
?
一個好的選題很重要，不過我們當時沒有注意到這一點，做出選擇不夠慎重——這并不是說我們最終做出的項目沒有吸引力，只是如果我們當時能夠計劃的好一些，開發過程中我們能少走很多彎路。從另一個角度來說，上軟件工程這門課，最重要的是學會一整套正規的軟件開發流程，而并不是說實現一個多難的技術，況且，一個很難的技術也不一定是用戶歡迎的，對于一個學生團隊，選擇項目，不應當以"開發者"驅動，而應當以"用戶市場"驅動。
?
- 項目的執行
在Beta階段開始的時候，PM給每位組員發了封整體進度安排郵件，郵件末尾說"希望軟件工程結課時，我們能說出一句："We're proud of each other""，現在快結課了，我們認為每個人都值得小組其他成員的這一句話: We're proud of youJ 項目執行的兩個階段，尤其是Beta階段，無論是PM/Dev/Designer/Tester的緊密配合，還是目標改變后的緊急調整，以及發布之前的緊密測試和應急計劃，我們都做到了一個良好軟件開發團隊應該做到的。
- 良好的設計架構和清晰的接口。我們的Dev們有著強大的單兵作戰能力和豐富的工程經驗，他們設計了一整套高效的游戲支持機制，整個工程有著清晰的層次架構：
- 最底層的游戲引擎負責圖片的透明化、放大縮小、去鋸齒、渲染、翻轉等操作，并進行圖片像素級的碰撞檢測和音效支持。
- 中間一層是基于引擎的游戲運行邏輯層，在這一層我們進行人物招數和狀態轉換的設計和加載，實現攻防判定、血氣管理、輸入檢測、AI機制、糾錯機制等等。
- 最上一層負責整個游戲的流程判斷：啟動、終止界面的加載、用戶選擇流程的分支等。
-
-
???????????????????????????? ?
我們三個層次不同的功能模塊之間定義好了完備清晰的借口，極大提高了Dev分工合作的效率以及Designer設計招數和特效的效率，并方便及時查錯（要知道設計游戲時，游戲引擎在進行毫秒級的不斷渲染，Debug是很難通過IDE 設置斷點來實 現的J）如果可能，我們也樂于開放自己的源代碼，供大家參考指正。
?
- 專業的招數設計和特效制作。我們的Designer中有拳皇游戲的骨灰級玩家，對每個人物的狀態轉換和招數設計有著很好的設計（這可是一個參數一個參數調試慢工出細活的過程^_^），同時也有精通PS特效制作、研究過用戶界面的同學，制作出的效果十分炫目，不信，自己下載游戲看看吧J 大家分別發揮自己的特長，進行充分的合作，保證了游戲的質量和進度。
- 嚴密的發布前應急和測試。我們一直有一個理念：發布日期定在那里，我們要在此之前發布，并且應當對用戶負責，不能讓用戶使用一個Bug很多的花架子。所以我們進行了清晰的進度規劃，大到周，小到半天，應當完成的進度十分明了。同時我們進行了有效的發布前規劃：
- AI機制在發布周之前都沒有涉及，我們制定了應急機制：在目標上降低需求，做出一個讓用戶不能輕易打贏的AI版本即可， 在實現機制上我們提前設計好了隨機性的AI貪心算法，并預留出了相關的接口。事實證明這套機制是行之有效的:我們的AI只用了周四一天的時間完成，經過相關測試，周五游戲就發布了。但AI效果非常好，電腦出招很犀利，（有的角色甚至讓玩家驚呼"Bug" "Imba"J） 剛剛上手的玩家很難打贏，這無疑能刺激用戶接著玩下去^_^
- 頻繁的健壯性測試。每當有人要Check in一個新版本，我們都規定他自己要進行近乎變態的測試：長時間的亂序鍵盤輸入檢測。這一點在發布周執行地更頻繁：每當有人Check in一個修改比較大的版本，我們都會組織兩個人在電腦上打一打，瘋狂的敲擊鍵盤J。事實證明這也是非常有效的：我們大部分的Bug都是這樣測試出來的，并且我們保證在發布之前這些Bug都被及時修正。在Test Report中，我們報出的"可以發布"的結果，是切實有效真正對用戶負責的。
- 發布前整流：在臨近發布前兩天，我們兵分兩路：PM和一個Dev進行發布的所有事項準備，Branch一個發布版本用于制作安裝包、測試、撰寫說明文檔、確定下載站點及統計方式等，其他人員接著做之前的事情。這樣保證我們發布時不會手忙腳亂，出現各種意外情況。
????????????????這些措施的實施，使我們提前兩天發布了游戲 ，并且到現在沒有收到用戶反饋的任何健壯性問題，我們保證了我們最一開始交付給用戶的，即是一個健壯合格的產品。
?
- 有效的時間管理。由于我們在確定實現的基本Feature時有過一些改變，所以真正開發起來時間顯得很緊張，我們必須保證大家都能充分利用時間，為此我們有以下機制：
- 修改了Scrum的流程，如果一個Daily Scrum沒有討論出真正必要的東西，我們為什么又要花那么多時間呢？所以我們規定：每天的Scrum不一定必須大家聚在一塊兒，只需由PM調查每個人的進度，并將每個人的進度通知其他人。PM應當對整個項目的進度有很好的了解，當PM認為有必要大家在一塊兒商討時，我們才會專門去會議室討論清楚問題。在每次Scrum之前，我們都提前確定了本次需要匯報給其他人的進度以及需要討論好的問題，確保會議時不會因為冷場而耽誤整個組的時間。這樣我們聚在一塊兒的Scrum基本上兩天一次。事實證明這是非常有效的溝通合作手段。
- 我們會充分考慮每個隊員當前的時間安排：畢竟有隊員會在某個時間段因為組里面有deadline而時間很緊張，我們會平衡每個人的負擔，將他的任務適當轉移給其他的隊員，大家也都能做到互相體諒互相幫助。
-
總結：盡管降低了難度，但不借助外界引擎開發一個完整的游戲，畢竟還是很有難度的。隊員們在四周的開發流程中圓滿完成了開發的任務，交付給了用戶一個負責任的產品。可以說，我們在項目選擇、計劃階段有考慮不周的地方，但在真正的開發過程中，我們的個人努力和團隊合作是高質量高效率的。
回想這個KOFLive開發流程，我們經歷過計劃大改的陣痛、成員意見的沖突、通宵工作的勞累，也經歷過目標實現的興奮、初具雛形的喜悅、游戲發布的欣慰，不管最終結果怎么樣，這樣一個過程讓我們真正了解了如何做軟件，更重要的是如何與他人合作：說服他人以及被他人說服J 這是讓我們感激彼此的重要原因。
最后，上張合影， We're proud of each other!
?
