おちゃめくらぶ掲示板 - 1659321896

1595：御茶目菜子：2013/05/27(月) 23:38:47: 「いまいちおもしろくないゲーム」を面白くするためには？
第2回プチコン大喜利に応募予定だったレースゲームを動画のみ公開してみたにょ。

　◎プチコン用3Dレースゲーム（試作品）
　　http://www.youtube.com/watch?v=hLr5VEevY9I

このゲームはポリゴン＋2軸回転処理で作っているけどウリとなっている部分は拡大、縮小と
カメラアングル変更がゲームプレイ中に自由にかつ無段階（といってもタッチパネルの
分解能の関係から256x192＝49152段階に止まるけど）にできるということにょ。
先月末に投稿が締め切られた第2回プチコン大喜利用のバックアッププランとして考えて
いたゲームにょ。
「1分」をテーマにした面白いネタが浮かばなかったらこれを使うつもりだったにょ。
GRP2軸回転ルーチンはすでに完成済みだったのでポリゴンルーチンの完成を急ぐ必要が
あったにょ。
そして、ポリゴンルーチンが完成したのが4月半ばでそれに全力を使い切ったため肝心の
レースゲーム作りを開始したのは締め切り直前（4月28日）になってからにょ。
ゲームの大半の部分は一晩で作ったためあまり出来の良いプログラムではないにょ。
何とか締め切り前には「とりあえず動く」というレベルのものはできたけどバランス調整を
全くやっておらずゲームとしては公開するに値しないレベルなので大喜利への投稿は断念
したにょ。

このゲームの仕組みを簡単に説明すると地面の表示は事前に用意していたGRP2軸回転の
プログラムにおいて表示部分をGRPではなくBGで表示しているというものにょ。（1つの
キャラは8x8ドットで構成されているため縦横の表示倍率は8x8倍で固定となる）
BGPUTは普通に使えば面積当たりの速度はGFILLよりも遅くなってしまうためスクリーン
データによる指定を行い引数を省略することで高速化しているにょ。
あとは限界まで高速化を行い2重ループの実行回数が多い内側のループではBGPUTと加算を
2回のみにしたにょ。
その結果1秒当たりループを8000回くらい実行できる速度を得ることができたにょ。

このゲームでは地面の表示領域は32x16キャラ分なので1回表示するために必要なループ回数は
512回となるにょ。
8000÷512≒16fpsだけど実際は外側のループで少し複雑な処理をしている関係上地面の表示で
15fpsになるにょ。
32x16という表示画面サイズはこの15fpsから逆算して考えたものにょ。
15fpsならば1秒間に7～8回のボタン入力が可能となるためこれがストレス無くボタン入力が
できる限界と考えたためにょ。（連射を意識した場合には一般人だと1秒間に10～15回程度の
ボタン入力が可能だけど普通にボタンをポンポン押す場合には6～7回程度に止まるため15fps
ならば普通にボタン入力をする限りは入力したのに反応しないということがほぼ無くなる）

地面の表示は2軸回転を普通に行っているだけであり、簡単にいえばX軸とZ軸に対して回転
処理を施しているだけにょ。（回転行列さえ分かればこの説明で分かると思う）
といっても画面に表示しているドットをすべてポリゴンのようにジオメトリ演算を行えば
処理速度がかなり遅くなるにょ。（512頂点と同じわけなのでポリゴン表示プログラムに
おいて糞重いアンドアジェネシスもどきの3倍以上の頂点処理になってしまう）
回転による座標演算処理は2重ループの外側のみで行い内側のループは不要なものはすべて
ループ外に出すことで処理速度の向上を行っているにょ。

