「ふにゃさん」に関する日記(19)

んでもってパネルγバージョンアップ完了。
キーボードによる入力を忘れてたけどまあいいや。

ふにゃさん、敵画像はリソースに入れておこうかと思ったけどなんとなく気が進まないので外部ファイルに。
ステージ読み込みとかそろそろ実装しようかなと思って作り始めています。

ふにゃさんのステージファイル形式。
データのまとまりごとにチャンクを作ったり画像データを内包したりすることから、PNG形式にしてみようかなと思ったりしたけれども、いくらなんでも荒唐無稽なんでやめました。
IEから右クリックで保存できるのがいいと思ったけど、BMPで保存されたり、クイックビューアで回されたり、最適化ソフトでステージデータをごっそり抜き取られたりするのは良くなさそうなのです。
それはそうと、ステージファイルそのものの大きさは、階層構造などもあるので、基本的には第一作の３倍程度のファイルサイズにはなるはずです。
そこで氷のステージを参考に今作でのステージサイズを計算してみると、およそ20KBとなります。
メモリ容量大丈夫だろうかと心配していたのですが、どうやらかなり大きなステージでも全データメモリに入れておいても問題はなさそうです。

http://www.sys.cs.meiji.ac.jp/~masao/Board/infosys2000/security/firewall.htm
ふにゃさんのステージでは公開鍵暗号により暗号化を施してみようかと思ったけど結構敷居か高いようです。

それはともかく、キャラの挙動について考えてみます。
キャラは元々できるだけ自分のことは自分でやる自立したオブジェクトなのですが、しかしキャラ同士はお互いに影響しあっているわけです。
例えば、ギヤバネなどは２体がぶつかるとお互いに相手をバネではじいて両方とも吹っ飛んでしまいます。
しかし、文字通りに相手をふっ飛ばしてしまったのでは、向こうにとっては「相手に動かされた」となり、キャラの自立性は損なわれるわけです。
こんな場合は、相手キャラに、これこれこういう力を加えたという情報を伝え、それに対してどうするかは相手に委ねるというのがよさそうだと考えます。

ナマライザ作り始めました。
ま、解析するよりも遅く、ゆっくりじっくり作っていこうと思ってます。
とりあえず絶対必須となるメインウィンドウとファイル管理ウィンドウだけ作成。
動作の実装はまだ。

ふにゃさんのステージファイル形式どうしようかな。
将来の拡張を考えると、データをチャンクごとに記録して識別子でヤットコヤットコやって、やるのがいいのかしら。
４バイトの識別子・４バイトのデータサイズ・可変長のデータ本体。とか。

さて、スクロール情報はどこに保管しておくべきか。
実際に影響が出るのはスプライトとマップなのでそのどっちかに保管しておくのがよさそうなんだけれども、スプライト側に保管しておくとなれば、みんな共通で使うのでstaticにするのだけれども、そうすればマップ側でスクロール位置を変更した際になぜか子分であるスプライトの代表に対してスクロール位置を教えなきゃならなくて、だからといってマップにそれを持たすと今度はスプライト全体がマップに依存した作りになる。
それで構わないっちゃ構わないんだけど、見るもの見てからだとできるだけ自立した作りにしたくなる。
やっぱ両方に用意しておいて、描画の段階でスプライトに渡す、というのが良いだろうか。

そうそう、学校ではオリエンテーションとか。
とりあえず今年取れる分で卒研以外はほぼ揃うんだけど、一年のときにおろそかにしていた教養科目のしわ寄せが少しばかりやってきて、時間割の関係上１科目だけ卒研の時期まで入ってしまいそうな予感。

身体検査。
身長は相変わらず。
体重も相変わらず。
視力も相変わらず。
・・・・

