プチコン講座

第4回 タッチパネルを使おう

【プチコン/mkII 両対応】

 プチコンでゲームを作るメリットはDSiや3DSがゲーム機であるため作ったゲームの操作がしやすいということが挙げられます。その反面でソフトウェアキーボードであるためPCゲームのようなキーボード主体のゲームは操作がしやすいとは言えません。そうなると「ソフトウェアキーボードのみに下画面(タッチパネル)を使うのはもったいない」ということで、やはり下画面(タッチパネル)を使ったゲームも作ってみたいですね。

 プチコンではタッチパネル用の命令やシステム変数が用意されています。
 タッチパネルを使う場合は下記の4つのシステム変数を覚えておくと良いでしょう。

TCHXタッチされたX座標
TCHYタッチされたY座標
TCHSTタッチ状態を調べるTCHST=1ならばタッチ状態にある)
TCHTIMEタッチされ続けている時間(フレーム数)
※タッチされてないときもTCHX、TCHYは前回タッチしたときの値を維持しているためTCHSTと併せて判定する必要があります。
 プチコン(というかDSiや3DSのハードウェア)はマルチタッチに対応していないため同時に複数の場所をタッチしてもそれぞれの正しい座標は分かりません。
 擬似的なマルチタッチはこちらのマルチタッチ検出ルーチンを参考にしてみてください。

タッチパネルサンプルプログラム
VISIBLE ,1,,,,1
PNLTYPE "OFF"
GPAGE 1
@LOOP
 GCLS
 X=RND(256)
 Y=RND(192)
 GCIRCLE X,Y,10
 VSYNC 20
 A=TCHX-X
 B=TCHY-Y
 IF A*A+B*B>100THEN @LOOP
BEEP
END

 これは下画面にランダムに表示される○をうまくタッチできたら終了という単純なものです。
 第2回で書いたようにスプライトやBG画面を使うためには前準備がいろいろと必要になりましたが、この下画面を利用するにも前準備が必要です。VISIBLEは下画面表示を行うため2番目の引数を1に設定する必要がありますが、これはデフォで1になっているため問題ありません。必ずやらないといけないのはPNLTYPE "OFF"とすることです。「OFFにしたら使えなくなりそう」と感じるかもしれないですが、OFFにしないとシステム側で下画面の表示を使用してしまうためユーザーは自由な表示ができません。(ユーザー側で下画面の表示はせず、「少しでも処理落ちを無くしたい」とか「ただのポインティングデバイスとして活用したい」という場合であればOFFではなくてPNLでもいいでしょう)
 あと、下画面でグラフィック、スプライト、BG画面を使用する場合はそれぞれの設定が必要です。上画面はGPAGE 0のように引数が0でしたが、下画面ではGPAGE 1のように引数が1になります。上画面と下画面で交互に表示する場合にはその都度忘れないように設定し直さなくてはなりません。

 下画面をタッチしてプレイする場合にはタッチするごとに鳴るシステム音が気になると思うのでそれが気になる人はSYSBEEP=0としてシステム音を消す設定にすると良いでしょう。SYSBEEP=1とすれば元に戻ります。
 また「下画面にソフトウェアキーボードが無いとどうやって停止したらいいの?」という人も中にはいるかと思いますがプチコンでは、プログラムをスタートするとき(RUNするとき)は[START]ボタン、停止する時は[SELECT]ボタンで出来るというのを覚えておくとよいでしょう。あと[←][R][START]の同時押しで表示が初期化されるのでこれも覚えておくと便利です。

 ただ、下画面は上画面と比べて表示において制限があったり使い方の異なるものがあります。

《 コンソール、グラフィック、スプライト、BG画面における上画面、下画面の違い 》
コンソール
下画面はPRINTでは表示できないため専用命令のPNLSTRでのみ文字表示が可能。(上画面と下画面は別命令で表示できるため上画面と下画面のページ切り替えは不要)
ただし、CLSでは上下画面ともにクリアされる。(上画面のみクリアするためのTips)

