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

今日メモちらしが原因不明の動作停止をしました。
元々暴走が怖かったため動いてるか動いてないかわからないぐらいの低速で動かしていたのでずいぶん長いこと気付きませんでした。
とりあえずソフトを再起動したら直ったのですが、止まる条件はプログラムの終了以外になかったはずだったので少し気持ち悪いです。

のんびりナマライザのログ読み込み部分の中枢が出来上がりました。
先月27日に言っていたところのファイル解析です。
まず、速度は多少遅くなるのですが、エラー処理を正しく行い、可読性の高いコードになるように、そしてもちろん正しいデータに対しては最低限正しく動くようにしました。
読み込みの都合や実際に解析するときの必要性などから一部のデータを使わないことにしたり場所を色々移動したりもしました。

掲示板の迷惑書き込み対策、もっと単純でなおかつ当たり前の方法がありました。
投稿内容反映の前に、投稿内容確認画面を入れて1ステップ多くするのです。
これにより一般のお客様には利便性が上がり、迷惑書き込みをする人には面倒になるのです。
一般のお客様から見れば、投稿結果のイメージが投稿前に確認できるし、やろうと思えばその場で修正もできるし、不適切な表現があれば警告が出るし(出せるようにしたい)、チャットのようにガンガン書き込みまくるということもないので便利さだけが大きく上がるのです。
そして迷惑書き込みをする人にとっては、一手間多くかかる(つまり2倍面倒になる)、機械での投稿がしにくくなる、ということで書き込みにくくなるのです。

掲示板にの一般の利用者に迷惑のかかりにくい迷惑書き込み対策については、一つの案として、レベル別の書き込みフォーム＆投稿内容制限の変化を考えています。
まず書き込みフォーム。
元々用途に応じて様々な形態の書き込みフォームを使うことを考えているので、普通の投稿にも様々な投稿フォームがあってもあまり問題にならないのです。
非常に大まかに分けると、簡易コメントフォームと通常書き込みフォーム。
簡易コメントフォームはテキストだけのシンプルな画面構成で誰でも書き込むことができますが、載せられる情報は少なく、ちょっとしたことで投稿内容審査に引っかかり、封印されます。
通常書き込みフォームは、クッキーと画像を使って、利用者別の投稿画面が自動的に割り当てられます。
画像には適切な代替テキストを用意せず、目で見ないと何が書いてあるかわからないようにし、入力フォーム自体の形や配置も毎回変化します。
これでロボットによる書き込みフォームの判別は難しくなります。
しかし、各入力欄のname属性がわかりやすい名前であると意味がないので、一見意味のない文字の羅列をname属性に使い、投稿された時点でCGI側で、じゃなくてPHP側で元の名前に読み替えます。
そして、元の名前と意味不明な名前の対応も、一定時間で変化します。
すると変化する時間をまたいでの投稿がまずいことになりますが、そのあたりの時間差は考慮して、正しい対応を取れるようにします。

メモちらしのページに暴走について記述しましたよ。
ちょっと数値設定に対してデリケートすぎるんですね。
こちらのほうでは時間を掛けてやっと傷跡が戻ったところです。
とにかく極端なパラメータ変化は危ないようなのです。

Bomber丸Worldの属性攻撃について考えてます。
私は敵の属性がわからず力押しで戦ってしまうことがたびたびあり、自分のゲームでも同じようなことがみんなに起こったら嫌だなぁと思うのです。
属性を色分けしてみるとか、いっそのこと誰かが教えてくれるとか、ちゃんと考えてプレイできるような方法を考えているところです。

