• Unity3D如何有效地组织代码?


    本文整理自知乎,原文链接:http://www.zhihu.com/question/21070379

    问题:

    Unity3D可以说是高度的Component-Based Architecture,同时它的库提供了大量的全局变量。

    这些都和我曾接触到的cocos2d-x,和非游戏框架有很大出入,

    请问各位前辈有没有什么好的方法、模式、框架来组织代码呢?

    谢谢!

    回答

     

    梁伟国

    准确地说,代码作为Unity项目里的一种资源,此问题应该扩展到如何组织Unity资源。简单说说我们的经验:

    - Unity有一些自身的约定,譬如项目里的Editor,Plugins等目录作为编辑器,插件目录等等。知名的插件会自己存放一个目录,譬如NGUI等。

    所以我们自己的代码,一般目录名会以下划线开头,譬如 "_Scripts", "_Prefabs"等。

    对于场景,文档等目录,用两条下划线,以便他们能排在最顶部。

    - 代码用C#,别用JS。必要的话用namespace将自己的代码括起来。我们是用namespace把自己积攒的公用库包住。

    - C#的注释要认真写,打///就能帮你补全了,没理由偷懒。

    - 每个程序文件开头要用一段注释写修改Log,谁改过什么简单留一条说明。就算用了Unity的版本管理或者Git,那些log终究会丢失,只有认真把log写在代码里,才会有意识去认真优化它。

    - Unity的脚本逻辑,就功能而言大体分为两种,一种是比较独立的,譬如爆炸之后1秒钟消失,这种单独写个脚本绑定到目标上即可。

    更多的是脚本里与其它的脚本进行交互。Unity里提供了一种万金油的方法是SendMessage, 这种方法性能略差,如果你调用的频率不高,随便用也无妨。另一种方法是直接通过对象的实例去调用。

    我们的做法是写几个公用的控制器,让它们各司其职,负责各自的事情:

    - 写一个一个GlobalManager.cs来控制游戏的全局变量及全局方法。静态类模式。譬如当前玩到第几大关第几小关,玩家的金币数量等。

    - 写一个GameController.cs来控制当前关的游戏进程。单实例模式。游戏的主循环也是用它控制。初始化,胜利、失败判定等等。

    - 写一个InputController.cs来控制所有的用户输入。单实例模式。鼠标、键盘、触摸屏,我们做游戏是保证同时支持这三种输入的,因为大部分时间是在PC上测试。

    关于GameController与InputController的联系,有点让人纠结。一般来讲是在InputContoller里调用GameController.Instance.Foo()执行方法。或者直接对Input写成Listener的模式,让GameController去监听。

    - 其它的类似菜单控制器,声音控制器,成就控制器,IAP虚拟道具控制器等等,也是采用类似的方法管理。

    - 关于PlayerPref的操作,统一写成静态类的get/set模式,程序中哪里要用则直接读写。

    - 如果你的项目里场景的数量少(<5),那么拖入场景的资源可以很随意。如果场景数量很多(几十个,有的解谜游戏每个关卡就是一个场景),那么拖入场景的prefab数量一定要少。

    - 设计你的prefab资源里,你要想像当其他人拿到这些资源,是否直接拖入一个空场景里就能run,顶多再简单设置几下。如果你设计的资源不能做到这些,那么得好好重新想想。

    写了这些,感觉写不下去了。

    想吃透Unity,起码得真做出几款产品放上线才行。真正做产品的过程中会碰到各种各样意想不到的问题,代码不断地被重构和妥协,不存在什么最佳的方案。

    暂时就写这些吧,希望能抛砖引玉。

    周华

    Unity除了挂在Game Object上的代码比较难找,这一点跟其他工具做项目不同外,其他就是每个公司自己的管理风格了。在实际操作中,无非就是文件夹/文件夹/.../文件,名字要起的好。这样就在源代码级别管理好了自己的代码。

    至于楼主所提的Component-based architecture,个人在管理过程中会习惯去适应unity的脚本概念,虽然与C++等代码做的项目一样,一样有源代码级的很多manager,但是这些manager的启动不再需要自己做一个类似main一样的入口手动启动,只要挂在某个Game Object上,在Start()中启动就可以。配合Unity的script execution order,慢慢脚本的概念就会扎入你的心里。用Unity,因为逃不开在Game Object上挂脚本,所以,个人觉得还是习惯这种方式,的确在概念上也很简单。唯一要注意的是,一定要对Game Object的名字有一定的约束,养成很好的命名习惯。然后自己再写一些查找工具用来查找用到某个名字的脚本的Game Object,配合起来就会理解Unity这样工具的设计理念:基于脚本的对象化。

    举个例子,单机版的一些存储,如果配合Unity的playerprefs和Unity的回调机制(OnApplicationPause(),OnApplicationQuit()),你会发现你不用为save/load去设计存储格式,去设计一个基于虚函数的OnSave()、OnLoad(),更不用需要去考虑各个模块的存储先后问题。Unity都给你做好了。

    我不知道有哪些模式,只知道也曾经用C++等熟悉的语言来组织自己的逻辑(因为当初刚开始untiy),但是当我做项目多了,发现其实unity的方式挺简单,也很好用。如果所谓的脚本能做好一件事情,你会发现小即是美。

     
  • 相关阅读:
    记录下QCustomPlot 热力图的用法
    Qt QChart 创建图表
    Qt TCP 简单通信
    Qt 设置Qt::FramelessWindowHint 后界面无法移动问题的一种解决方案
    Qt 操作 Excel 的相关文档
    Microsoft Word Application Reference Qt 操作word 的操作文档
    Python 进行excel查重
    Qt QPainter画个球啊
    Redis持久性文档中文翻译
    Docker 课前预习
  • 原文地址:https://www.cnblogs.com/forlove/p/3785302.html
Copyright © 2020-2023  润新知