Unity做遊戲有哪些比較好的代碼管理方式？

01-13

最近老看前輩一大堆代碼，最後自己都找不到了。。而且更可怕的是，代碼沒有注釋，很心疼接手的人-_-||所以我想問問各位大牛是如何管理代碼的。。還有就是用unity有什麼好的架構可以參照？

Unity 如何管理代碼
- 不僅僅是代碼，Unity項目里所有的資源都需要有命名規範，並且合理放置在不同的目錄。
- 我們的習慣是凡是自己創建的文件夾，統一用下劃線_開頭，譬如_Scripts, _Textures等等，場景文件夾專門用多幾根下劃線____Scenes, 方便讓它排在最頂部。
- 在場景的層級管理器（Hierarchy）里，所有的GameObject也要遵循合理的命名規範。往場景里放置腳本時，要單獨為它建立一個 GameObject 對象，採用特殊的命名，譬如「_GameController"，然後把腳本附加到上面。有很多 Unity 教程里，為貪圖方便把攝像機功能以外的腳本附加到 Camera 上，這是相當惡劣的做法。
- Hierarchy裡層級特別深的地方（超過4層）盡量別放代碼了，否則到時修改都得找半天，還不一定找得到。
- 腳本里的函數命名要規範，安排也要合理。確保每個函數在 IDE 里能用「跳到定義.." 「查看全部引用 Reference「這些功能可以準確導航。
- 腳本命名方面，UI 專用的腳本用 UIXXXX命名。特效專用腳本用 FX_XXXX命名。腳本根據功能的不同存放到各自的目錄下。
- 腳本要寫注釋，按三下「/」就能自動生成注釋了，而且 Unity5以後的 MonoDeveloper 可以直接輸入中文，比以前方便很多。
- 微軟有一套匈牙利駱駝命名法，很適合 C#程序，建議全盤學習拿來用。
另外有些題外話，程序員在生活中也要養成保持整潔有序的習慣。平時要定期整理電腦文件夾，確保資料能隨時找到。定期整理自己的辦公桌，定期整理自己的郵箱，定期整理自己的房間、床鋪、衣櫃。就算有妹子有老婆，這些事也要自己做。只有平時養成良好的整潔習慣，才能寫出簡潔優美的代碼，自己和別人讀起來才足夠賞心悅目。

Unity 遊戲框架搭建 (一) 概述

Unity 遊戲框架搭建 (二) 單例的模板

Unity 遊戲框架搭建 (三) MonoBehaviour單例的模板

Unity 遊戲框架搭建 (四) 簡易有限狀態機

Unity 遊戲框架搭建 (五) 簡易消息機制

Unity 遊戲框架搭建 (六) 關於框架的一些好文和一些思考

Unity 遊戲框架搭建 (七) 減少加班利器-QApp類

Unity 遊戲框架搭建 (八) 減少加班利器-QLog

Unity 遊戲框架搭建 (九) 減少加班利器-QConsole

Unity 遊戲框架搭建 (十) QFramework v0.0.2小結

Unity 遊戲框架搭建 (十一) 簡易AssetBundle打包工具(一)

Unity 遊戲框架搭建 (十二) 簡易AssetBundle打包工具(二)

Unity 遊戲框架搭建 (十三) 無需繼承的單例的模板

Unity 遊戲框架搭建 (十四) 優雅的QSignleton(零) QuickStart

優雅的QSignleton (一) Singleton單例實現

優雅的QSignleton (二) MonoSingleton單例實現

優雅的QSignleton (三) 通過屬性器實現Singleton

優雅的QSignleton (四) 通過屬性器實現MonoSingleton

優雅的QSignleton (五) 優雅地進行GameObject命名

Unity 遊戲框架搭建 (十五) 優雅的QChain (零)

Unity 遊戲框架搭建 (十六) v0.0.1 架構調整

Unity 遊戲框架搭建 (十七) 靜態擴展GameObject實現鏈式編程

Unity 遊戲框架搭建 (十八) 靜態擴展 + 泛型實現transform的鏈式編程

Unity 遊戲框架搭建 (十九) 簡易對象池

Unity 遊戲框架搭建 (二十) 更安全的對象池

首先代碼要分層，最基礎的就是MVC

之後所有層代碼放到同一個目錄里，每一層代碼放到同層目錄，每一層相同類型代碼放到同一個目錄里（Java寫的比較多，之後unity代碼也按Java代碼來管理了）

shader放到一個目錄下，並且按功能分目錄

資源放到一個目錄下，裡面應該包括音頻，圖片，配置等??都要分層

模型單獨放一起，按類型分層

(≧▽≦)/謝邀~~~好久沒人邀我了，好感動~~~

因為我是一個人負責一個項目的，所以我管理代碼的規則就兩條：1.看得懂 2.方便改。

為了看得懂，我會寫上一大堆注釋。隨便給你一小段代碼感受一下：

