「アイディア」に関する日記(8)

<前 次>

次々と

ふにゃさん、最初の画面でバージョンを表記するようにしました。
そしてゲーム上での操作説明も作り始めてます。
パネルγやふにゃふにゃのときのようなものですが、もっと効率の良いやり方を考えています。
例えば、今回の操作説明では、プレイヤーに実際に動かしてもらいながら次々と新たな操作を教えてゆくのですが、次々と、というのを実現するには、今何を教えているか、という情報が数値として必要なわけで、例えば、歩き方を教えている間は1、ジャンプを教えている間は2、というようにして数値で分ければよいのですが、いちいち数値を振るのが面倒だし、AというシーンとBというシーンがあればその間の遷移も必要になることもあるわけで、生真面目にやっていたらどんどん扱う数値が増えていって、定数として数値に名前をつけて混同をなくすようにしていったとしても、ただ順番に続くだけだったら、その名前が出てくるのもその一つ前のシーンでしか出てこないわけで、どうにも手間ばかりが増えるのです。
そこで考えたのですが、この番号を自動生成して、具体的な数値をあまり意識しないようにしたらどんどん次のことを書きなぐっていけると思うんですよ。
具体的な方法は既に考えていたマクロを使う方式と関数を使う方式を考えています。

ギリギリの契約更新

メモちらしの似非物理演算、最近いらないかなぁと思い始めています。
粒子を沢山置いたらどことも繋がってないのがすぐ飛んで行っちゃうし、腕は過剰な力で伸びきっちゃうし、常に動いてるからCPU負荷が大きいし、近似の精度が悪いとすぐ発散するし、正直思いついたから作ってみただけだったので実用性が追いついていないのです。
そういうことで、近いうちに別の原理で動作するメモちらし2が出てくるかもしれません。
たぶんバージョンアップで付加機能として作ると思いますが。

今日はサーバーの更新手続きを行いました。
本当は4日にメールが届いていたのですが誤って削除してしまっていて、今日削除済みアイテムのフォルダから発見し、期限が差し迫っていたので即座に利用料を振り込み、契約更新しました。

爆ボンのページを更新しました。
今日の更新は基本操作の頁です。
不必要に長ったらしい文章ですが許してください。

簡単なストーリーの流れ(ちょっとネタバレ)

<オープニング>
シロ、仕事する

同僚のテルルと一緒に帰る

途中売店に立ち寄る

シロだけ入って買い物しているとテルルさらわれる

シロ、終わってから気付き、慌てて帰る

クロに警察は当てにならないといわれ、自分らで探すことになる

途中、ふにゃと出会い、なぜかついてくることになる(任意)

また売店に立ち寄る

謎の男が襲われているので助けることになる

バトル:ヨワシ戦(ふにゃを仲間にしていなければこの戦いの途中で仲間になる)

謎の男が仲間になり、事件の事を聞かされる

とりあえず、クリアス・バイオ研究所なる場所へ行くことになる

<クリアス・バイオ研究所>
入るといきなりコピー機登場

バトル:コピー機戦

(途中、まだ考えてない)

よくわからないがクリアスが悪者ということらしいので戦うことになる

ボス:クリアス戦

謎の男が魔法のようなものでクリアスをどこかへ飛ばしてしまう

謎の男によると、他にも怪しいところがあるらしい

<ホーリィ製鋼所>
町でオミナガミから社員証をもらう(任意)

社員証を使い、入る(ない場合、扉を爆破し強行突入)

なぜかアラ軍団に襲われる

バトル:アラ軍団戦

(やはり、ダンジョン内の仕掛け等は実際作り始めてから考えるべきだろう)

開かずの扉を爆破するとプララに襲われる

ボス:プララ戦

謎の男が魔法のようなものでプララもどこかへ飛ばしてしまう

<海洋研究所>
どこかで船を借りて海洋研究所へ

(なにもかんがえてない)

ボス:ヨシフミ戦

謎の男が魔法のようなもので(以下略)