(CHRSETの使用可能バンクは上画面、下画面ともにBGF0のみ。下画面のキャラを書き換えるにはBGPAGE 1とするかリソース名をBGF0Lとする)
グラフィック
あらかじめGPAGE 1としておくことで下画面で使用可能。(上画面を使用するときはGPAGE 0)
GCLSでは指定した画面のみがクリアされる。
スプライト
あらかじめSPPAGE 1としておくことで下画面で使用可能。(上画面を使用するときはSPPAGE 0)
SPCLRでは指定した画面のみがクリアされる。

ただし、プリセットのものは上画面は上画面専用、下画面は下画面専用のものしか使えない。
また、定義可能上限は上画面が512個(1バンクあたり64個)なのに対して下画面は128個となっている。(8x8ドットの小さなスプライトを使用した場合でもこの上限は変わらない)
(CHRSETの使用可能バンクは上画面がSPU0SPU7の8バンク、下画面がSPS0SPS1の2バンク)

 ※上画面にもシステム用スプライトとなるSPS0SPS1は存在する(カーソルなどに使用されている)けど任意の番号のスプライトは表示できない。(上画面にもSPSがあるためSPPAGE 1としておかないと下画面でSPSは使えないけど下記欄外に書いたようにBGと同じくSPS0の後に"L"を付けることでSPPAGE 1無しでも下画面用SPSが定義が可能になる)
BG画面
あらかじめBGPAGE 1としておくことで下画面で使用可能。(上画面を使用するときはBGPAGE 0)
BGCLRでは指定した画面のみがクリアされる。

BGキャラの定義可能上限数は1024個で定義方法はコンソールと同じくBGPAGE 1を付けるかリソース名の末尾にLを付ける。
(CHRSETの使用可能バンクは上画面BGU0BGU3の4バンク、下画面BGU0LBGU3Lの4バンク)
※GCLS、SPCLR、BGCLRの指定画面はデフォ状態では上画面となっている。
 カラーパレットにおいては上画面、下画面は別々となっているためパレット変更をして上下で同じ色を使用したい場合はあらかじめページ指定した後に下画面で上画面と同じパレットを読み込ませる(もしくはCOLSETで同じものを設定する)必要がある。
 BGキャラ、カラーパレットにおいては上画面と下画面では異なるため末尾にU(上画面用)、L(下画面用)が付けられている。例えば下画面用のスプライト用のカラーパレットはCOL1Lとなっている。この「U」や「L」を省略した際には自動的に上画面用(U)として見なされる。
 mkIIから加わったACLS命令ではこのパレットを上下画面ともに初期化してくれるとともに画面初期化も行い上下画面をクリアしてくれる。(CHRSETで書き換えたキャラは初期化してくれない)
 ただし、GRPにおいてはACLSでもページ2、3はクリアされないのでGPAGE 0,2,0:GCLS:GPAGE 0,3,0:GCLSのようにしてクリアする必要があるため注意。
 キャラの各バンクにおいてバンクの末尾の数字を省略した場合はバンク0と見なされる。

 上記の表を見ると複雑そうですが、実は難しいことは全くありません。覚えておく必要があるのはGPAGE、SPPAGE、BGPAGEはデフォでは0となっているのでわざわざ設定しなくても上画面では使用することができるのに対して下画面では使用する画面(引数が0ではなく1)を設定しないと使用することができないということだけです。(表示されない、定義されないという場合はこの設定漏れによるものが多い)

 では、実際に下画面に何かを表示してみます。やはり簡単なのは上画面と下画面で仕様の違いがないグラフィック面(GRP)でしょう。

上下画面を円が動き回るサンプル
CLS
VISIBLE ,1,,,,1
PNLTYPE "OFF"
X=100
Y=50
V=5
W=5
@LOOP
 GPAGE 0
 GFILL 0,0,255,191,0
 GCIRCLE X,Y,10,15
 GPAGE 1
 GFILL 0,0,255,191,0
 GCIRCLE X,Y-192,10,15
 X=X+V
 Y=Y+W
 IF X<10 THEN X=10:V=-V
 IF X>245 THEN X=245:V=-V
 IF Y<10 THEN Y=10:W=-W
 IF Y>373 THEN Y=373:W=-W
 VSYNC 1