ちなみにZ軸回転は高速回転処理によく使われているスキャンラインを斜めにすることで
加算のみで済むアルゴリズムを採用しているにょ。
X軸回転は事前に用意していたX軸回転ルーチンを採用しているにょ。
X軸回転は「視点がプレイヤー視点か否か」「回転角度を固定か否か」で難易度が変わって
くるにょ。
というのもプレイヤー視点で回転角度が固定ならば回転行列の計算式によって回転の計算を
しなくても単純な1次式で表すことができるからにょ。

　◎3D座標をスクリーン座標に変換
　　http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#3d_screen

これが斜め見下ろし視点で回転角度を自由に設定できるためにはちゃんと回転行列を使って
計算を行う必要があるにょ。
その計算式を最適化したものは公開済みの「2D→3D RACE」で使用しているにょ。

　◎2D→3D RACE
　　http://www.youtube.com/watch?v=k6vrMHPMO8I
　　http://twitpic.com/byq6ew

「2D→3D RACE」が「PETIT RUN」などの疑似3Dゲームと根本的に異なる部分は座標を正確に
求めているということにょ。
PETIT RUNは第6回プチコン講座で書いたようにいかにカーブを表示するのかということから
発展させて「短く高速なプログラムで違和感が少ないもの」にしているため表示の正確さ
では劣るにょ。

　◎PETIT RUN mkII
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#prun2
　◎第6回プチコン講座
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p006.htm

PETIT RUNがあまり正確ではないのは画面表示において「遠くのものは形が同じで小さく
見える」という疑似3Dの根本的な考えをそのまま利用しているためにょ。
カメラに対して垂直な物体に対してはこれは正しいのだけど地面はカメラに対して
平行に近い状態であるためカメラから遠くになるにしたがって縦方向に縮小されたような
表示にすべきのに同じ形（同じ縦横比）を維持したまま小さくなっているため遠くほど
縦方向の誤差が大きくなるにょ。
ただし、遠くに行くほど画面上では小さくなるため誤差があってもほとんど気にならない
レベルになるにょ。
そして、PETIT RUNの方式ではカーブの表示が簡単になるというメリットがあるにょ。
80年代のラスタースクロール方式ではない疑似3Dレースゲーム（例えば「走れスカイライン」
など）でも良く使われた積算方式によるものであり、カーブは単純加算の繰り返しで表示が
可能になるにょ。
正確な表示でカーブを表示する場合にはコースデータのカーブの曲率から1ラインごとに
その曲率を元に三角関数を使って演算を行う必要があるにょ。
上記の「2D→3D RACE」においてジグザグではなく曲線的なカーブを表示できるように改造
してみればそれがどのようなものかが分かるにょ。

正確にカーブを表示してもX軸回転のみではほとんど意味がないということは上記の
「2D→3D RACE」を改造してみればすぐに分かるにょ。（正確なカーブでなくても積算
方式で道路の座標を少しずつ変化させてもいい）
それは進行方向が1方向のみになってしまうとカーブを曲がっている感覚が希薄になって
しまうからにょ。（カーブでは「かに歩き」状態になるだけ）
その点はPETIT RUNではカーブっぽく見えるような積算方式を用いており、なおかつ自
キャラは基本的にそのカーブの接線方向に進行しているという設定を与えることで
カーブをスムーズに曲がれるようにしているにょ。
これだと簡単にカーブを曲がれてしまうように見えるけど速度の2乗に比例する遠心力に
よって曲がりやすさが変わるため減速を上手く使う必要があるにょ。（この手法は処理
速度の遅いポケコンで疑似3Dレースゲームを作るための常套手段だった）

正確にカーブを表示してなおかつカーブを曲がっている感覚を出すためには自由方向に移動
できるゲームにするしかないにょ。
つまり、X軸だけではなくZ軸にも回転可能な2軸回転にする必要があるということにょ。
スーファミではハードウェアでBG画面の2軸回転が可能であり高速に処理が可能であるため
F-ZEROやマリオカートのようなゲームも実現可能になったにょ。（でないと、スーファミの
CPU性能だけでは実現は困難）
というわけで、この2軸回転を使うことでラスタースクロールや積算方式によるレースゲーム
より一歩進んだ3Dレースゲームを作ることが可能になるにょ。

