Phaser 性能预算：60 帧不是口号，是每一帧怎么花钱
从一个真实问题开始 测试机上 60 帧，线上用户反馈卡。这个场景太常见了：开发机 Chrome 很顺，低端安卓 WebView 里一开技能雨就掉到 25 帧。性能问题不是上线前压一遍 profiler 就能解决，它需要从玩法设计阶段就有预算。
posts
游戏开发专题：服务端、引擎与独立游戏
游戏开发是一个横跨客户端渲染、服务端架构、网络同步、音频物理、美术管道与商业运营的综合性领域。本专题系统覆盖 H5 游戏产业全景与技术选型、游戏服务端从入门到高级进阶（网络协议、状态同步、匹配系统、反作弊）、Lua 与 Rust 游戏技术栈演进路径、游戏商业指标（LTV/ARPU/留存/付费）与制作人知识储备、游戏引擎对比（Unity/Unreal/Godot/Defold/Phaser）、以及客户端引擎与渲染方向的深度补全（ECS 实体组件系统、场景图与帧循环、渲染管线与合批、物理碰撞与约束求解、游戏 AI 行为树与寻路、帧同步与回滚网络、性能剖析与平台优化），并扩展动画系统（骨骼/状态机/混合树/根运动）、音频系统（触发/3D 空间化/混音/动态音乐）、UI/HUD 系统（屏幕空间/数据绑定/生命周期/性能）、存档与序列化（结构/版本迁移/校验/云存档）、AI 感知与寻路（视野听觉/A* 优化/NavMesh/动态避障）、关卡与资源流式加载（切分/流式/优先级/加载屏）、从原型验证到上线运营的完整项目管线路径，为游戏开发者提供从创意到商业化的全方位指南。
Godot 动画 LOD 调度：远处角色少算一点，也不能突然像木偶
为什么要单独治理 主城同屏 80 个角色时，帧率主要花在动画采样和骨骼更新上。团队把远处角色动画更新频率降到每秒 5 次，帧率上来了，但玩家看到远处 NPC 像卡顿的木偶，靠近时还会突然补动作。动画 LOD 不是粗暴降频，而是要按距离、屏幕占比、动作重要度和镜头焦点调度。
Godot 画质动态缩放：分辨率、阴影和特效的运行时调节
背景：运行时画质动态缩放不是一个孤立功能 画质设置不是设置页里几个下拉框那么简单。低端设备进入战斗后掉帧，玩家不会去逐项研究阴影、粒子和后处理；高端设备又不希望被保守默认浪费。我们在做移动端 3D 场景时，最初只提供低中高三档，结果同一档在不同机型表现差异很大。
Phaser 插件化架构：可复用系统不要靠复制 Scene 代码
复制 Scene 是最快的技术债 活动小游戏团队经常同时维护多个 Phaser 项目。第一个项目写了 Loading、音频、弹窗、埋点、广告奖励和调试面板。第二个项目为了赶时间，直接复制一份。第三个项目又从第二个复制，顺手改了几个字段。半年后，三个项目都有类似系统，但 Bug 修复要改三遍，接口还不完全一样。
Godot 动画事件编辑工具：让命中、音效和特效不再靠猜帧
动作游戏里，很多体验差异藏在几帧之内。攻击命中窗口早两帧，手感会飘；音效晚一帧，打击感会空；特效挂点不对，角色动作再好也显得廉价。Godot 的 AnimationPlayer 能在时间轴上调用方法，但如果团队完全靠手动插 Call Method Track，后期维护会非常辛苦。
Phaser 游戏存档设计：localStorage 能救急，不能背整套经济系统
从 Phaser H5 游戏的本地存档、IndexedDB、localStorage、版本迁移和云同步冲突入手，讨论可靠存档设计。
Godot 运行时配置中心：远程参数、灰度与客户端保护线
背景：运行时配置中心为什么值得单独设计 运营活动、数值调节、入口开关、广告频控、下载地址、公告策略都希望不发版就能调整。远程配置因此很快进入 Godot 客户端。刚开始大家只是在启动时拉一个 JSON，解析后全局使用。
Godot 运行时纹理压缩 fallback：设备不支持时别把角色涂成紫色
为什么要单独治理 美术导出了一批 ASTC 纹理，测试机表现正常，线上某些低端 Android 设备却显示紫色材质或黑块。客户端日志只记录资源加载失败，没有说明设备支持什么格式、选择了哪个变体、fallback 是否存在。纹理压缩不是导入设置里的一个选项，而是资源分发、设备能力探测和运行时选择共同决定的系统。
Phaser 小地图与战争迷雾：探索状态要比画一个缩略图更可靠
小地图不是把场景缩小 很多 Phaser 项目第一次做小地图，会想到把整个地图截图缩小放到角落。这样能快速看到布局，但很快会遇到问题：未探索区域不该显示，动态敌人要更新，宝箱开过要变状态，地图太大时截图成本高，移动端小地图还会挡住操作。真正可上线的小地图不是缩略图，而是地图状态的可视化。
Phaser 剧情对话与演出系统：跳过、恢复和时间线都要先设计
剧情系统不是把文字打出来 很多 Phaser 小游戏最初只需要一句提示：“公主被困住了，去救她。”于是工程写一个半透明框、一个 Text、一个点击下一句。后来项目加了角色立绘、打字机效果、镜头移动、角色入场、屏幕震动、选项分支、跳过按钮和断线恢复，原来的对话框就开始撑不住了。
Godot 场景 Diff 评审工作流：让 .tscn 变更不再像盲盒
Godot 的 文本格式是协作优势，也是评审难点。它能进 git，能做 diff，但真实 review 时经常像盲盒：一堆节点顺序变化、资源 id 重排、导出字段移动，reviewer 很难判断到底改了什么。尤其当关卡、美术和程序同时改一个场景，冲突解决就更痛苦。
Godot RichTextLabel 内容渲染：公告、邮件与运营文本的安全边界
背景：富文本内容渲染不是一个孤立功能 运营公告、邮件、活动说明、礼包规则都需要富文本：变色、加粗、图标、链接、道具名、倒计时。Godot 的 RichTextLabel 支持 BBCode，看起来直接把服务端文本塞进去就行。
Godot 输入录制与回放：把偶现战斗 Bug 变成可复现样本
背景：输入录制与回放为什么值得单独设计 动作游戏和战斗系统最怕偶现问题。测试说“有一次翻滚后角色卡进墙里”，录屏里只能看到结果，看不到每一帧输入、随机数、碰撞状态和角色状态机切换。程序按感觉重试半天复现不了。
Phaser 移动端输入与音频策略：点击开始不是多余按钮
从一个真实问题开始 桌面浏览器里一切正常，发到手机上以后问题变得离散：背景音乐不播，第一次点击没有效果，滑动页面时游戏跟着滚，切到微信聊天再回来角色一直往右走。很多人把这些归为“移动端兼容性差”，但项目需要的是明确的输入和音频策略。
Phaser 角色换装与 Avatar 分层：皮肤预览不能只换一张图
换装系统很快会超过“换图” 小游戏早期的皮肤系统通常很简单：玩家选择红色角色，就把 换成 。如果每个皮肤都只有一整套图，这样能跑。但只要加入帽子、武器、翅膀、表情、染色、稀有特效和商店预览，单张图方案就会失控。每个组合都导出一套图，资源数量会爆炸；动画稍微改一帧，所有皮肤都要重导。
Godot 存档损坏隔离：读不出来时先别急着覆盖玩家进度
为什么要单独治理 玩家启动游戏时，本地存档 JSON 解析失败。最坏的客户端会把失败当成“没有存档”，直接创建新档并覆盖旧文件。更隐蔽的问题是部分字段读取失败，游戏用默认值继续启动，几分钟后自动存档把损坏状态写成正式状态。存档损坏时，第一原则不是立刻修好，而是隔离证据，保住可恢复空间。
Godot 内置关卡编辑器：UGC 创作、校验与运行时沙盒
背景：UGC 关卡编辑器不是一个孤立功能 让玩家自己搭关卡很有吸引力：摆平台、放敌人、设计机关、分享给好友。Godot 的场景系统看起来天然适合编辑器，节点拖一拖就能组成玩法。但面向玩家的 UGC 编辑器不能直接暴露真实场景树。
Godot 存档迁移测试夹具：版本升级时别赌玩家进度
存档系统最容易被低估。新功能上线前，团队通常会测试新建账号、新建存档、当前版本读写是否正常，却很容易忽略老玩家的真实存档。等版本发布后，才发现三个月前的存档缺少字段，某个任务状态无法迁移，或者背包里已经下架的道具让读取流程卡住。
Phaser 联机小游戏状态同步：插值、预测和回滚边界
联机不是把位置广播出去 Phaser 很适合做轻量联机小游戏，WebSocket 一接，玩家位置一发，其他人一收，看起来就能跑。但真实上线后会马上遇到问题：远端玩家抖动，本地玩家被服务器拉回，攻击看起来命中却没伤害，弱网玩家像瞬移，结算结果和画面不一致。联机难点不在 Phaser，而在状态权威和表现延迟之间的取舍。
Phaser 程序化地牢生成：随机种子、房间连接和可玩性校验
随机地牢最怕随机到不能玩 程序化地牢听起来很适合 Phaser 小游戏：每局地图不同，内容复用率高，玩家也有新鲜感。但随机生成不是把房间随便摆一摆。真正上线后，玩家会遇到门被墙挡住、出生点离出口太近、关键钥匙刷在不可达区域、Boss 房前没有补给、怪物密度忽高忽低。随机的结果必须可玩、可解释、可复现。