処理の流れ - Asagi Cube

無効な移動命令の除去
地図上無効な移動命令は UI で発行を制限するつもりなので輸送経路未成立の移動命令除去だけ。
支援命令の適用
支援対象となる命令と支援命令の接続および支援対象が存在しない支援命令の除去。
輸送命令の適用
輸送対象となる移動命令と輸送命令の接続および輸送対象が存在しない輸送命令の除去。
支援カットの解決
攻撃を受ける支援命令の無効化。
入替移動命令の解決
戦力が同等の入替移動命令を解決。
海上戦闘の解決
輸送命令を受けたユニットへの攻撃を優先的に解決。
阻止された輸送の除去
海上戦闘で輸送経路が破壊された移動命令を除去。
衝突する移動命令の解決
移動先が同じ移動命令を一括処理。
スタンドオフの連鎖解決
未解決の移動命令とスタンドオフによる他の移動命令への影響を順次解決。
確定
ユニットの移動や命令の遂行状況を確定。

マニュアルの diagram を順番に実装していったらこうなった。放棄したプロトタイプではまず先に処理の流れを考えてからひと通り実装しその後バグを取る一般的な手順で開発したのだがエンジンの開発だけでも数ヶ月かかったと記憶している。今回は二度ほど徹夜しただけでここまでたどり着いた。かなり大雑把に TDD ぽくやってみたのだが思っていた以上の威力だ。

ちなみに現時点でもまだまだ暫定実装とか空実装が多い。マニュアルの diagram を基準に作成したテストでは全然足りないのだ。どの処理が足りないかを考え出すと不安ループに落ちるのでどのテストが足りないかを考えるとしよう。いやそれすらも面倒なのでネットで拾ったリプレイを再現することに挑戦だ。

言うなれば受け入れテストに近いレベルを基準にするわけだ。クラス単位のユニットテストは大枠がある程度定まった後で良い。テストファースト原理主義的にメソッドから積み上げるようなやり方では小手先の実装に振り回されることは経験済みだ。まずひとつの完結した機能をイメージしてからそのインタフェースのテストを書いて内部処理はテストの要請に応じて練っていくのはなかなか良いやり方じゃないかと思う。