Unity ID
[ARPG笔记] 1.~30.阶段性重点总结

CoParks
游戏爱好者/在读研究生
阅读 234
2022年8月2日
重点思想和知识点总结
换装系统核心
换装系统核心在于替换mesh网格和材质来实现部位、颜色的自定义切换，由此引发出了资源的分包动态加载、UI交互逻辑。
UI窗口的搭建
1-6节是对换装UI的搭建，这里需要注意的是，颜色选择器和UI窗口仅作为素材导入，与换装系统的实现无关。其中第5节通过摄像机将模型映射到Image组件的Texture上用于在UI中展示。第6节完成了模型拖拽旋转的事件响应添加，使用了框架中的事件工具。
部位配置
对所有可切换的部位进行配置，首先定义了职业类型（ProfessionType）和部位类型（CharacterParType）的枚举类型，再定义所有部位（Hair、Face、Cloth）的配置基类（CharacterPartConfigBase），其中配置基类已经声明好了所有部位都有的属性（名称，网格，支持职业，部位类型），每种配置类通过SO可视化配置并定义自己特有的配置（如颜色Index，特殊网格），这里需要说明的是，配置所定义的属性根据实际开发而定，本案例使用颜色Index的原因是素材材质球改色的特殊性导致。
因此，重要的是如下四步：
定义切换逻辑的枚举类型
定义切换逻辑的配置基类
定义切换逻辑的配置子类
SO可视化出配置实例
最终换装的逻辑中，根据配置中存储的Mesh网格和材质颜色索引实现切换，因此实际AA管理的资源就是各个配置的SO实例。
UI事件响应
这里可以将整个UI响应的过程分成两层：UI的MVC和玩家模型的MVC。 以职业切换为例，当点击ProfessionButton时产生事件触发，经由当前窗口（UI_CreateCharacterWindow）的脚本类完成UI的响应，再调用玩家模型的Controller完成动画切换并进一步调用玩家模型的View完成网格切换。 这里需要说明的几点是：
在本案例中，UI的MVC集成在一个代码脚本中，实际上是可以在UI窗口上分开写两个脚本的，但一般没必要，且可以通过第二点来尽量避免UI窗口类持有过多的UI组件，以Controller发挥的作用为主。
在职业切换的逻辑中，每个按钮身上的脚本（UI_FacadeMenus_Tab）只负责鼠标事件的触发、音效、按键效果，相应的职业切换逻辑需要交由上层窗口（UI_CreateCharacterWindow）进行复杂功能的处理（通过把自己传给上层窗口），这样做上层窗口通过持有一个下层窗口的实例就可以获取子窗口所有数据，而不必持有子窗口的UI组件，在理想情况下，UI窗口类本身只做与外界数据（比如玩家模型）交互的高级功能，每个子窗口也可以只专心实现本层级下的逻辑。
尽管第二点的分层可以简化顶层窗口的逻辑，但需要额外注意在顶层窗口加载时对其每个子窗口进行数据的初始化顺序，避免出现子窗口之间调用数据为null的问题。
玩家模型Controller和View层分成了两个代码，但可以发现的是Controller实际作为一个空物体的脚本独立于玩家模型，这么做一方面可以通过Controller的单例快速获取到玩家的View层模型数据，同时在这个场景对玩家模型的一些操作逻辑如拖拽、动画切换并不会带到下一个场景中，且View层里面封装好了与模型数据直接相关的修改逻辑（如网格切换，材质改色），可以在下一个场景中由新的Controller直接调用。
AA与配置资源的加载和释放
由于配置资源按照规则命名，可以通过部位类型枚举、索引编号从AA中获取配置文件，但在本案例中，额外包了一层确定哪些配置允许在自定义角色窗口界面使用的逻辑，所以实现时不能再直接拼名字从AA中获取了，要先在配置列表ProjectConfig中确定当前职业类型对应的可以用的配置索引，再去AA中获取。
在UI窗口中获取每次获取配置都要从AA中获取一个资源，对应就要有一次释放，实际上配置可以直接从Player_View层获取，让其持有配置列表即可。
在切换部位和检查职业有效性时，都要从AA中获取配置，在检查完毕后和切换到新的配置时都要进行资源释放。
与具体逻辑相关的BUG
注意职业切换时不同职业对部位是否支持的检查，材质在使用前需要先实例化，颜色的同步，UI和模型是否同时刷新等。
程序
ARPG
发布于技术交流