生成独一无二的宝可梦：游戏内研究原型

概要

我制作了一个研究原型，根据玩家在游戏中选择的六个词，生成新的宝可梦种类。几分钟后，它会出现在草丛里，玩家可以与它相遇、捕捉它并给它起昵称。原型会生成外观、名字、属性、种族值、招式，以及将其整合进游戏所需的数据。

原型将游戏内对话、词语选择、后台生成、野外相遇、捕捉和命名连成一个完整体验，无需中断游戏。每个生成的新种类都会以现有游戏系统可使用的形式注册。

我的重点是生成框架，而非模型本身：定义维护游戏平衡与视觉一致性的要求，再让 AI 在这些边界内探索。我也亲自试玩原型，初步考察“独一无二”这一点是否足以让人对角色产生依恋。

问题——如果是独一无二的，会产生依恋吗

游戏让玩家选择、培养角色，并为它们命名，逐渐觉得角色独属于自己。不过，起点仍是开发者预先准备的选项。如果生成式 AI 让玩家从一开始就参与塑造角色，他们是否会产生更强的依恋？

要验证这个问题，仅生成一张图片是不够的。生成的存在需要进入游戏世界，遇见、捕捉，并且之后还能使用。因此，准备了两个玩家参与度不同的入口。与爷爷交谈时无需输入即可生成，而与奶奶交谈时玩家需要选择六个词。首次交谈的那一方决定了该次游戏的生成方式。

这个原型并不能对依恋感得出结论。它的目的是将生成内容融入日常游玩，并找出适合后续比较的条件。

游戏流程

以下展示玩家参与生成的流程。在 Petalburg Woods，玩家与老奶奶交谈，从游戏原有的 Easy Chat 词库中选择六个词。玩家继续游玩时，生成过程在后台运行。叫声提示新种类已准备就绪；进入草丛后即可与它相遇，并按通常的操作捕捉。每次生成都会产生名字、属性、种族值、招式、正面与背面的战斗精灵图，以及队伍图标。完整流程见演示视频。

设计挑战：让生成的角色融入玩法

生成新角色和让它在游戏中正常运作，是两个不同的问题。能力值过高可能破坏难度平衡，属性与招式不匹配可能让角色难以培养。过于复杂的外形在缩小为 64 × 64 像素的精灵图后，可能变得难以辨认。

另一方面，如果把一切都固定起来，就没有在每次执行时产生不同东西的意义。必要的不是消除AI的自由，而是区分作为游戏需要守住的部分和允许变化的部分。

因此，我关注的是设计能够生成哪些宝可梦的可能性空间，而不是单个角色。人来定义目标、约束、禁止内容与验证方法，AI 在这一框架内提出候选方案。这个可运行原型将我以约束驱动设计的思路付诸实践。

方法：定义生成条件

系统要求大语言模型（LLM）填写名称、属性、种族值、招式、体型和颜色等预定字段，而非撰写自由文本。验证器逐项检查响应，通过后才予以采用。如果响应违反规则，系统会反馈具体违规项，要求模型重新生成，直到满足要求。

1. 人来定义边界。将游戏平衡、易于辨认的精灵图和可接受内容等要求，转化为明确、可检查的规则。
2. AI 提出候选方案。模型根据玩家选择的词语，为允许填写的字段提出具体数值或内容。
3. 系统按规则检查输出。自动核对数值范围、招式组合和禁止内容。
4. 只反馈违规项。违反规则的候选方案会连同原因一起退回，要求重新生成。

维护玩法的约束。种族值总和设为 280–360，各项能力值也设有上下限。招式从游戏源码中提取，只允许与该种类属性相同的招式或一般属性招式。排除一击必杀、自爆、固定伤害和威力过高的招式。验证器还检查攻击招式数量，以及是否具有与自身属性相同的招式。捕获率、成长速度等因素固定，使生成结果之间的差异保持在便于比较的范围内。

