template/docs/intermediate/data-vs-render.md
unanmed 687e248ac1 docs(10-11): 用户修订循环 batch3(基础/其他 + 高级教程预留)
- U-01 src-tour:content 层主要在编辑器内改、对应初级教程
- U-02 data-state-overview:解释 state 静态类型按 L0-L3 逐层累加
- U-04 map-structure:按 alias/zIndex 取指定图层(非 addLayer)
- U-05 map-tiles:putMapData/getMapData 完整示例 + 高级教程预留
- U-06 flags:区分字段对象与字段值,两组接口如何选择
- U-20 events:以内置事件集已完整(发布前约 100 个)视角改写
- U-21 replay-commands:录像指令细节留高级教程
- U-22 11 篇:高级教程显式说明 + 非链接预留标记
2026-10-18 14:45:00 +08:00

2.9 KiB
Raw Blame History

数据端与渲染端

样板把整个游戏拆成了数据端与渲染端两部分,两者各自独立、职责分明。理解这个分工,是读懂后面所有内容的前提。

各司其职:算与画

数据端负责「算」,渲染端负责「画」。

  • 数据端处理一切与游戏逻辑和结果有关的运算:勇士移动、怪物战斗、道具使用、地图事件、存档与录像……它决定游戏里「发生了什么」。
  • 渲染端只负责把当前的状态画到屏幕上,并把玩家的操作转达给数据端:它决定游戏「看起来是什么样」。

可以拿一盘棋来类比:

  • 数据端像一本账本——记录棋子的位置、每一步的走法与胜负判定,真正「下棋」的是它;
  • 渲染端像棋盘与摄像机——把账本上的棋局摆出来给观众看,并接收观众挪动棋子的手。
graph LR
    D[数据端 src/data<br/>算:逻辑与结果]
    C[渲染端 src/client<br/>画:画面与交互]
    D -->|产生游戏状态| C
    C -->|转达玩家操作| D

代码分处两地

两端的代码分别放在两个目录:

  • 数据端代码在 src/data;
  • 渲染端代码在 src/client。

一个功能通常只在其中一端实现。想要改变游戏的规则与数值,去 src/data;想要改变游戏的画面与交互,去 src/client。两端的目录构成详见 src 导览。

好处:录像验证只跑数据端

双端分离带来的最大好处,是数据端可以脱离浏览器单独运行。

数据端不依赖任何渲染(画面、动画、DOM)逻辑,因此可以在 node 环境中独立跑通一整局游戏。所谓录像验证,就是回放一局录好的操作,只在这条「数据端」路径上重算一遍,据此判定这局游戏的成绩是否与录制时一致。

这意味着:

  • 验证一局成绩,不需要打开浏览器、不需要渲染画面,速度快且结果稳定;
  • 只要录像里记录的操作一致,无论在哪台机器、哪种渲染环境下重放,得到的游戏结果都应完全一致。

数据端代码不依赖任何渲染端内容,两端因此保持各自独立。

小结

  • 数据端 = 算,在 src/data;渲染端 = 画,在 src/client。
  • 数据端可脱离浏览器单独运行,录像验证只跑数据端。
  • 改变规则与数值看数据端,改变画面与交互看渲染端。

渲染端的结构性内容(渲染端内部如何组织、它与数据端的边界细节等)会在高级教程中系统讲解(预留标记:高级教程 · 渲染端结构);待高级教程就位后,此处会替换为链接。

想了解两端内部各有哪些内容、哪些需要改,见 src 导览;想在数据端的关键动作上挂接自己的处理,见 钩子。