关于unity:Unity开发实战经验分享

本课程次要记录了笔者我的项目初期碰到的并值得一说的理论业务问题，涵盖了比拟多客户端框架设计的内容，以及无效晋升开发者编程体验的内容。

次要包含以下内容以及一些其余配套的小工具。

• Luban 配表工具的应用介绍
• ECS 设计下的加载治理
• 设计我的项目资源规范化
• 设计本地化组件
• C# Task 使用指南
• 设计技能零碎
• Unity Android 多渠道治理 

作者 L： 杭州某游戏公司客户端主程
从事游戏行业六年无余，目前次要在公司负责通用底层框架设计，及一款手游我的项目的客户端主程

目录

1| Luban Excel 配表工具应用举荐及总结
2| 基于 ECS 设计下的加载治理
3| 对资源的规范化咱们能做什么
4| 如何设计本地化组件
5| C# Task 指南
6| 如何设计技能零碎
7| Unity Andorid 多渠道治理
附录 1| 一些对于代码积攒的记录
附录 2| 如何设计角色属性组件
附录 3| CliToolkit 工具
附录 4| ET Entity Tree 工具
附录 5| 内网 Package 治理

本篇转载自《Unity 开发实战经验分享》的第 1 节。

简直每个游戏的制作过程中都少不了和配置打交道的需要，有的是用 Unity 自带的 ScriptObject 进行存储，或者更多的是应用 Excel 等表格工具，二次导出配置文件等。

每种计划见仁见智，按照不同的应用场景各有优劣。

一般来说数据的输出都是由策动来实现的，而大部分策动十分偏向于应用 Excel 作为日常配置应用的工具，尤其是在须要批量拉表的场景下，其余的计划在这个场景下与 Excel 简直没有任何可比性。

相干链接
Luban 仓库地址
Luban 官网示例
Luban 官网文档
Luban 简略示例
Luban 简略文档
Luban Unity GUI 工具

为什么应用 Luban 

如果我的项目中应用 Excel 作为配表的载体，大部分都会抉择应用相干的导表工具，可能是我的项目本人开发，也可能是应用一些现成的工具，比方 Git 上 tabtoy、excel2json 等相干工具。

然而下面这些，包含大部分本人开发的导表工具，或多或少都会存在一些致命的限度，或者不够通用，亦或者不够灵便等等的问题。

一个具备普适性的配表工具须要兼容的场景十分多，各种语言、自定义生成模板、数据反倒、数据有效性验证等等。

而 Luban 是目前惟一一个市面上有资格成为行业配表规范的工具，将来也很难会有同类产品能够超过。

外围性能介绍 

数据有效性验证

这里的数据有效性不是指 bool 的格子填了一个 int。

有效性验证这个问题之前让我十分头大，经常出现策动跑过来找你说：“我这里程序有 bug，你检查一下”，而后花了半天工夫查到了因为配表中某一行的 id 或者要害数据填写不非法。

一次两次还能够，次数多了不免心态不好，尤其当人员产生变动，新来的人无奈齐全了解每个值的意义，就很容易放飞自我，最终就是事变，而这些问题是能够从源头无效切断的。

如果你我的项目中配表的内容存在某个中央须要相干人员记住应该怎么配，而没有相干 主动校验 ，那么这里假以时日 肯定会出问题。

工具反对的校验器如下：

当然，一个游戏的开发如果须要残缺校验所有配置的合法性，上述这些校验器是无奈齐全满足的，或者说这些简单场景不应该由 Luban 来解决，所以针对这些场景，在官网示例中有一个 CfgValidator 来解决这种问题。

生成模板
一个合格的配表工具该当兼容自定义生成代码性能，而 Luban 这里应用的是 scriban 的计划。

当你有代码定制需要时，99% 的场景不须要改代码生成工具的源码即可实现定制需要。

在我整顿的 Luban 简略文档这个文档外面蕴含了模板具体生成的介绍，能够减速你了解如何自定义模板。在 Luban 现有的设计下，简直能够兼容任何场景（包含老我的项目的迁徙）。

简单类型的填写
在这个仓库中，Luban 简略示例的多态示例中能够很直观地看到继承相干的简单类型该当如何在 Excel 中开展和填写。

配表反对继承在很多游戏开发场景中十分十分受用，比方游戏中的道具、配备和英雄类的定义肯定存在共用数据结构和特化的数据结构等，如果没有继承这里的代码会十分难看，而且配表填写的内容也会成为劫难。

Luban 反对任意简单数据结构的嵌套，只有在代码中能定义进去，Luban 就能解析，然而在理论应用中，并不举荐应用非常复杂的数据结构，这样会给策动带来额定的填表累赘，以及局部场景下的代码生成的额定工作量。

数据及定义过滤
一些定义只须要在客户端应用，或者只会在服务端应用，须要在生成时进行动静剔除，当然这个性能，个别的配表工具也都反对，但 Luban 额定思考到了一些场景，比方这一条数据须要长期正文或者仅在测试环境下应用。

这里的 test 就十分有用，咱们会独自配置一套 test 数据，用于游戏中的外围逻辑验证，及测试用例的辅助配表，而这些数据不会呈现在正式环境下。

数据反倒
有时候会有这种场景，我的项目一些配置须要在 Unity 等游戏引擎中实现，可能是一些技能的配置等，这个时候就可能须要反倒数据。

如果是一些老的我的项目须要迁徙，也是一个十分适合的场景。

本地化
只有是配表工具，就肯定绕不开本地化这件事，Luban 同样也提供了本地化的解决方案。

这里值得一提的是，Luban 会将所有未退出翻译表的 key 独自输入到指定的文件中，不便查看。

其余
Luban 反对的序列化格局、语言和场景十分多，这里不一一介绍了，仅对我目前应用中碰到的外围性能进行介绍。

流程举荐 

上面提到的内容在 Luban 简略示例仓库中都能够找到相干代码。

导出脚本抉择
集体比拟举荐实用 sh 作为我的项目通用导表工具，Windows 须要配置 sh 文件默认应用 git bash 作为打开方式即可。

这里次要思考的是平台兼容性问题，比方开发环境中可能有人应用的是 Mac 也可能是 Windows，然而在部署时大部分都是 Linux 服务。如果每个平台独自保护一份脚本，加上不同环境和应用场景，这里对应的文件数量就比拟离谱了。

test、dev、release
倡议我的项目依照这种形式来划调配表：

• test

  • 仅在测试用例、Editor 下应用

• dev

  • 仅在开发环境下应用

• release

  • 仅在正式环境下应用 

auto_validation
首先，咱们并不心愿策动推送一个曾经被主动流程检测出谬误的提交，此时须要对 Git 进行 Hook，外围就是提交时本地查看一遍，如果有谬误，禁止本次 commit，将这种低级谬误扼杀在源头。

watch
个别可能会有这种须要对配置热重载的性能，应用 watch，配合本人我的项目中的热重载就能够做到这边保留 Excel，Unity 不须要重开游戏就能够间接加载到新配置。

以上就是《Unity 开发实战经验分享》的第 1 节，此篇文章比拟适宜从事游戏行业的开发人员、对 Unity 开发感兴趣的同学以及心愿晋升底层设计能力，解决理论业务痛点的读者。

读完全篇后你会深刻了解如何实现理论业务需要，晋升底层设计能力以及局部文章的配套 Demo。