ふにゃさん、Cf3ObjectBase作成。
正直言ってどこまでyaneSDKに頼っていいのかまだつかみ切れていません。
とりあえずCSprite系列は求める結果を実現してくれそうにないので使わないことにします。
CMapLayer系も同様。
CShellも無意味だよなぁ。
しかしもしかしたら使うかもしれないというのを間違って削除してしまってはいけないのである程度形になるまではどのファイルも削除しない。
ファイルが多いとビルドに時間がかかるんだけどな…。
オーディオ系や描画系は特に判断しづらい。
どこでどういう関係になっているのか把握しきれない。
アシストクラスは単体で便利なので削除はしない。
気が向いたら使おう。

yaneSDKの中にあるCGameObjectBaseクラス。
ガーベジコレクションとか、いろいろ参考になります。
まあ、新たに作り直しても多分面倒なだけなのでふにゃさんのときにはこれの派生クラスからさらに派生させて使うことになりそう。
CGameObjectBaseを一度派生させたものをCf3ObjectBaseとしておいて、マップのスクロールも考慮した座標を使うことにする。ということで。
そういえばCSpriteExとかは…。

マップ構造どうするかな。
DirectDrawでは画面サイズを超えるサーフェスは作れないって聞いたことがあるような気がするけどどうなんだろう。
背景、キャラのすぐ後ろ、キャラのすぐ前、前景、の４つにすることはほぼ決まっているのですが、背景はできれば一枚絵を表示するという選択肢もほしかったのですが。
やっぱり背景もマップチップの組み合わせで・・・？
ゲームボーイっぽくなるなぁ・・・それはそれでかまわないけど。
ゲームと直接的に関わるのはキャラの前後だけなので他は表示しない設定も可能。
んでもって、表示させないことができるほうはサイズも自由、と。
キャラ前後のは32x32固定。

ひさびさに登校。
池を埋め立てて宝くじの宣伝に使うのは別にどうってことないけどそこに泳いでた鯉はどうした鯉はっ！！

ふにゃさんのステージデータのフォーマットを考案中。
他人と競うものがない今作においてセーブデータはあまり重要ではなく、むしろ誰でも作れるステージデータのほうが捏造に強いものにしておかなければならならない。
しかも、手軽さという点では、ひとつのステージデータは基本的にひとつのファイルに収めておかくべきである。
理想を言えばマップチップも取り込めるようにしたいが、これについては他のステージでも流用する可能性が高いので却下。
スクリプトも仕込めるようにしたいけどスクリプト本位のものは前作で懲りた。
そして、マップチップ本位で、敵キャラクターなどの仕掛けを無数に設置できて、ゲームシステムの範囲内で拡張性の高いものを作るべき。

BM98'S ROOMつうにてシーン管理クラスの使い方考え方とe-maのど飴について調べてきました。
そしてふにゃさんで使うシーンを適当に作成。
もちろん実装はまだ。

パネルγのページ更新。
裏話ですよ裏話！

ふにゃさんの開発再開。
久しぶりにコード見てみたら自前シーンクラスが。
う～ん、これでも一応行けそうな気はするけどちょっと不安だなぁ。
まず、なんにでも使える変数を用意しているところが無駄。
クラスごとに違う変数を使うのが当たり前だからなんにでも使える変数は何にも使われない。
使う手もないわけではないけどそれはそれで無駄。
クラスの中にRun関数を作ってその中でメインループをまわしてるけどこれはパネルγで懲りた。
Alt+F4で強制終了されたときの動作が不定になるんですよ。
たまに終了してもプロセスが残ってしまうバグはおそらくこれが原因。
そんなわけで、シーン管理にはyaneSDK2ndについてるシーン管理クラスを利用。
描画エンジンも、DIBのことはよくわからないけどとにかく使ってみたいのでyaneSDKのものを利用。
サウンドはどうするかな。
ただ鳴らすだけじゃ芸がない。
効果音は作れないし、となれば音はBGMに組み込むことになるだろうと思うので、yaneSDKは…使うかも。
ゲーム内の物体はどっちみち結果が同じだと思うのでyaneSDKのCGameObjectを利用。

MIDIAP、はじめました。
MIDI再生についてはhttp://www.ccad.sccs.chukyo-u.ac.jp/~mito/syllabi/mediaProg/midi/(chukyo-u,sccs,Ito Lab 中京大学、情報科学部、伊藤　誠ゼミ)を参考にしてみます。
さすがに学校の教材だけあってわかりやすい。
一応作り始めたんですよ。
これからどうなるのか、自分でも想像付かないんですけど。

