前端可玩性DEMO的開發
準備工作搞得差不多，項目開始正式啟動了。第一階段是製作一個單機可玩的DEMO，驗證玩法。用dota來打比方的話（再次重申我做的不是moba），就是先把地圖做出來，小兵的刷新機制，防禦塔的簡單AI，勝負判定條件，以及1-2個可用的英雄，但是缺少道具和商店以及相關的邏輯。
這階段最大的特點就是，每天要實現的功能我都不會做~哪怕是最基本的旋轉移動物體。解決辦法就是上百度直接搜“unity 如何讓物體圍繞自身旋轉”。看完幾頁鏈接的代碼再去查一下API，95%的設計都能實現出來。
由於每天都是先搞“研究”再開工，所以工作量不太好估。有時候我以為很困難的功能，做起來1個小時就完成了。也有時原本認為超級簡單的東西，要做上好幾天。因此這個階段沒有定非常嚴格的開發計劃，只是以周為單位設計大體的實現目標。坦白講，每天都學到新東西，把以前不知道怎麼實現的東西通過自己的雙手做出來，還是一件很有成就感的事。每一個機制，每一個功能對於代碼菜鳥的我來說都是挑戰，通過攻克這些難關，我切實的感受到了所謂的“心流”體驗。
初期有一個問題，就是unity和VS的報錯信息看不懂。多虧了我有很多優秀的前同事，遇到看不懂的報錯信息就QQ打擾他們，也不好意思總打擾一個人，就輪著挨個騷擾……還好報錯就那幾種，兩隻手數的過來，大概一個月以後，絕大多數的編譯錯誤和unity報錯都能自己解決了，也在此感謝前同事們的支持~
由於並不打算用這個DEMO去融資什麼的，因此美術效果全部沒有用心做，比如UI部分是上unity商店買了一套最便宜的，特效部分也是從簡，只要能表現出邏輯即可，沒有花時間細調。
前面寫過我想做異步對戰的遊戲，因此需要將一名玩家的所有配置（類比COC中的基地佈局）保存為一個儘量簡化的類，這個類數據還應該具有一定的可讀性，為後面的調試工作打好基礎。比如我想更換一件裝備或者修改一個配置，不管這個類數據是存成字符串還是保存在服務器上，應該都能直觀的看懂配置並直接加以修改。
這個階段大約持續了2個月左右，單機DEMO已經制作完畢，一次單獨的遊戲流程（類比DOTA的一次遊戲）可以完整的循環起來。
單機存檔以及道具相關係統的開發
遊戲流程能跑通以後就需要開發道具（或裝備）相關的系統，我們需要一個揹包，玩家能對道具進行獲取，裝備，合成，販賣等操作。這個揹包的數據暫時用xml文件保存在本地，做後端時再改格式。同時也包括一整套的揹包UI。
由於一個人的精力十分有限，因此與道具相關的系統設計要儘可能的精簡，要素越少，邏輯越清晰，QA的成本也越低。因此這個遊戲的道具系統沒有像通常的卡牌手遊那樣有大量的狗糧卡牌和複雜的升級數值。以我個人看來基本上精簡到了極致。
整個的揹包UI基本上就是參考NGUI的範例寫的，反正這種代碼誰寫出來都差不多，自己寫完能看懂就行。基本上還是兵來將擋水來土掩，哪裡不會就直接百度查，UI醜一點也沒事，資源到位後換圖還是挺快的。
NGUI的範例挺強大的
這個過程大概一個月左右。
這兩個階段過後，已經有了一個非常粗糙的遊戲原型。下一步是開始做後端。
後端的開發
後端的部分有一個曲折的過程，一開始我想的是把整個後端部分外包給前同事做，反正功能都比較簡單，工作量不大。後來想了想還是自己先摸索一下做著試試。於是我先諮詢了一下，資深程序同學告訴我大部分後端是用JavaScript或C++寫的，相對來說JavaScript相對容易點。故技重施，去網上下教學視頻，從頭開始學。學到第二天的時候我躺在床上突然想到，有沒有C#寫的服務端呢？有的話豈不是省掉學語言這一步了？上網搜了一下還真有，有個“光子引擎“是用C#寫的，有些上線的手遊和頁遊是用這個引擎做的。在開發階段也不收費，免費的key可以支持100人同時在線，完全可以滿足開發的需求。
就這樣我去下了一個光子引擎的教學視頻，用了兩週時間跟著視頻做了一遍，從初始配置開始搞，到後來能在本地正常的傳遞信息。完成視頻教程後照葫蘆畫瓢回到自己的項目，首先是把需要存在服務器的信息（玩家賬號信息，揹包信息，裝備配置等等）從存儲在本地的xml字符串轉化成MySql數據庫，重寫所有的解析方法。花了一週時間嘗試一個插件，將客戶端和服務器傳遞的信息統一為相同的類，確實比用JavaScript寫後端省事……省的在兩種語言中來回解析了。最後大概用了兩個月時間，在本地已經能實現unity和服務器之間的正常通信。
光子引擎
這個過程肯定不像說起來這麼簡單，其中遇到的各種困難沒法細說。比如說最開始遇到的問題是服務器和MySql的報錯信息看不太懂，不知道怎麼解決，只能靠猜著改。這個事還不太好問前同事，因為多數前同事都是用JavaScript和C++寫服務器的，沒幾個人用這種付費的商業服務器引擎……也不好意思把整個工程發給別人，讓他們看整個前後端代碼DEBUG。幸好沒遇到什麼解決不了的問題，也是做到一個月左右，所有的報錯和異常都能自己解決了。
上真機調試
前後端在本地調試成功後，下一步是上IOS真機調試。這個事分兩步，第一步是將後端和MySql挪到雲服務器上，第二部是IOS真機打包。
一開始我嘗試了一下亞馬遜雲，後來轉念一想還是用騰訊雲吧，等到真的想做海外市場時再租騰訊雲的海外節點就好。我以為用雲服務器就得用他們的數據庫，後來一個哥們一語點醒我，直接租一個便宜的windows服務器，把MySql和服務器程序直接放上去就好了。在研發階段只租配置最低的就好，一個月不到200塊，價格還可以接受。
PC端和雲服務器調通以後，下一步要打IOS包了。打包需要mac，上蘋果官網買了一個比較新的mac mini，接到電視上再配一套鍵盤鼠標，準備工作就做好了。之後去整一個開發者賬號，發現普通的VISA信用卡還不好使……申請開發者賬號原來需要銀聯和VISA或MasterCard雙標信用卡才可以……又花了點時間重新申請信用卡。開發者賬號和mac都到位後照著百度上搜的流程開始嘗試打包。
真機測試
在自己手機上成功安裝自己打出來的遊戲包還是挺有成就感的。但測試的時候遇到了一個尷尬的問題，手機連接雲服務器的時候，一部分通信信息傳遞不正確……可以成功登陸，說明玩家的用戶名和密碼可以正確的傳遞，但是揹包信息確是亂的……但PC端就沒這個問題。這種模擬器上沒事，真機莫名出現的bug就很煩。自己嘗試著改了兩天沒有什麼頭緒，於是我去unity商店買了一個小插件，一個用於mobile遊戲和服務器通信的解析插件。用了發現還是不行……但這個插件是收費的，於是我名正言順的給插件作者寫郵件求助。好久沒寫英文郵件了不太熟練，儘量把情況和報錯信息都貼了過去。這位美國大哥人還挺好，第二天就給我回了郵件，告訴我幾種可能的解決辦法。綜合他的回覆，再去unity官網論壇查了一下，終於定位了原因，需要將轉譯插件及相關方法特殊處理。這個bug花了一週的時間才解決掉，從此手機端和雲服務器也跑通了，寫了一封熱情洋溢的郵件給這位大哥表示感謝。
至此，技術上的瓶頸基本上都克服了。這個過程稍微有點曲折但還算順利，基本上還是按照原來的開發計劃在走。當然還有一些隱患在，比如沒有經過壓力測試，一兩個人登陸沒事，玩家人一多服務器會不會掛掉？不過既然已經有成熟的商業項目用這個引擎做到上線，想必是有成熟的負載均衡解決方案吧。走一步算一步。
閱讀更多 氪老師 的文章