なぜか帰りに詐欺容疑で警察に捕まる

<刑務所地下>
留置所じゃなくて刑務所…?ここの警察は当てになりませんから

囚人の一人に地下通路へと案内される(何もせず果てしなく長い時間待っていれば釈放されることも可能)

なぜかキャティアと戦うことになる?

バトル:キャティア戦

(これといった大事なイベントは用意されていない)

出口を塞いでいるボス!と戦わねばならない

ボス:ボス!戦(本名は今は教えません)

謎の男が魔法のようなものでボス!を……飛ばせなかった

ともかく、脱出

<インサイド・コエダメ>
病院の裏口から自然園へ潜入

どこかにある穴から地下のインサイド・コエダメへ入れる

(ここは、本当に何のイベントもない)

なりゆきでゲロノフン2世と決闘することになる

ボス:ゲロノフン2世

謎の男が(以下略)

<カリスマ小中高大一貫校>
練習試合という名目で入れるらしい

というわけで強さを試される(でも弱い)

バトル:先生戦(この先生にはまだ名前がありません!)

(ここには大小さまざまのイベントがあり書ききれない!)

悪徳校長を退治することになる

ボス:ノーリッジ戦

謎(以下略)

<カイモチ村>
謎の男から、最後に行くべき場所がカイモチ村だと知らされる

カイモチ村に入るとふにゃが何かの存在に気づく

バトル:オバケ戦

(以後、各地にいるオバケ達が見えるようになり、会話も出来るようになる)

村長かいもち1世に話を聞く

どこかの壁を爆破しラストダンジョンへ潜入

謎の男が仲間から離脱する

バトル:ツヨシ戦

(謎の男を再び仲間にするかどうかでストーリー分岐)

挑戦状

Bomber丸Worldのグラフィックエンジン2、よく考えたらドット絵と文字を別々の画面に分けたら文字の一部がドット絵に隠れるようなことができなくなるんでした。
というわけで、面倒だけど画面は一つにしておいて、ドット絵なら拡大、文字なら大きく表示と、別々の処理を行うことにします。

爆ボンでなにやら挑戦状を受け取ってしまいました。
6-3をフルパワーON+ハートなしでノーミスクリアせよとのこと。
最初の2つはスイッチ一つ一つを押した後地面に降りれば問題なさそうですが、残りの2つは広間渡りが入るのでかなりきついです。
気絶回復直後のわずかな無敵時間でやり過ごせるでしょうか…。
あるいはデモシーンでの無敵時間もあったような気がします。
とにかく死ねます。

GIFアニメーション

Bomber丸Worldのアニメーション機能、GIFアニメーションを使おうかと考えています。
理由はというと、一連の画像ファイルが一つのファイルにまとめられて、なおかつ各コマの表示時間が設定できるからです。
確かもうGIF特許はいいはずだし、いざとなれば無圧縮GIFアニメという手もありますし、使ってみてもよさそうです。
従来の独自形式から悪くなる点としては、ファイル数がポーズの数だけ増えること、ランダム表示時間が原理上できないことの2点です。
しかし、複数ファイルに分かれれば一つ一つのアニメーションの確認が簡単になりますし、ランダム機能は、実際に作ってみてほとんど意味を為さないことが確認されたので、欠点はなくなったことになります。
またそれとは別に、従来型の欠点を修正したバージョンのキャラ定義ファイルを作りたいと思っていたところなので、これを機会に作り直そうかと思っています。

今日の絵はかぼちゃなにわとり。
もちっとかっこつけさせたかったが画力が追いつかなかった。

1152370321.png

秘密