GOTO @LOOP

 GPAGEの0と1を切り替えることで上画面と下画面を交互に表示を行えばこのように上画面と下画面がくっついて1つの大きな画面になっているような感じにすることができます。
 このサンプルではY座標は上画面が0〜191なのに対して下画面は仮想的に192〜383(つまり上画面から+192)という設定にしています。これによって、下画面に表示する場合はその仮想Y座標から192マイナスした座標を表示すれば適切な場所に表示されます。ただし、この計算では上下の画面がくっついた状態でスムーズに表示されるようになっています。上画面と下画面との間にある隙間によって「下画面の上側から上画面の下側へとワープしているように感じる」という人もいるかもしれません。
 それではさらにスムーズに上下画面が繋がっているように見える方法を書きましょう。別に全く難しいことはなく見えない部分に本来は液晶画面が存在していると思って計算をすれば良いだけです。目測だと上画面と下画面の液晶の隙間は60ドット分くらいありそうです。それならば現在は256x384ドットという仮想画面をさらに60ドット分だけ縦方向に拡大して256x444ドットに変更すれば問題ありません。
 上記サンプルにおいてその修正を行った場合は下記のようになります。(修正部分は青字

上下画面を円が動き回るサンプル2
CLS
VISIBLE ,1,,,,1
PNLTYPE "OFF"
X=100
Y=50
V=5
W=5
@LOOP
 GPAGE 0
 GFILL 0,0,255,191,0
 GCIRCLE X,Y,10,15
 GPAGE 1
 GFILL 0,0,255,191,0
 GCIRCLE X,Y-252,10,15
 X=X+V
 Y=Y+W
 IF X<10 THEN X=10:V=-V
 IF X>245 THEN X=245:V=-V
 IF Y<10 THEN Y=10:W=-W
 IF Y>433 THEN Y=433:W=-W
 VSYNC 1
GOTO @LOOP

 「60ドット」は非常にアバウトな目測であり、もっと正確な値を知りたい人は物差しで実機のサイズを測って求めると良いでしょう。ただし、機種ごとに異なる値になるため注意が必要になります。

 《 機種ごとの上画面、下画面の隙間のドット数 》
機種名
隙間の幅の実測値(単位mm)
係数
隙間のドット数
DSi
---
3.57
---
DSi LL
---
3.00
---
3DS 全画面表示
17.7
4.17
73ドット
3DS 等倍表示
17.7
5.20
92ドット
3DS LL 全画面表示
---
2.97
---
3DS LL 等倍表示
---
3.76
---
※ドット数は隙間の実測値×係数で求めることができます。(係数は1mmあたりのドット数を示しています)
 ピクセル等倍表示は[SELECT]ボタンを押しながらプチコンを起動するとできます。(通常は全画面表示)
 3DS以外の機種は所有していないので皆さんで測定してください。(実測値のデータをご提供ください)
 実測値を求める場合には本体を180度開き物差しを画面に対して平行な位置に置き目の位置は目盛りに対して垂直になるような位置に持っていってください。
 画面と物差しの間に隙間ができるため基準位置(0mm)と測定位置で同じ目の位置だと1mmくらいの誤差がでます。
 事前にGCLS 15としておくと測定しやすいと思います。

 今度は先ほどよりもスムーズに上下画面が繋がっているように見えるでしょう。しかし、上下画面の間は見えないので見えない部分に重要なものが表示されないように注意しなくてはなりません。また、このサンプルのように動きが直線的ならば問題ないですが、不規則な動きをする敵の場合は攻略が困難になってしまうし、当たり判定にGSPOITを用いる場合には上下画面の間に非表示の領域があるとその部分の当たり判定が無くなってしまいます。ゲームによってどうすべきかを考えるのがベターでしょう。
 上画面と下画面で同じキャラ(円)を2つも表示させたら速度が遅くなると思いがちですが、画面外の描画はほとんど時間がかからないのでそれほど速度は落ちません。しかし、2画面使えば表示する量は1画面よりも相対的に増えてしまいがちなのでその分だけ速度は落ちると思います。

 上下画面を両方とも使ったゲームを作る時に問題になるのはスプライトの制限です。ゲーム作りに便利な上画面用のプリセットのキャラは下画面では使えないという制限や定義可能数の上限が厳しくなっているため下画面でスプライトを使ったゲームを作るのは簡単ではありません。(上画面用のスプライトキャラを下画面で使いたい場合は、CHRREADで上画面で使いたいスプライトのキャラを文字変数に入れてそれをCHRSETでSPSに定義するだけなので慣れてしまえば難しいことは何もない)


 さて、下画面(タッチパネル)を使ったゲームを作ってみようと思ったものの1画面(プログラムが29文字以内×24行以内)で出来るもので良さそうなものが浮かばなかったため昔ポケコン用に作った2LINEピョンコを移植してみることにしました。
 この2LINEピョンコは穴を飛び越えながら右端まで行けばクリアという某雑誌で出されたアイデアを元に作られたゲームです。多くの人が同じ基本アイデアを元にゲームを作ったのですが、私が作った2LINE版はアナログ的なキー入力によって操作するものになっています。
 これならば操作部分だけをタッチパネルに置き換えれば簡単にプチコン移植できそうです。

 プチコン版のピョンコを作るにあたって必要となることは「タッチパネル上での操作から速度をや角度を求める」「放物運動を行う」「地面との当たり判定を行う」ということです。
 ポケコン版のピョンコはキャラがバッタなのですが、プチコン版はキャラが女の子ということで「ピョン子」としました。



 このゲームをプレイしての通り、下画面には何も表示しておらずタッチパネルを使用した入力専用となっています。まずは入力部分から見ていきます。
 このゲームではタッチした速度と角度がピョン子のジャンプの初速と角度に変わるわけですが、標準で備わっているTCHTIMEはこういったアクションゲームにおいては精度の面で使い物にはならないため使っていません。というのも、TCHTIMEは1フレーム単位(1/60秒単位)でしか計測できないからです。タッチしている時間は数フレーム〜せいぜい10数フレームと非常に短いため1フレーム単位の計測では数値の変動幅が小さくなります。実は、TCHTIMEを使った場合は演算速度が100倍くらい遅いポケコン版よりも低い精度なのです。
 指先(ペン先)の微妙な感覚がゲームに反映されるかがこのゲームでは非常に重要だし、速度のコントールをより細かく可能にするため1フレーム単位ではなくもっと細かくしたいところです。これには乱数(RND関数)を用いても良いのですが、1画面プログラムということを考えて乱数無しで実装しているのがこのプログラムのように自前でカウンタを用意する方法です。これによって文字数削減とある程度のゆらぎ(ランダム性)を同時に実現しています。(自前でカウンタを導入することで細かくカウントできているもののタッチの入力精度は1フレーム単位なので数値が細かくなっても精度はフレーム単位の場合と変化しない)
 この自前カウンタ実装のためVSYNCも使っていない(これによって文字数の短縮ができている)ので初代とmkIIでは動作速度の関係で問題が起きる可能性があります。確かに全く同じようにプレイするというわけにはいきませんが、操作には余裕を持たせてあるし速く動かせば有利になるというゲームではないため速度差が多少あっても問題ありません。(とはいえ、mkIIでプレイすると初代プチコンでプレイ時より少し難易度は上がっている)

 あとは、タッチ速度をピョン子の速度に変換する係数をどれくらいにするかということだけを考えればいいです。この変換式もこのゲームで快適にプレイできるかどうか重要な要素となります。
 ペンを動かす速度をどうやって求める方法ですが、速度=距離÷時間であるため距離と時間が分かれば速度は分かります。分かるのは平均速度でしかないけど問題ないでしょう。距離は最初にタッチされた座標と離れる直前の座標の差を取れば分かります。
 私は素早く画面対角線上に動かして画面の端から端まで余裕で到達できるくらいの係数にしました。放物運動の場合は距離は初速の2乗に比例するため全力の半分となる微調整の効く速さだと画面の1/4〜1/3くらいの距離ジャンプできるようになります。1ステージあたり3〜4ステップでクリアするということを想定すればこれが快適にプレイできるラインになると思われます。

 また、このゲームではステージデータは完全に乱数で決められています。このため終盤ではクリア困難な面が生成される場合があります。この場合も一発でゴールにたどり着くことが可能であるため理論上クリアは可能です。ただし、上記のようにピョン子の速度にはある程度のゆらぎを持たせており遠距離ジャンプになるほどゆらぎが大きくなるため「理論上クリアが可能」といってもクリアするのは困難になります。後述のように当たり判定は大きめにとっているので一見するとクリアは不可能に近いようなステージでもクリアできたりします。
 また、このゲームではゴールラインを超えてしまった場合には面データが生成しなおされるためクリア困難という面が生成されてしまったらゴールラインを超えて生成しなおすという方法をとることも可能になっています。そういう選択を可能にするためにも「素早くタッチして画面端に到達できるレベル」にしておくことが重要になってきます。(mkIIだと上記のように演算速度が上がっている関係上、1回のプレイで画面の端から端までジャンプするのはかなり難しいためその分だけ難易度が上がっている)
 あくまで結果論ですが、初代で作っていた時点で余裕のある値にしておいたお陰でmkIIでも十分に遊べるようになりました。

 次はジャンプした際の放物運動について少し書いておきましょう。2Dアクションゲームに実装する場合は放物運動を物理の公式を使って計算するのではなくそれっぽく描かれていれば問題ないと思います。マリオのジャンプもちゃんとした放物線ではありません。
 しかし、ここでは物理の公式を元にした放物運動を行いたいと思います。それは絶妙な力加減でピョン子をコントロールすることこそがこのゲームの醍醐味だからです。
 放物運動を行うには基本的に速度と角度が必要です。角度がなぜ必要かというと速度をX軸方向とY軸方向に分解する必要があるからです。初速V、角度Pの場合はX軸方向の速度VXとY軸方向の速度VYは下記のようになります。

 VX=V*SIN (P)
 VY=V*COS (P)


※プチコンでは三角関数はすべてラジアンで計算されます。
PラジアンではなくP度ならばVX=V*SIN (P*PI()/180)としなくてはなりません。
P*PI()/180RAD(P)と表記できますが、RADは0〜360の範囲内しか受け付けないためその範囲内に収める処理が必要になります。

 そして、放物運動の場合はX軸方向は等速運動(ただし、風の影響や空気抵抗のあるゲームならば等速ではなく減速した方がそれっぽく見える)となっており、Y軸方向は等加速度運動となっています。Y座標方向は初速かから重力加速度の分だけ速度をマイナスにすればいいですが、その値によってジャンプの飛距離が変わってきます。ゲーム内容によって自由に決めて問題ないのでテストプレイによって最適な値を決めるといいでしょう。速度が分かれば現時点の座標に加算(Y座標の場合は上方向に小さくなっているので減算となる)すれば次に表示すべき座標が求まります。
 ピョン子ではタッチした座標によって、すでにX軸方向、Y軸方向に分解した速度が得られているためSIN、COSは使っていません。(不要なので角度も求めていない)

 もしも、角度を求めたいというのならばATANを使えばいいだけです。
 ピョン子ではタッチした最初の座標は(A,B)、離れる直前の座標は(C,D)となっています。画面上方向がプラスの角度とすれば角度は始点と終点を結んだ直線の水平面に対する角度(単位は「度」)はATAN ((D-B)/(A-C))*180/PI()で求められます。ただし、AとCが同じ座標(つまり完全な垂直方向)の場合は0で除算することになるのであらかじめAとCが等しくないかどうかのチェックが必要なのでATAN (D-B,A-C)*180/PI()の方が簡単かもしれません。(180/PI()DEG()と同じ役割となる)

 それと当たり判定についても書いておきましょう。このゲームは色と座標の2段階で判定を行っています。このゲームではゴール判定ミス判定の両方を行う必要がありますがこのゲームでは画面端までたどり着けばクリアであるためゴールしたかの判別はFOR〜NEXTのループで行っています。つまり、着地の時点でX座標が242以上ならばクリアと見なされるわけです。
 したがって、行う必要があるのはミスをしたかどうかの判定だけになります。これはY座標が地面の座標を超えたときにミスフラグを立てています。  ミスフラグは19行目の IF Z*Y>140THEN 〜 という判定によって立てられているのですが、これは IF Z==1 AND Y>140 THEN 〜 という意味です(Zの値が0もしくは1であるため)。フラグを立てるのではなくすぐにミスにしないのは、落下音を鳴らしながら落下させるためです。

 またこのゲームではX座標の判定の有効範囲は1ドット分しかないのに対してY座標の判定の有効範囲は6ドット分あります。これは放物運動をプチコン上で行った場合には頂点に達する段階で必ずしもY軸方向の速度がゼロになっているわけではないため着地の時点でジャンプ前のY座標に戻るとは限らないからです。(ジャンプでY軸方向において等加速度運動を行った場合Y軸方向の初速の数値が重力加速度の数値の整数倍になっている場合のみ元の座標に戻る)
 そのため有効範囲が小さいと地面を突き抜けてしまう可能性を考慮しなくてはならず当たり判定が複雑化してしまいます。Y軸方向の当たり判定に余裕を持たせることで当たり判定処理が単純化するのと同時にゲームの難易度が抑えられ、さらに「穴に落ちかけたけどギリギリ助かった」という感じの演出も可能になりました。
 ちなみに「有効範囲が6ドット」というのは私が実際にプレイしてみてY軸方向の初速は最大でも5ドット以下であるためそれより1ドット余裕があれば十分だろうと判断したためです。

 19行目のZ*Y>140Z*Y>135に変えればY座標の当たり判定の有効範囲が1ドット分になるので「地面を突き抜ける」のがどのようなものなのかを実際に確かめてみるといいでしょう。

コラム 当たり判定は正確に行う必要はない!?

 アクション系のゲームにおいて当たり判定は欠かすことのできない存在です。しかし、当たり判定というのは正確に行うことが必ずしも良いこととはいえないのです。

 放物運動をしているピョン子と地面の当たり判定を正確に行った場合を考えてみます。
 隙間の空いている地面の表面をそれぞれ線分とみなし、ピョン子の現フレームの座標と1つ前の座標を結んだ直線(線分)の当たり判定を行えば完璧にできます。その場合、地面それぞれの座標が分かっていればベクトルの外積を使うことで可能ですが地面は高さが一定だし、地面には固有の色が付いているためもっと簡単な方法で判定ができます。(地面が曲線だったり、複雑な形状とかだったらベクトルの外積を使った方が簡単になる場合もある)

 ピョン子が地面に立っている時のピョン子のY座標(スプライトであるため左上の座標)は134になります、したがって、放物運動によって落下しているピョン子がY座標134を通過した瞬間のX座標を求めそのときのピョン子の足元(1ドット下)の地面の色を調べればちゃんと着地できているかどうかの判定は可能になります。ピョン子のスプライトサイズは16x16ドットであるためピョン子のY座標+16の状態を調べれば良いわけです。
 例えばピョン子の1フレーム前の座標が(110,132)、現在の座標が(122,138)とすればその2点間を通る直線と直線Y=134の交点のX座標を求めます。その場合のX座標は114ということがすぐに分かると思います。つまり、座標(114,150)のドットの色をGSPOIT()関数によって空白かそうでないかを調べればミスかそうでないかが分かるということです。

 ただし、これでは正しくありません。それは座標(114,150)が空白ではないとしても現在ピョン子がいる座標(122,156)が空白でない保証はないからです。つまり、このゲームの場合は1フレーム前と現在の座標を結んだ線分で当たり判定を行うのではなくの現在と1フレーム後の座標を結んだ線分で当たり判定を行う必要があります。やることは上記と同じだけど当たり判定のタイミングを1フレームほど早くするだけです。
 簡単に言えば上記の1画面版ピョン子では地面に落下してめりこんだ後にY座標を補正しているのですが、めり込む瞬間の座標で移動を止めるというだけのことです。

 「めり込む前に止める」というのは正しいため自然なように見えます。しかし、地面の足場が1ドットしかない場合は正しく当たり判定を行った場合にはとてもクリアが困難なレベルの難易度になってしまいます。
 ところがY座標の当たり判定に6ドットの余裕があれば事実上ピョン子の移動ベクトルによる線分と1x6ドットの長方形との当たり判定を行うのと同義になり、当たり判定は非常に緩くなっています。この当たり判定の緩和によってこのゲームは普通に遊べるようにバランス調整されています。
 クリアラインの手前が空白だった場合には正確な当たり判定ではクリアすること自体が難しいですが、この当たり判定の緩和によってジャンプする角度を低くすれば容易にゴールすることが可能になるのと同時に角度を調整する戦略性が生まれてきます。

 当たり判定はシューティングゲームにおいては実感している人はかなり多いと思いますが 自機の当たり判定は見た目よりもずっと小さくなってしまいます。敵の弾が多少かすったくらいでは当たったことにはならいし、多少地面にめり込んでも当たったことにはなりません。だからこそ弾幕系シューティングゲームも普通に遊べているのです。また、敵に囲まれてミスになってそこから復活した際に無敵時間(当たり判定のない時間)を用意することで普通にプレイができます。
 あくまでゲームであってシミュレータではないため違和感や理不尽さ感じるようなものでないならば当たり判定は正しく厳密に行う必要はありません。むしろ、その当たり判定によってゲームの爽快感が得られるのならば積極的に変えてもいいのではないかと思います。(例えば敵との当たり判定は見た目より小さくする一方で重要アイテムは見た目通りもしくはそれよりやや大きめの当たり判定を行う感じでケースバイケースで変えるのも1つの方法)
 とはいえ当たり判定は不正確でも良いというわけではなくビリヤードのゲームのように衝突判定を複数回繰り返すなどの複雑な衝突判定を行う場合は誤差が蓄積され予想外のことが起きる可能性があるためなるべく正確に当たり判定を行った方が良いでしょう。

 重要なのはプレイヤーがミスをした時にその理由が納得できるかどうかということです。これはプレイヤーが「どうしてミスになったのか分からない」「ミスの判断基準がおかしい」と感じることはなく「自分のプレイ技術の不足だ」と感じるようにすべきということです。そのためには当たり判定の大きさや判定を行うタイミングはよく考える必要があります。

 「下画面」を使う場合には「ピョン子」のようにタッチパネルを補助入力装置、つまり、単なるポインティングデバイスとして使用するゲームならば簡単に作れます、上記のように下画面は上画面と全く同じ使い勝手では使用できないために下画面を生かしたゲームを作るというのはなかなか難しいです。それでも下画面を使えば便利になったりゲームの幅が増えていく可能性があります。タッチパネルは、麻雀やオセロのようなテーブルゲーム、実際にコマを操作する15パズルのようなパズルゲームや「PETIT KEYBOARD mkII」「SOUND PAD」のようなツール、そしてもぐらたたきのような直感型アクションゲームとは非常に相性がいいです。「JUMPING ISLAND」のようにアナログコントローラ代わりとしてタッチパネルを使うという方法もあります。
 使い方を覚えて積極的に使ってみると良いかもしれません。

 →第5回へ進む


RETURN

inserted by FC2 system