ふにゃさん、BGMに特殊効果はつけるつもりだけど、パネルγほど極端にはしない予定です。
なんとなくさっきと曲の雰囲気が違う、というイメージで。

昔に学校などで貰った、今になってはもういらないプリント類を整理していました。
高校時代の散々な成績のテストはシュレッダーにかけてポイ。
他のものも例外なく破いてポイ。
シュレッダーを分解掃除していたらばらばらになっちゃいました。
すぐ直したけど潤滑油が手についた。

「CharaBox」の画像別の表示を作りました。
Jpeg294個、GIF645個、なし331個でした。
ついでに、最終更新日別の表示に最終更新から1年以上2年未満のカテゴリーを追加しました。

「ふにゃさん」に登場するギヤバネを描いてみました。
敵か味方かと言われると、敵と言わざるを得ないのですが、行動がわかりやすく、扱いやすいので、うまく立ち回れば味方のように使うことも可能です。
ちなみに、バネは何かが近づかないと出てきません。

「ふにゃさん」に登場する敵「ギヤバネ」を描いてました。
機械仕掛けのおもちゃっぽい敵で、外側にぎざぎざがついています。
触ってダメージを受けることはないけど、跳ね飛ばされることがあるのである意味ダメージを受ける場合よりも注意が必要です。

「カービィのきらきらきっず」で、9999点になったら、ギブアップされちゃいました。
あと、ラウンドクリア全クリア。

画面の大きさw=(w, h)、ふにゃの位置p=(x, y)、速度v=(dx, dy)、表示位置s=(sx, sy)、実際の表示位置sr=(srx, sry)、表示位置のずれo=(sox, soy)、実際のずれor=(sorx, sory)、大文字は定数としてみる。
s = p - w / 2 + or
o = v * A
or は、それぞれの成分において、o に少しずつ近づく。
o = or にしないのは急停止及びジャンプのときに画面が乱れないようにするため。
sr = s
ただし、画面端では画面外を表示しないよう補正する。
滑らかで行き先を確認しやすいスクロールは思ったより簡単なアルゴリズムで実現できそうです。

明日までに合格貰わないと留年になってしまうレポートを出しに行ったらずっと先生不在。
明日に賭けますか。

そういえば基底クラスと派生クラスってコンストラクタとデストラクタが呼び出される順ってどうだったっけ。
と思ったので、早速実験用のプログラムを作ってみました。
基底クラスAとそれを継承した派生クラスBを用意し、それぞれのコンストラクタとデストラクタにメッセージを表示するコードを書いて実行時にクラスBを生成！
結果は、予想通りに「Aのコンストラクタ→Bのコンストラクタ→Bのデストラクタ→Aのデストラクタ」でした。
これまでは念のため基底クラスには初期化のコードを書かないようにしていたのですが、これからは心置きなくコンストラクタで初期化できます。
一応、ダウンロードできます。

3DはZバッファを部分のコードを写すところで面倒になって中断しました。
とりあえず今度からは「ふにゃさん」の制作のほうに取り掛かって、3Dは思い出したときにでも、ということにしておきます。

今日は一教科だけテストがありました。
最後の問題で、答を導き出す簡単な一次方程式まで作って、いざ解こうとした瞬間に、
「はいそれまでです」
・・・・

自宅サーバーで使っている簡易スケジュールCGIで、スケジュールを書き込むときに過去の情報を消して軽量化するようにしました。
また、日本で使っているので9時間の時差を調整する処理も作ったので、昨日の内容が表示されるということもなくなりました。