保持视觉清晰的约束。体型从缩小为精灵图后仍能清楚辨认轮廓的选项中选择，颜色与特征的词汇也受到限制。排除类人特征、血液、武器和文字。图像生成指令始终包含“仅一个生物”“展示全身”“不要多余肢体”等要求。

在某个记录中，模型最初提出了总种族值为380的方案。框架会检测违规并促使重新生成，最终收敛到320的规格。重要的是，不是偶然得到好的结果，而是设计了不采用偏离框架的结果的流程。

将体验在游戏内部完成

玩家只需在游戏中对话、选择词语和进入草丛相遇，无需另开生成界面。计算量大的工作由 PC 上的 Python 进程承担，通过文件与游戏交换数据。在 mGBA 模拟器中运行的 Lua 脚本连接二者，让游戏保留熟悉的操作方式，同时将 AI 处理放在外部。

1. 生成规格。本地语言模型将六个词转化为新种类的数据，经验证后使用。
2. 生成视觉素材。图像模型先创建参考插画，再生成视觉一致的正面、背面精灵图和队伍图标。
3. 转换为游戏数据。将图像减色至 15 色，再转换并压缩为 Game Boy Advance（GBA）兼容的精灵图与调色板。
4. 整合进正在运行的游戏。将数据写入预留区域，无需重启游戏即可加入新种类。

相同的数据也会写入磁盘，因此重新载入游戏后，生成的种类仍会保留。生成只进行一次，且无法撤销。玩家若在相遇时逃跑或落败，宝可梦仍留在世界中；若将其击败，它便不会再次出现。这种不可逆性让“这一轮游戏中仅此一只”成为体验的一部分。

在原型中确认的事项

我独立制作了这个原型，用于检验技术可行性。它并非完整游戏，也不构成用户研究。下文分别说明已经验证的内容、已经实现的功能，以及尚未测试的部分。

• 已完成端到端验证。在 mGBA 中，我确认了从游戏内对话、六词输入、后台生成、整合进运行中的游戏，到野外相遇、捕捉与输入昵称的完整流程。
• 为后续比较实现的功能。我加入了两种入口：无需输入的“被动生成”，以及通过选择词语引导生成的“玩家参与生成”。系统可记录对话、相遇和捕捉情况，供后续比较。
• 已接入现有系统，但尚未通过长时间游玩测试。捕捉后的升级、学习招式、对战、存入盒子，以及保存后继续使用，均已与现有游戏系统衔接。我尚未通过长时间游玩检验这些功能。
• 后续工作。在游玩过程中生成进化形态的功能尚未实现，也尚未开展多名参与者的依恋感比较研究。

自己尝试的结果——仅仅因为独一无二，并没有产生依恋

根据我自己试玩原型的情况，对生成的宝可梦没有产生强烈的感情。这只是开发者本人一个人的感想，不能作为普遍化的实验结果。不过，这为思考接下来应该改变什么进行比较提供了一些线索。

有两个因素值得进一步研究。

• 生成质量。如果外观和角色设定不够吸引人，仅凭“这一轮游戏中仅此一只”，可能不足以维持依恋感。
• 参与深度。只选择六个词，让我觉得结果更像是交到我手里的，而不是由我创作的。我推测，参与感取决于创作过程的质量：重新考虑选择、比较方案、修改细节，以及对结果负责，而不只是增加输入量。

相比之下，我对花狐（Hanagitsune）产生了感情。它是在游戏的自动生成流程之外，通过与多个生成式 AI 工具反复对话、手动完善而创作的角色。我比较候选方案、修正细节，直到自己满意。我认为，结果的质量和反复修改过程中的投入，共同促成了这份感情。

这个原型并没有回答“生成内容会产生依恋吗”这个问题。它将原本模糊的问题，分解为两个可以有意改变的因素：生成物的质量和参与的深度。在下一步的验证中，需要在制作过程中加入选择、比较和修改，并在将生成物的质量统一到一定水平后，由多名参与者进行比较。

实现

生成管道、约束与验证框架、面向GBA的数据转换、游戏方面的修改内容，都在GitHub 仓库公开。