主要观点：

• Casey Muratori 与 Primeagen 讨论游戏核心数据的高层架构设计，其观点与传统 OOP 软件背景相悖，建议不应围绕不同对象（如 OOP 对象）来组织不同游戏实体的数据，游戏实体的渲染数据不应与物理数据隔离。
• 游戏开发的基本事实是只有尝试后才知道什么有趣，小的约束变化可能会完全改变或破坏游戏，游戏的乐趣在于各部分相互作用形成的系统。
• 90 年代风格的 OOP 假设若能将问题建模为对象的层次结构则能解决问题，但实际上往往并非如此，还会导致后续工作困难，因此游戏开发中已从类层次结构的实例化对象集合转向实体组件系统。
• 在代码库中应在游戏领域级别下有能快速实验不同组合以产生有趣且可理解游戏玩法的地方，同时要注意实验性代码不应扩散到整个代码库，而应在合适时机从沙盒中移出并进行整理。

关键信息：

• 以游戏为例说明在不了解问题时不应过早锁定本体，应通过迭代、试错来寻找乐趣。
• 实体组件系统是用组件组成游戏实体的简化键值存储，可方便实验游戏玩法可能性。
• 沙盒的概念适用于软件，在代码中应有探索系统但未完全理解其性质的地方，同时要注意边界内外的区别。

重要细节：

• 如在顶视射击冒险游戏中，最初假设相机跟随玩家，若加入新武器遥控导弹则需改变相机跟随对象，若过早锁定本体则会增加工作量。
• 功能编程也有局限性，其假设数据模型固定，而实际情况并非如此。
• 软件开发中存在过早或过晚进行重构的情况，应在合适时机将实验性代码从沙盒移出。