その汎用の2軸回転プログラムをBGPUTを使用することで高速化したものがこのゲーム（3D
レースゲーム試作品）で使用されているのだけど地面が動いているというのが
明確に分かるためにランダムで道路の色を変えているにょ。（道路を縞々にしてもいいけど
こちらの方が処理が簡単だった）
そのランダムノイズとパレット変換は動画の下画面の様子を見れば一目瞭然にょ。
ちなみにこのコースデータは3分くらいで適当に描いたものにょ。
GRPEDなどで適当に描いたものが何でも使えるためコースを造るのは簡単だけどこれはゲーム
バランスを考慮せずに作ったため道幅が狭すぎて簡単にコースアウトしてしまうというのが
難点にょ。
このコースにおいて真ん中に表示されている四角形の池だけどこれは何のためにあるのかと
いうとショートカット防止用にょ。
このゲームでは自由にコース内を移動できるため簡単にショートカットができてしまうにょ。
この池を画面中央に強制的に設置することで少なくともこの池の周りを周回しないと1周した
とみなされないのでショートカットがしにくくなるにょ。（草地だと速度がでないため
池のすぐそばを回った方が距離は短縮できるけどタイムロスが大きくなる）

このゲームでは拡大、縮小やカメラアングルの変更をリアルタイムで無段階に行っている
関係上地面以外のものを表示する場合に問題があるにょ。
これが拡大率やカメラアングルが固定ならば道路の奥に別のBGを用意して遠景を横スクロール
させればいいし、自車も普通にスプライトで表示して、敵車を表示する場合にはスプライトの
拡大縮小機能を使えば問題ないにょ。（自車や敵車は後ろからだけではなく横や斜め方向
から見たデータも用意する必要はある）
しかし、拡大縮小、カメラアングルの自由変更を実現するためにはそういうわけにはいか
ないにょ。
遠景においては縮小やカメラアングルの変更によってデータ上のコースの端が見えるか否か
という点を考慮しなくてはならないためにょ。

コースがすべてポリゴン表示で遠景もポリゴンで描画されているのならばカメラアングルを
自由に変えることは容易だけどプチコンでそんなことをすれば0.1fpsさえ出ないにょ（笑）
このゲームでは下画面に用意されているGRPデータを読み取って拡大縮小回転によって
変形している2軸回転であるため視界の範囲が広くなればなるほどコースデータが無い部分の
整合性が問題となるにょ。
コースデータを本の表紙に置き換えて考えると本の表紙を斜めから見下ろした際にその表紙の
一部だけを取り出した場合には普通に表示されるけど目で見える範囲をすべて本の表紙が
カバーしているというわけではなく当然ながら本の表紙は視界の中で途切れているからね。

当たり前のことを言っているだけなんだけどこのコースデータ以外の部分（本の表紙以外の
部分）をどのように描画するのかが問題となるにょ。
コース以外の部分はコースに垂直な面を4面で囲い箱庭状態にしてコースデータの無い部分は
その箱庭の側面部分を描画すればいいだけの話となるけど別途データを用意しなくては
ならなかったり、側面かどうかを判定するIF文を2重ループの内側に持ってくる必要がある
ために処理速度が大幅に落ちてしまうという問題があるにょ。
したがって、このゲームでは処理速度を優先してコースデータのない部分は「空」として
単に水色を表示することにしたにょ。（カメラアングルや縮小率を制限して、草地の部分は
走れないようにすればこんなことをわざわざ考えなくても済むけどそれだとウリの部分が
大幅に損ねられてしまう）
何もない部分を空ではなく草地に見なすという方法もあり、その方法ならば遠景との整合性
問題も解決できるけど斜めからならまだしも90度見下ろしで遠景が見えることはないため
カメラ角度に合わせた遠景を用意する必要があるにょ。

