Unity手游開發札記——從零開始搭建手游開發的工具集

從8月中旬到現在12月底，四個多月的時間，經歷團隊組建、引擎熟悉、基礎工作流搭建、核心Demo開發以及一些技術預研的工作，這其中的每一項拿出來都可以寫出一篇文章。之前已經聊過一些Unity和Lua相關的技術，今天就主要聊一聊不那么技術的部分——對于一個從零開始組建的小團隊，游戲開發的一些基礎的工作流程和協作工具，希望可以幫助后來人節省部分時間，也拋磚引玉，想了解下其他團隊中有什么更好的解決方案~

1. 為什么需要

商業游戲的開發是一個大工程，需要參與的職位很多——策劃、程序、美術、QA、營銷、外包等等，每一個職位的人也不少，比如策劃團隊可能會有6-7人，程序團隊可能會在10人以上，還會區分客戶端與服務端。要想讓游戲開發的工作可以更好更快地推進，確保每個職位之間和內部的協作都是順暢的，需要工作流的精確定義和強大工具的支持。

在游戲開發中，程序的職責不僅僅是實現游戲玩法邏輯，構建合理的工作流程和開發強力的工具集也是工作的一部分。這一部分內容可能無法體現在最后發布的游戲中，但是在保證項目按時完成，提升整個團隊的工作效率方面卻具有非常重大的意義。

在大公司中，這部分內容會由IT、運維等其他部門的同事提供，但是在一家小公司，一切只能自己動手。作為程序組的負責人，特別是最初只有我一個程序的情況下，這份看上去 只是進行一些工具調研，然后部署 的工作就毫無疑問地落在了我的身上。實話實說，相對于實現一個有意思的玩法，這個過程的確有些枯燥無趣，但回頭來看，這些工作讓整個團隊可以順利地推進工作，沉淀知識，反思問題，也是一種成就感。

2. 包含哪些內容

這里涉及到的絕大部分工具都是不自己開發的，而是對于世面上已有的工具的試用和選擇。本文也不進行深入的技術探究，只從自己團隊需求的角度出發，記錄這些工具的選擇過程和決策原因。涉及的部分包括溝通工具、知識分享、版本管理、項目協作與管理、自動化構建工具、編輯器和部分程序開發工具這幾個方面。

3. 溝通工具

在團隊組建的最初，我們只有一個微信群來進行溝通。在搬進新的工作地點之后，公司正式成立，就需要確定對內和對外使用的溝通工具。這部分內容看上去非常簡單，但也有很多值得思考的內容。

3.1 郵件服務

郵件服務作為一個最為正式的溝通工具，無論是對內還是對外，都需要可以正常使用。可以進行的選擇是自己搭建一個郵件服務器還是使用比如騰訊或者阿里這樣大公司提供的企業級郵箱。在經過一些調研、對比和討論之后，出于對郵件內容安全性的考慮，我們選擇了自己搭建的方式。

使用 MDaemon 作為郵件服務器，申請了公司的域名，購買了阿里云的主機，搭建過程交給了一個朋友幫忙（所以不要問我是不是破解版，我不會回答的。。。），目前的工作方式是我自己遠程上去手動維護郵件賬戶和列表。（這有點蛋疼，但不頻繁還可以忍受...）

客戶端我們沒有強制規定，但大部分使用了網易的閃電郵，這完全是習慣使然，其中的日歷和會議邀請功能還是很實用的。

3.2 即時通訊工具

每個團隊都需要IM工具，在網易的時候使用的是POPO，但是作為一個對外好久沒有更新的工具，而且是“老東家”的產品，有點怕。我們調研了Slack、釘釘、微信企業版，考慮了QQ，最終選擇了釘釘。我個人很喜歡Slack這一類型的IM工具——使用頻道代替群的概念，信息永久保存、可以修改搜索消息，這些設計減少了水群的存在，也讓溝通的人說話更加謹慎高效。

