Unity开发实战经验分享

vvvvvvyb

本课程主要记录了笔者项目初期碰到的并值得一说的实际业务问题，涵盖了比较多客户端框架设计的内容，以及有效提升开发者编程体验的内容。
主要包括以下内容以及一些其他配套的小工具。

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

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

1｜ Luban Excel配表工具使用推荐及总结
2｜ 基于ECS设计下的加载管理
3｜ 对资源的规范化我们能做什么
4｜ 如何设计本地化组件
5｜ C# Task指南
6｜ 如何设计技能系统
7｜ Unity Andorid多渠道管理
附录1｜ 一些关于代码积累的记录
附录2｜ 如何设计角色属性组件
附录3｜ CliToolkit工具
附录4｜ ET Entity Tree 工具
附录5｜ 内网Package管理
<hr/>本篇转载自《Unity开发实战经验分享》的第1节。
几乎每个游戏的制作过程中都少不了和配置打交道的需求，有的是用Unity自带的ScriptObject进行存储，或者更多的是使用Excel等表格工具，二次导出配置文件等。
每种方案见仁见智，依照不同的使用场景各有优劣。

一般来说数据的输入都是由策划来完成的，而大部分策划非常倾向于使用Excel作为日常配置使用的工具，尤其是在需要批量拉表的场景下，其他的方案在这个场景下与Excel几乎没有任何可比性。

相关链接

Luban 仓库地址
Luban 官方示例
Luban 官方文档
Luban 简单示例
Luban 简单文档
Luban Unity GUI 工具
<hr/>为什么使用Luban

如果项目中使用Excel作为配表的载体，大部分都会选择使用相关的导表工具，可能是项目自己开发，也可能是使用一些现成的工具，比如Git上tabtoy、excel2json等相关工具。
但是上面这些，包括大部分自己开发的导表工具，或多或少都会存在一些致命的限制，或者不够通用，亦或者不够灵活等等的问题。

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

而Luban是目前唯一一个市面上有资格成为行业配表标准的工具，未来也很难会有同类产品可以超越。
<hr/>核心功能介绍

数据有效性验证

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

有效性验证这个问题之前让我非常头大，经常出现策划跑过来找你说：“我这里程序有 bug，你检查一下”，然后花了半天时间查到了因为配表中某一行的id或者关键数据填写不合法。
一次两次还可以，次数多了难免心态不好，尤其当人员发生变动，新来的人无法完全理解每个值的意义，就很容易放飞自我，最终就是事故，而这些问题是可以从源头有效切断的。

如果你项目中配表的内容存在某个地方需要相关人员记住应该怎么配，而没有相关自动校验，那么这里假以时日一定会出问题。

工具支持的校验器如下：


当然，一个游戏的开发如果需要完整校验所有配置的合法性，上述这些校验器是无法完全满足的，或者说这些复杂场景不应该由Luban来解决，所以针对这些场景，在官方示例中有一个CfgValidator来处理这种问题。


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

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

在我整理的Luban 简单文档这个文档里面包含了模板具体生成的介绍，可以加速你理解如何自定义模板。在Luban现有的设计下，几乎可以兼容任何场景（包括老项目的迁移）。
复杂类型的填写
在这个仓库中，Luban 简单示例的多态示例中可以很直观地看到继承相关的复杂类型应当如何在Excel中展开和填写。

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

Luban支持任意复杂数据结构的嵌套，只有在代码中能定义出来，Luban就能解析，但是在实际使用中，并不推荐使用非常复杂的数据结构，这样会给策划带来额外的填表负担，以及部分场景下的代码生成的额外工作量。
数据及定义过滤
一些定义只需要在客户端使用，或者只会在服务端使用，需要在生成时进行动态剔除，当然这个功能，一般的配表工具也都支持，但Luban额外考虑到了一些场景，比如这一条数据需要临时注释或者仅在测试环境下使用。

这里的 test就非常有用，我们会单独配置一套test数据，用于游戏中的核心逻辑验证，及测试用例的辅助配表，而这些数据不会出现在正式环境下。

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

如果是一些老的项目需要迁移，也是一个非常合适的场景。

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

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

其他
Luban支持的序列化格式、语言和场景非常多，这里不一一介绍了，仅对我目前使用中碰到的核心功能进行介绍。
<hr/>流程推荐

下面提到的内容在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不需要重开游戏就可以直接加载到新配置。
<hr/>以上就是《Unity开发实战经验分享》的第1节，此篇文章比较适合从事游戏行业的开发人员、对Unity开发感兴趣的同学以及希望提升底层设计能力，解决实际业务痛点的读者。
读完全篇后你会深入理解如何实现实际业务需求，提升底层设计能力以及部分文章的配套Demo。