コースデータ外の部分となる遠景表示はこれで一応は解決したけど自車の問題はこれでは
解決しないにょ。
それは、このゲームではカメラアングルが27度～90度まで自由に選択できるためにょ。
90度見下ろしで走っていて車は後ろから見たようなCHRデータというのもあまりに情けない
からね。
それを克服するためには多くの方向から見たCHRデータを用意しなくてはならないにょ。
拡大率が低ければ4～8方向程度で問題ないけど最大拡大率で実用になるレベルにしようと
思えばそれでは全然足らないにょ。

そこで考えたのが自車をポリゴンで表示するという方法にょ。
ポリゴンならばあらかじめデータさえ用意しておけばどんな方向からも描画が可能になる
からね。
そういうことで、このゲームを作る前にポリゴンルーチンを完成させる必要があったにょ。
当然ながら敵車もポリゴンなんてことをすれば処理はそれに比例して重くなるためfpsは
実用にならないレベルまで低下してしまうにょ。
しかし、タイムアタック専用と割り切ってしまえば問題ないにょ。
むしろ、個人的にはタイムアタック専用でも問題はないにょ。
何せ私はスーファミのF-ZEROは最初のコースである「MUTE CITY I」のタイムアタックだけで
数ヶ月楽しめたわけだしね。（お陰でダブル一点読みが出来るようになったけど）
したがって、タイムアタックが熱いものになっていればタイムアタックだけで何ら問題は
ないと認識しているにょ。

このゲームの試作品は以上の考えを元にして作られているにょ。

しかし、実際に試作品を作ってみると予想以上に面白くなかったにょ。（作る前から粗方
分かっていたけど作ってみてそれが明確になった）
ゲームを作ってみて試作品段階で「面白くない」というものは過去に多く存在したにょ。
もっとも、それらはゲームバランスを調整することで大幅に改善されたり、ゲームシステムを
変更することで全く別物のゲームに生まれ変わることがあるにょ。
ゲームバランスの調整に必要不可欠なのがテストプレイにょ。

　　◎ポケコンBASICによるゲーム制作講座「テストプレイはゲームの味見」
　　http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_5.htm

この講座はポケコンBASICを対象に書いているけど機種依存しないような内容になっている
ためプチコンやその他の環境で作る場合にも当てはまるものが大半だと思われるにょ。
要するにそのゲームが面白くなるようにパラメータの値を変更する行為がバランス調整と
言っても過言ではないにょ。
RPGで言えばパラメータは多数存在するためバランス調整で1つのパラメータを変えたら
別のものにも影響を与えてしまうため単純に「敵に与えるダメージが少ないので攻撃力の
パラメータを上げる」というわけにもいかないにょ。
ドラクエ方式のダメージ計算式だと「攻撃力－防御力÷2」がダメージ（ドラクエだとこれを
さらに2で割ったものなる）となるため例えば自分の攻撃力100、敵の防御力40の場合だと
ダメージは80となるためこれを1.5倍くらいにしたい時は攻撃力を140にすれば解決（与える
ダメージは1.5倍の120になる）に見えるけど防御力160の敵に関しては与えるダメージが20
だったのが60になるため与えるダメージは3倍になるにょ。
これでは堅い敵のイメージが台無しになってしまうため防御力のパラメータをすべて見直す
必要があるにょ。

このようにパラメータの値を1つ変えたら別のものにまで影響が出てしまうということも
あるためそれを考慮してから変えないとバランス調整が堂々巡りになってしまうにょ。
この場合だと「ダメージを1.5倍にしたいだけ」ならば攻撃力のパラメータを弄るのではなく
ダメージ計算式を「（攻撃力－防御力÷2）×1.5」にすればいいだけと考える人もいるかも
しれないにょ。
ただし、これだと敵味方両方のダメージが増えるためそれでいいかどうかによって決まる
ことになるにょ。（敵と自分のダメージ計算式を変えるというのも1つの方法ではあるけど）

