phaser-brainstorm

构思一款 Phaser 4 游戏

设计文档之前的步骤。GDD 回答的是游戏如何运作；而这里要回答的是 什么样的游戏值得投入，以及这个人能否完成它。

大多数被放弃的游戏项目，并不是做得不好，而是范围定得不合理——从未根据可用时间和技能评估想法的规模，因此在敲下第一行代码之前，失败就已注定。

---

先明确实际固定的条件

在构思任何想法之前，先问清楚以下四个问题。它们排除的可能性比任何头脑风暴都多，而且现在排除成本更低：

问题	为什么它能决定方向
有多少时间？ 一个周末、一个月，还是一年？	这是影响最大的限制因素。周末游戏和一年游戏是不同类型的东西，而不是同一种东西的不同规模。
这是为谁做的？ 游戏创作马拉松、作品集、付费玩家，还是自己？	作品集项目要优化的是令人印象深刻的 30 秒体验；商业游戏要优化的是玩到第 20 个小时的体验。
你能制作或获取什么？ 美术、音频、两者都有，还是都没有？	如果没人会画画，游戏就必须是不依赖绘画的类型——这是实实在在的设计约束，不是什么需要道歉的局限。
你以前完成过什么？	这是预测一个人接下来能完成什么的最佳指标。第一款游戏和第五款游戏，值得得到不同的建议。

不要因为用户看起来很有热情，就跳过这一步直接构思想法。没有这些信息就生成的想法，无异于掷硬币；而对一个规模不合适的项目抱有热情，恰恰是接下来六个月付诸东流的原因。

---

然后找到核心亮点

游戏概念需要用一句话让人想玩。不是游戏类型——游戏类型只是货架，不是创意。

不是核心亮点	核心亮点
“一款平台游戏”	“一款只有音乐响起时才能移动的平台游戏”
“一款塔防游戏”	“一款防御塔是你杀死的敌人的塔防游戏”
“一款 RPG”	“一款队伍中的每个成员都会记得你如何对待他们的 RPG”

测试方法：你能否用一句话描述它，并且其中包含一个出乎意料的动词？ 如果这句话只是“游戏类型＋形容词”，就继续想。

以下方法往往比“再多想想”更有效：

• 颠覆一种惯例。 这个类型里的每款游戏都默认了什么？平台游戏默认你可以控制何时跳跃；潜行游戏默认你想要不被发现。
• 把一种机制放到别的类型里。 在竞速游戏里构筑卡组；在恋爱模拟游戏里放置防御塔。
• 从一项限制出发。 一个按钮。一块屏幕。不能输。没有文字。
• 从一种感受出发。 “做什么都稍微晚了一点。”“收拾整理。”然后找到能带来这种感受的机制。
• 从你实际能制作的东西出发。 如果你唯一能做的美术是剪影，那么一款关于影子的游戏就不是妥协——它的美术方向已经有了现成的解决方案。

诚实地估算规模

这一步决定游戏能否顺利推出。具体一点，也直白一点， 因为另一种结果就是六个月后发现自己错了。

范围	实际可行的目标	内容
周末 / Game Jam	一个机制，执行到位	1 种场景类型、1–2 种敌人、3–5 个关卡或无尽模式
1–2 周	一个机制加上成长系统	菜单、游戏玩法、游戏结束界面、8–12 个关卡、存档
1–2 个月	一款小型完整游戏	3–4 种机制、20 个以上关卡或程序生成、音频、打磨
3–6 个月	一款商业化小型游戏	完整的成长系统、多样化内容、教程、设置、发行
1 年以上	不要从这里起步	—

把每项估算都乘以三。这不是玩笑——游戏开发者的估算与实际测量结果之间，大致就是这个比例，而且不论经验多少，情况都一样。

时间实际上花在哪里。 大家会估算核心机制，却忘了其他部分：

工作	占项目的比例
核心机制	20%
菜单、设置、存档、暂停、场景切换	25%
内容——关卡、敌人、平衡性	30%
音频、表现力、打磨	15%
错误、平台问题、发行	10%

核心机制做完的“简单平台游戏”只完成了 20%，离完成还远得很。这张表最适合拿给那些觉得自己快做完的人看。

缩减范围

如果创意超出时间限制，就删减内容，而不是核心卖点。只有一个出色机制和四个关卡的游戏是完整的。五种机制都只完成一半的游戏就不算游戏。

删减这些	保留这些
关卡、敌人、武器的数量	让游戏变得有趣的那一点
多人游戏	手感和响应速度
故事、过场动画、配音	核心循环
程序生成	可用的存档 / 读档
多个结局	一个结局

