游戏战斗策划平衡渲染负载与帧同步机制

求知鱼游戏学院

战斗策划必须具备跨程序与美术的复合工程思维，通过限制同屏特效预算并权衡前端预测与后端权威校验，来防止公会战崩盘并保障实时网络战斗手感。

AI-assisted summary of 【新人必看】游戏策划六边形战士养成记之战斗策划主要职责&核心能力要求 — original source. Check the original for full context.

Source published: 2026-10-18

Key ideas

战斗策划本质是具备技术实力的复合型系统策划，需要贯穿前端表现、程序计算与后端逻辑，并精通动作编辑器与性能控制。 (0:00)
视觉特效与模型面数必须遵守严格的性能预算，讲师提及曾因在30V30公会战中同屏叠加60个复杂大背光特效，导致瞬时算力超载并引发低配机型大面积卡死与闪退。 (2:37)
多人网络游戏的战斗判定需依靠前后端校验与帧同步机制，通常采用前端先行预测加后端权威后校验的策略，当延迟导致数据冲突时会触发强行拉回（Rollback）。 (5:00)

Detailed notes

## Background 该视频由求知鱼游戏学院于 2026 年 10 月 18 日发布在 Bilibili 平台。视频简介指出，战斗策划是一个对综合素质要求极高的复合型岗位，不仅需要扎实的游戏引擎与编程基础，还要兼顾战斗表现、打击感调优与工具设计，适合具备一定技术背景和美术基础的新人。

## TL;DR 视频深度拆解了游戏战斗策划的复合型定位，指出其本质是具备硬核技术实力的系统策划。核心职责不仅涵盖打击感、受击反馈与动作切分等前端表现，更要求策划站在程序开发角度把控性能预算，避免因炫技导致公会战等高并发场景崩溃。此外，战斗策划必须理解前后端权威校验与帧同步逻辑，在网络物理延迟与操作即时手感之间取得精准平衡。

## Atmosphere & style 讲师以资深研发老兵的务实视角切入，语调沉稳、干货密集且直击行业痛点。通过复盘当年公会战 60 个大背光特效导致客户端集体卡死的血泪教训，打破了新人对“策划只管天马行空”的美好幻想。整体节奏兼具严谨的工程思维与接地气的经验劝诫，让听众在真实的研发博弈中感受到专业战斗策划的重量感。

## Bulletin - [00:00](https://www.bilibili.com/video/BV1zJn36DEMH?t=0s) 战斗策划本质是具备技术实力的复合型系统策划，需要贯穿前端表现、程序计算与后端逻辑，并精通动作编辑器与性能控制。 - [02:37](https://www.bilibili.com/video/BV1zJn36DEMH?t=157s) 视觉特效与模型面数必须遵守严格的性能预算，讲师提及曾因在30V30公会战中同屏叠加60个复杂大背光特效，导致瞬时算力超载并引发低配机型大面积卡死与闪退。 - [05:00](https://www.bilibili.com/video/BV1zJn36DEMH?t=300s) 多人网络游戏的战斗判定需依靠前后端校验与帧同步机制，通常采用前端先行预测加后端权威后校验的策略，当延迟导致数据冲突时会触发强行拉回（Rollback）。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV1zJn36DEMH?t=0s) 战斗策划是典型的复合型岗位，以系统策划的公共系统思维和逻辑能力为底层基石。 - [00:20](https://www.bilibili.com/video/BV1zJn36DEMH?t=20s) 前端战斗表现涵盖静态的战斗UI与动态的即时打击感，包含顿帧、受击音效及周遭环境的动态交互。 - [01:15](https://www.bilibili.com/video/BV1zJn36DEMH?t=75s) 技能释放不能停留在通俗的前后摇认知，必须在程序逻辑中精确切分触发帧、初速度、飞行弹道及碰撞判定点。 - [02:37](https://www.bilibili.com/video/BV1zJn36DEMH?t=157s) 单纯在引擎中套用白模制作翻滚砍杀仅属基础操作，成熟的战斗策划需要具备从程序开发视角设计前端表现的能力。 - [03:05](https://www.bilibili.com/video/BV1zJn36DEMH?t=185s) 商业引擎自带的动画系统在复杂战斗项目中常有局限，需要项目组针对战斗节奏二次开发或魔改动作编辑器底层。 - [03:25](https://www.bilibili.com/video/BV1zJn36DEMH?t=205s) 特效粒子与溅射伤害目标必须设定明确的数量上限和检索范围，防止无序扩散击穿客户端算力极限。 - [03:42](https://www.bilibili.com/video/BV1zJn36DEMH?t=222s) 公会战大背光事件警示策划需树立量化意识，硬件无法承载时必须主动删减面数、削减粒子做设计减法。 - [05:00](https://www.bilibili.com/video/BV1zJn36DEMH?t=300s) 单机游戏可实现纯前端计算的丝滑手感，但多人联机对抗游戏中涉及敌我干涉的判定必须由后端做权威裁决。 - [06:10](https://www.bilibili.com/video/BV1zJn36DEMH?t=370s) 网络延迟若完全依赖服务器确认会导致手感断层，因此普遍采用前端先行预测播放、后端异步校验的博弈平衡机制。 - [07:15](https://www.bilibili.com/video/BV1zJn36DEMH?t=435s) 网络卡顿中的角色被瞬移拖回现象，是后端权威校验发现前端预测数据不一致时强制覆写下发的结果。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV1zJn36DEMH?t=0s) 战斗策划的复合定位：从前端美术表现到程序逻辑切分

