回顾之前做的几个Demo做点总结。

1、定义“纯粹的逻辑类”
  基本职责：对游戏对象的“逻辑值”进行定义、存储和计算。
  关键要素：只关心逻辑数据不考虑渲染问题。（如同在没有渲染能力的服务端写代码）
  举例说明：如定义、存储和计算 “变换相关的坐标、旋转、缩放”、“战斗属性相关的“生命、法力”等。

2、定义“纯粹的渲染类”
  基本职责：根据逻辑类中的数据，对物体进行实际显示更新
  关键要素：持有 实际的游戏物体（GameObject）。（获得游戏物体的对象引用）
            监听逻辑类中的数据变更事件并以此对要渲染的游戏对象及其子对象做显示更新（逻辑类和渲染类，昰一种观察模式的单向弱依赖）
  举例说明：如监听事件，对Transform组件上的值进行修改（直接赋值或平滑插值）

实际开发中，这两个类其实昰可以合并为一个类的只是要注意保持这种观察处理的方式。

二、意义（为什么要将逻辑与渲染分离）

1、清晰高效的交互模型
  可以认為：所有的逻辑类共同组成了一个 在客户端内部的、独立完整的 “个人数据服务器”。对外负责与真正的服务器同步（交换更新）数据；对内，通过事件驱动渲染显示
  逻辑与渲染的分离，可以让彼此有不同的 “心跳频率”通常，为了减少客户端与服务器之间收发消息嘚次数“逻辑类中的数据同步频率” 要远低于 “渲染刷新频率”。渲染时通过在逻辑值之间插值，仍然可以让显示平滑可做做到让玩家毫无察觉。

  所有数据都在逻辑类中显式定义不会存储在任何系统组件上。
  所以能够避免“意想不到的被修改”（比如被一些tween类插件意外修改）。
  能够避免使用浮点数这也是帧同步实现的重点之一。

3、可拆卸的渲染逻辑
  始终保持 “渲染” 观察 “逻辑”（单向弱依賴），所以
  能够随意销毁任何显示中的游戏物体（GameObject）而不影响逻辑运算（逻辑类一直存在，只是干掉了观察者）对于“按视野显示游戲物体，分质量（高低模、不同图片压缩品质）显示游戏物体” 这样的性能优化需求可以处理的得心应手。

发布了64 篇原创文章 · 获赞 17 · 訪问量 2万+