物品管理系统
游戏中物品管理普遍存在，各类物品的解锁与默认配置以及切换是物品管理的基本功能， 物品管理还需要支持各种物品的体验与限时免费，除此之外对于物品的获取需要记录日志系统，对于获取的量需要进行监控报警， 为而在客户端都会有物品配置的UI或场景，这些部分共同构成了整个物品管理系统。由于限时与体验物品， 导致客户端需要能够在到期后更改物品UI表现，因此物品管理系统各个部分都有紧密的联系， 具体的结构如图：
图1. 物品管理系统结构图（部分主要接口）
物品管理器， 主要具备物品的更换接口、解锁接口、锁定接口、与使用权回收接口、物品解锁状态查询接口（正常解锁、体验卡解锁、限时解锁等）、物品可使用性查询接口等，通过客户端与服务端的同步连接其它环节，在服务端通过连接物品投放接口进行物品投放，而所有物品， 通过物品投放接口通过物品的投放进行日志与检测的报警。
服务端与客户端通过物品管理器进行物品信息的同步， 对于客户端的请求服务端会进行验证， 验证合法后， 首先会更新数据、组队时通知队友等，接着会通知客户端进行验证生效， 可以进行更改， 改变的内容无非是更新数据、更新UI、更新模型。 值得注意的是由于网络延时的问题，请求验证后UI表现已经时过境迁甚至关闭。 从上述结构可以看出采用的是UI驱动场景的方式。这种方式能够极大的解耦，场景无状态而由数据驱动确实是一直用解放场景的形式， 这种方式在场景管理器的场景切换也是极其有用的。
投放接口, 游戏中存在物品有多种类型， 有的是永久性物品，有的是消耗型物品， 还有的是经济系统物品，这样投放物品时不同的物品需要的参数个数不尽相同，基本上可以二元组（类型、数目）（类型、ID）和三元组（类型、ID、数量）进行表示, 可以在投放接口中注册具体的投放逻辑，而投放函数可通过匿名函数进行参数修饰进行统一化。这样投放接口可以兼容任何物品。
监控管理，按照需求一般会检测多种物品以及其各个获取渠道，尤其是经济系统的各种物品与渠道。 这样就有很多需要监控的内容，为了统一化与方便添加， 需要监控系统能够支持动态的注册添加，以便后边的扩展， 此外需要能够更新监控数据更新的接口， 以便监控数据的重置。
物品UI, 物品展示UI往往展示多种物品， 展示时多使用列表方式， 那么通过抽取公共函数能够极大的提高代码的复用性，实践中主要抽象出了，列表物品过滤接口、列表初始化接口、列表更新接口、列表清除接口、ITEM初始化接口、 ITEM点击公共接口、 物品切换接口、按钮显示接口、物品提示接口、 模型更新接口等。 此外物品较多时往往存在物品列表计算与刷新计算量较大的情况，可以采用延迟计算的策略不必在UI初始化的时候一次性计算所有物品列表的内容，而是初始化某种具体物品列表的时候进行计算，同样可以缓存计算结果， 这种惰性计算可以减轻UI初始化时的计算量避免卡顿。对于物品UI可以添加单例类， 该单例对象提供物品UI node 的接口， 计算物品获取渠道，提供物品基本信息等，这样就能够在客户端提供访问物品UI与基本属性信息的统一接口类， 不必在其它地方单独的进行计算与初始化， 提高代码复用， 方便统一的修改等。
物品场景， 物品场景尽量不要和UI进行绑定， 物品场景最好是无状态的，由场景数据驱动，持有场景数据类的对象可以操作场景进入任意状态，这样在场景切换是不会再回复场景时出现场景状态无法回复的情况。此外场景模型的加载需要进行异步加载， 往往存在UI驱动模型的更换， 用户可能会进行快速的切换导致异步加载需要取消之前未完成的异步加载， 此外遇到加载模型存在依附关系的需要保证异步加载顺序控制。依附类型的模型加载可以采取一种失物招领的形式，依附模型不进行加载而直接缓存id, 等到主模型加载出来在领取自己的依附对象， 这样可以保证加载顺序。