个人游戏免费序章策略：Prologue 不是免费试玩的另一个名字
一篇关于个人游戏免费序章和 Prologue 发行策略的文章，讨论独立商店页、内容边界、愿望单导流、评价风险、制作成本和正式版承接。
category
GameDev
共 185 篇文章。
Godot 战斗动画状态机：AnimationTree、命中窗口和表现事件
战斗动画不是播放一个 animation_name Godot 做动作游戏时，最容易的做法是在角色脚本里 。原型阶段够用，但战斗动作一多，问题会马上出现：移动和攻击怎么混合，受击能不能打断，翻滚何时无敌，命中判定在哪一帧打开，连招输入窗口怎么处理，服务器结果怎么和动画对齐。
个人游戏开发者成功案例：先做本地玩家社区的小众游戏
写在前面：小市场也可以足够真实 乔安做了一款关于地方夜市经营的模拟游戏。玩家经营一个小摊，从卖烤冷面开始，逐渐解锁饮品、炸串和临时摊位。游戏重点不是复杂经营，而是夜市里的人情味：熟客、摊主互助、城管检查、雨天客流。
个人游戏开发者失败案例：把社区反馈管成了压力源
写在前面：听玩家和被玩家拖着走不是一回事 江也做了一款小队战术游戏。玩家控制三名角色在狭窄街区里执行任务，核心玩法是利用视野、噪音和同步行动避开敌人。早期 Demo 反馈不错。玩家喜欢“像策划一次偷袭”的感觉。
Godot 工具脚本工作流：用 EditorPlugin 把重复劳动留在编辑器里
好的 Godot 项目会把重复劳动搬进编辑器 Godot 不只是运行时引擎，它的编辑器扩展能力也很实用。脚本、EditorPlugin、自定义 Inspector、导入插件都能把重复劳动自动化。很多团队忽略这一点，导致关卡配置靠手填、资源检查靠人工、命名错误到运行时才发现、策划每次调数值都要找程序。
个人游戏技术选型案例：Mod 支持为什么先从 JSON 关卡开始
一个个人策略游戏在无 Mod、JSON 关卡、Lua 脚本和 Steam Workshop 之间做技术选型的案例，详细讨论安全、编辑器、兼容性和维护范围。
个人游戏愿望单转化：发售前最后两周，不是只等系统通知
写在前面：愿望单不是自动付款名单 很多个人开发者看着愿望单数字，会自然产生安全感。1 万、3 万、5 万。数字越大，发售前越像已经完成一半。但愿望单不是订单。它只是玩家在某个时刻表达过兴趣。到真正发售时，他可能忘了游戏，可能没钱，可能在玩别的，可能已经不记得当初为什么点了愿望单。
Godot 网络客户端：把 WebSocket、状态同步和重连边界拆清楚
网络层不应该散在每个玩法脚本里 Godot 可以直接使用 HTTPRequest、WebSocketPeer、MultiplayerAPI 等能力。很多项目早期会在登录页写 HTTP 请求，在战斗脚本里写 WebSocket，在聊天 UI 里直接发消息。
个人游戏开发者成功案例：一个机制撑起的益智小品
写在前面：少机制也可以有深度 林晚做了一款极小的益智游戏。规则只有一句话：玩家每走一步，整个房间都会旋转 90 度。这听起来像一个 Game Jam 点子。林晚一开始也只是周末做着玩。但他没有继续往里面塞新系统，而是围绕这个机制做了 72 个关卡。
个人游戏开发者失败案例：存档系统最后才做的代价
写在前面：存档不是最后加上的按钮 孟舟做了一款横版动作冒险游戏。游戏有地图探索、道具收集、支线任务和角色升级。前期开发很顺，他能快速做新区域、新敌人和新能力。为了保持速度，他一直用调试入口测试。想测第三章，就直接从第三章开始；想测某个技能，就在编辑器里勾选。
Godot 移动端导出与性能：从编辑器流畅到真机稳定
编辑器里流畅不代表手机上稳定 Godot 在桌面编辑器里跑得很顺，不代表导出到手机也顺。移动端有完全不同的约束：GPU 带宽、纹理格式、内存上限、发热降频、后台生命周期、触控延迟、安装包大小。很多问题只有真机导出后才暴露：第一帧黑屏太久，某些材质变粉，低端机切场景崩溃，玩十分钟后帧率下降。
个人游戏技术选型案例：发布流程为什么从手动打包改成半自动管线
一个个人游戏在手动导出、脚本化构建和完整 CI/CD 之间做技术选型的案例，详细讨论版本号、平台包、校验清单、Steam 上传和发布风险。
Godot 存档系统：Resource、JSON 和版本迁移怎么选
存档问题通常不是写文件，而是几年后还能读 Godot 做单机、买断制、轻联网项目时，本地存档非常关键。很多原型直接把字典转 JSON 写进 ，能存能读，看起来就完成了。真正上线后，问题会变复杂：版本更新后字段变了怎么办，写到一半断电怎么办，玩家改文件怎么办，云存档冲突怎么办，多角色 profile 怎么隔离，调试...
个人游戏开发者成功案例：从 Mod 走向独立游戏
写在前面：他没有一开始就做完整游戏 赵临最早做的不是独立游戏，而是一个生存游戏 Mod。这个 Mod 改动很小：它让玩家可以经营一个移动营地。营地会消耗燃料，需要选择停靠地点，还会根据路线遇到不同事件。
个人游戏海外发行：不要一开始就把全世界当成目标市场
写在前面：全球发行听起来很大，也很容易失焦 Steam、itch、App Store 和各种主机平台，让个人游戏看起来可以天然面向全球。页面可以开多语言。价格可以覆盖几十个地区。社交媒体也没有国界。但真正做发行时，个人开发者很快会发现：全世界太大了。
Godot UI 开发：Control、Container 和主题系统的响应式组织
Godot UI 不是把 Control 拖到看起来对的位置 Godot 的 Control 系统上手很快，拖按钮、改 Anchor、调 Margin，就能做出界面。问题是如果每个页面都靠手调坐标，到了多分辨率、移动端安全区、语言变长、手柄焦点、主题换肤时，界面会不断破。
个人游戏开发者失败案例：先画世界再找玩法的 RPG
写在前面：漂亮世界不能替代玩家行为 何霁是一名美术出身的个人开发者。他想做一款俯视角 RPG。故事发生在漂浮群岛上，每座岛都有不同风俗和神话。早期概念图非常漂亮：云海、断桥、风车塔、背着玻璃灯的旅人。
个人游戏技术选型案例：音频系统为什么没有一开始就接 FMOD
一个个人叙事探索游戏在引擎内置音频、FMOD 和自定义音频管理之间做技术选型的案例，详细讨论动态音乐、环境声、混音、授权和制作成本。
个人游戏开发者成功案例：90 分钟恐怖短篇带来的稳定回报
写在前面：短不是缺点，松散才是 白承做了一款 90 分钟的恐怖短篇。游戏场景只有一个：凌晨两点的自助洗衣店。玩家一边等衣服烘干，一边发现店里不断出现不属于自己的物品：儿童鞋、旧病历、带水渍的照片。这个项目没有庞大世界观。
Godot 输入系统实践：InputMap、手柄和移动端触控如何统一
输入系统先抽象意图，再处理设备 Godot 的 InputMap 很适合做动作映射： 、 、 、 。但很多项目仍然在脚本里直接判断键盘按键、鼠标按钮或屏幕触点。这样一开始很快，后来要支持手柄、移动端、键位重绑定、无障碍设置时，就会非常痛苦。