/// & /// 獲取地圖與視頻數據 /// & public void GetInformation() { JsonData jNode = null;// json串 DtoVideo dtoVideo = null;// 解讀的dtoVideo類 IList& mapList = null;// 解讀的map List 類 jNode = OwnWebservice.GetVideo(videoNo);// 連接伺服器獲取視頻json串 dtoVideo = ReadJson.ReadVideo(jNode);// 解讀json為dtoVideo類 OwnController.dtoVideo = dtoVideo;// 保存dtoVideo到控制器 OwnController.cameraAngle = dtoVideo.cameraAngle; OwnController.cameraFar = dtoVideo.cameraFar; OwnController.cameraNear = dtoVideo.cameraNear; //runStatus = OwnController.status;// 獲取當前狀態 jNode = OwnWebservice.GetMap(videoNo);// 鏈接伺服器讀取地圖json串 mapList = ReadJson.ReadMap(jNode);// 解讀json為IList& OwnController.mapList = mapList;//保存IList&到控制器 // 將mapList轉為transformList int lastframe = OwnController.CaculateLastFrame(mapList); OwnController.lastFrame = lastframe;// 保存結束幀到控制器 OwnController.TransformList = OwnController.CreateTransformList(mapList, lastframe);// 保存地圖列表到控制器 //Debug.Log("create dtomap and transformlist " + Time.realtimeSinceStartup); }

以上的注釋只是把C#翻譯成中文。還有很多代碼我會把業務邏輯、測試結果、注意事項、可以用其他辦法實現同樣效果但是被棄用的理由，都寫在注釋里。

為了方便改，我會儘可能的把代碼拆開，放在不同的腳本里。

比如我要實現兩種旋轉。一種是物體以一個固定速度旋轉。另一種是滑鼠拖拽的時候物體變速旋轉。雖然都是旋轉，但是我會把這兩種旋轉拆成不同的腳本，需要哪個掛哪個。╮(╯▽╰)╭更何況兩個旋轉都是在Update中實現的，非得塞一起的話也不太好寫。

再比如對同一個人物，我要實現它的數據同步且點擊它的時候有動畫顯示計算過的數據。這種情況按理來說是放同一個腳本比較好的，畢竟用的是同一套數據，放一起方便寫。但是為了方便後期更改同步數據的函數實現或者動畫顯示的部分，我把它們給拆了三個腳本。同步的就專心同步。動畫顯示就只負責顯示。點擊效果就調用同步過來的數據並稍微計算一下最後用動畫來顯示。這樣修改起其中一個腳本的的時候，對另外兩個腳本的影響不大。方便修改。如果還都塞一起，改一個同步數據就基本改了大部分的原腳本了。

架構什麼的我不太懂。。。這個真心幫不上了。

以上方式也不一定適合你╮(╯▽╰)╭畢竟寫注釋和拆腳本都比較耗時，效果也不是一時半會兒能看得到的。但是當你要重構代碼的時候，你就會無比慶幸了~~~

謝邀，最近忙到不行了。

代碼管理：

1.首先是理解項目的架構，例如pureMVC,項目架構strangeioc，架構本身脫離項目也是需要了解，知道優勢所在，適用情況，以及相關問題。有個整體的理解，當你對業務有了解後，你就知道這個架構優勢有自己的了解。

2.其實你是站在前人的肩膀上，有一個腳本不清楚當中具體的邏輯，只知道幹嘛，比較笨的方法，一行一行的讀，把不理解的這行注釋掉，看運行區別。

3.還有一種方式，別人寫的從UI選擇到進入戰鬥場景，開始戰鬥，戰鬥進行，到戰鬥勝利，獲取獎勵，切換場景，到回到UI界面。你可以在方法執行地方Debug.LogError("method Name"+Time.time);這樣幫助你熟悉代碼

4.項目有很多方法，是工具方法，如字元串解析等，還有Editor 工具擴展方法，這些代碼其實自己嘗試寫一遍，其實對於API熟悉，以及對代碼理解，是有幫助。其實你也在github或者別項目收集一些有意思編輯窗口功能。

5.當你對架構了解，模塊劃分，模塊之間互相調用方法，就方便你去具體的代碼了。

6.注釋的話，當你覺得你的代碼，通過方法名稱就表達是實現什麼功能的時候，是不需要的。有注釋是幫助新人熟悉更快的

7.樓上講到業務邏輯中文解釋，這種情況出現在，邏輯很多，有複雜一點的運算，或者說是策劃案子不明確的情況下。偽代碼，分解邏輯，實現每一步的功能。

接手代碼和管理代碼就這些了。關於很多架構，我只建議了解，畢竟架構是為業務服務的。多了解拓展下。

《代碼整潔之道》

瀉藥~）這個我剛畢業也不是很懂。根據我的理解，項目中好像並沒有用到什麼具體的架構。不過大部分大概可以分為如下幾點理解：

1、基礎功能的封裝。項目中一般都有基礎的像資源載入，場景管理，網路連接等等這樣的基礎的功能的封裝，是整個項目的基礎。

2、通用功能的封裝。項目中一般都有像定時器，統一的彈窗，數據表的讀取，音樂音效的接入等等這樣會經常用到的功能的封裝。

3、模塊功能的開發。基於以上兩點，就可以開發各個模塊了。

這就是我大概理解的項目中的思路了，剛畢業，回答得不好別打我。看不懂代碼就用vs斷點一步步看。架構這東西可以看看ulua或者pureMVC之類的~