第四十四回　逃げゲームプログラマー・ミナミ

ゲームプログラマーの方なら、ご存知だと思いますが、

割り算は死ぬほど重いです。

ついでに言うと掛け算も重いです。
小数点計算とかが重なると、
ＤＳやＧＢでは簡単に処理棒が限界突破します。

これらを縦横無尽に扱うのが当り判定なんですよね。

よって、３Ｄゲームでマシンのスペックによりますが、
極力当り判定を少なくする努力をしなければなりません。

さて前回の続きです。
ここまで書いたらわかると思いますが、
処理落ちの原因は当り判定です。
ハイスペックマシンを使っても落ちる程に当り判定処理が
・・・・ではなく、

ハイスペックマシンを使っても落ちる程の判定の数。

最初から最後までのコースと敵の当り判定計算をやっていれば、
そりゃ、マシンも悲鳴を上げて落ちます。

ダメゲームプログラマーに働かされるマシンも可哀想ですね。

掛け算と割り算を小数計算で惜しみなく使い
合計何万ポリゴンとの当り判定計算を１フレーム内でおさめ
ライブラリー関数なんて無視

そんな事をしていたら、
労働基準法違反でマシンに訴えられても仕方ありません。

というわけで、原因はわかったので早急に手を打たないと
ダメなわけですが、手を打つという事は修正するという事で、
簡単に修正できる程の技術は、当時のミナミにはありませんでした。

今のミナミなら「画面に表示されている範囲で当り判定を取る」という
一番簡単な処理ですぐに対応できますが、
当時のミナミには「画面に表示されている」という部分で、
すでに詰まってしまいました。

どうやって表示しているかどうかを判別するんだ？

３Ｄの基本がわかってないダメプログラマーは
こうやって修正でも最初で躓くのです。

画面に表示されているかどうかは、いろんな方法で判別する事が
できますが、とりあえずそれすらも判別する事ができないミナミが
とった方法は、

コースに関しては、自機が乗っているポリゴンから
２枚目先までで、一枚のポリゴンをできるだけ大きくする。
繋ぎ目の問題も解消する為に、ポリゴンの端は重ねて表示する。

敵に関しては、できるだけバラけて表示し、
最初の敵が消えたら次の敵に当り判定を移す。

これを逃げゲームプログラマーと言います。

どんどん、ゲームがしょぼくなってまいりました。

しかし、完成できなければ意味がありません。
ドラゴン○エスト９だって、当初はアクション戦闘だったのが、
いつの間にかコマンド戦闘に戻ってました。
（Wifiでは無理だったんでしょうね）

これは今でも開発末期の言い訳として、よく使います。

開発末期に思いつく仕様は、たいがいバグになります。

というわけで、このような下方修正により、当り判定問題は
解決しました。あとゲームとしてプレイするのに必要なのは、
コースや敵の配置の調整ですね。

次回はできたコースと敵の配置について書きたいと思います。

　　　　　　　　　　　　　　　　　　　　　　　　　　（敵少ないなあ・・・。編へ）

（ゲームプログラミング）

↓記事がおもしろかったらクリックおねがいします。