ふにゃさんのシークレット機能を考えてました。
恒例の重力変化は、変化した重力での挙動は組み込み済みで、後は条件を考えるだけです。
ちなみに無重力というのは、重力変化としては使わないつもりです。
ふにゃ1にあったような無重力下での挙動はただ単に重力パラメータを0にするだけではできず、プログラムから変更して全く違った性質の動きにする必要があるのです。
もし無重力を作ろうと思ったら、別キャラクターとして作り、重力変化ではなくてキャラクターセレクトで実現しようと思います。
う~ん、キャラクターセレクト…使えるな。
2のときみたいに初期状態ではノーマルふにゃとサングラスを選べるようにしておいて、特定の条件を満たすことで増えていくとか。
シークレット機能なら、氷の息使い放題というのもいいかもしれないなあ。

HPメーター

Bomber丸WorldのHPメーターの表示位置をどうするか考えてました。
今まで考えていた右側に縦方向に並べるという形だと敵が横、味方が縦に並んでバランスが悪かったんですよ。
そこで、横に並べる方式を使おうと思ったのですが、最大HPが100固定というのもあり、メーターの幅も100ピクセルにしたら幅320ピクセルの画面の収まりきらないんですよね。
そんなわけで重なる部分は縦にずらしてみたのが今回の画像です。

1150207602.png

書き散らかすソフト

なんか新しいソフト考えてみました。
テーマは書き散らかすこと。
思いついたアイディアをとにかく乱雑にでもいいから適当な場所にメモとして書いておく。
断片的に思いついたアイディア一つ一つをいちいちメモ帳を開いて書いてファイルに保存するのは面倒だしファイルの数がやたら増えるしいざとなって必要な情報が見つけづらかったりするので、乱雑に書き散らかし、必要になったら特定の語を含むメモをかき集めることができるようにするのです。
具体的な仕様については、
・一つのメモは一つの粒子として扱う
・メモはテキストを始め、画像なども使える
・粒子同士には距離の二乗に反比例する反発力が働く
・腕で繋がれた二つの粒子間には距離に比例した引力が働く
・メモの存在する画面を「世界」と呼ぶ
・唯一つ、質量無限大の粒子「愛を叫ぶ場所」が世界の中心にある
・愛を叫ぶ場所は、条件を満たす粒子全てと腕を繋ぐことができる
・粒子が運動するときには速さの単調増加関数で表される摩擦力が働く
とりあえず、C++だとIDEを使ってもそれなりの形になるまで時間がかかるし、VBだと処理速度の遅さやテキストと画像を同じように扱うのが面倒ということで、消去法でC#を使うことになりそうです。

モーションブラー

ふと思いついてふにゃさんにモーションブラーの機能をつけてみました。
ただ単純に前のフレームの内容を半透明で現在のフレームに合成しているだけなので画面全体に効果が及び、動くたびに全体がぼやけます。
やっぱりドット絵にモーションブラーは合いませんね。
画面写真は撮ってないけど沢山のものを配置している状況でブラーをかけると配置されたものがもはや別物に変化してしまいます。

そうそう、のんびりナマライザ、C#で書き直そうと画策中です。
やっぱりVB6じゃ、それもラーニングエディションじゃ遅くてお話にならないんですよ。
のんびり待つにも限界ってものがあるのです。

1144763600.png

グランチルダがボールになる

弟がバンジョーとカズーイの大冒険をクリアしてました。
最後のグランチルダは強かったはずなんだけどチイトの体力自動回復がダメージを受ける勢いをはるかに上回っていたためほぼ体力全快で勝利。
グランチルダはかなり残酷な最期を遂げました。

物理量解析プログラムの解析には5つのレベルがあります。
レベル0:完全に確定した分
レベル1:確定した小数
レベル2:確定した整数
レベル3:千の位まで確定した整数
レベル4:未解析の連続した数値
レベルは基本的に解析が進めば下がるって最終的には0になります。
アルゴリズムが完成すれば公開してみようと思います。

