思路描述##
考虑游戏设计模式的时候，很大程度上运用了单例模式的思路，保证一个在总的游戏流程中起作用的类只有一个静态实例，并且提供访问该实例的全局访问点。
很多时候我们想方便的直接响应游戏中的交互，比如处理一个技能造成的反馈，那么就必须要同时在不同的模块中进行注册，如果又要为了防止耦合问题，可能会倾向于用全局，但是这显然是不够面向对象的，所以单例在这里就是一个很好的切入点。
在很多逻辑架构上，配置好此类的基本模板，在团队协作中也是一个不错的方式，我们既可以去主动实现其他人预留的功能接口，也可以自己额外加入新的处理。
而对于同一个功能性数据类型，list容器用来充当数据库的作用，比如buff列表的管理，线性时间的插入是必须的。
模块花费##
在功能性数据类型的配置上是比较繁琐的，合理有效的配置好各种buff的参数或者技能组的要素，是一个偏体力的劳动。
另一方面，由于先要对底层数据逻辑进行构建，也不能保证一定能在实现的时候充分的进行利用。也就是说，即使完成整个游戏的基本逻辑架构，也不能说就可以在没有后顾之忧的前提下去设置这些参数。毕竟一旦出现问题，整个体系都要随之修改，但是如果不先写好一些功能，又难以找出对应的bug，所以我认为这方面的时间花费是比较大的。
过程中的问题##
首先显然是要有对新工具的学习和运用，由于我们团队采用的是Cocos2DX进行开发，代码规范和使用样例等方面在网络上都有比较完善的经验教程，虽然还是存在种种问题，但主要还是在花时间去学习架构。
但是由于实际上的沟通还是比较缺乏的，毕竟现在大家都很忙，所以对于队友搭建的工具部件，还是需要经常讨论细节，防止重复的功能代码和冲突，设计的时候保持低耦合。