yaneSDK.NET 四日目 - kowさんは天ざる大好き

四日目。前に何の根拠もなく考えていたScenario Frameworkっぽいのを試験的に作ってみる。

MVC。もでる。びゅー。こんとろーら。コントローラはTaskにお願いすることにした。ビューはグラフデータでシナリオを描画するつもりはないので、シンプルにゲームユーザの用のViewにする。モデルはシナリオのデータを上手く保持してくれればいい。
その前にシナリオスクリプトのパーサが必要だったので、yaneSDK4Dで実装されていたものを流用して作る。ドキュメントコメントで著作者のタグはなんでしょうかね...
さらに、C#がよく分かっていないので、手間取る。
構造体にしていたものが、値渡しでめんどいのでクラスに変更。
この結果、参照渡しになったが、コピーコンストラクタを作らなければならないということをすっかり失念していたため、しばらくデバッグしてこのことに気付く。

次に、頭の中で考えた根拠のないMVCそれぞれに必要なinterfaceを契約として導入。
なんか、yaneSDK2ndスクリプトありきなinterfaceだが、そのうちブッシュアップして、ホントに必要なものだけにしていこう。

去人たちではすっかりScenarioDrawが惨憺たるクラスになったことがトラウマになっている。
問題となったのは、シナリオの状態をうまく管理できていないこと。
そして「この命令タグは、この状態のときは、こういう振る舞いをして、こういう状態の場合はこんな振る舞いをする」という状況下での if else の地獄だ。まさにバグパターン。
さらに、長大なコードが可読性を著しく低下させていた。

実は、あたしゃ、この自分の酷いコーディングを体験して脱初級プログラマ！と思い立った経緯がある。
妙にテクニカルなコードを書けることはないけど、普通のプログラマになりたいと思った。

とあえず、スクリプトの命令文を解釈させるクラスが必要だった。
ScriptCommandHandlerとそれのFactoryを作って、それぞれの命令文毎に実装することにした。去人たちでは良く、「こんな命令が欲しい」ということで追加する度に、バグを追加していった。クラスとして完結していたほうがバグが少なくなだろうし、保守性もあるだろう。作ってみると、命令文追加も比較的容易な気がした。
次にInputデバイス関係はコントローラにやらせてもいいかなと思ったけど、モデルがInputを感知して勝手にデータを更新してくれたほういいかなと思って、デリゲートにしてセットしておくようにした。

そしてテストとして、テキスト表示とBGM命令だけ実装させて動かしてみた。
あいもかわらず、これだけの実装量にもかかわらず、致命的なバグが数個あったが、動かすことができた。
テキスト停止位置での停止、テキスト表示ウェイト、BGMの再生、停止、クロスフェード。
去人たちのテキストビューア（音はおまけ）状態。

今回はなるべく、結果コードを見るようにしているのだけど、Sound#StopFadeはsdl_errorが返ってくることがある。
Mix_FadeInChannel の戻り値はフェードアウトしているチャンネルになるので、エラーチェックが間違っているようだ。

まずはC#をもうちょこっと勉強していかないといけないなぁ。
今度こそ、ノリだけでコーディングせずにシナリオ状態を把握するために、ハレル図を書く...（もう遅い気がするけど

id:vancatさんが、「去人たち」をキーワードに登録してくれはりました。果たしてニーズがあるのかどうかわかりませんが（苦笑）、本当にありがとうございました。