战斗策划与其说是一个单纯的岗位，不如说是一个具体工作的综合体。它是典型的复合型工作，其本质是一个“具备一定技术实力的优秀系统策划”。因为系统策划所要求的公共系统思维与逻辑能力是一切设计的底座，而战斗系统直接贯穿了前端表现、前端逻辑与后端逻辑，并且深度绑定玩家操作，对最终的用户体验有着决定性的影响。前端表现通常可以划分为几大块：一是战斗 UI，二是核心的打击感与操作反馈。很多游戏本身的打击感偏弱，这时大量偏静态的战斗表现就会归入战斗 UI；而打击感的核心则是即时的操作与动态反馈。例如一个像金刚猿一样的庞然大物“从天而降”，落地的瞬间应该激起怎样的前端表现，需要战斗策划全面把控——落地时不仅会震动地面，还会波及周遭的石头、树木、对面的怪物，甚至是旁边水渠里游动的鱼，这些都属于需要策划从全局考虑的美术与动态呈现。

```mermaid flowchart TD accTitle: 战斗系统表现与逻辑分层 accDescr: 展示战斗策划需要覆盖的美术表现、前端计算、工具编辑器与后端校验四大层级架构。 subgraph S1["表现层 (Presentation)"] UI["战斗 UI / 静态展示"] Impact["打击感 & 动态反馈\n(地面震动、环境破坏、飞溅)"] end subgraph S2["前端逻辑层 (Client Logic)"] Action["动作阶段切分\n(前摇、触发帧、后摇)"] Collision["碰撞判定 & 伤害触发点"] VFX["特效渲染 & 状态附着\n(燃烧、击退、爆破)"] end subgraph S3["底层支撑 (Engine & Tools)"] Editor["动作 / 战斗编辑器开发与调优"] Perf["性能监控\n(面数压制、特效同屏限额)"] end Impact -.-> Action Action --> Collision Collision --> VFX Action --- Editor VFX --- Perf ```

除了美术视效，所有的战斗都依赖严密的前端计算逻辑，包括物体的碰撞、伤害计算以及动画的播放。以最基础的“施放小火球”为例：角色做出一个轻轻往前推的动作，火球呼啸飞出；在程序实现上，必须精确界定角色推手的动作进行到哪一帧触发火球生成（从 0 到 1 的生成节点）、火球以怎样的初速度和加速度飞行、击中小怪时的伤害触发点设在哪里，以及击中后是否需要产生暴击表现、是否需要在受击者衣服上附着持续燃烧的特效。诸如“施法动作、前摇、后摇”这类词汇，只是玩家层面的通俗概念；而在代码和程序逻辑中，战斗策划必须把每个时间切片与状态转换“一五一十地分清楚”。正如讲师所指出的：“你与其说它是个岗位，不如说它是一个某具体工作的综合体，就是我们前面讲复合型工作，其实某种方法来讲它也是一个具备一定的技术实力的优秀系统策划。”

- **表现与反馈的综合覆盖**：包含核心打击感（动作、音效、顿帧）、环境交互（树木倒塌、石头飞溅、水体扰动）及基础战斗 UI。 - **动作周期的微观拆解**：不能停留在“放技能”的表层认知，必须拆解为前摇判定、生成帧、弹道参数、碰撞盒检测、命中受击、后摇打断机制等可被代码量化的参数。

---

