游戏设计

逻辑与表现的分离

定义“纯粹的逻辑类”。基本职责：对游戏对象的“逻辑值”进行定义、存储和计算。关键要素：只关心逻辑数据，不考虑表现问题。（如同在没有表现能力的服务端写代码）。不用继承Monobehaviour（Unity中）、不在任何系统自带的组件上存取逻辑值。可在逻辑运算的特定的位置抛出数据变更事件。或在数据操作完成后回调到 Controller。举例说明：如定义、存储和计算 “变换相关的坐标、旋转、缩放”、“战斗属性相关的“生命、法力”等。
定义“纯粹的表现类”。基本职责：根据逻辑类中的数据，对物体进行实际显示更新。关键要素：持有实际的游戏物体（GameObject）。（获得游戏物体的对象引用）持有或可访问对应的逻辑类。（可获得对应逻辑类的数据内容）可监听逻辑类中的数据变更事件，并以此对要表现的游戏对象及其子对象做显示更新（观察模式单向弱依赖）。或由 Controller 类控制，“可选地” 对实际物体进行操作。

如：逻辑数据上的位移变化较粗糙，但修改实际物体时，可对Transform组件上的值进行直接赋值或平滑插值。

实际开发中，这两个类其实是可以合并为一个类的，只是要注意保持这种单向弱依赖的处理的方式。

清晰高效的交互模型可以认为：所有的逻辑类共同组成了一个在客户端内部的、独立完整的 “个人数据服务器”。对外，负责与真正的服务器同步（交换更新）数据；对内，通过事件驱动表现显示。逻辑与表现的分离，可以让彼此有不同的 “心跳频率”，通常，为了减少客户端与服务器之间收发消息的次数。“逻辑类中的数据同步频率” 要远低于 “表现刷新频率”。表现时，通过在逻辑值之间插值，仍然可以让显示平滑，可做到让玩家毫无察觉。
安全可靠的数据模型所有数据都在逻辑类中显式定义，不会存储在任何系统组件上。所以，能够避免“意想不到的被修改”（比如被一些tween类插件意外修改）。能够避免使用浮点数，这也是帧同步实现的重点之一。
可拆卸的表现逻辑始终保持 “表现” 单向弱依赖于 “逻辑”，所以，能够随意销毁任何显示中的游戏物体（GameObject）而不影响逻辑运算（逻辑类一直存在，只是干掉了类似观察者的东西）。对于“按视野显示游戏物体，分质量（高低模、不同图片压缩品质）显示游戏物体” 这样的性能优化需求，可以处理的得心应手

MVC模式：在Unity中，可以使用MVC（Model-View-Controller）模式来分离逻辑层和表现层。Model包含游戏数据和业务逻辑，Controller处理用户输入和在Model和View之间传递数据，View负责显示数据。使用MVC模式可以使代码更加可维护和可扩展，同时也可以提高重用性
ECS架构：ECS（Entity-Component-System）是一种对逻辑层和表现层进行分离的架构。在ECS架构中，游戏对象被分解为诸如Transform、Renderer和Physics等组件。逻辑层使用系统来对这些组件进行操作，表现层使用组件来渲染游戏对象。使用ECS架构可以提高游戏性能和可维护性。
观察者模式：使用观察者模式，逻辑层和表现层可以通过事件机制进行通信。逻辑层可以向表现层发布事件，表现层可以订阅事件并响应。使用观察者模式可以使代码更加松耦合，同时也可以提高可扩展性。

ECS（Entity-Component-System）架构是一种将游戏对象分解为实体、组件和系统的设计模式，用于分离游戏对象的逻辑和渲染。每个实体都由多个组件组成，每个组件都包含游戏对象的一部分数据和行为。系统则用于处理组件，例如更新位置、处理输入、渲染等。

具体来说，ECS架构的核心是：

实体：实体是游戏对象的抽象，每个实体都由一组组件组成。实体本身不包含任何逻辑或数据。
组件：组件是实体的一部分，它包含了游戏对象的数据和行为。例如，Transform组件包含了游戏对象的位置、旋转和缩放等信息，Renderer组件包含了游戏对象的渲染信息。
系统：系统是用于处理组件的逻辑模块，它可以更新组件的状态、处理输入、渲染等。系统通过访问组件来实现对实体的控制。

使用ECS架构可以带来多方面的好处，包括：

总之，ECS架构是一种非常有用的设计模式，特别是对于需要处理大量游戏对象的游戏来说，它可以提高游戏的性能和可维护性。