2006/05/22(月) [n年前の日記]
#2 [game][iappli] BGを高速スクロールさせたいのだけど
3D表示が当たり前になった今のゲームではどうでもいいことかもしれんのだけど、それはさておき。たまたま妹にこのへん説明していて、どうも図があったほうがわかりやすいなと思ったので作ってみたり。
例えば、2Dゲームで、128dotでループするBGがあって。キャラクターが右に進む ―― BGは左に向かってスクロールするとして。どのくらいまでスクロール速度を上げることができるか。
「128dotでループしてんなら、ざっくりと96dotぐらいで動かしちゃえばいいんじゃね?」とか言ってると、こうなる。
逆にスクロールしてるように見える。お前はグラ2か! なんちて。
*1
「じゃあ、半分のドット数 ―― 64dotぐらいだったらいけるんじゃねーの?」とか言ってると、こうなる。
スクロールしてるように見えない。なんかパカパカしてるだけ。…いや、見る側がかなり頑張って、好意的に見てやれば、もしかしてスクロールしてるつもり? と思えないこともないけど。右に進んでるのか、左に進んでるのか、わからんのはたしか。
…やはり、最初の画像と終わりの画像の間に、いくらなんでも2コマぐらいは入れて、動く方向を示さないといかん気がするわけですよ。1コマしか入ってない状態では、方向がわからん。ということで、つまりループ幅の1/3ぐらいが最高速度じゃないかなと。
下は、128dot の1/3 、42dot前後で動かした例。
これならなんとか高速スクロールしてるように見える。かな。ちょっと厳しい感じもするけど。
ループ幅の1/4ぐらいなら、かなり真っ当なスクロールに見えてくる。下は、128dot の 1/4、32dotで動かした例。
でも、ちょっと高速スクロールという感じから離れ始めてるような。いや、まだ大丈夫かな。
いっそ自分で描くか。でも、後から画像が届くと整合性を取るのが大変で。それ以前に、自分如きの画力では描けるものじゃないし。なかなか難しい。
高速スクロールをやめちゃうか。そうすれば、背景に障害物を色々置いても問題ない状態になるから、もっとゲームっぽくなるかもしれん。企画を根底からひっくり返すことに繋がりそうでもあるけど。
例えば、2Dゲームで、128dotでループするBGがあって。キャラクターが右に進む ―― BGは左に向かってスクロールするとして。どのくらいまでスクロール速度を上げることができるか。
「128dotでループしてんなら、ざっくりと96dotぐらいで動かしちゃえばいいんじゃね?」とか言ってると、こうなる。
「じゃあ、半分のドット数 ―― 64dotぐらいだったらいけるんじゃねーの?」とか言ってると、こうなる。
…やはり、最初の画像と終わりの画像の間に、いくらなんでも2コマぐらいは入れて、動く方向を示さないといかん気がするわけですよ。1コマしか入ってない状態では、方向がわからん。ということで、つまりループ幅の1/3ぐらいが最高速度じゃないかなと。
下は、128dot の1/3 、42dot前後で動かした例。
ループ幅の1/4ぐらいなら、かなり真っ当なスクロールに見えてくる。下は、128dot の 1/4、32dotで動かした例。
◎ 逆に言うと。 :
BGのループ幅が決まってたら、スクロールの最高速度も自ずと決まってしまうわけですよ。たぶん、おそらく、大体は 1/3 近辺で頭打ちになる。のじゃないかと予想するわけで。
仮に、32dot幅でループするBGがあったら…32dotの1/3だったら、10〜11dotぐらいかしら。こんな状態。
どうですか。高速スクロール! って感じですか?
上記のアニメGIFは10fpsだけど。 *2 一般的な家庭用ゲーム機のように、60fpsで表示できるハードなら、実際はこれの6倍の速度でスクロールしていく。であれば。まだ高速スクロールと呼べるかもしれん。
でも。10fpsしか出ないハードで、32dotでループするBGが渡されたら、この程度のスクロール速度にしかならない。どう見ても、もはや高速スクロールと呼べる状態ではないよな…。
で。iアプリってのは、おそらく 10fps ぐらいしか出ない。 *3 さらに、「自機が高速で移動してるように見せるゲーム」てな感じの企画をやろうとしてるなら…。16dot幅とか、32dot幅とかでループしちゃうBGチップ「だけ」描かれても困る事態に。描く前に気づいてよぅ…。>グラフィッカーさん。もっとも、画像容量削減という課題もあるから、対応は難しいだろうと予想するのでありますが。
仮に、32dot幅でループするBGがあったら…32dotの1/3だったら、10〜11dotぐらいかしら。こんな状態。
上記のアニメGIFは10fpsだけど。 *2 一般的な家庭用ゲーム機のように、60fpsで表示できるハードなら、実際はこれの6倍の速度でスクロールしていく。であれば。まだ高速スクロールと呼べるかもしれん。
でも。10fpsしか出ないハードで、32dotでループするBGが渡されたら、この程度のスクロール速度にしかならない。どう見ても、もはや高速スクロールと呼べる状態ではないよな…。
で。iアプリってのは、おそらく 10fps ぐらいしか出ない。 *3 さらに、「自機が高速で移動してるように見せるゲーム」てな感じの企画をやろうとしてるなら…。16dot幅とか、32dot幅とかでループしちゃうBGチップ「だけ」描かれても困る事態に。描く前に気づいてよぅ…。>グラフィッカーさん。もっとも、画像容量削減という課題もあるから、対応は難しいだろうと予想するのでありますが。
◎ なんとか見栄えを誤魔化す方法はいくつかありそう。 :
- BGチップは32dotでも、チップの配置の仕方でループしてる幅を広げる。<個人的にはそれが当たり前だと思ってたんだけど…。
- 手前に、そのスクロール速度で流れていく物体を表示する。
- 奥行きのある画面・多重スクロールができるなら、遠景は、スクロール方向がちゃんとわかるスクロール量にする。
- 高速スクロール時は、事前にブラーをかけた画像を別途用意しておいて、それに切り替えてしまう。
いっそ自分で描くか。でも、後から画像が届くと整合性を取るのが大変で。それ以前に、自分如きの画力では描けるものじゃないし。なかなか難しい。
高速スクロールをやめちゃうか。そうすれば、背景に障害物を色々置いても問題ない状態になるから、もっとゲームっぽくなるかもしれん。企画を根底からひっくり返すことに繋がりそうでもあるけど。
◎ このへん、ツールの不在に起因してるところもありそうな。 :
マップエディタにしろ、スプライト配置エディタにしろ、グラフィック担当の人が入手しにくい・活用しにくい状況があるが故に、こういう状況を招くのかもしれん。マップエディタがなければ、ループ幅を広く取ったチップの配置、てのをイメージしながら作業するのも難しそうな。
更に、マップエディタにスクロール表示確認機能なんてのがついてたら…。って、こうやってアニメGIF作れば説明できることを、わざわざツールに盛り込まんでもいいか。
そもそも、2Dゲーム作る人なんて少数派になりつつあるんだろうし。ツールの存在意義自体、あまり無いわな。と、いつもの結論に。
更に、マップエディタにスクロール表示確認機能なんてのがついてたら…。って、こうやってアニメGIF作れば説明できることを、わざわざツールに盛り込まんでもいいか。
そもそも、2Dゲーム作る人なんて少数派になりつつあるんだろうし。ツールの存在意義自体、あまり無いわな。と、いつもの結論に。
*1: MSX版グラディウス2、通称「グラ2」は、反対側に逆スクロールしていくと聞いた記憶が。プレイしたことないので本当かどうかは知らない。ちなみに、「グラ2」と「グラII」は違うらしい。後者はアーケード版。らしい。よく知らないけど。
*2: アニメGIFは、1/100s 単位でwaitを指定できる。これらは 10を指定してるので、10fps程度のはず。
*3: タイマ分解能が100msしかない端末が存在するので、100ms毎にしか処理ができない = 10fpsになってしまう上に、描画処理の速度が遅いので。タイム分解能が細かくて、尚且つ、描画処理が速い特定機種に合わせてチューンナップしない限りは、大体は10fps程度になるんだろう。と思う。
*2: アニメGIFは、1/100s 単位でwaitを指定できる。これらは 10を指定してるので、10fps程度のはず。
*3: タイマ分解能が100msしかない端末が存在するので、100ms毎にしか処理ができない = 10fpsになってしまう上に、描画処理の速度が遅いので。タイム分解能が細かくて、尚且つ、描画処理が速い特定機種に合わせてチューンナップしない限りは、大体は10fps程度になるんだろう。と思う。
[ ツッコむ ]
以上です。