スクリプトのことについてですが、よく考えたらこのスクリプトは任意の位置で一時停止できなければ役に立たないので、途中で止めることが困難なツリー構造から実行する形式は見直す必要があるかもしれません。
そうなればツリーのノード本位な今の設計も根本的に見直す必要があり、今度は大幅な変更が来るかもしれません。
で、今日はスクリプト自体は特に触らなかったので、TGBBSの開発を始めてみました。
ファイル形式などはまだ決まっていませんが、ユーザーから受け取るべきデータはほぼ決まりきっているので、投稿フォームから先に作り始めています。
しかし…フォームの位置がランダムに入れ替わるというのは少し面倒かもしれませんね…。
迷惑書き込み対策になるかどうかも未知数だし…。
Bomber丸Worldの施設の一つとして、病院というものを考えてみました。
元々4と死を結び付けない文化なので、3階と5階の間には4階があって病室になっています。
ただ、死とは関係なく、少しおかしい病室になっています。
そんなわけでプログラムを書き換えつつプログラミングのページも書いたりしています。
ちょっと順番が前後しちゃったため２ページを並行して書くことになりました。
共用体を使うとなれば中に入るデータの大きさが気になるところですが、このあたりはどうしましょうかね…。
ああもう！
値のことは後で考えるとかいってたけど、よく考えたらノード一つ一つには何らかの形で値が含まれるわけだから、ちょっとの手直しならともかく、これから根本的に内容を見直す予定なので、値のことは先に考えておいたほうがよさそうです。
どんな風に根本的に見直すつもりなのかというと、現在はなんとなく基底クラスのポインタをノードに保持させておいて、そのポインタの指している実体は派生クラスという形を取っていたのですが、そうすると値のコピーという点で不都合なことが多いので、最初から全部の型に対応した構造体一つで値を表そうかと考えています。
で、これをそのまま実装すると使用メモリが増えてしまうので、ここらで共用体という今まで私が使ったことのない構造を使ってみようかと思っています。
ただ、共用体といえども大きなクラスを含んだりすると結果的に同じようなことになってしまうので、その点は値型と参照型という形で、まあ、なんというか、値を示す構造体に値の実体を入れるのと実体へのポインタを入れるので分けて、大きなデータの場合はまた別のところで管理して、その管理されているデータへのポインタを値として持っておこうと考えています。
そんなわけで、スキャナの書き換えは中途です。
てなわけでスキャナの書き換えを始めました。
ノードはいろんなところで使いそうだしそれはそれで独立した内容を持っているので別ファイルに分けて、トークンの内容は完全にノードに含んでしまえるのでトークンのクラスは削除しました。
まだスキャナ自体の書き換えはできていないのでエラーが出ていますが。
スクリプトのパーサを作り始めてみて、スキャナがCMSToken型を生成して、パーサがCMSNode型を解析しているという、ちぐはぐな状態になっていることがわかりました。
これに対する対応は、一つには型をどちらかに統一する方法、もう一つには何らかの形で型変換をしてやる方法があります。
最終的な動作速度やコードの簡潔さで言えば前者のほうがよさそうですが、最初わざわざ分けて作ったものをまた統一するのはどういったものかと…
スクリプト講座、本当は配列について書こうと思っていたのですが、順番が悪いのと、パーサについてうまい考えが浮かんだので、急遽予定を変更してパーサの話にしてしまいました。
で、そのスクリプトを使う予定のBomber丸Worldですが、このままのペースでいくと、社会人になるまでに完成しそうにないので、ちょっとスケジュールを決めて期間内に終わるように考えたいです。
とりあえず7月中にスクリプトを作り上げ、7月末までにゲームとして動くようにして、夏休み期間を利用してテスト版を公開し、プログラムの動作チェックをしてもらえるようにしたいです。
そして翌年2月ごろまでにシナリオなども完成させて、3月末には正式公開できるようにしたいと考えています。
まあ、とてつもなく大雑把な計画ですが、なんとか頑張ってみます。
プログラミングの記事を書きつつ、日記を細かいところで修正しました。
日記をCGIからPHPに移行したところで変換トレーニングウィザード用のログへの書き込みが止まってしまっていたので、その対策です。
FFCC、ものすごく久しぶりに時が進みました。
ついに12年目です。
でもやっぱりミミィはちっこいです。
それと、いまや危なくて前線に立てない弱小組は、これからは荷物持ちとして活躍してもらうことになりました。