ナマライザの読み込み処理、これで完成かと思いきや全く正常に動かないプログラムであることが判明！
いえ、まだ実行したわけじゃないですが、簡単なデータを想定してコードを順番にたどっていったら、まだ読み込まれていないデータを処理しようとして、データがないとして、データが丸々残ってるのに次のステップに行って、その次のステップでは次に来るデータが特定の形式であることしか想定していないので、誤った場所のデータでは当然形式が会わなくて、どんどん違うデータを生み出し続ける、ということになってしまっています。
特定のフォーマットのみに対応して高速化を図ろうという考えでしたが、ちょっといくらなんでもデータの狂いに対して弱すぎるようでした。
今の状態だと全く正しく読み込めないばかりか、その正しく読み込めないところを修正したとしても、データそのものに少しエラーがあった場合でも、どんどん誤りを蓄積してそれ以降の全てのデータに悪影響を及ぼすのです。
ログデータは行単位で記録されているので、データの破損があったとしてもそれにより信用できなくなるのは該当する行だけであり、改行コードの一つも出ればそれ以降のデータは正しい可能性が高いのです。
というわけで今後の課題は、データの正しい読み込みと、エラー時の復帰の２つになります。
末端の表示処理はまあ速度さえ気にしなけりゃそれなりに楽にできるでしょう。
データ読み込みのときにも同じことを思っていたような気がしてなりませんが。

メモちらしの改良を考えています。
どうしても粒子の数が増えてくると色々なところで腕が伸びきってしまって扱いにくくなるので、腕が必要以上に伸びないような対策を考えています。
これの根本的な原因は平方根計算をするのを嫌って反発力の算出に距離の二乗に反比例した値ではなく距離に反比例した値を使ってしまったことだったのですが、既にこの仕様で動き出してしまっている以上、この部分は現段階のメモちらしでは変更するわけには行きません。
そこで、対症療法的な考え方ですが、これ以上伸びてもらうと困るという、そういう数値を設定しておいて、腕の長さがその数値を超えている場合は腕の引っ張り強さを上げるのです。
ただ、腕が長すぎる間ひたすら上げっぱなしだと、本当は時間さえかければ規定の長さに戻るのに、その途中であっても規定の長さに達していないというだけで必要以上に腕を引っ張ってしまうので、それが暴走や、縮みすぎという結果を招く可能性が高いです。
それを防ぐには、自動で腕の引っ張り強さを下げることはしないので、とにかく腕の引っ張り強さの上げすぎに注意する必要があります。
腕が長すぎるということは、つまり、腕の引っ張り強さが弱すぎて、反発力に負けているということを意味するので、反発力≧引っ張り力である間だけ引っ張り強さを上げてゆきます。
反発力＜引っ張り力となっている間は腕は縮み、腕が縮むと反発力が上がり、引っ張り力は弱まります。
引っ張り強さが足りない場合、腕の長さが規定に達する前に再び反発力≧引っ張り力になるため、改めて引っ張り強さを上げてやります。
これを規定の長さになるまで続けてやれば、おおよそ規定の長さよりも少し短いところで腕は縮み終わるはずです。
縮みすぎたところがあれば、まあ、それを編集するのは長すぎの場合よりは簡単なので、手動で調整してもらいましょう。

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

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

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

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

＜オープニング＞
シロ、仕事する
↓
同僚のテルルと一緒に帰る
↓
途中売店に立ち寄る
↓
シロだけ入って買い物しているとテルルさらわれる
↓
シロ、終わってから気付き、慌てて帰る
↓
クロに警察は当てにならないといわれ、自分らで探すことになる
↓
途中、ふにゃと出会い、なぜかついてくることになる(任意)
↓
また売店に立ち寄る
↓
謎の男が襲われているので助けることになる
↓
バトル：ヨワシ戦(ふにゃを仲間にしていなければこの戦いの途中で仲間になる)
↓
謎の男が仲間になり、事件の事を聞かされる
↓
とりあえず、クリアス・バイオ研究所なる場所へ行くことになる

＜クリアス・バイオ研究所＞
入るといきなりコピー機登場
↓
バトル：コピー機戦
↓
(途中、まだ考えてない)
↓
よくわからないがクリアスが悪者ということらしいので戦うことになる
↓
ボス：クリアス戦
↓
謎の男が魔法のようなものでクリアスをどこかへ飛ばしてしまう
↓
謎の男によると、他にも怪しいところがあるらしい

