99/10/30 マップって何よ?

久しぶりに、昔のEXTREME調に戻ります。

昔の「NaGu-Ru」でよく、
「手前に流れている川に敵を落とせないの?」
と言われたことがあります。
「うん、落とせないよ」
と思いつつ、プログラムを作ってたものです(^^;


何故って?
答えは簡単。「そんな機能はない」からです。
そもそも、システム自体へぼっちーゲームだったから、
そんなことを実現しようとすると、
「プログラムの再検討」が必要になり、 必然的に「組み直し」
要求されてくる。
あの、見ただけで吐き気を催すような「スパゲッティ」なコードでは、
それは無理だったのだ.....。



時は流れて早一年。
今年も作品出展のときがやってきた。
前回の皆様からの要望を受けるべく、
「二代目 NaGu-Ru」 (低い声にウーファーを聞かせた感じで)と名乗る
「見た目くにおくん的ファイナルファイト系」ゲームを作ってみた。
自称、「オブジェクト思考」
のゲームで、前作より規模が大きくなった。
コードは「3000行」「13000行」へ大幅アップ。
プロジェクト自体も、「ZIP圧縮して1.3MB」という
バックアップメディアにフロッピーを使っている人間(>俺)には
つらいほどでかくなってきた。
しかし、出展の際の 「人気っぷり」 (自称)に、
去年の要望などすっかり忘れてしまっていた.....。




出展終了後、雑誌へ投稿するため、完全版の制作に取り掛かることにした。
ずっと前から、第二ステージは「海・港」を舞台にした
ステージにしようと考えていた。

ある程度、システムが出来上がっているため
あとは「コーディング」より「データの用意」だと思っていた矢先、
次のような考えが脳をかすめた。

「...海って、泳げるよな....。」 ざざー...
....
....

ここにきてようやく、去年の要望を思い出してきたのだ。
あぁ、コードを見ればマップのシステムはそういうものに
対応している気配さえない。オブジェクト同士のあたり判定は
攻撃のときだけ.....。なんちゅうこっちゃ。



そこから、ぽくむらの
「マップとはなんぞや一人会議 in 授業」
が始まった。
授業開始直後、さっそうとルーズリーフを取り出し、
いろいろ書いてみる。そこで、あることを考え付いた。

ルーズリーフには、次のように書いてある。


・マップという概念をくつがえす

二次元配列にチップを保存するのではなく、
地面、空など、すべての「物体」を「オブジェクト」として扱う。

・メンバに「自分の下にあるもの」を追加

NULL(なぜかC)なら何もないことをあらわす。
そうでない場合、たとえば自分の下にある地面が動けば、
その上に乗っている、自分自身を含めたオブジェクトも移動することになる。

・「下にあるもの」がNULLになると、落下開始

そのオブジェクトに重力が働いている場合、
下にある物に衝突するまで落下する。
衝突したら、そのオブジェクトを「下にあるもの」とみなす。
また、そのオブジェクトの上にうまく乗っかるように、座標調整を行う。

...うーん、ここに書いてもしょうがないな。
大体、他の人にわかってもらえるだろうか?
ようは、今のマップシステムはおさらばってことです。

すべてをものとして扱う....。
なんかいい響きだ。これぞオブジェクト思考?
マップの「広さ」という物もこれで無くなる。
代わりに、「TScreenClipper」 とかいうスクロール&画面の広さ
制御オブジェクトでも作っとけばいいでしょ。

空も、地面も、ぜーーーんぶオブジェクト。
「TSky」とか 「TGround」とかそんなクラスを作っちゃって、
描画部分は二次元配列にしたがって書く、でいいか。
なんか、うまくいきそうだねぇ〜。




とはいえ、そんなうまくいったことなど一度くらいしかない。
だいたい、コードを書き直さなくちゃならない。
一週間やそこらで、片付く問題じゃないかもしれない。
しかし、これが完成すれば...。

飛行機から敵を落としたり、海に落ちたり、
ビルから飛び降りたり.....いろいろできてしまう。



こういうことは、海外の3Dゲームでちゃんと実装されている。
ソフトウェアレンダリングでがんばって速度出してるよりも、
今のところ、そっちのほうが気になる。つーか、お前らは
「どうやって坂道のあたり判定してるんだ!?」
線か? 線分で判定してるのか?
ベクトル? ベクトル使ってるんだな? コンチクショー!!
つっても、ベクトルも線分みたいなものだけど....。




U-------M、実際どうやって判定してるんだろう。
最近のゲームはちゃんとした物理計算で動かしてるから
動きがリアル
ってきいたけど、本当かな?
僕が見たところ、「UnReal」ではあまり重力加速度がなかったぞ。
目の錯覚かな?

でも、この前やってみた
「GP500」っていうバイクレースゲームでは、
動きという動きすべてがリアルだった。バイクがこけたときの
転がりかた、人の転びかた...。すごいリアルだった。
実際どうなんだろうか....。


俺のゲームでも、一応物理計算っぽいことをしてるんだぞ!!
ジャンプのときとか。 重力Gの値は「0.39」だけど!!
計算してるんだぞ!!だから !!




話がずれてきたから戻すけど、
「マップって何よ!?」
きっと、マップ=二次元配列で表現ってのが
頭に染み付いてるんだ。
もうきっと、二次元配列で擬似的に高さを表現しないぞ。
手抜きはあとで手痛いしっぺ返しをくらいそうだから。


多分、本格的マップはこんな感じだ!!

・すべてオブジェクトによって構成される。
・「もの」としてみなせるものとは、とりあえず当たり判定。
・下にものがないと下に落ちる。
・下にあるものが動けば自分も動く。
・二次元配列とかじゃないから、マップの広さは無限大(21億ピクセルぐらい)。
・直方体はあたり判定に使用しない。線で判定する。

まぁ、一番下はやらないとして(え?)、とりあえず、
あとのものはやってみたいですね。
でも、2Dゲームでここまで判定する必要があるのかな?
もっと、簡単な方法があるのでは....。
「くにおくん」シリーズではどうなっているんだろうか...。
「ふぁみこん」で動いてたし。
うーーーん。




何か、画期的なアルゴリズムはないのかなぁ。
というか、これぐらい常識?
俺が面倒だ面倒だと、文句言い過ぎ?
あぁ〜、若いうちからこんな悩んでたら、絶対はげるわ....(^^;




というわけで、「Quake」とかそういう3Dゲームで、
ちゃんとしたあたり判定が行われているものの、
アルゴリズムを知っている人は、こちら まで、ご連絡ください。







もどる