日記(997)

お、終わった…。
思ったより手間取った…。

ふにゃさんのヘルプ作ってます。はい。
正直、バージョン1.00はバグだらけだったので下手にヘルプを作って使わせるようにしなくてよかったと思ったりしています。
でもあれですわ。ゲームプレイとエディットに関する重要なバグは一通り潰したのでこれで心置きなくヘルプが作れますわ。
しかしHTMLヘルプってJavaScriptがうまく動かないな…。
JSでコンテンツの一部を動的に作成してHTMLヘルプとWWWの両方に対応させたかったのですが目論見が外れました。

はいはいはい～。ふにゃさんのバグを一覧にしてみたら結構沢山あるじゃないの。
そして自分で直せそうなものと直せないもの、直す気のないものなどに分けて、バージョンごとに記録してみました。
もっとも、今は先日公開した1.00と今作っている1.01しかないのですが。
せっかくなのでこういったバグや機能などのバージョンごとの変遷を表にしたページを作ってみました。
ちょっとこれはメタセコイアのページの影響受けてます。
そして、過去のバージョンの機能が見られるのなら過去のバージョンもダウンロードできるのが自然だろうというわけで、試験的に過去のバージョンもおくことにして見ました。
正直、今作っているバージョン1.01はほとんどバグフィックスのみなので過去のバージョンを導入する利益はほぼ皆無なのですが。

しかし簡単なアルゴリズムでできると思っていたけど思ったよりコード量が長くなってしまった。
しかも最初間違えてZeroMemoryしちゃったためにSTLのvectorが使う直前になって中身がなくなってしまって、読み込みそのものは正しいはずなのに必ずメモリエラーが起こるという事態になっていました。
もちろんこう書いているからには既に直しているのですが。
ほかにもいろいろ細かいところで間違いなどがあったのですがとりあえず今のところ困った誤動作はほぼ起こっていません。
ついでに画像リソースがいつの間にか解放されなくなっていたバグを修正。

1137503895.png

うん、キャラグラフィック、マップキャラだけでなく一般的に広く応用できるんじゃないかと思ったので若干内容を変更して仕様を定めてみました。
開発室に詳しく載せてます。
うん、なんか他のゲームでも使えそうだ。
そもそも今回は珍しく部品から作っているので他のゲームにも使いまわしやすいようにできているんですよね(というより「他のゲーム」が他でもないBomber丸Worldなのですよ)。
極力入力の手間を省く(データ量が手動入力するには多すぎる)ためかなり省略表現に強い作りになっていたりします。
1コマだけのアニメーションとすれば静止画にもなりますしアニメデータそのものは描画を担うわけではなくいつどこの画像を表示するかという情報を管理しているだけなので、描画する側でその情報の解釈を変えてやればマップチップにもマップキャラにも顔グラフィックにも戦闘グラフィックにも特殊エフェクトにも使えるようになります。

Bomber丸World、キャラグラフィックにはキャラごとに定義ファイルを用意して、それぞれのポーズ名と、そのポーズごとにどの画像を使うか(正確には画像のどの位置を切り取って使うか)、どのようなアニメーションをするか、どの程度ランダムに揺らぎを与えるか、などをデータとして定めておきます。
これにより、例えばふにゃの場合、「立っているポーズ」でたまに瞬きもしていたりしますし、キャラ一般の場合、「歩いているポーズ」で歩くアニメーションをキャラごとに定めたりできるわけですよ。
基本的にキャラグラフィック定義ファイルの書き方は、
「要素名 値1 値2 ～ "ポーズ名1" "ポーズ名2" ～」
てな感じで、要素名と値をクオーテーションで囲まずに必要数だけ書いた後、クオーテーションで囲んだポーズ名をずらずらと連ねてゆきます。
ポーズはキャラごとに任意に追加することが可能で、必須要素以外はイベントによりポーズを指定することで使います。
必須のポーズは"StopFront" "StopRight" "StopBack" "StopLeft" "WalkFront" "WalkRight" "WalkBack" "WalkLeft"の８つで、つまり、歩いていないときと歩いているとき、ということです。
ちなみに、"Common"というポーズもあって、これはポーズを定義したときに一部の要素が抜けていたりすると"Common"と同じ値だとみなされるようになっています。

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

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

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

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

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