点击塔防项目总结（一）（二）（三）（四）
其他
2019-04-23 19:13:35
阅读次数: 0
主要内容如下
- 数值不要太变态，如果自己做配置，留给自己配置的项目越少越好啊
- 想办法活下去才有希望
- 进一步熟悉使用QF
- 项目一开始就放在github上
- 要注意继承的代码规范的后缀，GUI也是用后缀，并且不用下标
- 字体组件在QF种积累
- Hierarrchy面板下命名的规范
- 项目种勇于尝试c#语法
- 脚本文件原则下数量越少越好
- 一般来讲遵循迪米尔法则，类之间沟通用方法
- 初始和回收用spawn despawn;
- 用.length-1做最后索引
- 重构函数包括改名字啊
- 重要而且感觉容易出错的代码做好单元测试
- update可以多写点逻辑
- 函数命名为Hierarrchy面板为基本，所以命名不能乱命
- 所有集合命名都要带s,命名就是英文加数字编号，别整ABCD
- 用Array.IndexOf()索引前提是数组元素都无重复，就这样用，方便修改
- 被动接受功能的物体，不需要有功能脚本，交给主动的物体
- 别注释todo了，
- 特效实例化的顺序：枪口特效 ->子弹飞行特效 ->飞出音效 -> 击中爆炸特效 -> 爆炸声音音效 -> 死亡特效 -> 死亡声音特效
- 寻求温度的软件版本，一般来讲用晚两年的软件
- 组件和低耦合的重要性
- 属性种不要用属性,属性的初始靠字段
- 母体工作流，先做成母体，然后覆盖现有的，库文件优先级第一，项目次之，资源管理同理，功能组件也这么来做哦
- 继承的深度，最多两层，特例3层
- UI用MVC相关架构， GamePlay用组件方式，感觉必要时候用继承方式
- 重构思路，精简代码，做模块化，做子系统
- 枚举最好做一个Null值
- json初始默认值全面装满数据方便测试
- 跨项目变量命名用readOnly
- 初始化和回收之间的关系是初始化设置数据 回收垃圾数据 倘若初始化不管用 回收函数再捡漏处理 awake和start同理实施
- 初始化单例、初始化各核心模块、并统一在这里设置各个脚本里需要的引用关系
- 尽量不要在Awake()、Start()里做操作
- 需要out太多东西时候，就要用类或结构了
- 装备的属性别做字符了，拿类的来做
- 一切索引用0开始
- Update Start Awake 做成虚方法更灵活吧
- 类图千万别心急啊，认真做，弄漂亮
- 声音的门面类很重要
- 关卡场景需要大预制体，但是呢有些不适合预制体,不是绝对啊
- 策划案用word来写啊
- 未来方向3D游戏,盈利捐部分钱公益,
- 游戏状态机逻辑写在属性，分散到处都是有点乱啊
- 数据传递规则是在一级的时候能得到值就在那里得到
- 函数里代码要紧凑，按照函数单一原则做成小函数和先后顺序写在大函数里，避免变量值顺序不同bug
- 主要场景命名First
- 为了体现buff，不建议做在属性里相加，而是在客户端的调用方法的参数里直接相加会好点把
- hierachy面板也要做管理
- 脚本式组件命名要公立一点
- 拖住不放就自动切图了很随意的
- 人脉的重要性，认识圈子里大佬
- FGUI能解放双手？
- Quaternion.Lerp(Quaternion.Euler(new Vector3(0, 0, 0)), Quaternion.Euler(0, 0, 90),Time.time * 0.1f);
- 销毁对象函数都叫RecycleObject，需要传递数据或者初始函数都叫NeedData
- 回收对象的墙一律起名字叫RecycleObjectWall,预制体也可以防御工具库里面，所以说一切可复用都要进行下去
- 后期统一了技术选型，再把框架做到极致和健壮，哪怕违背脚本主动原则
- 代码模板2017
- 字段和属性在类下面都不要赋值这样看起来很乱啊
- Manager下面是子系统->名字+“SonSystem” ->名字+“GrandsonSystem”
- 配置开始的时候就全部加载完啊
- 分清GameLevel和SceneLevel 避免混淆啊
- 最重要一条，地图数据除了用tileMap还可以用数组来生成，提高工作效率
- 对象有两种死亡方式的时候统一建议做成Hp减少，通过Hp属性来调用共同的一些函数
- 逻辑分散是罪恶根源，一切对外接口都是方法，自己写的库其实很靠谱，关键还得多累积组件，方便日后开发呢
#if 编辑器宏不要用了，因为不方便重构
转载自blog.csdn.net/qq_37811712/article/details/89357575