Unity实用技能-协作规范总结

实用技能系列

1. Unity实用技能-UI滑动条技能总结

前言

本人是初入行的客户端开发，有许多协作规范需要记录

协作注意事项-策划

1. 策划经常脑洞大开，有些需求是实时出现，不会一一写在策划案里，所以客户端在代码设计的过程中一定要考虑很强的扩展性，防止策划临时加新需求导致代码大改的情况
2. 有时候策划给的配置表数据是不合理的，最典型的就是配置表数据索引过深，遍历整一个大表才能找到对应数据；能通过一个字段就索引到数据就最好，不能就只遍历一遍表，然后存起来用
3. 对于有些可能会改动删除的表也尽量不要索引去读，而是读那些只会增加数据的表，这样后续维护代码也比较方便

注意：我一个职场老前辈告诉我，不要信策划的什么不会删表项的鬼话，指不定他哪天就删了，然后报错了就让你解决

协作注意事项-原画美术

1. 通常来讲UI客户端是不需要和美术交流的，但还是会有一些情况需要交流
2. 比如在美术调整场景中的人物站位什么的就调整一下代码之类的

协作注意事项-动效

1. 动效与客户端交流无非就是动画怎么播，材质怎么换，层级怎么调整
2. 先说动画播放的规范，动画这东西最好就是动效自动调整播放，尽量不要让程序来主动播动画，除非是动效那边不知道播放的时机才由程序主动播，最大的原因还是考虑到游戏性能问题以及后续的维护
3. 材质问题很重要，在公司试用期的时光，我遇到过2类材质替换问题。一种情况是2D材质替换，就是特效为了实现刷光粒子效果去替换材质，但由于2D贴图的情况实在太多，不能创建多个材质球一一替换，而是让特效制作每个贴图对应的粒子预设，这样后续维护的时候才比较好。还有一种情况是3D材质替换，3D材质为啥可以替换，自然是和2D相对，3D物体是在场景中的，想换材质就写一个C#脚本，保存材质列表，然后加载对应的材质即可
4. 层级问题也是经常遇到的问题，以我的项目为例，项目中动效通常是调粒子的层级，但项目中UI主界面的层级会随着重复打开而升高，所以为了让动效方便调层级，都会加入项目前辈写好的层级脚本，原理就是以挂载脚本的节点作为Root，向上查找父节点层级，然后以这个层级作为标准来计算设置当前挂载脚本的节点层级；然后还有一个脚本也是类似的原理，只不过是拖动式的，是给我们客户端用的，同样是设置层级；这样基本就能解决层级问题

职场老前辈给的名言：有些时候不要给美术开那个便利的口子，否则这种效果会渗透到整个项目，对于项目后续的维护是毁灭性的

协作注意事项-服务端

1. 与服务端的交流比较简单，可能的问题就是在自我测试的时候交流查代码看看是客户端的代码逻辑问题还是服务端的代码逻辑问题，以及服务端协议的定义交流
2. 对于逻辑问题，一般都是客户端先查，查完发现数据不对，再让服务端看看是什么原因
3. 对于协议的定义，有些服务端的资历比较浅，没有考虑到数据之间的一对一，一对多等关系就想当然设置了协议字段，遇到这种情况一定要当面交流，说清楚数据之间的要哪些字段会方便后续维护以及读取，同时也要考虑以最小消耗的字段来发送，比如能发int就不发string
4. 有时候服务端也会误解策划的意图而错误地定义了数据，所以一定要和策划以及服务端沟通清楚，不然会导致自己的任务拖泥带水

协作注意事项-测试

1. 我这家公司的测试是纯测试，有时候测试会测出bug，项目又分为两个版本包，所以需要分别判断处理
2. 测试在测出bug时，会分为必现bug和偶现bug，对于偶现bug，一般是测试没有总计复现方式而出现的bug，不管是必现还是偶现bug，都应该先让测试总结复现方式再去处理，否则只会白白浪费时间，相当于测试的工作给你做了一部分
3. 在对外发布的版本包，有时出现bug是需要在模拟器上测试才会出现，一般就是图集问题，逻辑问题

总结

这是我入职以来经历的各种问题总结，总之就是协作很重要，协作通气可以说是必要的，只有协作后才能把握方向，大方向对了，你才能正确实现效果