これまで2D野球ゲームでの背景となるグランドは基本的にマップとセルを使用した(呼び方は適当です)マップ手法というものがほとんどでした。
この手法を使う主な理由としては少ないメモリで高速な表現ができるという事です、これはメモリの少ない家庭用ゲーム機にとって基本技術であり、あらゆる問題の解決方法になります。
その例として、
- ロール・プレイング・ゲームでの歩ける範囲
- シューティングゲームでの背景の当たり判定
- レースゲームでのコースの作成
など、いろいろなものに応用されています。
しかし、いい事ばかりではありません大きな欠点があります、それはパーツを組み合わせているため同じような絵が並んでしまうことです。
ほとんどの野球ゲームではマップ手法を採用しているので球場の表現が、
- 芝生は四角ぽい
- ラインは直線的
- フェンスはカクカク
になっていますちょっと気にしてみてください。
私たちが制作したゲームではこの背景となるグランドを、
「もっと自然に表現したい」
という難題を与えられました、さっそく調べてみると球場データがどう考えてもゲーム中のメモリには収まりません、なんせ
1280x960 ドット(1,200KB) 20画面分もあるのですから。
天の声: | 圧縮すれば? |
ながはし: | その通り!、でも圧縮したデータを途中から展開は出来ないなぁ... |
天の声: | インデックスを使えば? |
ながはし: | なるほどインデックスを使えばどこでもアクセスできるね、 でも全部展開していたらゲームにならないよ。 |
天の声: | 部分的に展開すれば! |
ながはし: | なるほど、でもどこを展開すればいいのかなぁ... |
天の声: | 計算すればいいのさ! |
ながはし: | ....天からのお声で解決です。 |
天の声: | って、けっこう遅いじゃん!! |
ながはし: | そりゃ、マップ手法での高速という利点を拒否しているんだから、 この後の苦労は開発者達の涙ぐましいプログラム高速化!のたまものです。 |
このようにゲームを開発するうえでは、より良くするためにいくつかある手法のうち、自分たちの目指している方向性にそったものを選ぶ事も技術となります。
たった一つの部品についてもこれだけ苦労します、これがいくつも発生するのだからゲームを作るって大変だ!、ということが分かってもらえたでしょうか?
でもあきらめてはいけません、作るものが難しければ難しいほどやる気が出るってものでしょ?
それから実際に上記の手法を使っていますが、グラフィックデータも必要不可欠です、扱うデータはデザイナーが描いてくれるのですがそのままではもちろん使用できません、自分たちで使えるようにコンバートする必要があります、これもツールを自分たちで作ることになります。
こんな感じでゲームプログラムの裏を表に見せられたらいいなと思っています。
みなさまのご意見ご要望をお待ちしています。