Bomber丸WorldのBGMの変化パターンをいくつかに分類しようと考えています。
一つ一つにプログラムを組もうかとも思ったのですがデータと辻褄を合わせるのが結構大変そうだしめちゃくちゃ特別なことをするのではなく簡単なものを組み合わせるだけなので簡単なプログラムを組んでデータを渡すという方式にしたいのですよ。
サウンドテストを作るときにもプログラムとデータを分けたほうが都合がいいし。
フェード:指定の音量に徐々に近付く。目標値と時間を指定する。
プログラムチェンジ:音色を変更する。音色番号を指定。
即時切替:BGMを直ちに別の曲に変更する。BGM番号を指定する。
遷移:現在のBGMが終わった後に別の曲をかける。BGM番号を指定する。
効果音楽:指定の曲を現在のBGMに重ねる。ME番号を指定する。

クリップボードに保管

ミディビのデータ保護機能、とにかくJavaの外にデータを退避させておかなければJavaごと落ちたときに復旧ができないのです。
もちろんJavaが落ちるタイミングがわかるわけじゃないので常にどこかにデータのバックアップを取っておくことになります。
サーバー上に保存するというのは回線を切って作業できなかったりサーバー負荷が大きくなることなどから非現実的ですし、クライアント側のコンピュータにファイルとして保存するのもセキュリティの関係でできません。
そもそもバックアップがあったからといってどうやって復旧すればよいのでしょう。
画像のようにスクリーンショットが取れるわけじゃないのです。
そこで考えたのが、MIFUMIDIA上で復元可能な曲データを文字として表示し、コピーさせるというもの。
実際には面倒くさくてコピーなんてあんまりしないでしょうから、定期的に勝手にクリップボードにデータを転送します。
そうなるとユーザーがクリップボードを使えなくなるという弊害が出てくるのでデフォルトで自動バックアップは使わないようにして、「定期的にクリップボードに保存」にチェックを入れれば自動バックアップが働くようにします。
もちろんデフォルト設定はOFFです。
また、経験的にMIDIデータは同じ音が何度も続いたりして非常に冗長なので圧縮をかけてデータ量を減らします。
まともな曲を真面目に作るならどうしても10KB以上になってしまうことが多くて、その10KB分の文字というのが結構な量になったりするので圧縮が必要になるのです。
しかしそうすると高速圧縮アルゴリズムが必要になりますね。
ちなみに、この文字データをサーバー側のファイルに保存すれば、サーバーに一時保存してから後で再開するということもできるようになります。

2月1日、Bomber丸Worldのマップにかかるメモリを計算するときにさりげなく4をかけたりしていましたが、これは元々半キャラ分の大きさを当たり判定の単位にしようと考えていたからだったのですが、こうすると、二つのマップチップにキャラがまたがったときにどちらのマップチップを優先するかで困ってしまうため、やっぱり当たり判定等もマップチップの大きさとあわせることにしました。
本当は見た目に動きが不自然になるので嫌だったんですが遊びにくくなるよりはマシです。
実はこの方法、謎の男の歩き方にも悪影響を及ぼすのですが、しかしこうすることでメモリ使用量が単純計算で4分の1になるわけですから逆に言えば同じメモリで広いマップを作れるようになるので、やはりマップ優先で作ることにします。

フィールドマップ

スマブラを久しぶりにやってみたら十人組み手で次々記録更新。
全員15秒以内にクリアを果たしました。
多くのキャラで上強攻撃が有効のようですね。
そして続けてヨッシーで百人組み手クリア。
ヨッシーの場合下強攻撃がザコ軍団には有効です。
そして更に更にホームランコンテストでも記録更新。
特に今までずっと足を引っ張り続けていたドンキーで大きく記録を伸ばしました。
ホームランバットを取ってから、ヘッドバット→下強攻撃→下スマッシュ、を2回、落ちてきたサンドバッグ君にSMAAAAASH!!!

Bomber丸Worldのフィールドマップ、ファミコン・スーパーファミコンのDQやFFのように世界地図の上を歩く感じで行こうと思っていたのですが、そうすると広い範囲が一気に見えて、パルネッド王国にはほとんど町がない田舎国というイメージが付いてしまうので、ここは一つ、完全3DのRPGのように町の中とフィールドをほぼ同じ縮尺にして同じ感覚で移動できるようにしようと思います。
そもそもフィールド上で起こるイベントも結構あったりするのでフィールド上でも普通に人が表示できるようにしたかったんですよね。
しかしそうするとますますマップサイズが…。
となれば連続したマップでも少しずつ必要な部分だけ断片を読み込んでいってシームレスにつなげるということになるのか。
ちょっと面倒そうだぞ。

