喷火龙使出了「火焰拳」！乍看之下只是简单的行动，却会因为天气、特性、持有物等要素的组合，使结果产生大幅变化。超过 1000 种宝可梦、900 种以上招式，再加上 300 种以上特性与 200 种以上道具，这些庞大的设定资料彼此影响而形成的战斗逻辑，究竟是如何在每次推出新作时持续扩张，同时维持整合性的呢？
此外，2025 年发售的《宝可梦传说 Z-A》（以下简称 Z-A）采用了即时制战斗，这套系统又是如何与过往的回合制战斗共享基础架构的呢？这些令人好奇的问题，在 7 月 22 日于「CEDEC 2026」举办的讲座「支撑宝可梦对战进化的战斗系统基础设计与运用事例」中获得了解答。
本次登坛的讲者，是隶属于 GAME FREAK 研究开发部「宝可梦・战斗系统团队」的宗像快与小幡敏宏。
- 宗像于 2016 年入职，并从《精灵宝可梦 究极之日／究极之月》系列开始参与开发，
目前仍在同一团队担任主程式，负责过场演出、招式演出等与时间轴相关的程式。
小幡则是在 2009 年入职，从《宝可梦 黑／白》系列参与开发，
目前以跨专案的方式，负责战斗逻辑相关资料的维护与开发。
就算使用同个招式，也不会发生同样的事
宗像快首先展示了三项宝可梦战斗的特征。第一个，便是战斗系统使用的设定资料有多么庞大。总数超过 2400 种类，且每次的新作总是会追加宝可梦与招式等合计 200 种类以上的资料。正是因为如此庞大的资料才造就了战斗的多样性，却也很难维护品质。
第二个是被动技能。不用玩家操作，只需要达成条件就能自动发挥效果。作为举例的特性「威吓」，在战斗出场的时候，就会降低对手一阶的攻击力。
这类处理并非单纯插入一段效果就能解决，有时甚至会发生递回计算，因此必须能够控制复杂的处理顺序。
第三个，便是在战斗中的数值会时时刻刻变化。宗像快接著以甲贺忍蛙的特性「变幻自如」为例，甲贺忍蛙原本同时具备水属性与恶属性，但在使出招式前，特性会发动，使自身属性变为与该招式相同的属性。也就是说，若甲贺忍蛙选择飞行属性招式，那牠自身也会变成飞行属性。
这三项要素彼此影响，使得《宝可梦》的战斗系统变得更加复杂。若各专案都各自开发，就必须一边考量庞大的组合数量，一边维持品质，这是相当困难的事。因此，宗像氏等人的「宝可梦・战斗系统团队」会跨专案参与所有《宝可梦》作品，并支援战斗系统的实作。
接著换小幡敏宏上场，针对基础设计的说明进行演讲。一开始向听众显示本次讲座中，「战斗系统」的定义。举例来说，「火焰拳」是火属性的攻击招式，并有 10% 机率让对手陷入「灼伤」状态。现场播放的示范影片中，皮卡丘正是受到喷火龙攻击后陷入灼伤。
那么，如果让喷火龙携带道具「樱子果」，皮卡丘的特性为「静电」，并且让天气设定为「晴天」的话，结果会怎么变化呢？
结果会大幅改变。由于「晴天」效果会提升火属性招式的伤害，而当皮卡丘的特性「静电」发动时，进行攻击的喷火龙会陷入「麻痺」状态。接著，喷火龙持有的「樱子果」会发动，恢复牠的麻痺状态。即便只是同一招「火焰拳」，也会依照状况产生复数不同的连锁反应。
小幡氏将战斗系统定义为：接收「由谁，做了什么」这样的行动资料，并加入特性、道具、天气等状况后，决定「会发生什么事」的机制。
在实际对战中，对手的行动以及增益、减益效果也会介入，使现场发生的现象更加复杂。招式、特性、道具会随著系列作品持续增加，而过去登场过的规格，也必须保证在后续作品中维持相同运作。因此，《宝可梦》系列的战斗逻辑，可以说是必须跨作品维持品质与整合性。
利用「Section」与「Event」切分游戏逻辑与个别规格
小幡敏宏接著先提出了一个设计思维，说明了战斗系统再构造的背景故事。在初代《红／绿》，是没有特性也没有持有物的简单战斗，到了《金／银》世代加入了新属性与天气，到了《红宝石／蓝宝石》世代则是加入了特性与双打对战。在之后的作品还导入了三打对战、超级进化等机制，但在实作上仍是在既有系统之下进行扩张。
而在 2016 年的《精灵宝可梦 太阳／月亮》则成为一大转捩点。当时登场的皇家对战，使团队必须实作以往架构无法完整对应的多种战斗规则。
随著战斗系统不断进化，程式也持续扩张，并逐渐产生档案肥大化、类别职责过多、紧密耦合、函式巨大化等问题。这些问题互相牵连，导致团队难以安全地追加新规格，也可能损害战斗系统的维护性与扩充性。
在《太阳／月亮》开发结束时，宗像等人的战斗系统团队判断，若继续沿用原本的程式架构，将无法对应今后战斗系统的进化，因此决定将既有系统改造成清楚且具弹性的结构。于是，「宝可梦・战斗系统团队」就此成立，并在《宝可梦 剑／盾》开发时进行系统重构。
新的战斗系统设定了四项要求：不论由谁实作都会采用相同结构的「结构化」；不改动既有程式码也能追加招式与特性的「扩充性」；能以少量修改对应规格变更的「弹性」；以及容易理解、修正与除错的「维护性」。其中，弹性与维护性往往是实现结构化与扩充性后所获得的成果，因此讲座接下来主要聚焦于前两者。
团队最一开始著手的，是游戏逻辑的结构化。这部分导入了名为「Section」的机制。再次以「火焰拳」为例，处理流程会依序进行攻击力决定、防御力决定、伤害计算、HP 减少等步骤，而攻击力还会加入天气「晴天」的补正。
流程本身虽然单纯，但若以原本方式将大量招式、特性、道具全都组合进计算中，游戏逻辑就会变得相当复杂。于是，团队将「要以什么顺序计算哪些内容」的部分定义为「游戏逻辑」，并将招式、特性、道具各自的处理切分为「个别规格」。在上述例子中，天气「晴天」的效果就属于个别规格。
「Section」则是游戏逻辑的最小单位。透过连接「攻击力决定 Section」与「防御力决定 Section」等单位，便能表现处理流程。
小幡接著强调，决定攻击力的 Section 并不包含「天气加成 1.5 倍」这类个别规格。Section 只定义游戏逻辑的进行，并将个别效果切分出去。透过这样的职责分工，就能抑制结构复杂化与实作方式的差异。
Section 也能对应阶层结构。团队会将攻击力决定、防御力决定、伤害计算整理为「伤害计算 Section」，再将 HP 减少也加入其中，形成「给予伤害 Section」。接著，由上位的「招式效果 Section」统整这些处理。像「火焰拳」这类具备追加效果的招式，则能再把「赋予异常状态 Section」加入机制中运算。
接下来说明的是扩充性。在《宝可梦》的战斗系统中，不改动既有程式码也能追加招式与特性，并且能在建置时排除不需要的规格，这就是此处所说的扩充性。
以「攻击力决定 Section」为例，除了天气「晴天」之外，还有特性「猛火」「大力士」「毅力」，道具「讲究头带」「电气球」「粗骨头」等许多补正因素。若将这些补正全部直接堆叠在 Section 里，就会降低维护性。
负责扩充性的，是「Event」与「EventHandler」。当 Section 触发 Event 时，对应的 EventHandler 便会反应，并对计算结果进行补正。Event 可以说是让个别规格介入 Section 处理的接点，使游戏逻辑本体不必改动，也能追加新的效果。
当攻击力决定 Section 触发攻击力补正 Event 时，天气「晴天」的 EventHandler 便会反应，对攻击力套用 1.5 倍补正。若特性「猛火」与道具「讲究头带」的 EventHandler 也依照条件介入，就能叠加复数效果，计算出最终攻击力。
当然，也会出现一个 EventHandler 对复数 Event 产生反应的情况。天气「晴天」一方面会让火属性招式威力提升为 1.5 倍，另一方面也会让受到水属性招式的伤害降低为 0.5 倍。因此，晴天的 EventHandler 能同时对应攻击力补正 Event 与防御力补正 Event。
若将相同运算交给 Section 处理，关于晴天的程式码就会分散到多个地方。但若以 EventHandler 集中管理，就能更容易掌握与修正规格。
小幡接著归纳出 Event／EventHandler 的三项优点：不改变主要逻辑即可追加个别规格；不需要的功能可以在建置时移除；以及像超级进化或太晶化这类并非每部作品都会登场的大型机制，可以与游戏逻辑本体完全切分开来。至于不会出现在该作品中的招式、特性、道具等，只要不登录对应的 EventHandler，就能在建置时排除。
这样的结构还承担了另一项职责，那就是《宝可梦》对战特有的「插入处理与连锁」。以开头举例来说，皮卡丘的「静电」会插入「火焰拳」的处理，接著喷火龙的「樱子果」又会发动。
若要将这些直接写进游戏流程中，每次新增招式、特性、道具时，都必须追加 Section 的呼叫，结构复杂化也会变得无法抑制。因此，团队让 EventHandler 具备呼叫任意 Section 的功能，使其不只可以介入计算结果，也能让新的现象发生。
具体来说，团队会在招式效果 Section 最后放置「招式效果后处理 Section」，并从该处触发反应 Event。起反应的「静电」EventHandler 若呼叫「赋予异常状态 Section」，喷火龙就会陷入麻痺状态。接著，收到异常状态 Event 的「樱子果」EventHandler 会呼叫「恢复异常状态 Section」，治好持有者的麻痺。
当 Section 触发 Event，EventHandler 再呼叫其他 Section，透过这样的递回结构，就能以共通机制处理复杂的插入处理与连锁效果。
「赋予异常状态 Section」不只可以用于「火焰拳」让皮卡丘陷入灼伤的情况，也能用于喷火龙因「静电」而陷入麻痺的情况。不过，最一开始的异常状态 Event 并不会满足「樱子果」的发动条件，因为当时喷火龙尚未陷入异常状态。
像这样，EventHandler 只会在满足条件时呼叫下一个 Section。透过以递回方式连结共通处理的结构，便能支援被动技能造成的插入处理与连锁。
将游戏逻辑切分为 Section，并以 Event／EventHandler 将个别规格分离出来。透过这样的结构，不仅能确保再利用性与扩充性，也能维持整个系列战斗系统的品质与整合性。
回合制与即时制，在同一套基础上运作
接下来，宗像解说了这套系统在《Z-A》中的运用实例。在《Z-A》中，招式的攻击距离与范围、出招时机，以及宝可梦的站位都会大幅影响胜负。训练家会与宝可梦一起移动，并在使用招式的同时回避攻击或替换宝可梦，是系列首次采用的即时制战斗。
宗像表示：「先从结论来说，即使是完全不同的战斗形式，也使用了相同的战斗系统。」而让这件事得以实现的要素之一，正是游戏逻辑的结构化。
在《宝可梦 剑／盾》与《宝可梦 朱／紫》的回合制战斗中，系统使用的是统整一回合内行动，并输出该段期间会发生哪些现象的「行动执行 Section」。
选择招式后，处理会从「招式效果 Section」开始，依序进入「发动判定 Section」「命中判定 Section」「给予伤害 Section」。发动判定会确认宝可梦是否因「冰冻」状态等原因无法行动；命中判定则会依照招式命中率与对手回避率等因素计算是否成功。最后的给予伤害 Section，则会参照属性相克来决定伤害。
但是在即时制中，战况会随时变化，因此无法使用以一回合为单位处理的「行动执行 Section」与「招式效果 Section」。命中判定也会改由碰撞体彼此接触，也就是俗称的碰撞判定来取代。另一方面，「发动判定 Section」与「给予伤害 Section」则能在不改变规格的情况下再利用。
宗像提到：「从 Section 的观点来看，回合制战斗中使用过的 Section 有许多都能再利用，因此不能说这是完全不同类型的战斗。」能依照规格调整呼叫 Section 的顺序或内部处理，并只选择必要项目，正是因为基础设计已经结构化。
在《Z-A》中，只要按下招式按钮，就会呼叫发动判定 Section；若符合使用条件，宝可梦就会使出招式。接著系统会根据碰撞体之间的碰撞判断是否命中，若成功命中对手，就会把处理交给给予伤害 Section。也就是说，这是将回合制中使用的 Section 一部分抽出，并组进即时制运算中的形式。
作为扩充性的例子，讲座中也介绍了「守住」的实作。在回合制中，为了使该回合不会受到对手招式命中，EventHandler 会让招式发动失败。另一方面，在没有回合处理的《Z-A》中，「守住」则改为让宝可梦在一定时间内进入「守住」状态，借此防止受到伤害的机制。
为了对应这两种不同运算，团队移除了回合制用的 EventHandler，并新建了会在给予伤害 Section 的 Event 产生反应后，将伤害设为 0 的处理。当需要改变招式效果时，只要移除不需要的 EventHandler，并依需求新增或替换成必要功能即可。既有 EventHandler 也能再利用，这同样是其优点之一。
宗像总结表示，透过以结构化与扩充性为核心设计而成的共通战斗系统，团队得以同时对应回合制与即时制两种战斗形式。提高程式码的再利用性，也与开发效率改善及品质稳定化密切相关。
本场讲座的重点，在于将游戏逻辑分割为「可以再利用的单位」，并将个别规格「从主要逻辑中分离」。宗像氏最后表示：「本次讲座介绍的 Section 与 Event／EventHandler 设计，应该不只适用于《宝可梦》，也能套用在所有持续复杂化的游戏逻辑上」，接著便结束了本次演讲。
（C）2025 Pokémon.
（C）1995-2025 Nintendo/Creatures Inc./GAME FREAK inc.
ポケットモンスター・ポケモン・Pokémonは任天堂・クリーチャーズ・ゲームフリークの登录商标です。
（C）2024 Pokémon. （C）1995-2024 Nintendo/Creatures Inc. /GAME FREAK inc.