Unity做游戏有哪些比较好的代码管理方式？

462710480

Unity做游戏有哪些比较好的代码管理方式？

幸福341

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 游戏框架搭建 (二十) 更安全的对象池
Unity 游戏框架搭建 (二十一) 使用对象池时的一些细节
Unity 游戏框架搭建 (二十二) 简易引用计数器

我的苦恼冉

Unity 如何管理代码

不仅仅是代码，Unity项目里所有的资源都需要有命名规范，并且合理放置在不同的目录。我们的习惯是凡是自己创建的文件夹，统一用下划线_开头，譬如_Scripts, _Textures等等，场景文件夹专门用多几根下划线____Scenes, 方便让它排在最顶部。在场景的层级管理器（Hierarchy）里，所有的GameObject也要遵循合理的命名规范。往场景里放置脚本时，要单独为它建立一个 GameObject 对象，采用特殊的命名，譬如“_GameController"， 然后把脚本附加到上面。有很多 Unity 教程里，为贪图方便把摄像机功能以外的脚本附加到 Camera 上，这是相当恶劣的做法。Hierarchy里层级特别深的地方（超过4层）尽量别放代码了，否则到时修改都得找半天，还不一定找得到。
脚本里的函数命名要规范，安排也要合理。确保每个函数在 IDE 里能用“跳到定义.." “查看全部引用 Reference“这些功能可以准确导航。脚本命名方面，UI 专用的脚本用 UIXXXX命名。特效专用脚本用 FX_XXXX命名。脚本根据功能的不同存放到各自的目录下。脚本要写注释，按三下“/”就能自动生成注释了，而且 Unity5以后的 MonoDeveloper 可以直接输入中文，比以前方便很多。微软有一套匈牙利骆驼命名法，很适合 C#程序，建议全盘学习拿来用。

另外有些题外话，程序员在生活中也要养成保持整洁有序的习惯。平时要定期整理电脑文件夹，确保资料能随时找到。定期整理自己的办公桌，定期整理自己的邮箱，定期整理自己的房间、床铺、衣柜。就算有妹子有老婆，这些事也要自己做。只有平时养成良好的整洁习惯，才能写出简洁优美的代码，自己和别人读起来才足够赏心悦目。

胡37

首先代码要分层，最基础的就是MVC
之后所有层代码放到同一个目录里，每一层代码放到同层目录，每一层相同类型代码放到同一个目录里（Java写的比较多，之后unity代码也按Java代码来管理了）
shader放到一个目录下，并且按功能分目录
资源放到一个目录下，里面应该包括音频，图片，配置等都要分层
模型单独放一起，按类型分层

123456833

\(≧▽≦)/谢邀~~~好久没人邀我了，好感动~~~

因为我是一个人负责一个项目的，所以我管理代码的规则就两条：1.看得懂   2.方便改。

为了看得懂，我会写上一大堆注释。随便给你一小段代码感受一下：
    /// <summary>
    /// 获取地图与视频数据
    /// </summary>
    public void GetInformation()
    {
        JsonData jNode = null;// json串
        DtoVideo dtoVideo = null;// 解读的dtoVideo类
        IList<DtoMap> 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<DtoMap>
        OwnController.mapList = mapList;//保存IList<DtoMap>到控制器
        // 将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中实现的，非得塞一起的话也不太好写。
再比如对同一个人物，我要实现它的数据同步且点击它的时候有动画显示计算过的数据。这种情况按理来说是放同一个脚本比较好的，毕竟用的是同一套数据，放一起方便写。但是为了方便后期更改同步数据的函数实现或者动画显示的部分，我把它们给拆了三个脚本。同步的就专心同步。动画显示就只负责显示。点击效果就调用同步过来的数据并稍微计算一下最后用动画来显示。这样修改起其中一个脚本的的时候，对另外两个脚本的影响不大。方便修改。如果还都塞一起，改一个同步数据就基本改了大部分的原脚本了。

架构什么的我不太懂。。。这个真心帮不上了。
以上方式也不一定适合你╮(╯▽╰)╭毕竟写注释和拆脚本都比较耗时，效果也不是一时半会儿能看得到的。但是当你要重构代码的时候，你就会无比庆幸了~~~

123456865

谢邀，最近忙到不行了。
代码管理：
1.首先是理解项目的架构，例如pureMVC,项目架构strangeioc，架构本身脱离项目也是需要了解，知道优势所在，适用情况，以及相关问题。有个整体的理解，当你对业务有了解后，你就知道这个架构优势有自己的了解。
2.其实你是站在前人的肩膀上，有一个脚本不清楚当中具体的逻辑，只知道干嘛，比较笨的方法，一行一行的读，把不理解的这行注释掉，看运行区别。
3.还有一种方式，别人写的从UI选择到进入战斗场景，开始战斗，战斗进行，到战斗胜利，获取奖励，切换场景，到回到UI界面。你可以在方法执行地方Debug.LogError("method Name"+Time.time);这样帮助你熟悉代码
4.项目有很多方法，是工具方法，如字符串解析等，还有Editor 工具扩展方法，这些代码其实自己尝试写一遍，其实对于API熟悉，以及对代码理解，是有帮助。其实你也在github或者别项目收集一些有意思编辑窗口功能。
5.当你对架构了解，模块划分，模块之间互相调用方法，就方便你去具体的代码了。
6.注释的话，当你觉得你的代码，通过方法名称就表达是实现什么功能的时候，是不需要的。有注释是帮助新人熟悉更快的
7.楼上讲到业务逻辑中文解释，这种情况出现在，逻辑很多，有复杂一点的运算，或者说是策划案子不明确的情况下。伪代码，分解逻辑，实现每一步的功能。
接手代码和管理代码就这些了。关于很多架构，我只建议了解，毕竟架构是为业务服务的。多了解拓展下。

伊索谗言

《代码整洁之道》