对多人游戏要特别提醒：它不是增加一个功能，而是让整个项目的复杂度倍增。网络代码、同步、大厅，以及每个错误都变成两个错误。除非多人游戏本身就是核心卖点，否则就删掉它。

---

承诺之前，先经受压力测试

六个问题。现在发现答案站不住脚，代价很小；到了第三个月才发现，代价就很大。

1. 玩家每时每刻都在做什么？ 如果答案要讲一段话，说明游戏循环还不清晰。“在平台之间跳跃，同时躲避不断塌陷的地板”就很清楚。
2. 为什么第二分钟比第一分钟更有趣？ 如果答不上来，就说明没有成长系统；游戏只是个小玩具——参加 Game Jam 无妨，但做任何更长的项目都致命。
3. 玩家会在哪里犯错，又该如何学会？ 没有失败状态的游戏就没有紧张感；失败了却无从学习的游戏则只是蛮不讲理。
4. 要证明创意可行，最小的版本是什么？ 那就是你的原型，应该花几天而不是几周完成。
5. 什么因素可能让项目夭折？ 现在就说出技术风险。“我不知道能不能把物理效果做对”就该先做原型验证，而不是到第六周才发现。
6. 你自己会玩吗？ 不是“这游戏卖不卖得出去”。如果诚实的答案是否定的，那么花六个月做它会比听起来更糟。

---

适合 Phaser 4 吗？

Phaser 是一款 2D WebGL 引擎。它很擅长某些事情，但也有不适合它的领域；现在就坦诚说明会更好。

非常适合： 平台跳跃游戏、俯视角动作游戏、解谜游戏、塔防游戏、射击游戏、卡牌和棋盘游戏、Roguelike 游戏、无尽跑酷游戏、视觉小说、各类基于图块的游戏，以及所有面向浏览器运行的 2D 游戏。

付出努力即可实现： 物理模拟要求高的沙盒游戏（Matter 能胜任，但要求较高）、大型开放世界（需要分块和剔除）、节奏游戏（真正的问题是浏览器音频延迟，而不是 Phaser）、实时多人游戏（Phaser 仅负责客户端；服务端是独立项目）。

不适合： 3D。Phaser 4 的渲染器是 2D 的——正式的 3D 支持已列入计划，但目前尚未实现。请使用 Three.js 或 Babylon。此外还有纯文本游戏，使用 Web 框架会更简单。

Phaser 4 的具体优势： Beam 渲染器能处理的屏幕内容远超 v3；滤镜可应用于任意对象；SpriteGPULayer 让弹幕游戏中的海量子弹成为现实；锥形光照让潜行视野锥的实现成本很低。如果创意依赖光照、特效或海量精灵，v4 已经改变了哪些效果可以经济地实现——请参阅 skills/phaser-fx/。

---

交付内容

最后给出用户可以采取行动的方案，而不是罗列选项：

1. 创意概念，用一句话说明，并突出核心亮点。
2. 范围判断，说明时间预算以及为控制范围而删减的内容。
3. 原型，具体说明包含什么、验证什么，以及预计耗时。按天计算。
4. 明确的风险——最可能导致项目失败的一件事，以及原型如何验证它。
5. 下一步： 使用 /phaser-gdd 编写设计文档，或使用 /phaser-new 立即搭建并制作原型。

如果用户提出了多个创意，推荐其中一个并说明理由。排序列表只是在回避决策，而用户需要的正是这个决策。

---

先做原型，再做设计

凡是开发周期长于 Game Jam 的项目，都应在编写 GDD 之前制作原型。没人体验过的机制，其设计文档就像虚构故事——你会为一个最终感觉不对劲的跳跃机制写上三页。

原型只回答一个问题：核心机制玩起来感觉好吗？ 用彩色矩形就够了。不需要菜单、美术、音频或存档。

/phaser-new              # scaffold
# build the one mechanic
/phaser-playtest         # verify it actually runs

然后亲自试玩。如果用矩形做出来都不好玩，美术也救不了它——而用三天而不是三个月就发现这一点，是整个步骤中价值最高的成果。

---

其他资源

参考文件

• references/ideation-prompts.md — 当用户卡住时可用的结构化创意生成工具：约束提示词、机制反转、类型混搭，以及将模糊感受转化为具体机制的问题。
• references/scope-calibration.md — 真实游戏类型的范围拆解示例，按系统估算所需小时数，并说明项目超时后的删减顺序。

相关内容

• skills/phaser-gdd/ — 下一步：将已确定的创意转化为设计文档
• skills/phaser-init/references/template-archetypes.md — 九种现成的游戏类型模板，既可用作起点，也可帮助了解各类型实际包含的内容
• skills/phaser-architect/ — 设计完成后的技术架构