2017项目 review-message

游戏相关记录:（主要是一些项目经验的总结，记录一下方便查阅）

google-protobuf:

扩展 & 复合 & 引用，模块化业务逻辑，规范定义，减少相似度高的重复定义

sql table maker:

key (string) pk -- 自定义名称 eg:create_table_character

version (string) pk  -- 一般是时间戳就好 eg:20180101100000

desc (text)  -- 执行的sql语句

因为业务的扩张难免会修改表结构或者新增表，sql语句（包含key & version）放在一张xml或者其他格式的配置文件，最初的时候建立一张 table_maker表，服务器启动对version进行检查：select max(version) < x from table_maker where key = ''; true:exec sql 并且 insert 到 table_maker里面

这样子后期无需单独维护数据库的表结构

定时器：

wheel形式，如果是状态同步的服务，精度需要支持到至少300ms

如果定时器里面有 inc repeat time/modify caller param/release等操作，对于游戏战斗是很有用的

attribute：

每个属性包含：attribute_basic/attribute_abs/attribute_per basic一般是配置的基础属性，abs/per处理装备、战斗中对属性的修改

底层需要一个属性系统的模块，提供get/set/inc/dec/on_get/on_set等接口，规范、便捷上层接口的调用，on_get支持传入自定义的callback_function

但是这个结构一直没想清楚，想保证所有人可以把属性放到类最开始，但是又不想用define的增加阅读&调试成本

背包：

背包应该分为两层：slot（格子）、item（道具），所有资源类货币也属于道具

需要一个operator管理道具的add/remove/rollback/commit/auto_use/log_note，背包操作应该是事务性的，rollback/commit对于一笔业务需要多次操作背包很有必要

存储：

玩家enter memory分配db hash thread，之后相关这个角色的所有操作只在这一个线程进行，区别于hash(character_id)的方式，线程的分配更平均，并且，db操作需要key -> update memory data 这种方式，不然一个逻辑多次调用update tablex的操作数据库需要执行多次明显浪费

任务：

之前做的C风格的condition机制还算好用，但是如果可以需要对索引任务的关键值按级区分，比如第一级是触发类型，第二级是触发check用到的关键信息，这样子可以避免condition太多次？好像意义也不是很大，之后再考虑下

但是需要避免触发的时候在遍历玩家身上任务浪费的效率，任务很多的时候这里会是很大的开销

其他：

避免一个指针对象在多个结构、容器出现

避免指针作为容器的索引

鉴于上面两条需要避免的情况，对于关键对象，游戏内可以使用对象池的方式，对象池的索引作为该对象的object_seq_id，其他结构或者容器需要这个对象信息的时候，用object_seq_id转换成对象