[02:37](https://www.bilibili.com/video/BV1zJn36DEMH?t=157s) 性能天花板与同屏极限：从公会战崩盘反思策划的“程序思维”

很多新人认为做战斗策划就是搭建白模，在引擎里拿着网上现成的模型改一改，做出跑动、连砍、跳砍、翻滚就大功告成了，但这仅仅代表具备了最基础的引擎操作能力。真正的战斗策划必须站在程序开发的角度设计前端战斗表现，尤其要精通“动作编辑器”（或战斗编辑器）的使用与优化，并协同前端程序完成性能调优。虽然 Unity 与 Unreal Engine（UE）自带了动画系统，但在高强度战斗项目的实际生产中往往并不顺手，需要项目组自行魔改、二次开发或优化引擎底层，以保证动作播放的绝对流畅。更关键的考验在于性能预算的控制：无论是模型面数，还是粒子特效的复杂度，策划都不能信马由缰。例如火球术击中后的溅射伤害，策划需要明确计算到底是溅射 3 个人、5 个人还是 50 个人，是有序检索最近目标还是无序扩散，其影响范围是无限还是有限。

一旦战斗策划缺乏这种技术量化意识，项目上线就会遭遇灾难性的崩盘。讲师分享了当年研发神魔题材项目时的惨痛教训：当时为了追求极致炫酷的视觉冲击，策划给神魔阵营的每个角色身后都配置了一个类似佛祖佛光的大背光特效。平常单人跑图测试非常华丽，但到了 30V30 的公会战场景时，同屏 60 个角色同时顶着极其复杂的大背光特效进行混战。瞬时算力直接击穿了客户端的承载极限，“60 个大背光直接把整个游戏卡死，根本动不了，程序算不过来”。由于玩家的手机与电脑硬件配置参差不齐，大量用户的前端直接闪退、卡死并当场崩溃。讲师严肃告诫，如果硬件承受不了，策划必须主动做减法，甚至不惜删减模型面数、削减特效粒子、直接改动原始设计需求，而绝不能盲目堆砌。讲师对此总结道：“真正的战斗策划其实更大的点在于理解程序逻辑，站在程序开发的角度去做前端战斗表现，这才是合理的，因为我们吃过太多这种亏，就是策划脑洞一开，这个加这个炫那个酷全部给我一股脑上，最后程序告诉你：拜托，那帧崩了，扛不住，但也有手机发烫的，就你烧得太狠了温度上去了。”

- **项目血泪教训（公会战大背光事件）**：30 vs 30 阵营战同屏出现 60 个动态高发光背光特效，瞬间压垮渲染管线，导致多数低配机型前端直接卡死闪退。 - **性能约束与优化手段**： - 特效控制：限制同屏粒子发射上限、溅射目标数量封顶（明确上限范围而非无界判定）。 - 资产降级：动态降低远景/非核心角色模型面数（LOD 策略）、压制发热功耗以防降频卡顿。 - 编辑器定制：依据项目战斗打击感节奏，深度优化或重构商业引擎原生动画播放管线。

---

[05:00](https://www.bilibili.com/video/BV1zJn36DEMH?t=300s) 前后端校验与帧同步机制：网络延迟下的判定博弈

要做好战斗策划，必须对前端与后端的交互逻辑有深刻的计算机基础与软件工程思维，特别是要弄清楚“前后端校验”与“帧同步”到底由谁说了算。在单机体验或纯前端计算的游戏中，玩家“指哪打哪，角色就跟到哪”，体验极其丝滑；但到了 MMORPG 或竞技类网络游戏中，移动和技能施放往往直接干涉另一名真实玩家。例如角色起跳开大招，技能设定的判定范围是 3 米，目标到底在不在 3 米范围内，直接决定了对方是中招眩晕还是大招打空。这种牵涉敌我多方的交互逻辑，绝对不能单纯由某一方的前端计算拍板，必须统一交由后端做权威判定。然而，如果所有动作都要等后端计算完毕再同步给前端，网络延迟就会直接摧毁战斗手感，导致玩家看到的画面完全失真——即在本地施法时对方明明在圈内，大招砸下去时对方已经在 3 米之外。

```mermaid flowchart LR accTitle: 战斗网络校验与预测回滚流程 accDescr: 展示前端客户端先行预测执行、后端权威校验，以及数据冲突时客户端强制拉回的同步逻辑。 subgraph Client["前端客户端 (本地先行)"] Input["玩家释放大招 / 移动"] --> Predict["本地先行表现\n(准星对准/技能动画即刻播放)"] Rollback["位置拉回 / 判定失效\n(发生瞬移、大招打空)"] end subgraph Server["后端服务器 (权威校验)"] Verify{"接收包并校验时序\n位置数据是否一致？"} end Predict -->|"上传操作数据包"| Verify Verify -->|"一致 (校验通过)"| Confirm["确认生效 / 同步状态"] Verify -->|"不一致 (延迟/外挂)"| Rollback ```

为平衡“操作手感”与“数据准确性”，网络游戏通常采用预测与后校验机制。讲师以射击游戏为例解释：玩家准星对准敌人头部扣动扳机的瞬间，从前端逻辑看，0.01 秒内对方理应爆头倒地；但由于网络延迟的存在，如果纯等服务器确认，这一枪就可能会因为数据包迟到而打空。因此常见的同步策略是：先默认前端的数据操作是合理的，让玩家本地先行执行并播放反馈；后端随后进行逻辑校验。如果校验结果与后端运算状态吻合，则战斗顺畅进行；一旦后端发现因网络延迟或丢包导致前端数据与真实服务器状态产生偏差，后端就会强行覆写前端表现。这就解释了玩家在网络卡顿、延迟飙升时经常遇到的诡异现象：明明角色一直在往前跑，下一秒却突然被硬生生扯回到几个身位之前的起点。讲师明确强调：“所以帧同步的意思会变成说，我先假设你的前端数据是对的，你先执行，你先算，我的校验是后校验；如果这个时候我校验完发现你的数据跟我后端数据一致，那没毛病，你继续对吧；但如果我发现你前端不对，他会被拖回来。”

- **本地先行与手感平衡**：纯前端计算保证操作即时性与丝滑感，权威逻辑置于后端防止作弊与状态冲突。 - **网络延迟与时空割裂**：物理延迟导致多端时间轴不同步，若缺少合理的预测补偿，会导致大招打空、瞄准爆头却未命中的体验断层。 - **回滚机制（Rollback / 拖回现象）**：后端检测到本地客户端模拟状态与权威状态存在冲突时，强制下发服务器帧数据覆盖前端，造成视觉上的瞬移或回退。

## Notable quotes > [02:37](https://www.bilibili.com/video/BV1zJn36DEMH?t=157s) 真正的战斗策划其实更大的点在于理解程序逻辑，站在程序开发的角度去做前端战斗表现，这才是合理的。 — 讲师

## Mentioned Unity, Unreal Engine

## Video description 【新人必看】游戏策划六边形战士养成记，战斗系统是相对比较复杂的系统，战斗策划也是一项相对高难度挑战性工作，需要有很强的游戏引擎使用能力和一定的编程基础，既要有战斗系统设计和开发能力，又要对游戏的战斗表现和打击感，对游戏角色/英雄设计、怪物设计、武器或者枪械设计有很高的敏感度，最好也有编辑器和相关工具设计和开发的能力，是各方面综合要求比较高的岗位，适合有一定技术背景又有一定美术基础的同学。程序、策划、美术的工作都略知一二。如果你也想第一时间了解秋招&校招实习信息，请关注我们。如果你想要《26年秋招游戏行业公司信息表》，也请在评论区扣666或者私信我，谢谢！

[Source](https://www.bilibili.com/video/BV1zJn36DEMH)

中文简报

游戏战斗策划平衡渲染负载与帧同步机制战斗策划必须具备跨程序与美术的复合工程思维，通过限制同屏特效预算并权衡前端预测与后端权威校验，来防止公会战崩盘并保障实时网络战斗手感。视频深度拆解了游戏战斗策划的复合型定位，指出其本质是具备硬核技术实力的系统策划。核心职责不仅涵盖打击感、受击反馈与动作切分等前端表现，更要求策划站在程序开发角度把控性能预算，避免因炫技导致公会战等高并发场景崩溃。此外，战斗策划必须理解前后端权威校验与帧同步逻辑，在网络物理延迟与操作即时手感之间取得精准平衡。战斗策划本质是具备技术实力的复合型系统策划，需要贯穿前端表现、程序计算与后端逻辑，并精通动作编辑器与性能控制。 (0:00) 视觉特效与模型面数必须遵守严格的性能预算，讲师提及曾因在30V30公会战中同屏叠加60个复杂大背光特效，导致瞬时算力超载并引发低配机型大面积卡死与闪退。 (2:37) 多人网络游戏的战斗判定需依靠前后端校验与帧同步机制，通常采用前端先行预测加后端权威后校验的策略，当延迟导致数据冲突时会触发强行拉回（Rollback）。 (5:00)

Reading summary

求知鱼游戏学院指出，战斗策划本质上是具备技术实力的复合型系统策划，不仅需要把控打击感与美术反馈，还必须深入程序逻辑，统筹微观时间切片、性能预算以及网络环境下的前后端同步机制。表现拆解与微观状态切片 (0:00) 战斗策划不仅负责战斗UI与打击感等前端动态反馈，还需要从全局把控角色落地时的地面震动、环境破坏和飞溅效果。更为关键的是将玩家感知的动作周期转化为严密的前端计算逻辑。以施放小火球为例，策划不能仅停留在“推手放技能”的表层描述，而必须在代码逻辑层面明确界定推手动作到第几帧生成火球、飞行初速度与加速度、伤害判定点位置，以及命中后是否触发暴击或燃烧特效。前摇、后摇等通用概念必须被细化为可量化的时间切片与状态转换机制。性能边界意识与量化调优 (2:37) 战斗策划的核心能力不仅限于在引擎中拼接现成模型和基础动作，更在于站在程序开发视角理解性能天花板。商用引擎自带的动画系统在高强度战斗中往往需要二次开发或优化底层，策划需要精通动作编辑器的调优，并对模型面数、特效复杂度和目标数量进行严格量化。例如对于火球溅射伤害，必须明确限定影响范围以及溅射目标究竟是3个、5个还是50个，是有序检索还是无序扩散，绝不能无界扩散。同屏过载教训与设计减法 (2:37) 缺乏性能量化意识会导致灾难性的上线事故。讲师列举了神魔题材项目的过往教训：团队曾为追求炫酷视觉，给神魔阵营每个角色都配置了大背光特效，单人测试表现良好，但在30V30共60人同屏的公会战混战中，瞬时算力击穿了客户端渲染承载极限，导致大量用户设备因算不过来和发烫而直接卡死或闪退。讲师指出，当硬件无法承载时，策划必须主动做减法，甚至需要削减特效粒子、下调模型面数或直接修改原始设计，避免盲目堆砌视效。网络延迟与前后端校验博弈 (5:00) 在多人在线交互环境中，移动与范围技能判定不能单纯依靠本地前端计算，必须交由后端服务器进行权威校验，以防止作弊与状态冲突。然而完全等待后端确认会导致严重的操作延迟与失真。网络游戏普遍采用本地先行预测与后端后校验结合的机制，例如射击游戏中玩家开枪时本地即刻播放命中反馈，随后上传数据包由服务器比对时序与位置；若校验一致则判定生效，若后端发现延迟或丢包导致两端数据产生偏差，服务器会强制下发数据覆盖前端，这也是玩家在网络卡顿时角色被突然“拖回”几个身位的底层原因。战斗策划的成熟度取决于是否能跳出纯视觉脑洞，建立涵盖前端表现切片、引擎工具优化、性能硬约束及前后端网络校验的完整技术认知。

Source quotes

[2:37] 讲师: 真正的战斗策划其实更大的点在于理解程序逻辑，站在程序开发的角度去做前端战斗表现，这才是合理的。

Original transcript

[0:00] 第三个大维度就是战斗策划或者叫战斗设计这样的岗位你与其说它是个岗位不如说它是一个某具体工作的综合体就是我们前面讲复合型工作其实某种方法来讲它也是一个具备一定的技术实力的优秀系统策划因为前面已经刚解释过了系统策划或者系统思维是几乎所有岗位的公共逻辑思维能力所以通常来讲战斗系统它其实涉及到了前端表现前端逻辑当然也有后端逻辑也涉及到用户操作对用户的体验影响也非常的巨大前端表现通常我们会分为几个大块第一就是战斗的UI其次就是你最熟的打击感虽然你硬要把战斗UI归入打击感也不是不行但是确实有很多游戏它本身打击感是比较弱的所以通常我们会把一些相对偏静态的战斗表现统统还是回到了战斗UI战斗打击感其实就是战斗操作和反馈就像刚才我随口举例的一个大猴子从天而降一个金刚猿这样的一个旁然大物从天而降动一声落到地面的那一瞬间它应该有什么样的前端表现这个其实是纯美术表现这个是你战斗策划本身就需要去把握的就像前面前的例子它会影响到地面影响到旁边的石头旁边的树甚至影响到对面的怪甚至影响到旁边的水渠里的鱼等等这是一个点第二就是所有的战斗它必须有一个前端计算逻辑无论是这个物体的碰撞还是伤害计算或者我们有种习惯叫动画播放有点像我经常拿小火球举例我这么轻轻一推这个火球build一下出去了那我推的这个时候我这个动作就有什么时候触发这个火球出现因为从0到1这个火球什么时候出现这个火球它有一定的飞行速度他碰到了对方比如打到了一个小怪身上他的伤害出发点在哪要不要暴力要不要附着就是附在衣服上燃烧这些你都需要由前端逻辑来计算你们叫施法动作也好前摇好后摇好这些其实是用户或者普通玩家层面比较容易理解但是我说的是程序代码逻辑他需要这么一五一十的分清楚然后最终回到另外一个点动作编辑器或者叫战斗编辑器这个无所谓反正就是用来编辑动画虽然现在Unity跟UE都有自带的动画系统但是确确实实有时候它用起来可能没有那么顺手所以才有我们前面举例假设的要对游戏引擎的动画系统进行优化优化的目的其实就是为了保证动画本身的播放当然如果是相对硬核一点的战斗策划它还有协助前端程序进行性能优化这个性能优化就多了例子特效还是模型特效你比如说把火球换成建设建设到底是三个人还是五个人还是五十个人是无序的建设还是有序的范围是无限的数量还是相对比较少的数量如果你是一个不用如座我们当年在Q罚下的时候就碰到过这样一个现实的问题因为每个人背后都有个大背光就是神魔片每个人背后都有个大背光特效特别的炫酷在打公会战的时候一边各有三十个人厂上有60个顶着大背光的人就类似于佛祖佛光因为神魔都有大背光60个大背光直接把整个游戏卡死根本动不了程序算不过来当然是因为用户本身前端硬件各种差异会导致大多数用户在这一个特定场面里面前端直接就卡死崩盘所以回到那个点你要去做前端表现没有问题但是你要想一下这样的一个表现你的这个用户的前端你的用户的硬件能否承受得了如果可以那当然没问题那如果不行你就要做优化甚至有时候为了前端的顺畅他不惜做一定的模型面数减少甚至改变需求所以就会变成说你作为战斗策划他不是简单的只是说我去做个战斗的模型白模跑过去砍两下怪很多同学的战斗demo就是这样的用一个可能是网上现成的一个模型拿回来改一改过去砍两下刺一下什么连砍什么跳砍什么翻滚等等这些其实只是证明你有一定的引擎使用能力真正的战斗策划其实更大的点在于理解程序逻辑站在程序开发的角度去做前端战斗表现这才是合理的因为我们吃过太多这种亏就是策划脑中一开这个家这个旋那个库全部给我汉巴拉上最后程序告诉你拜托那只崩了 [5:00] 扛不住但也有手机发烫的就你烧得太狠了温度上去了所以最后会变成说如果你想做好战斗策划在前端逻辑上一定要有一个非常深刻的理解这就是为什么又回到前面那个问题为什么要有一定的程序开发和软件工程基础支持为什么要有一定的计算机基础和互联网基础支持因为你自己需要有这个概念因为你知道所有的数据需要通过前后端来做检条的只是你前端算完我后端也要算的比如说你们最熟的真同步这个东西到底谁说了算很多时候你会发现你在玩游戏的时候你指哪点哪那个角色就跟得到哪它很丝滑因为它这个是纯前端计算它没有任何的毛病但是在MLRPG里面因为你的移动你的技能释放会涉及到另外一个玩家比如说我跳坎我跳过去开个大我的范围是三米那你到底在不在我这个三米范围之内当然我刚才讲的是第一次如果你在我三平范围之内你会中招你会眩晕但如果你不在我这个范围内我这个大就丢空了这个时候他就得由后端说了算因为这种敌我双方涉及到不同玩家之间的这样的一个交互一定只能由后端说了算但是如果什么都等后端判断完计算完再传过来这个时候你会发现前端已经完全失效因为用户看到的就不是所见即所在我的技能范围内我施法的时候他的那个施法范围是对的但是当我跳过去放到那个大的时候他离我三米远这就是网络延迟可能大家对这个不太好理解我们以设计游戏为例好我明明准精对着他的头我明明按正常的速度计算我抠过去这0.01秒他就抱头死了但是因为我网络延迟了我这一枪打空了对方还活着对所以真同步的意思会变成说我先假设你的前端数据是对的你先执行你先算我的教验是后教验如果这个时候我教验完发现你的数据跟我后段数据一致那没毛病你继续对吧但如果我发现你前端不对他会被拖回来这就为什么有时候如果你碰到网络卡的时候你明明往前跑但是你会突然往回退好几个人