但是，Slack沒有中文版本，詢問了一下開發者，貌似近期也沒有推出的計劃，而國內幾個小團隊做的相似版本不太敢去用，怕哪天倒閉了聊天內容都沒辦法導出來。相比之下，雖然釘釘有很多我個人不喜歡的地方——譬如“釘一下”的概念是為老板服務的——我們還是無奈選擇了它，有如下幾個原因：

1. 帶有簡單的OA，比如部門管理、簽到、審批，這些是我們初期需要但又不想花太多時間去開發新的內容；
2. 有比較完備的桌面版和移動版；
3. 使用方式還是比較常規的方式，適合策劃和美術上手；
4. 有Open API提供，可以進行一些工具的開發；
5. 阿里“爸爸”怎么說也是家大公司，倒掉的概率比較小。。。對于我們這種小團隊的信息也懶得偷看（迫害妄想癥）。。。

當然用了這幾個月也有很多槽點想吐：

1. 完全沒辦法圖文混排，美術吐槽這點吐槽了好久；
2. 傳輸文件不是點對點的方式，而是上傳然后再下載，也無法傳輸文件夾，我們現在局域網傳輸都不用它了，嫌慢又怕外泄；
3. 出于安全的考慮，Open API不開放獲取聊天信息的接口，導致我們現在一些想做的便捷功能沒辦法做；
4. 我只把它當做一個IM工具，不想釘別人，也不想被別人釘……（純吐槽）

總之，小而精的團隊，可以嘗試下Slack~~

3.3 現場溝通

對于小團隊來說，吼一嗓子，或者跑到位置上去聊，可能是最為快速高效的工作方式了。這不需要任何工具，只是有時候需要提醒注意討論對于其他人工作效率的影響，比較長或者涉及人比較多的討論還是建議去會議室進行。但最好進去之前明確討論主題，注意討論時間，否則很容易錯過飯點。。。（流淚）

4 知識共享

團隊開發需要知識共享，一些規范也需要讓別人可以方便地查找，對于后進入團隊的人，也可以盡快熟悉規范，避免一些坑重復去踩。因此我們需要一些知識和文件共享的方式。

4.1 文件共享

文件共享分為兩種，不需要版本控制的我們使用了FTP的方式，購買了一臺windows server的服務器放置在了內網，然后直接使用了系統自帶的FPT服務，用于文件共享和一些內網的文件傳輸中轉，簡單粗暴。

需要版本控制的文件，比如策劃文檔，我們使用了SVN進行管理。

4.2 文檔共享

基本上是出于個人習慣的考慮，文檔共享方面推薦團隊使用了 印象筆記 。一開始團隊中有人吐槽它沒有文件夾管理太難用，其實我覺得Tag的方式比文件夾更加方便合理。當然也有一些不方便的地方：

1. 無法支持兩個人同時編輯一份文檔，甚至一個人看的時候光標只要在文檔內就會把文檔鎖定別人無法修改。當時考慮了一下 石墨文檔 ，但是沒有推廣去用，需要的朋友可以去看下。
2. 對于Markdown的支持不夠好，排版太難看。。。嘆氣。 馬克飛象 雖然可以用，收費不說，還不能在印象筆記中修改，怎么共同編輯，摔。
3. 美術不樂意用，嫌棄說都是文字不夠直觀……這個我也沒辦法，手動攤手。

知識共享和記錄是一件非常重要的事情，前兩天就遇到部署Jenkins的時候沒有做記錄，然后重啟機器遇到問題忘記怎么弄又搗鼓半天的事情。年紀大了，事情多了，腦袋不好使了，爛筆頭更重要了。更何況，很多東西是規范性的，需要其他職位的人遵守，口頭的約定總是會忘記或者記不清楚，落實到文字上才更有約束力。

5 版本管理

前面提到了，策劃文檔使用了SVN管理，游戲工程也是選擇了SVN，原因是團隊大部分成員習慣了SVN的使用。如果只有程序團隊使用，可能就去推行Git了，但是想想要給美術和策劃培訓Git，還有解釋本地版本和服務器版本的概念就頭疼。在剛進入網易的時候有一段時間是跟著美術處理各種svn沖突，clean up無效等問題，深深體會到svn和git這種按照程序員理性思維建立的工具，感性的美術需要花挺多精力去理解。

