我们的目标，首先是为逻辑开发程序员屏蔽掉底层细节。其次给他们提供简明易用，同时又可以扩展的类和接口。
那么对于游戏逻辑的开发者来说，游戏是什么？
对这个问题的答案，我是从话剧中得到的灵感。话剧是在一个布好景的舞台上，一些演员按照剧本作出的行为。游戏跟这个很类似，只是多了玩家控制这个因素，能做出动作的也不仅是演员，还包括许多其他有响应的物体。因此游戏基本可以定义成：在一个或多个舞台上，对象在玩家输入或AI的控制下作出的行为。
由这个定义，得到三个基本的类。舞台类Stage，对象类Object和行为类Action。以前的游戏许多是把行为作为对象的成员函数来实现，实践证明那样的设计不尽合理，更好的设计是把行为从对象中分离出来，用不同的行为组合来实现特定对象的功能。cocos2d本身就是这么设计的，这里沿用cocos2d的设计思想。因为存在很多行为，行为类Action实际上是个类族，有很多派生类。
为了管理舞台的切换和加载，增加一个管理类StageManager。
玩家输入和部分输出由UI控制。UI是个比较大的系统，难以用一两个类抽象，暂时先放到一边。
再加上网络消息管理NetManager，模块间事件通讯EventManager，以及程序启动和配置类Application，就基本可以满足游戏逻辑开发的全部需要。这些类可以屏蔽掉图形、线程和网络细节。剩下的数据库/存取盘相对要复杂一些，可以有类似Saver这样的类提供读写操作，但是具体读写哪些内容可能还需要逻辑层写相当数量的代码，没有想到比较好的通用方案。
这些类及其提供的接口，就是逻辑开发需要打交道的全部东西了。够不够呢？是否任何游戏类型的任何游戏逻辑，都可以用，并且只用这些类相关的词汇来描述？就我的经验来讲，应该可以满足绝大部分的需求了。
如果再进一步的话，道具，任务这种并非所有，但是很多游戏都会用到的系统，是不是可以通用化？这个已经超出了简单框架的范围，留着以后考虑。