- 博客(6923)
- 收藏
- 关注
RSS订阅原创 游戏循环中的时间：为什么表现层适合可变步长，模拟层适合固定步长？
可变步长和固定步长并不是互相竞争的两套方案，而是服务于不同目标的工具。可变步长方便表现内容跟随实际时间和渲染节奏。固定步长为模拟提供稳定的时间尺度，便于定义规则、控制数值行为以及进行联网同步和重演。插值、预测等手段负责把离散模拟转化为平滑画面。决定游戏事实的部分，优先考虑固定步长；负责把游戏事实呈现出来的部分，优先考虑可变步长或插值。
2026-11-06 03:34:22
173
原创 游戏软件架构 02｜游戏循环与时间：让世界按同一个节拍前进
时间系统上线后，唐棣把探照灯的转速在三台电脑上各测了一遍，结果一致。陆川按住快进穿过风暴，燃料终于和正常游玩时对得上了。周五的代码评审中，她打开，发现第一行多了一句。提交者只是想用一下，这个改动完全合理，也通过了所有测试。但下周，同一个文件又多了一个Debug.Log，接着是一个Transform字段，因为"这样取位置最方便"。上个月定下的规则是"玩法逻辑不引用界面和场景"，可它只写在文档里，编译器并不知道。"靠大家记住规则是撑不了多久的，"她对陆川说，“我想让违反规则的代码根本编译不过。
2026-11-06 02:20:02
150
原创 游戏软件架构 01｜什么是游戏软件架构：目标、取舍与系列地图
回到唐棣。那次周会之后，她把的行数写在了团队看板的角落里：3,412。每周五，她会更新一次这个数字。它没有一下子变成零。有些周它几乎不动，因为那一周的需求都在别的地方；有一周它反而涨了二十行，因为一个热修复来不及整理，她在旁边写了一条注释和一个 ADR 编号。三个月后，这个数字是 1,180；发布前，是 260——剩下的部分，主要是一些启动流程和调试命令，大家一致认为留着也没关系。"我们从来没有专门停下来’做架构’，"陆川后来说，“只是每次改东西的时候，多问一句：下一次改这里，会不会更容易一点？
2026-11-03 03:24:33
153
原创 独立游戏开发全流程 15｜上线与长尾：发布日、第一周与之后的每一天
第 08 篇讲过冻结的原则；冻结大致时间（示例）之后允许的改动功能冻结发布前 6～8 周不再加新功能；只完善已有内容内容冻结发布前 4～6 周不再加新关卡、新文本（本地化需要时间）文本冻结本地化开始前改一个字都要通知所有语言的译者代码冻结发布前 1～2 周只修复经过评估的问题，每个改动都要审阅发布候选版本（RC）发布前数天到一周只有阻断性问题才会产生新的候选版本时间取决于团队规模、平台审核与本地化的工作量。多平台同时发布时，主机平台的认证往往决定了冻结的时间（以平台要求为准）。
2026-11-03 02:19:07
130
原创 独立游戏开发全流程 14｜公司、法务与合规：保护好你的游戏和你自己
回到陆川。尽职调查结束后，他把那份素材清单留在了项目的根目录里，文件名叫。每次有人往工程里加一个新文件，构建流水线就会提醒一次：这个东西从哪里来？周屿后来成了公司的第二位股东。签股东协议的那天，他们花了一个下午讨论"如果有一天我们其中一个人想离开怎么办"。那是他们合作以来最尴尬、也最坦诚的一次谈话。"把最坏的情况说清楚之后，"周屿说，“反而觉得可以放心地一起往前走了。那款标题字体的作者，是一位独立的字体设计师。她回信说，这是第一次有游戏开发者问她这个问题。商标申请在大半年后获得了注册。
2026-11-03 02:12:59
136
原创 独立游戏开发全流程 13｜钱与发行：资金、发行商与你的商业模式
回到陆川。签完合同的那天晚上，他做的第一件事不是庆祝，而是更新了那张跑道表。二十万元预付款分四个里程碑到账，PC 版的资金缺口补上了，而且多出了三个月的缓冲。他把其中一个月的钱，单独转进了一个他承诺不会碰的账户。主机版的移植比合同约定的时间晚了两个月。他翻出合同，找到"权利回归"那一条，然后给发行商写了一封很客气的邮件。对方第二天就打来电话，调整了移植团队的人手。三个月后，主机版上线了——他后来说，那一条条款他从来没有真正用过，“但它让我们双方都很清楚，承诺是有分量的”。
2026-11-03 02:05:27
184
原创 独立游戏开发全流程 06｜技术选型与工程化：引擎、工具链与项目骨架
数据驱动的意思是：把游戏内容（原料、顾客、敌人、关卡、对话、数值）从代码中分离出来，放在数据文件或编辑器资源里。硬编码数据驱动加一种原料要改代码、重新编译加一个数据文件或表格的一行只有程序员能调整数值设计师可以直接修改数值散落在各个脚本中所有数值集中可见、可比较、可校验时间点加入一个统一接口的成本第一天写一个空壳，几小时第三个月修改几十处调用，一两天第十八个月修改上千处调用，测试所有界面，几周接下来几节，分别讨论最关键的四个系统和平台层。回到小周。
2026-11-01 22:14:32
189
原创 独立游戏开发全流程 05｜试玩测试：观察陌生人，读懂真实反馈
出声思考（Think-Aloud Protocol）是用户研究中最常用的方法之一：请参与者在操作时，把自己的想法持续地说出来。它能让你知道行为背后的原因只看行为加上出声思考试玩者把火和冰两张卡放进了坩埚“火和冰放一起会不会炸？试试看” → 他在主动冒险试玩者把火和冰两张卡放进了坩埚“随便放两张吧，反正看不懂” → 他没有理解系统同一个行为，两种完全不同的含义。只看日志，你会把第二种也算作"主动尝试新组合"。回到阿杰。展会之后，他重新组织了一轮测试。
2026-11-01 20:25:42
150
原创 独立游戏开发全流程 04｜原型：两到四周，只回答一个问题
时间盒（Timebox）是一个硬性的截止时间：时间到了，无论原型做到什么程度，都必须停下来做决定。时间盒适合几小时到 2 天纸面原型、单个机制的快速验证、Game Jam 式的点子筛选1 周一个小规模的数字原型，或一个技术原型2～4 周一个能让陌生人试玩的核心循环原型（本篇的主要情况）超过 6 周通常意味着原型在回答太多问题，或者已经变成了正式开发Kyle Gabler 等人在"实验性游戏项目"（Experimental Gameplay Project）中，曾以每个游戏不超过七天。
2026-11-01 05:28:25
182
原创 独立游戏开发全流程 03｜找到钩子：从灵感到一句话卖点
钩子：一个能让目标玩家迅速理解"我在这款游戏里会做什么"，并且立刻产生好奇或渴望的核心点。关键词含义目标玩家钩子不需要打动所有人，只需要打动你的核心玩家；对恐怖游戏玩家有效的钩子，可能会吓跑温馨经营的玩家迅速理解以秒计算，而不是以分钟计算；需要解释的钩子不是钩子好奇或渴望玩家的反应应该是"然后呢？““我想试试”，而不是"哦，听起来不错”名场面是玩家或观众会忍不住截图、录屏、转发、讨论的那一刻。在主播和短视频主导发现渠道的今天，名场面是钩子最有力的传播载体。类型说明例子（示意）意外与反转。
2026-11-01 05:11:38
188
原创 独立游戏开发全流程 02｜立项调研：先看市场，再爱上点子
回到阿青。如果她在动手之前做过一次调研，她会发现：她那个"没有竞品"的品类组合，在 Steam 上其实有几款类似的游戏，只是评测都只有个位数或几十条——它们不是不存在，而是没人看见。她会发现，玩家社区里几乎没有人在寻找这种组合；她也会发现，与她的点子最接近的一个成熟品类里，玩家正在反复抱怨一个问题，而她的核心机制恰好能解决它。也许她仍然会做这款解谜游戏，但会换一个框架，把它放进那个有需求的品类里；也许她会把规模缩小一半，让回本线落在中位数附近；
2026-11-01 05:04:44
167
原创 游戏大厂技术全景（49）：角色技能——英雄射击的技能框架与射击的交互
/ 技能定义：只读配置；阶段、资源、目标、标签与效果全部数据化PhaseId id;// 秒；0 表示瞬时// 此阶段赋予的状态标签，例如 State.Casting、State.HandsBusy// 被这些标签打断（第四节）// 进入阶段时施加的效果（第七节）// 进入阶段时执行的动作：生成投掷物、开始位移、扫描……// 资源// 共享冷却组（第三节）// 释放条件// 需要具备的标签，例如 State.OnGround。
2026-10-31 02:24:07
5
原创 游戏大厂技术全景（41）：UGC 与模组——编辑器、沙箱与内容审核
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题 31 物理与碰撞 / 32 技能与战斗框架 / 33 游戏 AI / 34 着色器编译与 PSO 卡顿 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法 / 37 相机、输入与手感 / 38 音频技术 / 39 存档与数据演进 / 40 主机平台开发 /← 当前 / 42 程序化内容生成。
2026-10-30 03:22:55
8
原创 游戏大厂技术全景（39）：存档与数据演进——序列化、版本迁移与云存档
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题 31 物理与碰撞 / 32 技能与战斗框架 / 33 游戏 AI / 34 着色器编译与 PSO 卡顿 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法 / 37 相机、输入与手感 / 38 音频技术 /← 当前 / 40 主机平台开发。
2026-10-30 03:12:43
8
原创 游戏大厂技术全景（38）：音频技术——中间件、空间音效与语音聊天
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题 31 物理与碰撞 / 32 技能与战斗框架 / 33 游戏 AI / 34 着色器编译与 PSO 卡顿 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法 / 37 相机、输入与手感 /← 当前 / 39 存档与数据演进。
2026-10-30 03:01:07
9
原创 游戏大厂技术全景（35）：网络传输层与弱网对抗——UDP 可靠性、拥塞控制与 NAT 穿透
问题说明对游戏的影响队头阻塞一个包丢失，后面已到达的数据都要等它重传完成才能交给应用丢一个旧快照，导致后续所有新快照一起被卡住重传时机不可控重传超时由内核按 RFC 6298 一类的算法计算，且有最小值与指数退避弱网下延迟尖刺可达数百毫秒乃至数秒拥塞控制保守丢包被视为拥塞信号，发送窗口大幅收缩在随机丢包的无线网络中吞吐与延迟都恶化字节流语义没有消息边界，也无法表达"这条可以丢"所有数据被一视同仁地可靠传输Nagle 与延迟确认默认合并小包、延迟发送确认需要。
2026-10-29 21:48:57
6
原创 游戏大厂技术全景（34）：着色器编译与 PSO 卡顿——变体爆炸、预缓存与平台差异
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题 31 物理与碰撞 / 32 技能与战斗框架 / 33 游戏 AI /← 当前 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法。
2026-10-29 21:31:35
3
原创 游戏大厂技术全景（33）：游戏 AI——寻路、决策架构与大规模单位
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题 31 物理与碰撞 / 32 技能与战斗框架 /← 当前 / 34 着色器编译与 PSO 卡顿 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法。
2026-10-29 18:04:07
8
原创 游戏大厂技术全景（32）：技能与战斗框架——属性、Buff、命中判定与打击感
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题 31 物理与碰撞 /← 当前 / 33 游戏 AI / 34 着色器编译与 PSO 卡顿 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法。
2026-10-29 17:17:18
8
原创 游戏大厂技术全景（31）：物理与碰撞——检测、求解、角色控制与确定性
第零至第七部分 · 主线 01～30（全景地图 → 引擎地基 → 客户端 → 渲染与表现 → 网络与服务器 → 生产与效能 → 质量与安全 → 运营与前沿）第八部分 · 进阶专题← 当前 / 32 技能与战斗框架 / 33 游戏 AI / 34 着色器编译与 PSO 卡顿 / 35 网络传输层与弱网对抗 / 36 匹配与排位算法。
2026-10-29 15:25:14
4
原创 游戏大厂技术全景（03）：游戏循环与任务系统——让所有 CPU 核心都忙起来
第零部分 · 开篇 01 全景地图第一部分 · 引擎地基 02 引擎选型 /← 当前 / 04 数据导向设计、ECS 与内存管理第二部分 · 客户端 05 客户端框架 / 06 UI、生命周期与平台适配 / 07 资源管理 / 08 代码热更新 / 09 版本与补丁分发第三部分 · 渲染与表现 10 渲染管线与 Render Graph / 11 GPU Driven、Nanite 与 Lumen / 12 风格化渲染 / 13 大世界与机型分级 / 14 动画技术。
2026-10-28 02:26:22
5
原创 游戏大厂技术全景（02）：引擎选型——大厂为什么不一定自研
第零部分 · 开篇 01 全景地图第一部分 · 引擎地基← 当前 / 03 游戏循环与任务系统 / 04 数据导向设计、ECS 与内存管理第二部分 · 客户端 05 客户端框架 / 06 UI、生命周期与平台适配 / 07 资源管理 / 08 代码热更新 / 09 版本与补丁分发第三部分 · 渲染与表现 10 渲染管线与 Render Graph / 11 GPU Driven、Nanite 与 Lumen / 12 风格化渲染 / 13 大世界与机型分级 / 14 动画技术。
2026-10-28 02:20:10
9
原创 游戏大厂技术全景（01）：全景地图——游戏大厂的技术体系
当一家公司有多个项目时，很自然会想到：登录、支付、热更新、性能工具，每个项目都要做一遍，能不能做一套大家共用？这就是技术中台的出发点。中台方向提供的能力对应篇目引擎与渲染引擎定制版本、渲染方案、画质分级、性能工具客户端基础框架资源管理、热更新、UI 框架、SDK 接入05-09服务器基础登录、支付、社交、匹配、排行、跨服18-20工程效能平台构建、发布、测试、版本管理23、24质量平台自动化测试、云真机、APM、崩溃收集25-27安全平台反外挂、防破解、风控28。
2026-10-28 02:15:38
10
原创 游戏大厂技术全景：从引擎到运营的完整技术栈
品类常见方案原因FPS / TPS状态同步 + 预测 + 延迟补偿需服务器权威判定命中MOBA / RTS帧同步或状态同步单位多，帧同步流量小；但防透视较难格斗回滚对输入延迟极其敏感MMO / 大世界状态同步 + AOI玩家多，只同步附近内容传输层面，实时性要求高的游戏常基于 UDP 自建可靠传输（如 KCP），序列化常用 Protobuf 等格式。启示：没有绝对好的方案。先确定游戏最在意什么——手感、公平还是规模。
2026-10-28 02:03:45
8
原创 游戏大厂业界技术全景：从引擎到运营的完整技术栈
游戏大厂的技术是一个分层体系：客户端与服务器是基础，往上是内容管线、工程效能、质量、安全和运营支撑；引擎选型看品类、团队和长期成本，大厂不一定自研，更常见的是在商业引擎之上建设技术中台；客户端的核心是框架分层、资源管理、热更新和多平台适配；渲染的核心是画质与性能的平衡，以及大世界技术；网络同步有帧同步和状态同步两条路线，选择取决于品类；服务器围绕分服、房间、全服等模式设计，重视扩展性和数据安全；内容生产管线和工程效能决定了团队能做得多快、多大，是大厂与小团队拉开差距的关键；性能、质量、安全。
2026-10-28 01:54:54
9
原创 Unity 游戏中的 Android 生命周期：从原理到业务处理
Unity 游戏通常只有一个 Activity，生命周期问题集中在前后台切换和进程被杀；区分四种状态：前台、失焦、后台、被杀。失焦不等于后台，被杀没有任何回调；用统一的生命周期管理器接收回调，按后台时长分级处理，并控制各模块的执行顺序；进入后台时做最后的保护：存档、记录时间、注册本地推送、释放可重建的资源；回到前台时做校验：检查连接、同步时间和数据、修复丢失的渲染内容；时间按时间戳计算，发货和奖励以服务器为准，客户端只负责表现；把进程被杀当作必然会发生的事。
2026-10-26 03:29:54
5
原创 工程路径为什么不能带中文和空格：从原理到业界案例
空格问题是"分隔"问题：路径在拼接命令行、Makefile、Shell 脚本、URL 时，空格被当作分隔符，路径被拆成多段；中文问题是"编码"问题：Windows 上 UTF-16、GBK、UTF-8 并存，A 版 API 依赖系统代码页，不同工具之间对路径字节的解释不一致，导致乱码或字符丢失；操作系统本身没有问题，问题出在工具链中某个没有正确处理路径的环节，而且报错通常出现在下游子工具中，所以显得"莫名其妙"；
2026-10-26 02:27:13
158
原创 Unity 项目打出 Android 包全流程 ——从点下 Build 按钮，到包装进玩家手机（大白话版）
① 环境 ② 平台 ③ 配置 ④ 签名Unity Hub → 切 Android → 包名/版本号 → Release Keystore自带 JDK 贴图 ASTC IL2CPP + ARM64 妥善备份SDK/NDK 缓存服务器 Target API 达标 密码不进仓库⑤ SDK ⑥ 出包 ⑦ 测试 ⑧ 上架EDM4U 管依赖 APK / AAB → adb / bundletool → Play：AAB + 分阶段发布。
2026-10-26 02:14:10
248
原创 移动端贴图“软解压“原理：GPU 不支持的格式，CPU 为什么能解
压缩格式 = 公开的数据排列规则 + 还原公式，解码只涉及读比特、查表、整数运算和插值；GPU 支持某格式 = 纹理单元里有执行这套公式的专用电路，没有电路就无法直接使用该格式；CPU 是通用处理器，把同样的公式写成代码就能解码，ETC、ASTC 都有现成的开源实现；解码结果写成 RGBA32 原始像素，这是所有 GPU 都必须支持的格式，所以一定能上传成功；
2026-10-26 02:05:28
217
原创 移动端贴图压缩格式选择：从原理到分发方案
GPU 压缩格式能同时降低包体、内存和带宽，前提是设备支持该格式；格式不受支持时会被 CPU 软解压为 RGBA32，内存可能膨胀近 10 倍甚至更多，加载也明显变慢；ETC2 是 Android 的兼容底线，ASTC 是画质和压缩率的最优解；海外 Google Play 用 TCFT 自动分发，国内渠道用"ETC2 首包 + ASTC 热更新"；按贴图用途设置 ASTC 块大小，并通过真机测试和自动化巡检，确保线上没有意外的软解压。
2026-10-26 01:48:31
130
原创 FPS 射击游戏的命中判定:权威、延迟补偿与公平性
联网 FPS 中,每个玩家屏幕上的画面都是不同时刻的世界。开枪的人、被打的人、服务器,三方对"目标在哪里"的答案各不相同,因此必须约定由谁来判定命中。服务器拥有最终判定权,并通过延迟补偿按开枪者当时看到的画面判定命中。散布等随机因素通过确定性随机数保证客户端与服务器一致。这套方案让开枪者"瞄准即命中",代价是被打的人偶尔会遇到"已经躲进掩体却仍然被击杀"。本文依次分析:问题来源、三种判定权威模型、延迟补偿的实现、随机散布的同步、公平性代价及缓解手段,最后讨论相关的作弊风险。玩家按下开火│▼。
2026-10-25 05:58:23
14
原创 散布随机数如何让客户端和服务器一致
1. 随机数是公式算出来的:同样的种子 + 同样的公式 = 同样的结果2. 种子 = 混合(比赛种子, 玩家 ID, 第几发, [第几颗弹丸])3. 每发子弹的种子独立计算,不共享一串随机数,避免错位4. 公式自己写,只用整数运算,不用 rand() 和标准库分布5. 散布大小由服务器自己算,不信任客户端6. 最终以服务器为准,客户端只负责"先猜一个给玩家看"
2026-10-25 04:50:10
179
原创 FPS 射击游戏中摄像机与枪口的矛盾
上一篇沿调用链跟踪了一次开枪的全过程,其中FireShot这条射线从哪里发出?是玩家的眼睛(摄像机),还是枪口?本文讨论这个问题。它看起来只是一个起点的选择,实际上牵涉到瞄准手感、近距离遮挡、第一人称渲染、第三人称视角和网络同步。:代码延续上一篇的简化自研引擎风格,类名和函数名为虚构,数学部分可以直接使用。
2026-10-25 03:10:10
5
原创 一次开枪的完整调用流程:从 USB 中断到 Present
硬件与内核:USB 轮询、中断、HID 驱动栈、Raw Input Thread,最终变成一条WM_INPUT消息。这一段通常只有一毫秒左右,而且基本不受游戏控制。平台层:消息泵取出消息,读取数据,打上时间戳,放入平台事件队列。消息在队列中等待了多久,取决于游戏线程何时运行消息泵。引擎主循环:先等待(交换链、低延迟 SDK、帧率限制),再采样。等待的位置是整条链路中最重要的一个调度决策。输入系统:把原始事件转换为带帧内时刻的"开火"动作边沿。游戏逻辑。
2026-10-25 02:40:15
5
原创 从按键到枪口火焰:一次开枪的延迟全链路解析
模式延迟特点画面特点VSync 关闭画完立即显示,延迟最低画面撕裂VSync 开启(双缓冲)画完要等下一次刷新,增加 0~1 个刷新周期无撕裂;帧率低于刷新率时会掉到整数分之一VSync 开启(三缓冲 / 队列式)可能额外增加一帧排队帧率更平稳,但延迟更高显示器刷新跟随帧的完成时间,接近关闭 VSync 的延迟无撕裂VRR 的常见建议是把帧率限制在刷新率之下几帧(例如 240Hz 显示器限制在约 225~237 fps)。
2026-10-25 00:52:18
7
原创 大白话聊聊：FPS 战斗系统（进阶篇③）：武器接入服务器位置，子弹从影子身上打出去
开枪也只是一种按键。服务器先替你走到那个位置，再替你扣下扳机，你屏幕上的子弹只是提前演给你看的。下一篇预告：进阶篇④——延迟补偿为什么你屏幕上的敌人总是"过去的敌人"：插值显示和渲染延迟；服务器把每个玩家每个 tick 的命中盒都存下来，形成一段"历史录像"；开枪时，客户端在输入里带上"我当时看到的是第几个 tick"；服务器把所有命中盒倒回那个时刻再做射线，然后再摆回来；最多能倒回多久，为什么要设上限；“我明明躲到墙后了还被打死”：延迟补偿的代价，以及各个游戏怎么取舍。
2026-10-24 06:54:54
7
原创 大白话聊聊：FPS 战斗系统（进阶篇②）：客户端预测与回滚，对不上就重来
客户端先走，服务器裁判。对上了什么都不做，对不上就从服务器的答案出发，把自己的输入重新走一遍。下一篇预告：进阶篇③——武器接入服务器位置把"开枪"也放进InputCmd，和移动输入走同一条线；服务器在执行第 N 个 tick 的移动之后，用自己算出来的位置和速度计算开枪位置和散布；射速、弹匣、换弹由服务器检查，"一秒开 100 枪"的外挂失效；删掉开枪消息里的origin和hSpeed，漏洞一正式补上；顺便把FakeServer改用FakeLink，两条线统一管理。
2026-10-24 06:46:04
10
原创 大白话聊聊：FPS 战斗系统（进阶篇①）：服务器权威移动，先让服务器自己走一遍
让客户端只报按键，让服务器用同一套规则自己走一遍。只要规则一样、输入一样，结果就一样。下一篇预告：进阶篇②——客户端预测与回滚服务器每隔几个 tick 把"第 N 个 tick 你在这里"寄回客户端；客户端翻出自己第 N 个 tick 的历史对答案；对不上就把状态改成服务器的，再把 N 之后的输入重新跑一遍；怎样让纠正过程不"瞬移"，看起来平滑；测试 3 和测试 4 里越走越远的影子，会在下一篇被拉回来。
2026-10-24 06:41:56
8
空空如也
it界所谓的35岁门槛
2025-07-03
5年Unity引擎游戏客户端月薪统计
2025-06-27
TA创建的收藏夹 TA关注的收藏夹
TA关注的人