ミディビアンケート中間発表

6票 編集画面すら出てこない
2票 ピアノ部分クリックで音がなり、演奏によっても音が出た
2票 ピアノ部分クリックでは音がならず、演奏では音が出た
0票 ピアノ部分クリックで音がなったが、演奏では音が出なかった
0票 どちらでも音は出なかった

「編集画面すら出てこない」ってのは問題外で考慮しないけど一応確認のため、と思って項目に入れてたんですが6割もいちゃ無視できませんね。
どうも最近のパソコンにはJREは標準では入っていないようです。
JREのダウンロードページへのリンクが必須ですね。
そして2位の「ピアノ部分クリックで音がなり、演奏によっても音が出た」というのは理想的ですが、「ピアノ部分クリックでは音がならず、演奏では音が出た」がいる以上無視するわけにはいきません(何より自分もその一人ですし)。
「ピアノ部分クリックでは音がならず、演奏では音が出た」は簡単な方法でピアノからも音が出せるようになります。
「ピアノ部分クリックで音がなったが、演奏では音が出なかった」でも音が出るようにはできますが難しいので正直いなくてよかったと思います。
「どちらでも音は出なかった」は残念ながらどうしようもないです。
いなかったのが幸い。

結論。
編集画面すら出ない人のためにJREダウンロードページ(http://java.com/ja/download/)へのリンクをつける。
そしてピアノロールから音が出ない人でもちゃんと音が鳴るように改善する。

Bomber丸WorldのグラフィックエンジンはほぼyaneDIBだけなのでさらりと実装。
しかしマップの実装に苦戦中!
なんせアニメーションして高低差もあってデータ的に前後関係を作らなくても(例えばRPGツクールやSFCのRPGなどでは「手前」にあるマップチップを「上」に置くことで見た目に正しくしている)自然な形のマップデータを与えればただしい前後関係で表示されるマップを作らなきゃならないんですから!
アニメは余裕ですが高低差と前後関係は結構悩みどころです。
高低差があれば当然高いほうを後から描くのですが、じゃあ前後関係との兼ね合いはどうなる?ってこと。
自然な形のマップデータにより、一つのマップチップの大きさが任意に変えられるようになるため、スクリーン座標でZソートして描画するとデータ的には前にあるのに後ろに描画されてしまったりすることがあるのですよ(ビルボーディングと同じ問題)。
だからマップ座標でZ(奥行き)ソートしたものを更にY(高さ)ソートすれば理想的にはうまいこと表示されるはずなのですが、それにキャラを乗せると、キャラの奥行き方向の幅によりあるZ座標の範囲でまた前後関係の誤認が起こるのですよ(ビルボーディングと似た問題)。
そのため、奥行き方向の幅を補正するために画像データに近い段階でZ方向にオフセットをかけてやり、誤認される範囲を少なくし、更にゲーム的に移動範囲に制限を設け、残った誤認が起こる範囲に入れないようにするのです。
これでおそらく見た目に問題となる範囲では前後関係の誤認は起こりえないでしょう。

それと、ぜひ付けたい映像表現が、ちびロボ!にあった、主人公が物陰に隠れるとそのシルエットが最前面に浮き出て見えるという表現。
これ、ちびロボほどじゃないにしても小さくてすぐ物陰に入って見えなくなってしまう主人公たちには必須なのだと思うのですよ。
実装はどうやればいいかな…。後で考えておこう。

再利用性

もう言ったと思いますが、Bomber丸Worldのグラフィックは2Dに見せかけた3Dにしています。
そして今日作ったのはテクスチャ管理システム。
今回はRPGである都合上、画像をふんだんに使いますので、その画像を効率よく処理する仕組みが必要というわけです。
3Dで作るということで画像の表示はポリゴンにテクスチャを貼って表示させるわけですが、RPGのマップだと同じマップチップをいろんなところで表示したり、戦闘画面では同じ種類の敵が複数登場したりと、同じ画像が複数の場所で使われるケースが多いため、使う数だけ同じ画像のテクスチャを作っていては無駄であり、特にマップチップだと同じテクスチャ(それも結構でかいやつ)が何百枚と作られて、まともに動かせる状態ではなくなってしまいます。
だから、同じ画像のテクスチャを作ろうとしたときは前に作ったテクスチャを代わりに使うようにするわけですが、RPGでは場面の切り替わりと共にさっきまで沢山使われていた画像が今度は全く使われなくなるというケースもあり、逆にもう使われなくなった画像はどんどん破棄していく仕組みが必要なわけです。
ちなみにふにゃさんでは画像再利用をマップキャラ(ふにゃやギヤバネなど)に使っていたのですが、画像のサイズは高が知れているし、どのキャラもその後近いうちに再び使われる可能性が高いということで、読み込み時間を減らすため、破棄するのは絶対に使われなくなってから、つまり、ゲーム全体の終了時のみになっていたりします。
話を戻しますと、幸いにしてDirectXの全てのインターフェースはそのための参照カウントシステムを持っているため、ファイル名とテクスチャを関連付けてリスト(実際にはSTLのmap)に記憶しておき、あるファイルのテクスチャを使うときはリストからファイル名に対応するテクスチャを探し出し、見つかったらテクスチャの参照カウントを1増やしてからそのポインタを確保しておき、見つからなかったらテクスチャを作成した上でリストに追加、逆に使い終わったときは必ずリストにあるはずのテクスチャを探し出して参照カウントを1減らし、0になったらテクスチャを破棄(これは自動で行われる)した上で、リストからもテクスチャの情報を削除。
これで、常に必要な分のテクスチャだけがメモリ上に置いてあるということになります。
もしかしたらこういうことはDirectXが勝手にやってくれてて自分は無駄なことをやっているだけという可能性もありますが、まあそれにしても無駄はリスクに比べればそう大きなものでもないのでよしとしましょう。

人物を描いてみた

以前の日記に書いたドットを潰さないレンダリング方法、あれ別に3Dでなくとも2Dでも高さ成分を真正面から見た高さの8割になるように、奥行きを真上から見た奥行きの6割になるようにドット絵で描けば縦・横・高さの比率が正しいドット絵として立派に成立するじゃないですか!
というわけでそういう描き方をしたマップチップでマップを描くプログラムを作ろうとしていたのですが何をどう間違えたのかマップチップを作っているうちにマップ上に配置する人物キャラを描きだしてしまいました。
元々人物のデッサンなんて小学校以来やってはいないしましてや37度から直立姿勢の人を描くなんてことは一度もなかったので、とりあえず理論的に正しい人物を描こうと身長別-男女のボディサイズ平均を見て数値を見ながら描いていったのですがどうにも日本人の体は細長すぎるようだったので、今度はメタセコイアに入っていた人物の3Dモデルを37度の角度から見下ろした画像から輪郭抽出してそれを参考にしながら描いてみたら結構自然な感じになりました。
しかし謎の男のつもりで描いていたのですが、暗いね。

1136645637.gif

文字列配列管理クラス

さりげなく昨日のStringArrayを公開しました。
プログラミングコーナーの一番下からいけますよ。

先日のBomber丸Worldの敵DLLの問題、敵キャラクラスは根性で共通インターフェイスを作って、逆にDLLから本体へのアクセスは文字列としてコマンドを渡して動かすということにしようと考えています。
これなら本体に後から機能追加してもDLLのほうはコンパイルしなおさなくて済みますからそれなりに開発しやすくなると思います。

分離型

プログラミングコーナー更新ですよ!
はっきり言って思いつきでふと更新しました。
しかし変数に符号付きデータを使っているということを忘れていてソート結果をバイナリエディタで開いて0付近から始まっていなくてかなりあせてしまいました。
しかも、ActiveBasicはファイルの読み書きが弱く、バイナリファイルをまともに読むにはAPIに頼らねばならなくて、面倒だったのでVBで読み込んで「data[0]=… data[1]=… …」というようなプログラムで直接変数にデータを代入するファイルを作って、ABだけファイル読み込みはせずに済ませてしまいました。
純粋にアルゴリズムだけの速度を比較したいということのほかにこういうこともあったんですよね、ファイル読み込みの時間を考慮しなかったこと。

Bomber丸Worldの敵のシステム、基底クラスにキャラクラス、そこから派生して敵キャラクラス、更に派生して個別の敵のクラス、という構造にしたいのですが、それを全部いちいちプログラムに埋め込んでいたら実行ファイルのサイズが、使用メモリが、起動時間が、えらいことになってしまいます。
そこで考えたのが、敵キャラクラス一つにつき一つのDLLに埋め込んで、敵キャラをDLLで提供するという方法。
こうすれば本体をコンパイルしなおさなくても敵を追加できますし、動作が独立になることで保守もしやすそうに思えます。
しかしこれには問題があって、例えばDLLを見れば一気にネタバレしてしまったり、ファイルを削除すれば敵が出なくなったり、そのあたりは適当に考えて隠したり存在チェックをすれば済む話なのですが、もっと問題なのは、DLLの実装方法です。
基本的に同じ基底クラスを本体とDLLで共有して、DLL側で派生クラスとして実体を提供するという形になるのですが、途中で基底クラスの実装を変更してしまうとDLL全部をコンパイルしなおさなくてはならなくなり、かえって保守が難しくなってしまうのです。
だから先にインターフェイスを決めてしまい、後はずっと同じものを使うのですが、この問題があるということは、もっと別の問題も考慮しなくてはならなくなります。
それはDLLの敵からゲーム本体にアクセスする方法です。
このゲームでは他のキャラクターを使って行動したり、ゲーム内の変数を利用したり、高度なグラフィック処理をする可能性があるので、ゲーム本体のクラスなどに比較的自由にアクセスできることが必要なのです。
う~ん…難しそうだ。

管理について考える

ふにゃのページ更新しましたよ。
機知のバグとインストール・アンインストール方法を掲載しました。

そして、実はアクセス解析により訪問者の見るページの傾向に、説明をほとんど見ずにダウンロードする人と、説明ばかり読んでダウンロードしない人の二極化が見られたので、それに合わせるよう、リストのページからさっさとダウンロードできるようにはして、なおかつ紹介ページは紹介ページで充分なボリュームを持たせ、その上更に、私のことだからこんなことをしたらきっとリストのページか紹介ページのどちらかを更新し忘れたりすると思うので、リストのページのほうは紹介ページから必要な部分を抜き出して自動生成するようにしようかと考えています。
幸い、リストのページは完全に型にはまった書き方をしているので、プログラムによる作成が容易です。
ついでに言うと、ファイルサイズは更新し忘れ率が非常に高いのでこれもプログラムで自動生成するようにしたいです。
しかしこれを実現するにはまずダウンロードページ全般の構成を見直さねばなりません。
専用ディレクトリを作るか作らないか、どちらかに統一しないと不規則でプログラムには扱いづらいのです。
もちろんパネルγのように紹介ページにやたらと多くのファイルを使っているものもあるのでここはディレクトリ作成に統一で。
しかし、数少ないとはいえ検索サイトからHTMLページに直接飛んでくる人も多いのです(どっちや)。
いきなりディレクトリに移行して前のページを消してしまっては何かと不便でしょう。
だったら両方作ればいいのだけれど、例によって片っぽの更新を忘れるのでやはり同じファイルは作るべきではなさそうです。
それならばリダイレクトを使って、HTMLページに飛んできたら自動的にディレクトリに飛ばしてやればよいのです。

Bomber丸Worldのキャラのページを誤って削除してしまいました。
手元にもサーバーにももちろんゴミ箱にもファイルが残っていないのでキャラ紹介ページは1から作り直しになります。
まあ別にいいでしょう。
あんまり気合入れて作ってなかったし、半分忘れかけてたし、アキヤメのほうにもっと詳しいのがあるし。

ふにゃさんのセーブデータを作ろうとしているのですが、仕様がなかなか固まりません。
セーブデータと設定は分離すべきか。
シークレット機能によりセーブデータと設定は連動しているのですが、設定はエディタで変更されてもいいけど、セーブデータでは簡単には改変されたくない。
既にユーザー定義BGMの設定は分離することが決まっています。
はっきりと分離するメリットがあったためです。
セーブデータは簡単には改変されたくないのですが、デバッグのためや、ゲームを破壊的に楽しむ人を思うと、ここは別に一緒くたにして改変されてもいいかなと。
だけど、普通の人が設定ファイルを開いてついうっかり、は避けたいし。
暗号化も面倒だし、意味もあまりないし。
う~ん、簡単な符号化とチェックサムとか。

簡単エディタ

ふにゃふにゃのページを更新しました。
開発メモ。どうやら以前のエディタは難しすぎてエディタ作者自身にも手に負えない代物だったようで、以前の何でもできるエディタは残しつつも、新しい簡易エディタを作ることにしました。

  1. ペイントの鉛筆ツールで曲線を描くかのごとく自由で簡単で直感的な直線生成
  2. ドラッグ&ドロップで置きたい場所に置ける画像
  3. 必要なファイルは全部ステージファイル一つに埋め込み、最低限動作に必要なファイルを極力減らす
  4. エクスプローラからドラッグ&ドロップで勝手に背景としてインポートされる一枚絵
  5. その他必要なファイルはインポートできるようにする。インポートしたファイルは関連付けられたプログラムで開く
  6. いろいろあった設定は必要最低限まで減らす。あとは自動設定
  7. 当然の如く用意されるすり抜け防止策
  8. ステージ作者が最初に使いたがるだろう機能をコンパクトにまとめたツールボックス
  9. ステージ作者を困惑から救う優れたヘルプシステム
だいたい開発理念はこんなもの。

そして、Bomber丸Worldのページも更新。
戦闘画面がついに出ました。
イメージ画像ですけど。
なかなか面白いことになっていますよ。

そんでもって、RPG±0、さしあたり自分で不便に思っていた右クリックの挙動を統一。
スポイト機能と右クリックメニュー、両方一気に実行されます。

チャットの人工無能ちゃん、以前のようにファイルに入れておくよりも、mySQLのデータベースに入れておいたほうが管理しやすいと思ったので、mySQLを勉強し始めました。
とりあえずphpMyAdminの使い方を思い出しつつどんなデータがどう使われるのかを覚えていきます。

ふにゃさんは今日はBGMを作成中。
先日言っていた違和感はほぼ取れたように感じます。
メロディ以外のパートは修正するときの補助のために入れた音で、後ではずすかもしれません。

1125326932.mid

在室者管理

さてと、チャットの在室者管理でも作りますかね。
入室時:member.dat読み込み→入室者チェック→member.datにデータがなければmember.datに入室者を追加して入室メッセージを表示→member.datを更新
ログ表示時:m読み込み→長期ROMの人がいた場合自動退室させてm保存→在室者を表示
発言時:m読み→発言者がmになければエラー→最終発言時間を更新してm保存→ログ表示
退室時:m読→退室者いなければ何もせず→いたら削除&m保&退室メッセージ
てな具合でどうでしょ。

DirectMusicProducerで作ったデータを再生しようとして見事に挫折。
どう頑張っても全く音が鳴らないしエラーが出るんですよぉ。

今日は「Bomber丸World」の海音楽裏。
短調です。

日記カテゴリに「掲示板」と「チャット」追加しましたよ。

1124204328.mid

<前 次>