Direct3Dを使ってのプログラミングを始めることにしました。
とりあえずは入門書に書いてあることをそのまま…とはいっても例によって当てにならない本で、おまけにインストールされているSDKは8のものということで、またまたいくつかの不具合が出てしまいました。
今回はほんとーーに右も左もわからない状態で始めたので、ソースはスパゲッティ状態(微妙に別の意味にも取れそう)かつ関数の意味を説明するコメントだらけになりそうです。
いいんです、練習用ですから。
で、3Dオブジェクトは、自作するのが面倒なので、フライングジャンプ3のウィリアム＝パピヨット9世君を使うことにします。
いいんです、練習用ですから。

「ふにゃさん」のインプットクラスに、マウスに関する変数を作りました。
キーボード及びジョイスティック操作の時には無視されます。
また、マウス使用時も、方向キーの代わりに使っている間は無視されます。
それと、設定用のクラスも作りました。
「ふにゃふにゃ」のときの、設定ファイルの内容が正常値から少しでも逸脱すればすぐ初期化してしまって設定に拡張性がなかったということの反省を踏まえて、今回は設定バージョンというものを取り入れて、読み込みは完全な上位互換性を維持し、書き出すときは最新バージョンで記録します。
簡単に言うと、設定が追加されても後から正常に使えるということです。

「VisualBasic初心者連盟」が、2月中に閉鎖されてしまうようです。
掲示板のPRが寂しくなるなぁ…

「ふにゃさん」は片手でプレイできます。
以前からもやろうと思えば片手プレイができていたのですが、今回は、マウス操作も採用することにしました。
そしてジョイスティック操作も。
もちろんキーボード操作の場合はキーカスタマイズがある程度自由にできます。
マウス操作の場合は、左クリックでジャンプ、右クリックで攻撃、中央ボタンor代替キー→カーソル移動で移動。
基本的にマウスもジョイスティックも対応するキーの状態に変換し(左ボタンクリック→ジャンプボタンが押されたと認識)、キーボード操作のときの同じ感覚でプログラムができるようにしています。
クラスの継承を使っているのでこの辺の実装は簡単・・・・だと思います。

リンク集に「KEN's」を追加しました。
今日見つけてほぼ衝動的に。
CGIを使っていながらいまだにリンク先の追加は手動です。
負荷を軽くするためHTML版のインデックスページも作ってみたのですが、こちらも手作業で作っています。

「ふにゃさん」には、数も種類も少ないですが、敵が登場します。
そのうちの一種、ギヤバネについてお話してみようと思います。
歯車の機械仕掛けで動き、バネで近づく者を弾き飛ばす敵で、上下前後のバネの有無と走行用のタイヤの存在により32種類に分けられます。
「ふにゃさん」には、敵が登場しますが、あまり強くありません。
ギヤバネは、タイヤがついているときは平らな場所で左右に動き回り、上にバネがついているときは乗ったものを高く飛ばし、下にバネがついているときは常にジャンプをし続け、前にバネがついているときは壁に触ると高速で跳ね返り、後ろにバネがついているときは後ろから近づいたものを跳ね飛ばすことができますが、跳ね飛ばされたからってそれ自身に攻撃力があるわけではなく、動きも規則的なのでうまく使えば行けなかった場所にも飛ばしてくれることさえあります。
つまり、どちらかというと倒すべき「敵」というよりは、ステージの仕掛けという色合いが強くなっています。
敵を倒してゴールへたどり着くゲームではなくステージ内にあるバナナを回収するのが目的なんですから・・・
それと、ギヤバネについては、風の抵抗や慣性の影響を受けてふわふわと動くふにゃに対して、機械的にカクカクと動き回るようにしようと思っています。
あと、その性質上かなりの応用が利くので、動きのパターンもそれ相応に豊富にしようとも思っています。

「ふにゃさん」の開発をしていました。
「ふにゃふにゃ」のときはひとつのクラスにあまりにも多くの仕事をさせすぎたために似て非なるクラスが量産されて効率が良くなかったのですが(というよりクラスを使っている意味がなかったのですが)、今回は可能な限り各部のパーツを独立して動くようにさせて、コードを一目見て大体の意味がすぐにわかるように作るつもりです。
コードの一部をアップしましたので、「その他」から見に行ってみてください。
あれでしっかり動くんです、真っ黒な画面だけですけど。