状態遷移は表のディレクトリ構造である。

ゲームプログラミングを始めて、ステップ処理に嫌気がさした頃、どうにかしてコーディング量を抑え、バグの特定やキャラクターの動作の状態遷移のトレースがしやすいかと言う事を自問自答していたときに見つけたのがタスク処理だった。
しかし、このタスク処理･･･、実際に書いてみるとステップ処理を関数毎に分けただけで状況によってはステップ処理の記述の仕方の方がコード片が散乱しなくて分かりやすいというジレンマを生んでいた。
また、タスク処理を行うに当って１タスクの中にステップ処理を記述するとまたステップ処理部分をタスク化する必要が出てくるくらいのコード量になってしまい堂堂巡りになってしまう事が少なからずあった。*1
よってタスクの中に新たなタスクマネージャーを置き、云々かんぬん･･･というコードを書くことになるのだが
この力技･･･。まったくスマートではないのだ。面倒なのだ。ソフトウェアを作るに当ってこれだけの状態遷移が必要であったとしてもコード上では一切管理はしたくないのだ。
FSMをC言語などの手続き型言語のソースコードに置き換えると特に見難い。参照しにくい。編集しにくい!!!
よって、FSMのコードジェネレーターやDKFSM構想(妄想)をして頭の中でこねくり回していた。


今更ながら、よくよく考えてみると状態遷移に関しては状態遷移表として伝統的な図示の方法があるのだから、この事例の現象と照らし合わせてみると状態遷移表はディレクトリ構造ではないか？という事に気付いた。
状態遷移の中に新たな状態遷移が現れた時は状態遷移表の一つのセルの中に次の状態遷移表へのリンクが出来てその中の状態遷移表に従うといった形では･･･と考えた。
おそらく、既にそのような形でプログラミングしている方々はいると思う。もしくはそのような形にせざるおえないような気もしなくも無い。
図示にいたってはどうすればよいのか･･･と悶々としていた中、ちょっと希望が見えてきた。


追記：そういえばKlick&Playも状態遷移表のようなイベントエディタが付属していた。そのセルをクリックするとダイアログが現れてイベントを設定できるといった形。既に理想は実現されているものですね。

*1:ステップ処理やタスク処理に関する事の詳細は後日この日記に書く予定です。