就个人经验来说，这是个有趣而困难的问题.
不同处境的开发者往往习惯与从自身的开发处境出发，给出对架构以及模式的种种看法。轻量游戏，独立游戏开发者，对架构选择的权重会小一些，而对于项目前期规划严谨，开发人员众多的大型项目，架构的选择则重要得多。
总而言之，好的架构能力将降低你日后推倒重来的风险，所以，无论你的开发规模如何，请认真审视框架的设计问题，然后做出恰到好处的设计。
进入正题：
框架的宏观设计
- 数据层服务：管理好你的游戏配置数据以及应用层网络协议数据
- 状态转移控制：使用你的设计知识，提供足够抽象和清晰的游戏流程转移控制，推荐从工作流模式开始逐步学习并扩展，阅读《流转的永恒之道》
- 视图与数据：一个游戏通常需要使用UI，我们需要视图及其数据呈现模型，永远不要轻视MVC模式的哲学意义，它并不会因为你制作的是游戏而变得过时，就本人的项目而言，大量使用了MVVM模式
- 对象层服务：对象是什么？对象来自于游戏设计所蕴含和**作的一切抽象、具象实体，我们需要一种服务，掌控游戏对象的生存，消亡，形态的千变万化。这是最富有挑战性，最难以总结的设计层。 如果试着总结，例如对于对象的生命周期，我们提供对象池技术；对应AI逻辑变体，我们大量使用行为树，等等。更多的，需要你自己对玩法做出深刻的洞察，并抽象出最适合游戏本身特点的对象操作服务
框架的微观设计
- 组件系统: 组件是现代游戏引擎较为流行的对象设计方式，一个游戏对象往往由多个可精确描述其行为的组件组合而成，组件系统提供复杂多变的组件实例，这些实例依附于对象从而为对象赋予不同的功能性。这一点，与通过释放接口编程的思想类似
- 事件系统: 函数的功能调用，完成不同特性间的一对一通信，而事件的广播特性将提供一对多通信机制，俗话说的解耦神器便是~
- 沙盒系统: 沙盒系统是一个你的游戏中可以描述的封闭环境，对沙盒中产生，消亡对象，约定对象的运行法则和变化限度，沙盒外的逻辑与沙盒内无任何耦合。 例如，贪吃蛇的地图类，刻画了一个沙盒，提供了移动的边界，食物等。
这里介绍的只是海量框架模式的冰山一角，目的是引出对需求本身的洞察，需求决定了你的设计复杂程度.
大量的实践使你的开发能力不会掉队，而对框架设计的领悟决定你将可以超越多少人.
以上。