まずいよーまずいよー。
おさかなさんとけてるよー。
やきざかなにがいよー。
今日はブルーリゾートの1・3面のスピード攻略を作っていました。
3面のクリアタイムを更新、1面は3通りの方法を検討しています。
詳しいことはまだ後日書きます。
チャット配布用一応できましたがオリジナル版との違いが予想より大きくなってしまったためちょっと内容を再検討中です。
あと、やはり不足している機能が多すぎること。
ナマライザの解析部分でリクエスト先を更に分解してディレクトリ・ファイル名・?以下の文字列に分けるようにしました。
しかしそのときクラス内で使っているユーザー定義型はまともな方法では外部に公開できないということがわかってVBへの不信がいっそう募ったり。
外部標準モジュールに一時保存用の変数を作ってそれ経由で渡さねばならないようです。
本当にVB6のオブジェクト指向は形だけで役に立ちません。
チャットを配布用に改造中です。
配布用ということでとりあえず的にロック処理を作ったりマニュアルを書き直したりしています。
爆ボンのページブルーリゾート３面を更新しました。
ここは攻略ネタが少ないため簡単でしたが実はここ、面白いネタがあったりします。
まあそのことについては後日ということで…。
ふにゃさんの項目選択機能を作りました。
パッパッパーっと作った割にはものすごく便利でもうなぜ今まで作らなかったんだろうと不思議なくらい。
早速手っ取り早くポーズメニューを作って自爆とタイトル帰還ができるようにしてみました。
いやもう、こんなに簡単でいいの？って思うくらい簡単にできちゃって。
今度はコンティニューするかどうかの選択を作って、タイトルメニューも作って、ステージセレクトも作りたいし…。
でも何より必要なのはステージそのものの充実だな。うん。
チャットの人工無能、二人以上の人工無能がいたとき辞書データのリセットがうまくいかず次の人工無能に前のデータが引き継がれてしまうバグがあったため修正しました。
日記で一部のカテゴリで勝手に\マークが増えて正しく検索されないことがあったバグを修正しました。
それと、見ればわかりますが検索機能も追加しました。
新カテゴリの人工無能はこれで探しました。
ふにゃさん、プレイ記録の保存とゲームオーバーからのコンティニュー時のペナルティができました。
データのロード＆セーブ処理は例によって項目追加のときにロードかセーブのどちらかを忘れてしまいそうだったので設定項目の追加は一箇所で行うようにしてセーブとロードは一括処理するようにしています。
ついでにチェックサムも入れてあるので下手に変更するとデータが消えます。
そして今は項目選択機能を作成中。
つまりはいとかいいえとか、ゲームを続けるとかタイトルに戻るとか、そういうのです。
いやー。そろそろステージ作りも始めなければいけませんね。
のんびりナマライザのログ一覧表示を作りました。
LineConstructorを使いまわしています。
どうも少し重いようですが既存のコントロールを使ったときのような余計な制限やメモリ消費がないところが強みです。
コントロールを使うとコントロールにデータのコピーを置かなければならないのでメモリ消費とデータ反映にかかる時間が馬鹿にならないのですよ。
もっとも、スクロールにスクロールバーコントロールを使っているのでいまだに32767項目の制限があったりするのですがね。
日記を改良しました。
JavaScriptが有効になっている方は既にわかっていると思いますが、左側のリストがクリックで開いたり閉じたりできるようになっています。
Netscapeだとon～系のイベントが出ないようでクリックしても反応が無いのですがそのときはそのときで少なくとも前より悪いことはないと思うので勘弁してください。
爆ボンを改めて最初からプレイしてみました。
フルパワーなので楽勝楽勝！
と思いきやいきなりドラゴ戦で自爆！
あの過剰な爆発力に自分自身が餌食となってしまいました。
リッパーのときも同じく自爆しまくりだったのですがこちらはハートを何度でも回収できるので本当に楽勝でした。
しかし最大の難関！ブラックシティ！
正面突破は最短ルートでの突破に失敗し、かなりのタイムロス。
アルタイルタワーともなると、まさに難攻不落、フルパワーなんて全くの無力なのです。
あまりに全てが揃いすぎていて非現実的なパワーで侵攻しているというのにその結果があまりに現実的なタイム！
レインボーパレスがただのボムジャンプ練習場に見えてきます。
そしてクリアするとシアターでは見られないノーマルエンディング！
ものすごく久しぶりに見たのですがスタッフロールでのあの完璧なプレイと言ったら！
シリウス版のあの馬鹿なNGエンディングとは全く違う感動的なまでの完璧なスーパープレイ！
一瞬の無駄すらもありません！
最後のレインボーパレスへの布石はレインボーパレスとクリアしてから見るとまた違って感じるものがあります。
あの頃は単なる観光地だと思っていたなぁ。
クリアタイム16分です。
アルタイル１戦目の体力が分かったのでそこを更新です。
なんと！カテゴリ分けされて分かりやすくなったのだ！
しかもカテゴリ分けしたのをCGIで管理しておきながら表示はHTMLなので管理が楽でなおかつ軽いのだ！
例のWebスペース増加のおかげでいくらファイルを作りまくっても強気でいられるのだ！！
ふははははっ！
日記CGIを機能制限して軽くしました。
まず、コメント＆トラックバック機能除去。
コメントはいらないしリファラを見ればトラックバックも不要だし、そもそもブログじゃないので最初から不要な機能だったのです。
そして次に、管理者の私にしか日記は更新できないため公開サーバーに置く利点がないということで、ローカルサーバーでのみ動作するようにしました。
それに伴い、同じサーバーを共有する他のユーザーに気を使って重い処理を避ける必要がなくなったので、自分で使うのに便利なように多機能にしてみました。
まあ、分割していた処理を一括で実行するようにしただけなんですが。
こうして書いた日記をあとでFTPでアップするのです。
公開サーバー側では一切書き込み処理をしないのでミラーリングアップロードが使えます。
チャットもリロード処理を改良しています。
リロードをログ表示側の処理ではなく、投稿フォーム側でJavaScriptにより処理することで、そのときの気分次第で自由にリロード時間を変えられるようになります。
勝手にリロードされると困る場合はリロードなしにすればよいのです。
ちなみに、JavaScriptが無効化されている場合は自動リロードは行われません。
ふにゃのページ更新しましたよ。
機知のバグとインストール・アンインストール方法を掲載しました。
そして、実はアクセス解析により訪問者の見るページの傾向に、説明をほとんど見ずにダウンロードする人と、説明ばかり読んでダウンロードしない人の二極化が見られたので、それに合わせるよう、リストのページからさっさとダウンロードできるようにはして、なおかつ紹介ページは紹介ページで充分なボリュームを持たせ、その上更に、私のことだからこんなことをしたらきっとリストのページか紹介ページのどちらかを更新し忘れたりすると思うので、リストのページのほうは紹介ページから必要な部分を抜き出して自動生成するようにしようかと考えています。
幸い、リストのページは完全に型にはまった書き方をしているので、プログラムによる作成が容易です。
ついでに言うと、ファイルサイズは更新し忘れ率が非常に高いのでこれもプログラムで自動生成するようにしたいです。
しかしこれを実現するにはまずダウンロードページ全般の構成を見直さねばなりません。
専用ディレクトリを作るか作らないか、どちらかに統一しないと不規則でプログラムには扱いづらいのです。
もちろんパネルγのように紹介ページにやたらと多くのファイルを使っているものもあるのでここはディレクトリ作成に統一で。
しかし、数少ないとはいえ検索サイトからHTMLページに直接飛んでくる人も多いのです（どっちや）。
いきなりディレクトリに移行して前のページを消してしまっては何かと不便でしょう。
だったら両方作ればいいのだけれど、例によって片っぽの更新を忘れるのでやはり同じファイルは作るべきではなさそうです。
それならばリダイレクトを使って、HTMLページに飛んできたら自動的にディレクトリに飛ばしてやればよいのです。
Bomber丸Worldのキャラのページを誤って削除してしまいました。
手元にもサーバーにももちろんゴミ箱にもファイルが残っていないのでキャラ紹介ページは１から作り直しになります。
まあ別にいいでしょう。
あんまり気合入れて作ってなかったし、半分忘れかけてたし、アキヤメのほうにもっと詳しいのがあるし。
ふにゃさんのセーブデータを作ろうとしているのですが、仕様がなかなか固まりません。
セーブデータと設定は分離すべきか。
シークレット機能によりセーブデータと設定は連動しているのですが、設定はエディタで変更されてもいいけど、セーブデータでは簡単には改変されたくない。
既にユーザー定義BGMの設定は分離することが決まっています。
はっきりと分離するメリットがあったためです。
セーブデータは簡単には改変されたくないのですが、デバッグのためや、ゲームを破壊的に楽しむ人を思うと、ここは別に一緒くたにして改変されてもいいかなと。
だけど、普通の人が設定ファイルを開いてついうっかり、は避けたいし。
暗号化も面倒だし、意味もあまりないし。
う～ん、簡単な符号化とチェックサムとか。
ふにゃさん、ステージ内に埋め込まれた画像を読み込む処理の改良に成功しました。
やはりこの前考えたとおり、GlobalAllocで確保したメモリアドレスと違う位置を渡していたのが原因だったようです。
mapを使って識別子とデータを関連付け、データクリア時にはそれぞれを別々にメモリ解放します。
要するに今回はこの関連付けるデータを一つ一つGlobalAllocで確保したというわけです。
また、確認はしていませんしその必要もないと思うのですが、以前のものだとデータの長さ(というよりデータの要素数)にほぼ比例した検索時間が必要でしたが、新しいほうだとその対数オーダーでの増加になるので大きなステージでは読み込みが速くなるはずなのです。
もしかしたらメモリの解放忘れがあるかも。でも多分無いかと。うん。自分を信じよう。スペル間違い以外に不具合は無かったんだし。
ミディビのMIDI受信プログラムを少し改良しました。
データを簡単に検査することでMIDIかどうかを判別し、MIDIデータでなければ保存しないのです。
MIDIには必ず存在するデータというものがあるのです。
それが存在するかどうかさえ調べればおかしなデータが送られてきたときにエラーを出すことができるというものです。
ミディビは一応完成したら配布するつもりなので悪意のあるデータを排除するというのも必要になってくるわけです。
そういえばPerlの正規表現ってバイナリデータに対してはどう動くんだろう？
PHPについてはどうやら一行のデータを前提にしているらしいのですが。
ん？でも掲示板とかで複数行のデータを渡したときもちゃんと動いてる？どーなってんだろー。
しかしもしバイナリデータでも正規表現が使えるなら強いですよ。
なにせ正規表現だけで曲名も作者もコメントも抜き出せるのです。
JavaのおかげでMIDIのバイナリデータを直接扱うことはありませんでしたがやはりいずれにせよMIDIファイルの知識は必要だったようです。
それでも一応MIDIメッセージの段階まではMIDIに踏み込むことができたのでできる自信はあります。
正規表現の挙動しだいですが…。
ミディビで保存ができなかった原因がほぼ特定できました。
http://support.microsoft.com/default.aspx?scid=kb;ja;175622で見てみると、どうも我々のアプレットは信頼されていないため、クライアントであろうとサーバーであろうと関係なく保存できないようです。
お絵描き掲示板はどうなっているのかと見てみると、アプレットから画像ファイルのデータの中身がそっくりそのまま送られてきていて、それをCGI側で保存するようになっていたのですが、これは今回のようなセキュリティの問題だったのかもしれません。
そこで自分もそれに倣ってCGIにデータを渡す方法を考えることにしました。
MidiSystemのwriteメソッドにはFileクラスを渡して直接ファイルに書き出してもらうものともう一つ、OutputStreamの派生クラスを渡して自分で作った出力ルーチンに書き出すものがあって、それを使うと、出力先を自由に変えることができるんですね。
ここで、Socket通信によってデータ受け取りCGIに出力すると、セキュリティに問題の無いCGIから保存ができるようになるということです。
アプレットからCGIにデータを渡す方法などについてはhttp://www.sm.rim.or.jp/~shishido/cgij.htmlなど。
LineConstructorを使っていたら、大きなファイルを開いたときにエラーが起こりました。
機能の足りない部分があってもバグはない自信があったので少しショックだったのですが、原因はどうやらスクロールバーが大きな数に耐えられなかったことが原因だったようです。
今日はチャットにクッキー保存機能をつけました。
本当ならGBBSのプロフィール機能と連動させたかったのですが、それぞれで必須とされている要素が異なり、GBBSのプロフィール自体もまだ発展途上であるため、連携するようにするのは控えておくことにしました。
まあそんなこんなでアルニックはレベル24達成。
目指せレベル30です。
爆ボンのための3Dマップソフトを作成中です。
3Dマップはどの方向にどのようにマップが広がるか分からないし、マップのほとんどの部分は空白状態なので、2Dのときのように二次元配列を用意してそれぞれにマップチップを、というわけにはいかないので、STLのsetに、マップ上の位置とチップ情報を詰め込んだクラスを入れて、順序付けされた配列として扱っています。
なぜ順序付けされた配列にする必要があるかというと、描画段階において確実に奥のチップから表示するためには奥行きでのソート(Zソート)が不可欠であり、マップチップが動かず、視点も動かないことを考えると、描画の時点でソートするより、最初からソートされた配列に順序を狂わさないようにデータを入れてゆけばそのまま最初の要素から順番に描画してゆくことで簡単に描画ができるようになるためです。
しかし、クラスはそのままでは大小関係を見て順序付けすることができないので、operator<だとかoperator>だとかを使って大小関係をつける関数を自作(いや、この場合演算子を定義か)。
なにしろsetにぶち込んで利用するからには値のように扱えるようにしなければならないので、他にもコピーコンストラクタやらoperator=なども考える必要があったりして、結構いい刺激になりました。
もっとも、コピーコンストラクタとoperator=についてはC++が勝手に書いてくれてるので自分で書く必要はないはずですが。
今日はチャット管理のぼっとの辞書管理を作りました。
これで辞書に単語と応答を追加していくことでどんどん賢くなっていくはずです。
で、ためしにいろいろ入力していったところ、チャット本体のほうでバグ発見。
時間が誤って解釈されていたので修正しました。
現在のアルニックの賢さは7,168ポイント！！
ちなみに、インターフェース面でも改良を加えていたりします。
チャット管理プログラム作り始めました。
現在はぼっとの辞書を見ることのみできます。
一応形だけ削除フォームと追加フォームが作ってあります。
こればかりは実物を見せるわけにもいかないので画面写真のみ公開しておきます。
調子に乗ってレッドマウンテンの曲まで作ってしまいました。
昨日は爆ボンのブルーリゾートの曲を作っていてあまりの難しさに放棄したのですが、今日は最後まで作りました。
で、やっぱり幸せ気分粉砕。
あまりにひどいデータなので公開していません。
チャットの人工無能、基本機能がほぼ出揃ったのでアップしました。
まだ辞書がほとんどできていないのでろくな返答はできませんが。
今後は辞書の充実のため、辞書管理プログラムを作ってゆきます。
メテオスのスタートリップの最高難易度をノーミスでクリアできました！
しかし、レベルMAXだというのに、みんなそろいも揃って弱い。
いや、さすがに後半にもなるとなかなか強いのですが、前半、15秒でブレイクといったら、何も操作しなくてもできる芸当じゃありません。
無駄にタイムアクセルを踏み、敵の激烈な攻撃でもない限りはこんな早業は不可能です！
レベルMAXだからこその驕りというものでしょうか。
後半は積みあがるとほぼ瞬殺なのでそこそこ張り合いはあったのですが。
今日の絵は昨日の人カラーバージョン。
少し笑顔です。
パネルγの暗号化アルゴリズムを改良しました。
ランダムにキーを生成していると何度も同じデータで保存するうちに規則性を見抜かれてしまう恐れがあるので、同じ点数には同じ暗号を吐き出すようにしたのです。
そして、受け取り側のCGIも完成。
以前のランキングとの互換性も維持しつつパネルγ方式の新しいデータも受け取ることができるようになりました。
まだセーブに難ありですが暗号・復号処理は大体OKみたいです。
メテオスのヒュージィ曲、4番まで全部作ってみました。
そして、3番までを繋げてみました。
0と1との切り替わりが少し分かりにくいかもしれません。
今日の絵は、白けるコンビ、シャイとカンです。
テキトー落書きと蛙という意味不明な組み合わせです。
メテオスのヒュージィのナンバー５作りました。
聞いてってください。
パネルγのスコア受信CGI作ろうとしたけど…。
GChat、phpMyAdminで仮のデータをいくつか入れて、とりあえずmySQLに接続するだけのコードを書いて、いざ接続！と思ったら、あんたのサーバーからは接続させてやらん、とのデータベースサーバー様の仰せだったので、ローカルテストのときのデータベース利用は諦めることに。
本当は自分のコンピュータにもmySQL入れればいいんだけど、もうこれ以上面倒なものをインストールしたくなかったし、今までどおり普通のファイルでも一応実現はできるので、早々と従来の方式に切り替えてしまいました。
まあ、仮で入れてみたデータで、必要そうなデータは大体分かったので、一応意味はあったものと思います。
RPG±0、マップチップのサイズも自由にして欲しいとの意見があったので、それに対応するためデータ形式とインターフェースを全面的に作り直すことにしました。
まあ、インターフェースに関しては既に作り直す気になっていたのでちょうどいい機会です。
ふにゃさんのBGMはちまちまと作り続けています。
サブメロディも入れてみたり。消すけど。
ふにゃふにゃのページを更新しました。
開発メモ。どうやら以前のエディタは難しすぎてエディタ作者自身にも手に負えない代物だったようで、以前の何でもできるエディタは残しつつも、新しい簡易エディタを作ることにしました。
そして、Bomber丸Worldのページも更新。
戦闘画面がついに出ました。
イメージ画像ですけど。
なかなか面白いことになっていますよ。
そんでもって、RPG±0、さしあたり自分で不便に思っていた右クリックの挙動を統一。
スポイト機能と右クリックメニュー、両方一気に実行されます。
チャットの人工無能ちゃん、以前のようにファイルに入れておくよりも、mySQLのデータベースに入れておいたほうが管理しやすいと思ったので、mySQLを勉強し始めました。
とりあえずphpMyAdminの使い方を思い出しつつどんなデータがどう使われるのかを覚えていきます。
ふにゃさんは今日はBGMを作成中。
先日言っていた違和感はほぼ取れたように感じます。
メロディ以外のパートは修正するときの補助のために入れた音で、後ではずすかもしれません。
アキヤメのキャラ名簿、１５０人達成しました。
忘れかけてたキャラ、まだ名前しか決まってないキャラ、キャラと呼ぶには微妙な存在など、いろいろありますが、今までのキャラとしてはほぼこれで全部だと思います。
いや、ほぼだから本当は全部じゃないです。
本当の本当に忘れちゃってたキャラもいますし、微妙な線でキャラじゃないと判断されたやつもいますし。
チャットプログラム、昨日のバージョンまでは好きなときに読み込んで好きなときに書き込むようにしていましたが、これは動作が重くなる原因になるばかりでなくログ消失の危険性が著しく高く、というよりはもはや壊れてくれといわんばかりの仕様でしたので、同じファイルは一連の流れの中で一度しか読み込まず、保存はログが変更されたときのみ終了時に行うようにしました。
あとはファイル監査機能をつければログの異常を発見することができ、そこからまた対応するプログラムを書けるようになるのでそれなりに強いプログラムになるものと思われます。
さらに、二重投稿防止機能を改良。
各人ごとに最後の発言を記録してゆき、それと同じ発言は次回にはできないようにしました。
テキストファイルの行数を数えるプログラムを作りました。
もっとも、最後の行が改行されているか否かで結果が変わってしまうのですが。
ふにゃふにゃのキャラ紹介ページの画像を更新しました。
この間の手抜きの絵ですが、それより前のさらに手抜きの絵よりはずっとマシでしょう。
ふにゃさん、ふにゃが寝るようになりました。
ふにゃふにゃで登場させ損ねた元祖のアクションをどんどん取り入れていきます。
やっぱりしゃがみストップと何の影響も受けない安定した歩きは欠かせないと思っています。
こうしてみてみると、ふわふわアクションとか言いつつも、ある部分においてはパキパキ不連続な動きをしていて、言ってみればアナログ的要素とデジタル的要素を併せ持ったゲームとなっているようです。
今日の音楽はふにゃさんのメインBGM作りかけ。
どこか音をはずしているのは分かるんだけどどこをどう間違えたのかが分からないから途方にくれています。
今日はチャットの動作確認もかねておしゃべりしてました。
現状では特に問題もなく動いてくれているようですが、実はまだロック処理というものをしていないのでいきなりログが消えることがあります。
そして、さらに、人工無能が入ってくるところまで今日は作ったのですが、動作がかなり不安なのでアップはしていません。
メッセージフォームには同じくチャットを作っているうにゅさんのJavaScriptを使わせてもらって、過剰なリロードを制限しています。
１秒に１回リロードしたってどうせ状況なんて変わらないと思うので。
学習帳を全部TGWSの色に合わせました。
今日の絵はマザー２の武器屋のおっさん。
ゲーム中とは違って優しそうなイメージ。
実は骨格から描いていたり。
ふにゃのページを更新しました。
遊び方のページが増えています。
しかし遅い落下速度のことをまだ書いていないのでまた後日更新します。
FFCCのMIDI「哀しい怪物」を修正しました。
でもまだまだ音源依存が強くて、というより楽器間違えてて、音程も間違えてて、本当はもっともっと修正しなければならないんですけれども、正直言って私の耳ではこれ以上は聞き取れないのです。
それでもまあ前よりはずっとマシになりましたよ。
爆ボンのページに続いてカービィのエアライドのページを独立しました。
内容そのものは更新していません。
今後は単体で10kBを超えたゲームはページを分離していこうと考えています。
チャットの在室者管理ができたので、チャットとして最低限の機能は揃ったと思います。
とはいえいまだにクッキーと発言自動消去などができていませんが。
GChatの最大の特徴として、在室者管理の徹底があります。
ます、入室していない状態や退室した後に発言しようとするとエラーが出て発言できません。
つまり、「落ちた振り」ができないわけです。
そして、3分間発言しないままだとROM(見てるだけ)だとみなされ、1時間発言しないでいるとブラウザを閉じたか話す気がないとみなし、自動的に退室させられます。
そして、この機能は通常のチャットの機能とは別に、もう一つの効果を生み出します。
それは、ずっと昔に言っていた、「気まぐれ人工無能」の実現です。
世にも珍しい、チャットから退室するぼっとです。
ぼっとも人間と統一した扱いで在室状態を管理すれば、誰とも話していないときが勝手に自動退室機能が働いて退室するのです。
もしいなければ呼べばいいし、いなくていいなら呼ばなきゃいい。
しかも、呼ぼうと思えば二人以上のぼっとも呼べたり…。
あのときのような絵空事ではなく、これが今実現しようとしているのです。
