游戏经验总结
- 战斗相关经验总结
- 任务
- 演出剧情
- 红点
- 多渠道管理
- 触发器
- AI
1. 战斗相关经验总结
割草类游戏
参考之前的每周总结，其中一些点其他类型游戏应该适用
主要就是
逻辑和表现分离
逻辑完全独立于表现
属性和被动双设计
属性只用作必要的地方（比如攻击，血量，伤害等），其他地方靠被动触发来做
怪物动画走序列帧或者Spine动画
序列帧性能最好，Spine可以节约资源
技能搜索走过滤器设计模式
技能设计要考虑属于不同宿主的情况（人物技能，宠物技能），可以直接引用所属实体对象
场中的实体对象都应该由状态机控制（主要是怪物和人物，技能倒还好）
2. 任务
最近一个项目在设计主线任务的时候，任务状态控制完全由客户端来判断和转变的，判断是否可以完成以及当前进度也是客户端来做的，这会导致各个任务的完成条件变动时候要触发任务表现刷新下，这会增加客户端代码的复杂度。同时这种模式不支持计数型任务。
正确来说任务状态转变控制可以由客户端来驱动，比如客户端需要有个交任务过程，但是任务的计数变动都由服务端用触发器来做，并实时下发变动到客户端，客户端只需要监听任务变动事件来驱动表现刷新即可。
3. 演出剧情
TODO
4. 红点
之前写过一篇红点总结
5. 多渠道管理
参考之前的每周总结
- 自动打包
- 统一的配置后台
- 除了配置后台统一以外，其他的功能包括（账号，充值，事件等）都下沉各个游戏项的服务器功能到各个游戏，方便管理
6. 触发器
TODO
除了触发器，每个模块在需要时候还是应该要有回调接口。触发器适合用在那种需要配表支持的并带有计数的情况，比如玩家生命周期内的触发功能，任务，成就等，而一些有限范围内的功能还是走回调方便，比如一些模块受到月卡开启和关闭时候的一些处理，一些模块在等级升级时候需要进行一些处理。但是这种感觉大部分也能用触发器替代，能不用就不用吧。
7. 人物AI
放服务端控制，除非纯单机
8. 属性模块设计
- 考虑多种类型属性，需要自动恢复的（血量，蓝量），可以设置值也可以设置百分比的属性（对外是算出来的一个值），单一属性
- 设置属性的时候增加来源，来源最好两级，包括大模块（整数），具体key（字符串），比如装备模块的具体的某件装备Id