【プチコン/mkII 両対応】
プチコンでゲームを作るメリットはDSiや3DSがゲーム機であるため作ったゲームの操作がしやすいということが挙げられます。その反面でソフトウェアキーボードであるためPCゲームのようなキーボード主体のゲームは操作がしやすいとは言えません。そうなると「ソフトウェアキーボードのみに下画面(タッチパネル)を使うのはもったいない」ということで、やはり下画面(タッチパネル)を使ったゲームも作ってみたいですね。TCHX | タッチされたX座標 |
TCHY | タッチされたY座標 |
TCHST | タッチ状態を調べる(TCHST=1ならばタッチ状態にある) |
TCHTIME | タッチされ続けている時間(フレーム数) |
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 |
下画面は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の使用可能バンクは上画面がSPU0〜SPU7の8バンク、下画面がSPS0〜SPS1の2バンク) ※上画面にもシステム用スプライトとなるSPS0〜SPS1は存在する(カーソルなどに使用されている)けど任意の番号のスプライトは表示できない。(上画面にもSPSがあるためSPPAGE 1としておかないと下画面でSPSは使えないけど下記欄外に書いたようにBGと同じくSPS0の後に"L"を付けることでSPPAGE 1無しでも下画面用SPSが定義が可能になる) | |
あらかじめBGPAGE 1としておくことで下画面で使用可能。(上画面を使用するときはBGPAGE 0) BGCLRでは指定した画面のみがクリアされる。 BGキャラの定義可能上限数は1024個で定義方法はコンソールと同じくBGPAGE 1を付けるかリソース名の末尾にLを付ける。 (CHRSETの使用可能バンクは上画面BGU0〜BGU3の4バンク、下画面BGU0L〜BGU3Lの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と見なされる。 |
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 |
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 |
コラム 当たり判定は正確に行う必要はない!?アクション系のゲームにおいて当たり判定は欠かすことのできない存在です。しかし、当たり判定というのは正確に行うことが必ずしも良いこととはいえないのです。放物運動をしているピョン子と地面の当たり判定を正確に行った場合を考えてみます。 隙間の空いている地面の表面をそれぞれ線分とみなし、ピョン子の現フレームの座標と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つの方法) とはいえ当たり判定は不正確でも良いというわけではなくビリヤードのゲームのように衝突判定を複数回繰り返すなどの複雑な衝突判定を行う場合は誤差が蓄積され予想外のことが起きる可能性があるためなるべく正確に当たり判定を行った方が良いでしょう。 重要なのはプレイヤーがミスをした時にその理由が納得できるかどうかということです。これはプレイヤーが「どうしてミスになったのか分からない」「ミスの判断基準がおかしい」と感じることはなく「自分のプレイ技術の不足だ」と感じるようにすべきということです。そのためには当たり判定の大きさや判定を行うタイミングはよく考える必要があります。 |