【CEDEC 26】《寶可夢傳說 Z-A》的運用實例 支撐回合制與即時制的共通戰鬥系統
噴火龍使出了「火焰拳」！乍看之下只是簡單的行動，卻會因為天氣、特性、持有物等要素的組合，使結果產生大幅變化。超過 1000 種寶可夢、900 種以上招式，再加上 300 種以上特性與 200 種以上道具，這些龐大的設定資料彼此影響而形成的戰鬥邏輯，究竟是如何在每次推出新作時持續擴張，同時維持整合性的呢？
此外，2025 年發售的《寶可夢傳說 Z-A》（以下簡稱 Z-A）採用了即時制戰鬥，這套系統又是如何與過往的回合制戰鬥共享基礎架構的呢？這些令人好奇的問題，在 7 月 22 日於「CEDEC 2026」舉辦的講座「支撐寶可夢對戰進化的戰鬥系統基礎設計與運用事例」中獲得了解答。
本次登壇的講者，是隸屬於 GAME FREAK 研究開發部「寶可夢・戰鬥系統團隊」的宗像快與小幡敏宏。
宗像快首先展示了三項寶可夢戰鬥的特徵。第一個，便是戰鬥系統使用的設定資料有多麼龐大。總數超過 2400 種類，且每次的新作總是會追加寶可夢與招式等合計 200 種類以上的資料。正是因為如此龐大的資料才造就了戰鬥的多樣性，卻也很難維護品質。
第二個是被動技能。不用玩家操作，只需要達成條件就能自動發揮效果。作為舉例的特性「威嚇」，在戰鬥出場的時候，就會降低對手一階的攻擊力。
這類處理並非單純插入一段效果就能解決，有時甚至會發生遞迴計算，因此必須能夠控制複雜的處理順序。
第三個，便是在戰鬥中的數值會時時刻刻變化。宗像快接著以甲賀忍蛙的特性「變幻自如」為例，甲賀忍蛙原本同時具備水屬性與惡屬性，但在使出招式前，特性會發動，使自身屬性變為與該招式相同的屬性。也就是說，若甲賀忍蛙選擇飛行屬性招式，那牠自身也會變成飛行屬性。
這三項要素彼此影響，使得《寶可夢》的戰鬥系統變得更加複雜。若各專案都各自開發，就必須一邊考量龐大的組合數量，一邊維持品質，這是相當困難的事。因此，宗像氏等人的「寶可夢・戰鬥系統團隊」會跨專案參與所有《寶可夢》作品，並支援戰鬥系統的實作。
接著換小幡敏宏上場，針對基礎設計的說明進行演講。一開始向聽眾顯示本次講座中，「戰鬥系統」的定義。舉例來說，「火焰拳」是火屬性的攻擊招式，並有 10% 機率讓對手陷入「灼傷」狀態。現場播放的示範影片中，皮卡丘正是受到噴火龍攻擊後陷入灼傷。
那麼，如果讓噴火龍攜帶道具「櫻子果」，皮卡丘的特性為「靜電」，並且讓天氣設定為「晴天」的話，結果會怎麼變化呢？
結果會大幅改變。由於「晴天」效果會提升火屬性招式的傷害，而當皮卡丘的特性「靜電」發動時，進行攻擊的噴火龍會陷入「麻痺」狀態。接著，噴火龍持有的「櫻子果」會發動，恢復牠的麻痺狀態。即便只是同一招「火焰拳」，也會依照狀況產生複數不同的連鎖反應。
小幡氏將戰鬥系統定義為：接收「由誰，做了什麼」這樣的行動資料，並加入特性、道具、天氣等狀況後，決定「會發生什麼事」的機制。
在實際對戰中，對手的行動以及增益、減益效果也會介入，使現場發生的現象更加複雜。招式、特性、道具會隨著系列作品持續增加，而過去登場過的規格，也必須保證在後續作品中維持相同運作。因此，《寶可夢》系列的戰鬥邏輯，可以說是必須跨作品維持品質與整合性。
小幡敏宏接著先提出了一個設計思維，說明了戰鬥系統再構造的背景故事。在初代《紅／綠》，是沒有特性也沒有持有物的簡單戰鬥，到了《金／銀》世代加入了新屬性與天氣，到了《紅寶石／藍寶石》世代則是加入了特性與雙打對戰。在之後的作品還導入了三打對戰、超級進化等機制，但在實作上仍是在既有系統之下進行擴張。
而在 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 設計，應該不只適用於《寶可夢》，也能套用在所有持續複雜化的遊戲邏輯上」，接著便結束了本次演講。
此外，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 設計，應該不只適用於《寶可夢》，也能套用在所有持續複雜化的遊戲邏輯上」，接著便結束了本次演講。
本文章來自巴哈姆特電玩資訊站 GNN 新聞網
- 記者：巴哈姆特 GNN
- 更多遊戲新聞 »