5.1 外鏈問題

在工程中，避免不了的是有些目錄需要同時出現在多個地方，比如客戶端與服務端可能會共用一份數據文件，當數據修改的時候，在多處進行修改是不合適的做法，維護起來很麻煩。于是版本管理軟件提供了外鏈的功能，比如svn的externals。但是外鏈有一個很嚴重的問題是當你需要建立分支的時候，如果不做任何修改，外鏈還會是指認到原始trunk上的路徑，當外鏈很多的時候，就需要針對每個外鏈單獨建立分支，然后修改整個分支中所有外鏈的路徑到正確的分支位置去。在項目后期，需要編寫一個單獨的腳本來進行分支的創建，而不是一條簡單的cp指令就可以了。與外鏈相對應的是所謂的“內鏈”，即路徑不再是一個以https或者svn開頭的全地址路徑，而是一個類似 ../../../CommonData 這樣的相對路徑。這樣，只要保證分支是在根目錄創建的，內鏈就是分支內部的路徑，不需要做任何額外的修改。當然，內鏈無法跨svn repository運作，如果是另外一個svn repository的內容，只能使用外鏈的方式。

SVN的這部分構建和設計工作最好在項目初期做好規劃，否則后期進行分支維護的時候會比較麻煩，容易出錯。

5.2 工具使用

SVN服務使用了最為簡單的VisualSVN Server，帶有gui，方便易用，目前比較惡心一點的是為別人創建賬號的時候密碼輸入只能在界面上進行，暫時沒時間調研更好的工具來自己創建賬號。 權限的分配完全按照Group進行，從不單獨針對某一個賬號進行權限分配 ，這點是在網易的時候維護SVN權限時老大強調的一點，方便，不容易出錯。雖然是小團隊，但是SVN的權限管理還是要做好，否則代碼泄露出去隱患還是很大的。

SVN服務端的Hook目前只加了兩個：

1. 不允許提交過短的log，強制防止有人偷懶不寫log；
2. 允許log被提交者自己編輯。

客戶端基本推廣的是小烏龜，Mac和Linux就使用命令行。美術同學有人喜歡裝一個中文語言包，就按照各自的喜好去用。這里有幾個小Tips提供給不太熟悉小烏龜的人：

1. 按住Shift點擊右鍵，彈出的svn菜單里會多一些比如“刪除不再版本控制下的文件”這樣的快速選項；
2. 在Settings中，Main Context Menu中可以添加常用的菜單選項，比如revert、Show Log，這樣就不需要進入SVN的二級菜單了；
3. 如果在update的時候，有更新的文件被比如3DS Max、Photoshop等軟件打開著的時候，可能會出現被鎖死的情況，這時候提示你要進行Clean up操作，在關閉了相應軟件之后，如果Clean up仍然失敗，可以嘗試使用如下的代碼來解決。如果仍然不行，可以只刪除掉.svn文件，然后重新check out，這樣既可以保留已有的修改，又可以避免下載所有的文件，加快速度。

   sqlite3.exe .svn/wc.db "select * from work_queue"
   sqlite3 .svn/wc.db "delete from work_queue"
   ECHO "DONE!"
   PAUSE

5.3 美術外包資源管理

除了游戲工程之外，美術外包或者內部制作的Max等資源也需要進行一定的版本管理。本質上說，使用svn對這部分資源進行管理并不合適，因為這些資源大都是二進制而非文本的，svn這種代碼版本管理軟件并不非常合適，更好的選擇是NXN和Preforce這樣的——有圖形化的樹狀結構界面，不需要完整下載到本地，修改之前必須獲取鎖——這些這對于美術來說是更加直觀、容易理解的方式。

但是，NXN收費很貴，Preforce也只允許20人以下的團隊免費使用。花費了一些時間去做調研，但是目前我們出于統一和成本的角度考慮，依然使用SVN來對這部分的美術資源進行管理，后續可能會進行一些改進。