私はゲーム作りにおいてはゲームバランスが非常に重要と考えているためコーディングの
時間よりもテストプレイの時間を遙かに多くとってゲームバランスを調整しているにょ。
ゲームによってバランス調整の仕方が異なるため私のプチコン講座では毎回バランス調整に
ついて書いているにょ。
多くの講座ではコーディングやアルゴリズムの説明がメインであり、バランス調整について
解説しているものはほとんどないにょ。
バランス調整というのは知識として覚えるだけではだめで常に意識しておかないとできない
ため毎回書いているわけにょ。

では、このレースゲーム試作品においてはパラメータと言えるものは多数存在するにょ。
しかし、パラメータ変更をする場合には上記のように「与えるダメージを1.5倍に増やしたい」
という感じで具体的かつ明確に問題点を把握しておかなくてはならないにょ。
レースゲーム試作品の動画を見ると頻繁に道路からはみ出して草地へと突入しているのが
分かると思うにょ。
これはまだ十分にテストプレイをしていないためコースを把握していないというのもあるし
カメラで撮影しながらテーブルに本体を置いて操作をしているため操作がやりやすい環境に
ないというのもあるけど「カーブが思うように曲がれない」というゲームバランスになって
いるのも事実にょ。（このため最大で450km/hの速度が出せる自車なのに実質200～300km/h
程度の速度しか出すことができない）

「カーブが思うように曲がれない」というのならば速度を減らす、速度を元にした移動量を
減らす、ハンドルの回転角度を増やすなどの方法が考えられるにょ。
速度を減らすくらいならば「そのカーブは減速しないと曲がれない」という設定にすれば
いいだけ（テクニカルなコースという位置づけにして別の簡単なコースも用意する）だし、
移動量はゲームのスピード感や操作感に与える影響も考慮する必要があるにょ。
ハンドルの回転角度を増すと簡単に曲がれすぎたり、ゲームが大味になったりするため
注意が必要となるにょ。
ちなみにPETIT RUNでは最終コーナー以外はベストなライン取りができれば減速無しで
すべてのカーブが曲がれるようなバランス調整が施されているにょ。
したがって、スピーディかつテクニカルなものになっているにょ。

このゲームは試作品をとりあえず作ったという段階のもの（4月30日現在から現時点まで手を
加えてない）ということでテストプレイもろくに行っていないためバランス調整は不十分
だけどバランス調整を行えば本当に良くなるのかといえば疑問が残るにょ。
確かにバランス調整を十分に行えば操作性や操作感はかなり改善されるけどそれによって
このゲームが目指している「タイムアタックが熱いもの」になるかどうかは微妙だからね。
そこで必要になるのがシステム変更にょ。
単調過ぎて面白くないゲームだとアクセントになるようなものをいれたり、複雑すぎて
楽しめない場合は思い切って不要なものを削って面白い部分のみを凝縮したりなどシステム
変更といっても様々なものが考えられるにょ。

システム変更の一例として第7回プチコン講座において試作品ゲーム「JUMP ACTION GAME」
から「JUMPING ISLAND」を作った場合を見てみるにょ。

　　◎第7回　プチコン講座（後編）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p007_2.htm

再現性のある疑似乱数を用いて固定ステージを自動生成してそれをジャンプのみで越えて
ゴールするという単純なゲームだけど最初に作った「JUMP ACTION GAME」は戦略性のない
単調なものだったにょ。
このゲームのウリである「ジャンプ中に左右に自由に動ける」というものが影響して穴の
幅によってジャンプする位置を考えるという予定していた戦略性が失われてしまったにょ。
それならば「ジャンプ中に左右に自由に動ける」という要素を無くしてしまえば解決という
ことで出来たのが「JUMP ACTION GAME2」にょ。
「大小のジャンプボタンを使い分けなくてはクリアができない」という戦略性ができたものの
ウリの部分を失った代償は大きいにょ。
では、「ジャンプ中に自由に動くことが可能」でなおかつ戦略性の高いものはできないのか
ということで出来たのが「JUMPING ISLAND」にょ。

