遊戲開發中會遇到各種各樣的問題，只有經歷過了纔會深刻，這裏就遊戲開發的經驗點滴給讀者分享一下，下面先從代碼說起。
從事IT行業這麼多年了，寫過或者看過很多代碼，有的項目代碼寫的不錯的，大家經過多年的努力都會從初級程序員到主程的發展，作爲主程除了做架構設計，帶團隊外，就是審覈代碼，現在程序員寫的代碼，大部分都是隻根據需求而寫，遊戲開發與其他開發最大的不同是需求經常變化，朝令夕改用於遊戲策劃一點都不爲過。這就要求程序員再根據需求寫邏輯時，多跟策劃溝通，把一些可能發生的事情都考慮完整再動手寫代碼，即使這麼做了，後期還會修改。所以作爲邏輯程序員很難的。程序員能做的事情儘量減少自己的工作量，把代碼設計的靈活一些，最好的方式就是採用數據驅動。
數據驅動
我在做端遊的時候，項目經理說的最多的就是數據驅動，我們的邏輯是通過配置數據讓其運行的，表的設計，這些就需要程序員跟策劃協商溝通，每個表都有自己的唯一ID項，通過ID去查詢數據，程序要做到，邏輯的增加只侷限於幾個文件，不要牽扯太多。切記在代碼裏面不能出現具體的ID號，這樣一旦策劃修改表項，你的邏輯就需要修改，看過一些代碼把具體的ID號都寫到程序裏面了，這麼做是非常不好滴，讓人感覺不專業，非常業餘，還有代碼不加註釋也是不能容忍的，這個是爲了更好的傳承，我們說一個公司的技術積累，這個積累也包括代碼註釋。
在程序啓動時，關於數據表的加載問題，很多程序員的一些做法是：在程序啓動時，把數據表一次性加載到內存，然後用到數據時再去一條一條查找。這麼做可以不？答案是可以的，但不是最優方案，因爲首先把所有的數據表一次性加載到內存中，會佔用大量的內存，很多人見過的表可能不是很多，但是一旦表格數量很多，表格數據達到萬行以上就是一個災難啊，爲了防止災難發生，加載時就要有選擇的去加載，當前場景用到的數據表加載進來，分步驟進行。再有一個問題是遍歷數據，服務器大家如果瞭解過應該知道，它可以離線加載數據，而且可以一次性加載，查找數據不需要去每條遍歷，這樣提高了運行效率，這種方式客戶端也可以使用的，優化要從一點一滴做起。
代碼拆分
再說代碼的編寫，看過遊戲開發的代碼，動輒幾萬行，至少幾千行。讓新人閱讀起來非常費勁，再加上沒啥註釋，看代碼簡直就是災難。這種代碼就需要重構了，怎麼重構？很簡單的，首先根據功能進行劃分，類有一個修飾詞partial，它可以將一個類拆分成多個類，類的名字可以根據功能進行命名，這樣一旦擴充起來可以使用多個類文件表示，不用在一個類裏面一直寫，這樣會導致代碼非常龐大，函數的定義可以根據類的功能名字去劃分。比如下圖所示的：
資源打包
unity官方提供了一個打包工具，Assetbundle，我們可以將美術資源，音效，文本文件都可以打成Assetbundle，關於資源打包，我們還需要考慮依賴打包，因爲很多模型都會彼此依賴，這個關乎內存的加載和釋放。很多人打包並沒有使用依賴打包，導致資源重複的加入到內存中，依賴打包還需要注意釋放的先後順序，這個可以通過引用計數的方式進行，另外，這個工具我們可以在此基礎上進行擴充，比如加入版本更新的處理等等，效果如下圖所示：
角色動作處理
隨着Unity版本更新，大部分公司使用的都是Animator，採用AnimatorController控制器的新動畫狀態機去處理Unity的動作切換，使用這個的好處是，該動畫狀態機使用了FSM的封裝處理，加入了動作的融合，另外，提供了Humandoid模式，不同的角色可以採用同一套骨架的處理等等，Animator作爲Animation的替代品，Unity官方一直維護着，細節的東西，Unity引擎都爲我們處理過了，我們只需要使用諸如SetTrigger，SetInteger這些函數接口調用就可以，另外還需要動作的幀回調函數，可以採用配置表的方式進行，不需要每次都是在動作上自己填寫，一旦動作更換非常麻煩，因爲Animator它會牽涉到一些矩陣變換，所以，在不需要的物體上切記不要掛Animator這個組件。因爲Max導出模型直接放到Unity引擎時，會自動掛上，導致程序運行時幀率降低，所以可以寫個工具檢測一下，不需要的可以直接刪掉。
Shader優化
Unity官方提供了一些Shader，這些都是最基本的，在開發高品質產品時基本用不上，在我看來，它只適合於學習，不適合做產品開發。Shader的編寫其實我們不需要一行一行的代碼敲，有幾個插件可以使用比如：Shader Forge和Unity自身的Shader Graph。Shader Forge，它爲了適配不同的硬件會使用D3D，OpeGL，Metal等等圖形庫，它做的是非常全面了，但是在Android比較挑剔的情況下，我們是不需要的，可以把對應的#pragram 註釋掉，這個也是一種優化方式，還有看一下Setpass call的數量，它也是Shader優化的一種方式，當然數據變量的精度也是需要考慮的，另外Shader中儘量避免判斷條件語句和循環語句的出現，以及複雜函數的計算等等。
現在遊戲品質要求越來越高，角色Shader的渲染，爲了提升渲染效果，美術需要製作多張圖片，普通的製作方式已經不能滿足需求了，也就是通用的法線，高光，反射這些已經無法滿足需求了，這就帶來一個問題，當程序加載角色資源時，會涉及到大量的圖片加載，這樣的後果會導致實例化一個角色時間比較長，當然加載時間長也會有其他因素，比如一些廢棄的面和動作沒有刪除掉，但是我們能夠控制的是可以將多張圖片進行優化，比如顏色有RGBA，我們也可以將貼圖按照RGBA通道進行合併，這種方式比較流行。
後處理渲染效果，Unity提供的Post Processing Stack由於效率問題，我們一般會做一些優化操作，這個可以參考UE4的處理方式，可以將一些傳統的算法優化，可以將UE4的移植到Unity裏面。
貼圖的優化可以使用國外提供的壓縮方案：www.tinypng.com
特效製作流程
美術製作特效流程，很多特效人員對其執行的並不是特別好，其實非常簡單，主要分以下幾步：
第一步：一般的特效需要特效人員把特效製作好，按照原點的方式製作，不要產生位移；
第二步：特效名字是根據使用者命名的，命名規範要做好。
第三步：特效的掛節點通過配置表進行配置，然後程序動態的生成虛擬掛節點，這個事情可以由策劃提供。
第四步：關於一些特效大招，比如有鏡頭的控制，一般是由特效人員去製作完成，當然動作這塊可以進行配 合，也可以在MAX工具裏製作鏡頭移動然後交付給特效人員使用。
第五步：特效製作完成後，需要策劃跟動作一起驗收，看是否滿足需求，提出修改意見。
第六步：將角色和特效放到遊戲實際場景中去看效果，這個需要程序配合，提出修改意見。
總結
遊戲開發會涉及到方方面面，這裏只是把項目中暴露的一些問題做了總結，以備查閱使用。