在一個團隊中，推廣一個工具的使用需要不少的人力成本，尤其是美術和程序是兩種不太相同的思維方式，而且很多美術對于工具使用都是一種機械記憶而非理解原理的方式，因此這也限制了一些可能更好的工具的應用。

6. 項目管理與協作

項目管理這一部分也是花費了較多時間的，調研和試用了一系列的工具，稍微整理一下：

1. Project和Excel ，這是最為傳統的項目管理軟件了，簡單來說基于甘特圖，適合項目經歷做排期和監控項目進度，但是對于團隊中各個職位的同事協作幫助并不大。
2. Redmine ，在網易的時候也是使用Redmine進行項目管理的，后來網易公司也自己開發和擴展了“易協作”這樣的平臺。這應該是最為老牌和經典的項目協作軟件了，免費開源，也有比較豐富的插件提供。
3. 偏向敏捷開發的協作平臺 ，比如 teambition 、 Tower 、Worklite等等，試用了幾個，感覺大同小異，和Redmine的區別在于更加偏向于小團隊敏捷開發，一些跨職位的流程功能提供不是非常全面，比如有些就沒有提供從策劃提單、程序做單、QA測單的流程性的東西。

目前我們采用了內網Redmine+worklite的方式。出于搭建方便，節省時間的考慮，從淘寶購買了一套組織好插件的所謂“一鍵部署”的Redmine版本，自己做了兩個簡單的調整：

1. 我的工作臺看板增加若干列，提供更多信息；
2. ticket可以進行主題和描述的編輯功能。
   部署過程還算順利，除了遇到了端口和VisualSVN Server使用的端口沖突之外，沒遇到太多問題，后面修改這兩個調整花費了一些時間，對于Ruby和Web開發都不是很熟悉，一點點通過代碼搜索來尋找修改的地方，然后不斷測試修改才搞定。
   Worklite我們用在對外美術外包的一些工作管理和面試流程管理上，因為外網方便訪問，所以這么來做。我個人是很想推進一些敏捷協作平臺的使用的，無論從理念上還是從美感上，可能都比Redmine要舒服一些，但是最終在試用之后沒有這么來做的原因有如下幾個：
3. 數據安全性的考慮，項目的一些內容，比如玩法設計可能會在任務單中有體現，這些是想保密的，放在外網服務器還是有些擔心；
4. 做平臺的小公司倒掉了，我們怎么辦？遷移的成本很大。
5. 比如前文提到過的從策劃提單、程序做單、QA測單的工作流程，很多敏捷工具不能很好地定義和推進；
6. 有一些硬性的功能修改需求，使用Redmine花費一些時間還有可能實現，使用別人的平臺，可能只能去提建議；
7. 在試用的時候，遇到過外網訪問困難的情況，比如刷新慢，上傳文件比較慢等等問題，還是內網效率高速度快；

對于工具的選擇，往往有各方面的限制，其實不完全是決定著自己的喜好可以左右的……

7. 自動化構建工具

網易內部有一套很有趣的網易POPO機器人，來輔助比如導表、打包這樣的自動化構建過程，減少程序員的工作量。會申請一個特定的機器人賬號，把它加入到一些工作群，只需要在這些群里輸入比如“Android打包”，它就會構建已經建立好的自動化腳本進行打包，并把結果輸出在群里，比如失敗的錯誤信息，成功之后的下載鏈接等等。

這套東西非常方便，最初選擇釘釘的時候看到有Open API就想去構建一下這套自動化的流程，后來經過測試和向官方詢問發現無法通過接口獲取群的聊天信息，其實后來也想通過網絡抓包、釘釘軟件破解等方式來做，但是太過麻煩，而且維護起來比較費時，所以選擇了使用Jenkins+釘釘的方式。

Jenkins本身就是自動化持續構建的工具，釘釘只是用來反饋一些信息給策劃、美術這些不習慣使用Jenkins的同事，比如打包結果，導表的錯誤信息等。這里提供一個簡單的通過釘釘發送消息的Python腳本，需要的可以拿去用：

