流程本身雖然單純,但若以原本方式將大量招式、特性、道具全都組合進計算中,遊戲邏輯就會變得相當複雜。於是,團隊將「要以什麼順序計算哪些內容」的部分定義為「遊戲邏輯」,並將招式、特性、道具各自的處理切分為「個別規格」。在上述例子中,天氣「晴天」的效果就屬於個別規格。

「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 集中管理,就能更容易掌握與修正規格。