Unity3D使用经验总结 优点篇 xx年还在和其它小伙伴开发引擎的时候，Unity3D就初露头角。 当时就对这种基于组件式的设计结构很不理解。 觉得拆分过于细致，同时影响效率。
而时至今日，UNITY3D已经成为了众多团队的首选3D引擎。 并且，随着Unity3D
4.3的发布，原生的2D支持也让人大开眼界。虽然Unity3d的原生2D功能还有很长的路要走，但也阻挡不了它称霸当下。
20xx年中，公司的引擎项目停止之后，我的目光便转到了U3D的身上，经过几番挣扎后，终于对基于组件式的对象模型有了新的认识。 而如今，这种模式，成为了我最推崇的模式。 因为它能解决我在设计引擎对象时的纠结。 而这些纠结，是我在先前的引擎开发中，一直不能优雅地解决的。
首先，我们来说说U3D的好处。可能总结得不够完善，如果有不足的地方，就表示我自己没有体验到。
一、可定制的IDE环境
U3D这种ALL IN ONE的设计思路，我在一个叫神咒的代码中见到过。 集所有编辑器于一身。 虽然神咒的编辑器不能自由扩展，但由于是公司内部的引擎，所以，它的使用，也很方便。 比如，在场景中突然想要对一个模型的材质进行编辑，则选中此模型，右键，弹出材质编辑器即可。 的组件式思路，将这种关系变得更加紧密。 你都感觉不到自己在使用一个材质编辑器。 你会觉得，你是在操作这个模型本身。 它的材质，它的碰撞器，它的对象结构等等。
回想一开始进入游戏行业的时候，天天啃着代码。 当时觉得代码就是一切，各种认为很牛X的代码，都忍不住读上一番。 而随着时间的推移，特别是经过项目的洗礼后。 突然发现编辑器是多么的重要。 就我做的第一个页游来说，起手前两个星期，我们就做了动画编辑器，场景编辑器。而最终证明，因为这两个简陋的编辑器，使我们后面的工作变得更加容易。
因此，一个好的引擎，必定得先有一个功能完备的编辑器。
二、基于Mono的开发脚本
C/C++无疑是图形界的宠儿，也没有人想过用另一种语言来替代它。即使是U3D，亦是如此。 但是，早期使用C/C++编写的引擎，都理所当然地使用C/C++来作为上层逻辑的开发。 又有一些，采用了纯脚本的模式。比如Python,LUA。 脚本的好处在于更
低的编码成本（经过仔细研究，我发现，这是由于写脚本语言的心态和写C++的心态导致的。 写C++的时候，总是想着代码的复用度，而在脚本的时候，很多时间会认为，这个脚本，就是为这个对象服务的，那我就按照策划需求来写就可以了。 我想，这也是许多时候，脚本语言存在的意义。特别是早期引擎中，使用脚本来处理一些关键的事件响
应）。 而大家熟知的虚幻引擎以及有一个名不见经转的Torque，则自己整了一套开发语言。 我想，它们的目的，就是为了使大家能够以一种更安全的方式来编程， C++一不小心，则会带来内存和效率问题。 它的使用成本，人员成本其实是高于其它语言的。 Mono C# JS,BOO的出现，再一次让大家的眼睛一亮，原来，引擎可以这样整。
Mono的桥接，使得高效的C++图形引擎与带GC的内存安全语言进行结合。不仅减少了安全隐患，也使得大家编写跨平台代码时更佳容易。 同时，这类语言的反射机制，更适合做编辑器。而比起先前的一些DIY语言和像LUA这样的小巧型语言，Mono使脚本编程可以进行DEBUG，而不单纯的靠PRINT输出。文章出处【狗刨学习网】
这里就顺带说一下三个语言的区别
C# 这是我见过的大型项目中使用得最多的语言，也是我比较喜欢的语言。 因为它和C++很像，同时严格的类型和语法检查。
JS 在帮一些朋友做小东西的时候，使用过这个语言，由于mono自带的提示功能，写起来还是挺顺手。 但总给我一种摸不着头脑的感觉。 并且U3D给的JS，不是严格的JS，有些语法不支持，而有些语法又很特别。
BOO 完全没有使用过，貌似也很少有人使用。
三、基于组件的对象系统
这是一个我最喜欢的系统，我也使用irrlicht引擎山寨过，山寨的过程中，几乎看完了它的组件参考手册，使我对U3D引擎的组件系统又有了新的认识。 同时，目前公司自主研发的引擎，也是这样的思想。 不管我是在工作中，还是业余捣鼓都受组件系统的影响。 慢慢的，喜欢上了这种对象模式。
之前在做一个RTS游戏项目的时候，参考了著名开源项目 0.A.D的代码。 当时只是为了去寻找LOS和多单位协同寻路的方案。 但在参考其代码的时候，发现了它整个系统，都是基于组件式的。又一次，对组件式有了好感。 而经过仔细思索后。 回到了我一直坚持的子系统划分法的游戏框架。 当我不禁感叹，原来，自己也一直是在组件式。 只不过，我的组件式，是MANAGER方式，MANANGER内部进行对应的实体管理、。 比如，背包系统，则只负责玩家背包数据，背包使用，背包相关的功能。 不管是数据存储，还是与
前端通信，都是背包系统自己在负责，其它模块完全不需要干涉。 而U3D中的组件系统，则将这个粒度划得更仔细了……。 这对于早期的像OGRE的entity系统。仅仅是认为对象可以由子对象构成，可以说是一个质的变化。
早期的引擎，基本上都是继承优先的设计方案，更多时候考虑的是编码的便利性，且引擎的走向都具有针对性。 而当面对一些复杂情况的时候，继承式的编码是十分麻烦的。 并且，对于JAVA,C#这样的语言，并没有提供多继承能力。 因此，继承式的编程，在面对越来越广泛的游戏需求的时候。显得无能为力。 组件式则是一种聚合优先的编码方式，它的复用度和伸缩度，都远远大于继承。 唯一让一些C++程序员觉得不太顺眼的，可能就是过多的变量和虚函数调用开销吧。 但这些，在当下来说，都不是问题。 影响大众步伐的，早已不是那种语言特性本身导致的开销。更多的，是如何使我们高效率，高质量地完成一个游戏。 因此组件模式已经成为必然。 从新版的UE4的变革，以及畅游的G3D，国外一个开源的godot引擎，就可以看出来，大家对组件模式，已经有了深深的好感和接受度。
四、所见即所得
这可以说是许多人最喜欢的特性，这也是G3D群里，问的人最多的特性，三天两头就有人问，G3D能不能像U3D一样在编辑器里预览游戏效果呀。
U3D除了编辑后立即运行，还能在运行过程中时实编辑，查看效果。当然，运行过程中编辑对象的数据，会在停止后失效。（注意，对文件属性的修改，不会失效）
五、代码驱动的开发模式
这种模式，可以使我们快速地构建一个原型。 对于U3D中的MonoBehaviour来说，它扮演的，就是如何驱动它的目标对象。 因此，你可以将你的对象的各种能力分配到不同的脚本组件中，然后根据对象的需求来挂接。
六、多平台发布
U3D支持的平台，无疑是当下较为流行的平台。 满足绝大部分项目需求。 早期的引擎，多以PC和CONSOLE为主。 支持WINDOWS,XBOX,PS2已经是很不错了。 U3D便利的多平台发布特性，也使得它成为了当前性价比最高的引擎的原因之一。
也有许多公司正在自主研发引擎，或者是将先前的PC引擎修改为多平台
（IOS+ANDROID居多）。 但这也档不了U3D的步伐。
七、良好的生态圈
在使用公司引擎的时候，我就发现，若我遇上一个问题，只能问公司的老员工们，或者找其它引擎TEAM寻求帮助。而U3D这种生态圈，不是一天两天能形成的。GOOGLE,百度，各种论坛，都能很容易找到自己想要解决的问题。 而对于一些经验上的问题，也有不少人总结。 这使得后来者，可以快速上手引擎。
而AssetStore的出现，不仅使U3D的生态圈更加稳固，同时也提供了许多机会。 你可以制作插件放网上卖，赚取一些利益，也可以购买别人的插件，作为使用或者参考也好。 有时候，购买一些插件，可以让你快速脱离当前的困境。 一个是解决进度问题，一个是解决思路问题。 这是之前其它引擎不具备的。文章出处【狗刨学习网】
第二篇：Unity3D技术之使用经验总结篇
Unity3D技术之使用经验总结篇 xx年还在和其它小伙伴开发引擎的时候，Unity3D就初露头角。 当时就对这种基于组件式的设计结构很不理解。 觉得拆分过于细致，同时影响效率。
而时至今日，UNITY3D已经成为了众多团队的首选3D引擎。 并且，随着Unity3D
4.3的发布，原生的2D支持也让人大开眼界。虽然Unity3d的原生2D功能还有很长的路要走，但也阻挡不了它称霸当下。
20xx年中，公司的引擎项目停止之后，我的目光便转到了U3D的身上，经过几番挣扎后，终于对基于组件式的对象模型有了新的认识。 而如今，这种模式，成为了我最推崇的模式。 因为它能解决我在设计引擎对象时的纠结。 而这些纠结，是我在先前的引擎开发中，一直不能优雅地解决的。
首先，我们来说说U3D的好处。可能总结得不够完善，如果有不足的地方，就表示我自己没有体验到。
一、可定制的IDE环境
U3D这种ALL IN ONE的设计思路，我在一个叫神咒的代码中见到过。 集所有编辑器于一身。 虽然神咒的编辑器不能自由扩展，但由于是公司内部的引擎，所以，它的使用，也很方便。 比如，在场景中突然想要对一个模型的材质进行编辑，则选中此模型，右键，弹出材质编辑器即可。 组件式思路，将这种关系变得更加紧密。 你都感觉不到自己在使用一个材质编辑器。 你会觉得，你是在操作这个模型本身。 它的材质，它的碰撞器，它的对象结构等等。
回想一开始进入游戏行业的时候，天天啃着代码。 当时觉得代码就是一切，各种认为很牛X的代码，都忍不住读上一番。 而随着时间的推移，特别是经过项目的洗礼后。 突然发现编辑器是多么的重要。 就我做的第一个页游来说，起手前两个星期，我们就做了动画编辑器，场景编辑器。而最终证明，因为这两个简陋的编辑器，使我们后面的工作变得更加容易。
因此，一个好的引擎，必定得先有一个功能完备的编辑器。
二、基于Mono的开发脚本
C/C++无疑是图形界的宠儿，也没有人想过用另一种语言来替代它。即使是U3D，亦是如此。 但是，早期使用C/C++编写的引擎，都理所当然地使用C/C++来作为上层
逻辑的开发。 又有一些，采用了纯脚本的模式。比如Python,LUA。 脚本的好处在于更低的编码成本（经过仔细研究，我发现，这是由于写脚本语言的心态和写C++的心态导致的。 写C++的时候，总是想着代码的复用度，而在脚本的时候，很多时间会认为，这个脚本，就是为这个对象服务的，那我就按照策划需求来写就可以了。 我想，这也是许多时候，脚本语言存在的意义。特别是早期引擎中，使用脚本来处理一些关键的事件响
应）。 而大家熟知的虚幻引擎以及有一个名不见经转的Torque，则自己整了一套开发语言。 我想，它们的目的，就是为了使大家能够以一种更安全的方式来编程， C++一不小心，则会带来内存和效率问题。 它的使用成本，人员成本其实是高于其它语言的。 Mono C# JS,BOO的出现，再一次让大家的眼睛一亮，原来，引擎可以这样整。
Mono的桥接，使得高效的C++图形引擎与带GC的内存安全语言进行结合。不仅减少了安全隐患，也使得大家编写跨平台代码时更佳容易。 同时，这类语言的反射机制，更适合做编辑器。而比起先前的一些DIY语言和像LUA这样的小巧型语言，Mono使脚本编程可以进行DEBUG，而不单纯的靠PRINT输出。文章出处【狗刨学习网】
这里就顺带说一下三个语言的区别
C# 这是我见过的大型项目中使用得最多的语言，也是我比较喜欢的语言。 因为它和C++很像，同时严格的类型和语法检查。
JS 在帮一些朋友做小东西的时候，使用过这个语言，由于mono自带的提示功能，写起来还是挺顺手。 但总给我一种摸不着头脑的感觉。 并且U3D给的JS，不是严格的JS，有些语法不支持，而有些语法又很特别。
BOO 完全没有使用过，貌似也很少有人使用。
三、基于组件的对象系统
这是一个我最喜欢的系统，我也使用irrlicht引擎山寨过，山寨的过程中，几乎看完了它的组件参考手册，使我对U3D引擎的组件系统又有了新的认识。 同时，目前公司自主研发的引擎，也是这样的思想。 不管我是在工作中，还是业余捣鼓都受组件系统的影响。 慢慢的，喜欢上了这种对象模式。
之前在做一个RTS游戏项目的时候，参考了著名开源项目 0.A.D的代码。 当时只是为了去寻找LOS和多单位协同寻路的方案。 但在参考其代码的时候，发现了它整个系统，都是基于组件式的。又一次，对组件式有了好感。 而经过仔细思索后。 回到了我一直坚持的子系统划分法的游戏框架。 当我不禁感叹，原来，自己也一直是在组件式。 只不过，我的组件式，是MANAGER方式，MANANGER内部进行对应的实体管理、。 比如，背
包系统，则只负责玩家背包数据，背包使用，背包相关的功能。 不管是数据存储，还是与前端通信，都是背包系统自己在负责，其它模块完全不需要干涉。 而U3D中的组件系统，则将这个粒度划得更仔细了……。 这对于早期的像OGRE的entity系统。仅仅是认为对象可以由子对象构成，可以说是一个质的变化。
早期的引擎，基本上都是继承优先的设计方案，更多时候考虑的是编码的便利性，且引擎的走向都具有针对性。 而当面对一些复杂情况的时候，继承式的编码是十分麻烦的。 并且，对于JAVA,C#这样的语言，并没有提供多继承能力。 因此，继承式的编程，在面对越来越广泛的游戏需求的时候。显得无能为力。 组件式则是一种聚合优先的编码方式，它的复用度和伸缩度，都远远大于继承。 唯一让一些C++程序员觉得不太顺眼的，可能就是过多的变量和虚函数调用开销吧。 但这些，在当下来说，都不是问题。 影响大众步伐的，早已不是那种语言特性本身导致的开销。更多的，是如何使我们高效率，高质量地完成一个游戏。 因此组件模式已经成为必然。 从新版的UE4的变革，以及畅游的G3D，国外一个开源的godot引擎，就可以看出来，大家对组件模式，已经有了深深的好感和接受度。
四、所见即所得
这可以说是许多人最喜欢的特性，这也是G3D群里，问的人最多的特性，三天两头就有人问，G3D能不能像U3D一样在编辑器里预览游戏效果呀。
U3D除了编辑后立即运行，还能在运行过程中时实编辑，查看效果。当然，运行过程中编辑对象的数据，会在停止后失效。（注意，对文件属性的修改，不会失效）
五、代码驱动的开发模式
这种模式，可以使我们快速地构建一个原型。 对于U3D中的MonoBehaviour来说，它扮演的，就是如何驱动它的目标对象。 因此，你可以将你的对象的各种能力分配到不同的脚本组件中，然后根据对象的需求来挂接。
六、多平台发布
U3D支持的平台，无疑是当下较为流行的平台。 满足绝大部分项目需求。 早期的引擎，多以PC和CONSOLE为主。 支持WINDOWS,XBOX,PS2已经是很不错了。 U3D便利的多平台发布特性，也使得它成为了当前性价比最高的引擎的原因之一。
也有许多公司正在自主研发引擎，或者是将先前的PC引擎修改为多平台
（IOS+ANDROID居多）。 但这也档不了U3D的步伐。
七、良好的生态圈
在使用公司引擎的时候，我就发现，若我遇上一个问题，只能问公司的老员工们，或者找其它引擎TEAM寻求帮助。而Unity这种生态圈，不是一天两天能形成的。
GOOGLE,百度，各种论坛，都能很容易找到自己想要解决的问题。 而对于一些经验上的问题，也有不少人总结。 这使得后来者，可以快速上手引擎。
而AssetStore的出现，不仅使U3D的生态圈更加稳固，同时也提供了许多机会。 你可以制作插件放网上卖，赚取一些利益，也可以购买别人的插件，作为使用或者参考也好。 有时候，购买一些插件，可以让你快速脱离当前的困境。 一个是解决进度问题，一个是解决思路问题。 这是之前其它引擎不具备的。
第三篇：域管理优点总结
公司电脑使用域管理的优点
一 工作组与域的区别
现公司所有电脑采用工作组的管理模式，域管理与工作组管理的主要区别在于：
1、工作组网实现的是分散的管理模式，每一台计算机都是独自自主的，用户账户和权限信息保存在本机中，同时借助工作组来共享信息，共享信息的权限设置由每台计算机控制。在网上邻居中能够看到的工作组机的列表叫浏览列表是通过广播查询浏览主控服务器，由浏览主控服务器提供的。
而域网实现的是主/从管理模式，通过一台域控制器来集中管理域内用户帐号和权限，帐号信息保存在域控制器内，共享信息分散在每台计算机中，但是访问权限由控制器统一管理。这就是两者最大的不同。
2、在“域”模式下，资源的访问有较严格的管理,至少有一台服务器负责每一台联入网络的电脑和用户的验证工作，相当于一个单位的门卫一样，称为“域控制器（Domain Controller，简写为DC）”。
3、域控制器中包含了由这个域的账户、密码、属于这个域的计算机等信息构成的数据库。当电脑联入网络时，域控制器首先要鉴别这台电脑是否是属于这个域的，用户使用的登录账号是否存在、密码是否正确。如果以上信息有一样不正确，那么域控制器就会拒绝这个用户从这台电脑登录。不能登录，用户就不能访问服务器上有权限保护的资源，他只能以对等网用户的方式访问Windows共享出来的资源，这样就在一定程度上保护了网络上的资源。而工作组只是进行本地电脑的信息与安全的认证。
二 公司采用域管理的好处
1、方便管理,权限管理比较集中，管理人员可以较好的管理计算机资源。
2、安全性高，有利于企业的一些保密资料的管理，比如一个文件只能让某一个人看,或者指定人员可以看,但不可以删/改/移等。
3、方便对用户操作进行权限设置，可以分发，指派软件等,实现网络内的软件一起安装。
4、很多服务必须建立在域环境中，对管理员来说有好处:统一管理,方便在MS 软件方面集成,如ISA EXCHANGE(邮件服务器)、ISA SERVER(上网的各种设置与管理)等。
5、使用漫游账户和文件夹重定向技术，个人账户的工作文件及数据等可以存储在服务器上，统一进行备份、管理，用户的数据更加安全、有保障。
6、方便用户使用各种资源。
7、SMS（System Management Server）能够分发应用程序、系统补丁等，用户可以选择安装，也可以由系统管理员指派自动安装。并能集中管理系统补丁（如Windows Updates），不需每台客户端服务器都下载同样的补丁，从而节省大量网络带宽。
8、资源共享
用户和管理员可以不知道他们所需要的对象的确切名称，但是他们可能知道这个对象的一个或多个属性，他们可以通过查找对象的部分属性在域中得到一个所有已知属性相匹配的对象列表，通过域使得基于一个或者多个对象属性来查找一个对象变得可能。
9、管理
A、 域控制器集中管理用户对网络的访问，如登录、验证、访问目录和共享资源。为了简化
管理，所有域中的域控制器都是平等的，你可以在任何域控制器上进行修改，这种更新可以复制到域中所有的其他域控制器上。
B、 域的实施通过提供对网络上所有对象的单点管理进一步简化了管理。因为域控制器提供
了对网络上所有资源的单点登录，管理远可以登录到一台计算机来管理网络中任何计算机上的管理对象。在NT网络中，当用户一次登陆一个域服务器后，就可以访问该域中已经开放的全部资源，而无需对同一域进行多次登陆。但在需要共享不同域中的服务时，对每个域都必须要登陆一次，否则无法访问未登陆域服务器中的资源或无法获得未登陆域的服务。
10、可扩展性
在活动目录中，目录通过将目录组织成几个部分存储信息从而允许存储大量的对象。因此，目录可以随着组织的增长而一同扩展，允许用户从一个具有几百个对象的小的安装环境发展成拥有几百万对象的大型安装环境。
9、安全性
域为用户提供了单一的登录过程来访问网络资源，如所有他们具有权限的文件、打印机和应用程序资源。也就是说，用户可以登录到一台计算机来使用网络上另外一台计算机上的资源，只要用户具有对资源的合适权限。域通过对用户权限合适的划分，确定了只有对特定资源有合法权限的用户才能使用该资源，从而保障了资源使用的合法性和安全性。
10、可冗余性
每个域控制器保存和维护目录的一个副本。在域中，你创建的每一个用户帐号都会对应目录的一个记录。当用户登录到域中的计算机时，域控制器将按照目录检查用户名、口令、登录限制以验证用户。当存在多个域控制器时，他们会定期的相互复制目录信息，域控制器间的数据复制，促使用户信息发生改变时（比如用户修改了口令），可以迅速的复制到其他的域控制器上，这样当一台域控制器出现故障时，用户仍然可以通过其他的域控制进行登录，保障了网络的顺利运行。
域管理的作用
企业 企业内部网络以及信息系统的管理会更安全，更灵活，管理成本会进一步降低。
管理员 劳动强度工作量下降，管理复杂性降低，IT管理策略措施更灵活、更快捷、更安全。
客户 使用体验增强，满意度提高，工作效率上升。
域管理的方法和效果
1.帐号集中管理 所有帐号均存在服务器上,方便对帐号的重命令/重置密码
2.软件集中管理 利用软件发布策略分发软件,可以让用户自由选择安装软件
3.环境集中管理 利用AD可以统一客户端桌面,IE,TCP/IP等设置.
1.控制网络，员工不能想干嘛就干嘛，可提高员工的工作效率
2.网络比较的安全，资料统一管理不易丢失或者不易被窃
3.监控网络，使网络速度合理分配，
4.统一部署杀毒软件和扫毒任务，避免电脑系统经常崩溃，既节省开支，又不影响工作
5.集中化管理，公司文化更易传播，更规范合理，让客户看到咱们的一体化和信息化建设如此强大
6.合理的机房设施也是公司向客户承诺一种信息、资料是安全，可靠的信号
三 公司域的详细规划
下图为域建设图：
1、公司采用单域单站点管理模式，建设AD与BAD，即主域控器与备份域控制器，在其下面采用OU（组织单元）的模式进行集中管理各部门人员与电脑。此种管理模式，成本降低，且减少管理复杂度和维护量。
2、AD(主域控制器)：公司所有权限管理，用户建立以及各种策略、软件等的管理及实施到每台电脑。
3、BAD(备份域控制器)：采用与AD完全相同的设置，继承AD上的所有管理资料，防止AD出现故障后，公司电脑无法登陆AD和使用网络资源，在BAD服务器上，建立资源共享文件夹，即File server，进行公司种文件的共享和使用，将BAD服务器做成WSUS服务器（windows补丁服务器），管理公司所有电脑的补丁的下载与提供安装的服务，如有需要还可集成ISA SERVER服务器，进行公司网络的管控（上外网的的控制）。
现企业当中有电脑500台左右，有200台在澳门，200台在中山，另外有100台电脑分布在其它三个城市，中山与澳门是通过384K的IPLC专线连接，其它各个分部是通过VPN进行连接，不稳定。现此网络环境需要布署设计域环境。 要考虑以下问题：
1．活动目录的总体如何规划？
2．域控制器及OU如何命名？
3．中山的域控制器与澳门及其它各个分部的域控制器如何进行同步？
4．如何利用组策略来管理OU？
6．DNS，DHCP，WINS，RIS如何应用？
不知大家是如何设计布署及考虑相关问题的。
首先,这个规模的AD不是一个很大的case,所以不要感觉很复杂,很难,其实等你做完了,你发现也就不过如此.
总体规划,你们各个分支机构的技术力量不是很强,所以还是不要用父域-子域模式了,就用一个域好了.因为澳门,中山直接有稳定的专线,所以可以把他们2个地方当作一个地方来看,各部署一台DC好了,当然如果你们机器多,可以多部署一台,其他3个城市,每个地方部署一台dc,然后做site,这样分支机构登录速度有保证的.
DC和OU的命名和规划,这个每个企业的组织架构和使用方法不一样,所以没有什么定式的,怎么方便,怎么好管理就怎么用.
DC的同步问题,在win20xx里面,AD的同步做的很好了,如果你没有很大的改动的话,每次同步的数据流不是很大,所以不要为这个太担心. 如何用组策略管理OU,不明白什么意思?怎么方便怎么管理,呵呵.
至于其他的DNS,DHCP等,根据自己的实际情况应用,没有什么一定的,当然DNS是一定要有的.