# -*- coding: utf-8 -*-
import time
import sys
import Config
from HTTPUtils import http_get
from HTTPUtils import http_post

class TokenManager(object):
    """Token每隔兩個小時過期一次，再次獲取刷新時間間隔。"""
    def __init__(self):
        super(TokenManager, self).__init__()
        self._token = None
        self._update_time = 0

    def get_token(self):
        if not (self._token and (time.time() - self._update_time < 1000)):
            self._token = get_access_token()
            self._update_time = time.time()
        return self._token

token_mgr_instance = TokenManager()

def get_access_token():
    access_token = None
    ret, msg = http_get("https://oapi.dingtalk.com/gettoken?corpid=%s&corpsecret=%s"%(Config.CORP_ID, Config.CORP_SECRET))
    if ret:
        access_token = msg["access_token"]
    return access_token

def send_message(msg, chat_id = Config.ROBOT_CHAT_ID):
    access_token = token_mgr_instance.get_token()
    data = {"chatid" : chat_id, 
            "sender" : Config.ROBOT_ID,
            "msgtype": "text",
            "text":{
                "content" : msg
            }}
    ret, msg = http_post("https://oapi.dingtalk.com/chat/send?access_token=%s"%access_token, data)
    return ret

http_get 和 http_post 兩個方法使用了Requests，基本定義如下：

import requests

def http_get(url):
    try:
        response = requests.get(url, timeout=10)
    except Exception, e:
        logger.error(e)
        return None
    result = json.loads(response.text)
    return handle_result(result)


def http_post(url, data):
    headers = {
        "Content-Type": "application/json",
        "Accept-Charset": "utf-8"
    }
    try:
        response = requests.post(url, headers=headers, data=json.dumps(data), timeout=10)
    except Exception, e:
        logger.error(e)
    result = json.loads(response.text)
    return handle_result(result)

最初的時候使用urllib2，但是在mac系統上遇到了SSL錯誤的問題，研究半天最后還是使用了Requests庫來做。Jenkins的搭建也是花費了一些時間和精力，包括在Mac機器上的權限問題，編碼問題，SVN權限問題等等，可惜的是當時沒有做完整詳細的記錄，一些坑沒有辦法完全記錄下來，但是遇到了之后通過Google都可以找到解決方案。

通過這一套方案，加上一些基于Python腳本構建的自動化打包、導表等流程，就可以讓一些原本需要程序來做的工作編程策劃/美術驅動機器人來完成，沒有錯誤的情況下無需程序參與。

8. 編輯器

游戲開發的最理性情況，是程序編寫玩法框架，策劃來填充游戲內容，比如UE4的藍圖功能、Unity的PlayMaker插件，就是一種對于程序工作的釋放。但是在一個大型商業游戲的開發中，引擎原生提供的編輯工具還是無法為策劃、美術和UI提供完整的游戲內容實現工具，需要程序來實現一些與游戲玩法相關的編輯器或者代碼功能，比如技能編輯、戰場編輯器等等。

網易早期，加上現在了解到的一些創業小團隊，是以Excel表為核心提供策劃編輯的功能。Excel的強大功能和靈活的編輯方式的確為策劃提供了很多便利，但是還有一些小問題：

1. 比較難做到所見即所得，即對于有些東西的編輯不夠直觀，比如場景中的位置等；
2. 一些多維的數據需要進行拆分到多張表里的方式實現，設計和填寫上會有些困難；
3. 比較難限制策劃填寫一些數據的正確性，比如一個外鍵值，策劃填寫時需要去其他表中查詢這個key值是否存在，編輯器就可以提供下拉列表這樣的方式來做。（Excel使用比較麻煩的方式也可以做到，或者在導表程序的后處理中檢查。）

對于這樣的數據，我們采用編輯器的方式來實現，之前項目使用了一套元數據的編輯器框架，不需要維護編輯器的人修改界面，只需要簡單增加或者修改一些元數據就可以了。Unity引擎本身的編輯器就是類似這樣的實現思路，因此我們無需做額外的太多工作。