＜ホーリィ製鋼所＞
町でオミナガミから社員証をもらう(任意)
↓
社員証を使い、入る(ない場合、扉を爆破し強行突入)
↓
なぜかアラ軍団に襲われる
↓
バトル：アラ軍団戦
↓
(やはり、ダンジョン内の仕掛け等は実際作り始めてから考えるべきだろう)
↓
開かずの扉を爆破するとプララに襲われる
↓
ボス：プララ戦
↓
謎の男が魔法のようなものでプララもどこかへ飛ばしてしまう

＜海洋研究所＞
どこかで船を借りて海洋研究所へ
↓
(なにもかんがえてない)
↓
ボス：ヨシフミ戦
↓
謎の男が魔法のようなもので(以下略)
↓
なぜか帰りに詐欺容疑で警察に捕まる

＜刑務所地下＞
留置所じゃなくて刑務所…？ここの警察は当てになりませんから
↓
囚人の一人に地下通路へと案内される(何もせず果てしなく長い時間待っていれば釈放されることも可能)
↓
なぜかキャティアと戦うことになる？
↓
バトル：キャティア戦
↓
(これといった大事なイベントは用意されていない)
↓
出口を塞いでいるボス！と戦わねばならない
↓
ボス：ボス！戦(本名は今は教えません)
↓
謎の男が魔法のようなものでボス！を……飛ばせなかった
↓
ともかく、脱出

＜インサイド・コエダメ＞
病院の裏口から自然園へ潜入
↓
どこかにある穴から地下のインサイド・コエダメへ入れる
↓
(ここは、本当に何のイベントもない)
↓
なりゆきでゲロノフン２世と決闘することになる
↓
ボス：ゲロノフン２世
↓
謎の男が(以下略)

＜カリスマ小中高大一貫校＞
練習試合という名目で入れるらしい
↓
というわけで強さを試される(でも弱い)
↓
バトル：先生戦(この先生にはまだ名前がありません！)
↓
(ここには大小さまざまのイベントがあり書ききれない！)
↓
悪徳校長を退治することになる
↓
ボス：ノーリッジ戦
↓
謎(以下略)

＜カイモチ村＞
謎の男から、最後に行くべき場所がカイモチ村だと知らされる
↓
カイモチ村に入るとふにゃが何かの存在に気づく
↓
バトル：オバケ戦
↓
(以後、各地にいるオバケ達が見えるようになり、会話も出来るようになる)
↓
村長かいもち１世に話を聞く
↓
どこかの壁を爆破しラストダンジョンへ潜入
↓
謎の男が仲間から離脱する
↓
バトル：ツヨシ戦
↓
(謎の男を再び仲間にするかどうかでストーリー分岐)

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

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

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

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

1152370321.png

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

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票 どちらでも音は出なかった

「編集画面すら出てこない」ってのは問題外で考慮しないけど一応確認のため、と思って項目に入れてたんですが６割もいちゃ無視できませんね。
どうも最近のパソコンには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でも高さ成分を真正面から見た高さの８割になるように、奥行きを真上から見た奥行きの6割になるようにドット絵で描けば縦・横・高さの比率が正しいドット絵として立派に成立するじゃないですか！
というわけでそういう描き方をしたマップチップでマップを描くプログラムを作ろうとしていたのですが何をどう間違えたのかマップチップを作っているうちにマップ上に配置する人物キャラを描きだしてしまいました。
元々人物のデッサンなんて小学校以来やってはいないしましてや37度から直立姿勢の人を描くなんてことは一度もなかったので、とりあえず理論的に正しい人物を描こうと身長別－男女のボディサイズ平均を見て数値を見ながら描いていったのですがどうにも日本人の体は細長すぎるようだったので、今度はメタセコイアに入っていた人物の３Ｄモデルを３７度の角度から見下ろした画像から輪郭抽出してそれを参考にしながら描いてみたら結構自然な感じになりました。
しかし謎の男のつもりで描いていたのですが、暗いね。

1136645637.gif

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

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