では、なぜバランス調整だけではタイムアタックが熱いものにできないかというとやはり
速度重視のためにBGを使ってしまったのが理由だと思われるにょ。
内部では無段階で計算されているのに表示はキャラ単位で行われているためにょ。
つまり、絶妙な操作を行ってもそれが画面に反映されないということにょ。
コンソールオンリーでゲームを作っている人ならばキャラ単位で表示で内部では小数で
演算処理をしているギャップがどのようなものかを把握しているだろうけどタイムアタック
重視のレースゲームではそのギャップが極めて大きいと思われるにょ。

ならば「BGではなくGRPで表示すればいい」となるけどそうなると速度が大幅に低下してしまう
ことになるにょ。
これは表示1回あたりのループ回数を減らすことで解決可能になるにょ。
地面の表示だけだとBGならば15fpsで32x16ドット分（1ドット＝1キャラクタ）表示が可能
だけど同じ15fpsでもGRPならば32x7ドット分が限界となるにょ。
1回表示するのに必要なループ回数はBGならば32x16＝512回、GRPならば32x7＝224回で概ね
15fpsとなるというわけにょ。

処理速度を改善するにはループ回数を減らすしか方法はないけどそれを上手く活用していると
感じたのが昨日えぬおうさんが発表したカートレース（仮）の動画にょ。

　　カートレース（仮）作成中　　by えぬおうさん
　　http://www.youtube.com/watch?v=JdwcE5-DkMg

このゲームを見ているとそれなりにスムーズでかつ荒さは感じないけどえぬおうさんに聞いて
みたところこれは台形状になっていて手前が7ドット分、奥が27ドット分で8ライン分とのこと
なので単純計算ではループ回数は (7＋27)×8÷2＝136回にょ。
道路だけならば20fps出るということだけどこのループ回数ならば納得にょ。
上手い方法を思いついたものだと思わず感心してしまったにょ。
同じくGRPで描画している上記の「2D→3D RACE」はX軸回転のみであるためループ回数は実質
100回で済みゲーム全体の速度は32～35fps出ているにょ。（ただしVSYNC 2を入れることで
30fpsで動作させている）

2軸回転における地面の視界は台形となっているためループ回数を減らすならば全体を一様に
減らすのではなく台形状にするのが最も効果的にょ。
画期的だと思えるえぬおうさんの方式をパク・・・ではなく参考にして作り変えるという
方法もありそうだけどこの方法は拡大率やカメラアングルが固定だからこそ実現可能な方法と
いえるにょ。
視界となる台形の形は拡大率やカメラアングルによって変わってくるからね。
これは言い換えると拡大率やカメラアングルを変えた場合にはループ回数を変更しなくては
ならないということにょ。
単純に変更するだけならば問題ないのだけどタイムアタック専用ならば地面の表示速度で
ゲーム全体の速度が大きく左右されるため選択しずらいにょ。
拡大縮小やカメラアングルの自由設定をやめれば簡単に解決できる問題だけどそうなると
えぬおうさんの後追いとなってしまい私が作るゲームの価値も失われてしまうにょ。
ということで、ウリの部分を捨ててまで完成させることはできないため何かいい方法が思い
つくまで開発を凍結という結論になったにょ。
まぁバランス調整のみを行い「タイムアタックはそれほど熱くはないけどとりあえずゲームと
して遊べる程度にする」いう妥協案もあるけどその妥協案はなるべく使いたくはないにょ。
やはり、公開するからには自信を持って勧められるようなものにしたいからね。（自分が
「いまいち」と考えているようなものは・・・）