編輯器的開發需要消耗程序不少的工作量，因此有時候在進度緊張人力不夠的情況下，需要評估編輯器能夠產出的價值。當編輯器真正能夠讓使用者的工作效率得到的提升遠大于程序付出的時候，編輯器的意義才能夠展現出來。

9. 程序開發工具

程序開發工具可以說的有很多，這里分為Unity和Lua腳本兩部分進行簡單的描述。

9.1 Unity引擎部分

選擇了Unity作為游戲開發的引擎，為了方便熱更使用了Lua作為游戲邏輯開發的腳本語言。Unity引擎對于游戲調試的支持還是很好的，我們在開發便利性方面只引入了兩個增強型的工具：

1. Unity Editor內的SVN集成插件： Svn Tools Lite
2. 控制臺Log查看支持搜索等功能的擴展： Console Enhanced Free

9.2 Lua部分

Lua語言方面，我們使用了 Tango 作為 跨Lua虛擬機通訊 的解決方案。在游戲腳本開發中，支持斷點調試通常比較困難，或者在聯網情況下并不非常好用，比如有可能一斷點就網絡就斷掉了，因此類似于Telnet的方案，可以在另外一個Lua虛擬機中直接連接游戲進程中的Lua虛擬機，進行一些屬性查看、方法調用，也是一種非常實用的方法，甚至可以支持遠程連接移動設備進行調試。

這種多虛擬機的整合方案在網易內部應用得非常廣泛，因為我參與的大部分項目都使用了Python語言，因此使用 RPyC 作為解決方案，為游戲引擎外運行的編輯器開發提供了非常多的便利，與測試用的服務器相連接，也可以通過編輯器/控制臺直接更新服務器內存數據。在手游項目中，也大量的使用于設備上的測試。可惜的是目前使用Lua語言，Tango雖然也提供了類似的功能，但是相比如RPyC來說完備性和易用性差很多，而且它是一個5年沒有維護的項目了。。。好在基本的功能還是可以使用的，因此也就不再挑剔什么了。

在游戲邏輯的開發中，可以利用Lua腳本語言的動態特性，提供運行時Reload的功能，在不重啟游戲的情況下，修改游戲邏輯之后直接一鍵Reload游戲代碼，然后查看修改結果。這可以非常大地提升游戲開發效率，當然對于添加函數或者修改數據結構這樣的修改可能會存在一些問題，適用性有一定的限制。

Lua的斷點調試方式我們目前還沒有走通，ToLua#的中提供了一套基于 zerobrane 的調試方法，但是我們試用還存在一些問題，斷點只能停在main函數入口的地方，其他位置無法斷點，還需要一些時間踩坑。

Lua這部分可以聊的有很多，語言特性、面向對象的結構等等，有時間計劃拿出單獨的一篇博客來講，這里就只提供上面的幾個工具的實現思路，有興趣的可以留言詳細聊。

10. 總結

洋洋灑灑寫了這么多，其實有技術含量的東西不多，但這些零零碎碎的工作，卻又是從零開始組織一個手游開發公司必不可少的過程。一個程序的負責人必須利用有限的時間和人力，使用盡量少的資源搭建起讓所有職位都可以正常運轉與合作的工作流程與工具集合，而且盡量讓這個流程更高效。

從大公司的“溫室”里“逃”出來，想做些不一樣的事情，但初始要做的，卻是這些在大公司不屑于去做的事情。這雖然有點諷刺的以為，但這個過程，也是學習和反思的過程——從之前的工作流程中提取好用高效的部分，反思哪些流程是可以改變和改進的。慚愧的是，現在搭建和使用的這些工具，大多還是“網易 like”的模式，不過已經看清了那些好處和壞處，等以后有人力和時間的時候，可以進行大刀闊斧的改進，這些是在大公司不太會去思考和改變的。

 

 

來自：http://www.jianshu.com/p/2189a26076c1