プチコン講座

第1回 コンソールとグラフィックを使おう

【プチコン/mkII 両対応】

 ゲームを作るには欠かせないのは画面表示です。プチコンでは画面表示においてコンソールグラフィックスプライトBG画面が利用できます。今回はその中からコンソールとグラフィックについて書いていきます。
 プチコンにおいてコンソールというのは簡単に言えば「普通の文字(アルファベットや数字や記号など)」のことでグラフィックというのは点や円や四角形などのことです。どのような命令が用意されているかはプチコン内蔵の説明書や公式サイトにあるWeb版の説明書(初代プチコン用/プチコンmkII用)で確認するといいでしょう。

 プログラミングにおいては命令を覚えるたけでは駄目でアルゴリズムを考える必要があります。アルゴリズムというのはコンピュータに処理させるための手順のことです。これは初心者の場合は自分ですべて考えるのは難しいため実際のプログラムを見て覚えるのが一番です。幸いにしてプチコンはBASICということもありプログラムリストは多数公開されているし、プチコンにはいくつかのサンプルプログラムが内蔵されているためそれを参考にするといいでしょう。
 またプチコン公式サイトではそのサンプルプログラムを元にした初心者向け講座(初代用mkII用)があるのでまずはこれを一通り読んで、実際に試してみることをお勧めします。頭だけで覚えるのではなく身体で覚えることが重要です。(見ただけでは分かったつもりになっている場合が多い)

 ゲーム作りにおいては完成形がイメージできることが必要になってきます。
 「こういうゲームを作りたい」というイメージが具体的なほどいいです。カッコイイゲームとかスピーディなゲームとかいう曖昧かつ抽象的なものでは駄目です。具体的な形が決まればそれを実現するにはどのようなアルゴリズムが必要なのかということが分かります。したがって、完成形のイメージが制作途中で変わるのは問題ありませんが、作りたいものが具体的にイメージできないと作ることはできません。
 どのようなゲームを作りたいのか具体的なイメージが難しければ既存のゲームを参考にするのも1つの方法でしょう。その場合はイメージを具現化させるためには技術面やスペック面で難しいこともあります。その判断ができない最初のうちは自分が作りたいゲームを考えたらそのイメージを壊さない程度に簡単なものに置き換えることが求められることもあります。

《簡略化の一例》
◎「スーパーマリオ」のようなゲームを作りたい

     ↓(簡略化)

 ・敵を出さずにスクロールする床をジャンプで越えていくゲームにする
 ・固定画面でジャンプしながら敵をかわすゲームにする

     ↓(難しくて作れないようならばさらに簡略化)

 ・自分のキャラをジャンプさせてみよう
 ・画面をスクロールさせてみよう
 ・敵を動かしてみよう

最初は簡単なもので十分です。1つずつ完成させて経験値アップをしましょう!

 では、実際に何かを作ってみることにします。簡単なのは「100m走」の類のゲームでしょう。2つのボタンを交互に押して人型のキャラを走らせ画面はスクロールせず固定で端からスタートして逆端まで来たらゴールというゲームです。

 さて、イメージできたでしょうか?

 100m走タイプのゲームを作るのが簡単な理由は移動に使うボタンが2つで済むということと移動がスタートからゴールへの一方通行であり基本的にそれ以外のルールというものがないからです。つまり具体的なイメージが決まりやすいことを意味します。これは、言い換えれば「ボタンを交互に押す」ということと「キャラをスタートからゴールまで移動させる」ということの2つのこと(2つのアルゴリズム)が分かればこのタイプのゲームを作ることが可能になるわけです。

 いきなり「交互に押す」というのは難しいので[A]ボタンを押したら変数Xの値が1増えるというプログラムを作ってみましょう。
 プチコンではどのボタンが入力されているかはBUTTON()関数を使えば調べることができます。説明書にはそのボタンを押したらBUTTON()関数の値がいくつになるかが書いてあります。[A]ボタンは16になっているのでIF文を使えば「[A]ボタンを押している場合はXに1加算する」というのはIF B==16 THEN X=X+1となります。あとXの値がちゃんと増えているかどうかを確認のためPRINT命令を使って表示することにします。

ボタン入力判定サンプル
@LOOP
 B=BUTTON()
 IF B==16 THEN X=X+1
 LOCATE 15,12
 PRINT X
GOTO @LOOP

 [A]ボタンを押している時のみXの値がすごい勢いで増えていることが分かるでしょう。
 LOCATE命令によってXの値を表示する位置を決めています。プチコンにおいてはコンソール(文字)表示の画面はX座標0〜31、Y座標0〜23となっているためLOCATE 15,12というのは画面の中央付近の座標となります。
 このプログラムには終了処理がないので[停止]ボタン(もしくは[SETECT]ボタン)で停止することで強制終了する必要があります。ここで、一端停止して再び開始すると1からではなくいきなり前回停止した時の数字からカウントされていることが分かります。ゲームの場合はゴールした直後に再びスタートではなくゴールから始まってしまえばゲームにはなりません。そのためゲームでは初期設定をちゃんとしておく必要があります。今回はカウントされているか否かさえ分かればいいので特に問題はないのですがカウントを1からちゃんと行うために先頭にX=0を置くことにしましょう。(CLEAR命令を実行すればすべての変数を0にしてくれる)
 それと、RUNをした直後の画面上の余分な文字が邪魔ですね。それを消すためにはCLSを使います。

 さて、いよいよ「交互に押す」という方法について考えていきます。そのためには前回押したボタンが何かが分からなければ判定のしようがありません。したがって前回どのボタンを押したのかを別の変数(ここでは変数A)に入れておくことにしましょう。
 今回[A]ボタンを押して(変数Bの値が16)、前回[B]を押した(変数Aの値が32)という場合にXの値を1加算するというのはIF B==16 AND A==32 THEN X=X+1となります。
 2つの条件を1つのIF文で判別するためにはこのようにANDを用いれば簡単にできます。あとは今回[B]ボタンを押した場合についても考えればいいのです。これで、「[A]ボタンと[B]ボタンを交互に押したらXの値が1ずつ増えるプログラム」を作る場合には下記のようになります。

ボタン交互押しサンプル(1)
CLS
X=0
@LOOP
 A=B
 B=BUTTON()
 IF B==16 AND A==32 THEN X=X+1
 IF B==32 AND A==16 THEN X=X+1
 LOCATE 15,12
 PRINT X
GOTO @LOOP

 これで見た目には問題がないように感じますが、実際に動作させると画面中央に表示されているXの値がなかなか変わってくれないことに気が付くでしょう。素早く[A][B]ボタンをこすれば時々反応してくれますが、ゆっくり交互に押したらまず反応してくれません。
 実はBUTTON()関数を実行時に何も押してない場合には値が0になってしまうからです。そのため変数Aには前回押したボタンの値が入っているのですが、前回0だった時は反応してくれないのです。(このプログラムで正常にボタンを押した回数をカウントするためには[A]ボタンから[B]ボタンへの移動を1/60秒で済ませる必要がある)

 それでは実用にならないため「Bの値が0でない時」(=何かボタンを押したとき)だけAにBの値を入れたら良いと考えるかもしれません。
 しかし、A=BIF B!=0 THEN A=Bに変えても直前に[A][B}ボタンを同時押ししてしまった場合には次に[A]ボタンや[B]ボタンを単独で押しても反応しないという問題があります。

 こうなると別の方法を使って判定を行うしかありません。そこで役立つのがフラグを使ってチェックする方法です。
 フラグの値が0の時は[A]ボタンを押せばフラグが1になり、フラグの値が1の時は[B]ボタンを押せばフラグが0になるというものです。これで直前にどのようなボタンを押していても[A]ボタンを押した後に[B]ボタンを押した場合(もしくはその逆)にその回数をカウントできるようになります。

ボタン交互押しサンプル(2)
CLS
X=0
F=0
@LOOP
 B=BUTTON()
 IF F==0 AND B==16 THEN X=X+1:F=1
 IF F==1 AND B==32 THEN X=X+1:F=0
 LOCATE 15,12
 PRINT X
GOTO @LOOP

 これで「交互に押す」プログラムはできました。
 しかし、今回のように特定の2つのボタンを交互に押すという場合は2回に分けて判定する必要はないのです。

ボタン交互押しサンプル(3)
CLS
X=0
F=16
@LOOP
 B=BUTTON()
 IF B==F THEN X=X+1:F=48-F
 LOCATE 15,12
 PRINT X
GOTO @LOOP

 プログラムリストがかなり簡略化されましたが、これでちゃんと動作しています。
 上記のようにBUTTON()関数において[A]ボタンは16[B]ボタンは32となっているため最初にFの値は16に設定しています。そして、[A]ボタンを押すことで変数Fには48-16=32という値が入ります。これは[B]ボタンの値になっています。さらに次に[B]ボタンを押すとFの値は16に戻ります。
 つまり、IF文1つで[A]ボタン、[B]ボタン両方の判定ができるというわけなのです。

 処理速度の遅い8ビットパソコンやポケコンではこのような手法はゲームの実行速度を上げるためには非常に有用となってきますが、ポケコンと比べて60〜100倍程度速いプチコンの場合は、速度面ではメリットはそんなに大きくはありません。しかし、積み重ねればそれなりに大きなものになってくるし、ネット上でプログラムリストを公開して手入力をしてもらうつもりならばプログラムリストはなるべく短い方が好ましいでしょう。可読性を下げたりバグに対処できなくなる恐れがあるので初心者のうちは無理な短縮よりは分かりやすいプログラムリストの方が良いかもしれません。

 ボタンの交互に押すプログラムが出来るようになったらいよいよキャラの移動です。要するにLOCATE命令を使って人型の文字を動作させることにしましょう。キャラを移動させるのはプチコン内蔵のSAMPLE7を参考にすると分かりやすいでしょう。

 キャラを移動させるにはキャラを消して新たな場所にキャラを表示するということが必要になってきます。それさえ分かれば作るのは簡単でしょう。

人型キャラ移動サンプル(1)
CLS
X=0
F=16
@LOOP
 B=BUTTON()
 IF B==F THEN X=X+1:F=48-F:LOCATE X-1,20:PRINT ""
 LOCATE X,20:PRINT "人"
GOTO @LOOP
(※はスペースを示す。人型のキャラ(キャラクタコード244)が表現できないためで代用した。)

 しかし、このような100m走タイプのゲームの場合は、スタートからゴールへの一方通行ということもあり、移動方向は固定です。これは、例えば画面左がスタートで右がゴールの場合には消さなくてはいけないキャラの位置は新しく表示するキャラの位置と比べて「常にX座標がマイナス1になっている」ということです。
 そのため2箇所にあるPRINTは下記のように1つにまとめることができます。

人型キャラ移動サンプル(2)
CLS
X=0
F=16
@LOOP
 B=BUTTON()
 IF B==F THEN X=X+1:F=48-F
 LOCATE X,20:PRINT "人"
GOTO @LOOP

 これでPRINTが1つで人型キャラを移動できるようになりました。ただし、人型キャラの表示可能な座標の範囲は(1)の方は0〜31ですが、(2)の方は1〜31へと変わる点に注意が必要です。
 また(2)の場合はLOCATEの指定場所に表示されるのはスペース()であるためLOCATE指定の有効範囲は0〜30になります。したがって、画面右端(X座標31)がゴールの場合はLOCATE 30,20に"人"が表示された段階でゴールとなります。

 これで、「ボタンを交互に押す」アルゴリズムと「キャラを動かす」アルゴリズムは理解できたと思います。あとは、ゴールしたかどうかの判定を加えればゲームとして完成しそうです。
 では、私が実際に作ったゲームで見てみましょう。タイトルは「プチコン50m走」です。



 最初に画面クリアをするため初期設定でCLSとGCLSを入れています。CLSは上記のようにコンソール画面のクリアなのですが、GCLSはグラフィック画面のクリアです。このゲームにはグラフィック命令は使ってないのでGCLSは本来ならば不要なのですが、直前にグラフィックを使ったゲームをプレイしてその画面クリアをしてない場合を想定すればコンソールのみのゲームでもGCLSは入れておいた方が無難でしょう。あとこのゲームの背景色は黒なのですが、GCLS (色番号) とすることで背景色を設定することができるのです。(GCLS 2なら赤背景になる)
 プログラム実行中ではなく編集中であれば[START]+[R]+[←](左)ボタンの同時押しをすることで画面の消去(VRAMの初期化)が可能です。mkIIではこのコマンドと同じものをプログラム中でもACLS命令によって可能になっています。ただし、mkII専用命令であるためこの命令を使用した場合はmkII専用のプログラムになってしまう点に注意しておく必要があります。

 このゲームを作るのに必要な2つのことはすでに説明済みなので恐らくこのリストを見ても分からない部分はないでしょう。

 実際はボタンを交互に押す方法は(2)、(3)どちらでもよく、キャラ移動も(1)、(2)どちらでもよいのですが、今回はより効率のよい方法があることを知ってもらうために書いておきました。幸いにしてプチコンは動作速度が速いためこのような処理の簡略化による速度の向上はあまりないもののプログラムリストを短くすること第三者が入力する場合に手間が減るため余力があればやってみるといいでしょう。

 ゲーム作りで重要なのはテストプレイを十分に行うことです。テストプレイを行うことでバグをとったり、バランス調整を行ったりできます。このプログラムのように単純なものであれば数回のテストプレイでほぼバグが無くなりますが、複雑なプログラムの場合は様々な状況を試してみないとバグを十分にとることができません。
 あとバランス調整ですが、この場合は50m走ということで連射がある程度速い人で6秒台のタイムになるようにTの加算量を調整しています。しかし、そのためにこのゲーム内でのタイムは現実の時間と大きなギャップがあります。
 今回はボタンを1回押すごとにX座標を1ずつ移動させるというゲーム内容であるためタイムの加算量でしかバランス調整を行うことができませんが、移動量そのものを調整できる場合はその加算する移動量を変化させることでバランス調整をするとよいでしょう。

 このバランス調整で問題となるのは初代プチコンとmkIIの処理速度の差です。環境が固定されているならば自分のプチコンで動作させてそれでバランス調整を行えば良いのですが、mkIIは初代と比べて概ね3〜4割高速化されています。このリストではメインルーチンを1回実行するごとにタイムが加算されてるためmkIIと初代の速度差がそのままタイム差になってしまいタイム競争をするゲームとしては致命的なレベルの差になります。
 そのためメインルーチン1回の時間が同じになるようにする必要がありますが、そこで出てくるのがVSYNCという命令です。例えば1回の実行に1/100秒の場合と1/200秒の場合では一定時間の実行回数には2倍の差ができてしまうのですが、メインルーチンの中にVSYNC 1を入れることで1/60秒固定にすることが可能になります。(処理そのものが1/60秒以内に完了しない場合を除く)

 それを踏まえてこのゲームを初代でもmkIIでも同じようにプレイできるようにするためにはVSYNCを置く場所は画面表示が行われた後であればメインルーチン内のどこでも構いません。ただし、常に実行される必要があるためIF文のTHEN以降に置いた場合には常に実行される保証がないのでそこだけは避ける必要があります。(メインルーチン内で行っている画面表示をすべて行う前にVSYNCを実行すると正常に画面表示を行うことができない場合があるので基本的にメインルーチンの最後の方に付ける方が良い)
 ここでは15行のIF X<30 THEN @MAINの前に置くことにしましょう。VSYNC 1を入れた場合には入れる前と速度が変わってくるので再度バランス調整が必要になります。10行のT=T+1/300T=T+1/15くらいに変更すれば連射が早い人で6秒程度のタイムになると思います。
 VSYNCは初代とmkIIの速度差を埋めるというだけではなく表示のタイミングを図る効果やボタン入力判定の誤動作防止の役割もあるため特に難しく考えず「基本的には入れるもの」と考えておけば良いでしょう。(VSYNCとmkIIで加わったWAIT命令に関しては詳しく知りたい人は第2回のコラム参照)



 続いてグラフィックを使ったゲームを作ってみます。やはり、簡単なのはいわゆる「ドットよけゲーム」の類でしょう。(1つのボタンでふらふら動くものが多いため「よっぱらいゲーム」とも言われている)
 このタイプのゲームには様々な種類がありますが、画面に表示されているドット(=要するにただの点)などの障害物を避けながら自分のドットを1つのボタンのみを使って動作させて画面の端から逆の端まで移動させるというものが基本になっています。
 つまり、「1つのボタンを使って画面端までドットを動かす」ということと「ドットと障害物の当たり判定(衝突判定)を行う」ということができればこのタイプのゲームを作ることがができるのです。

 では、1つのボタンで画面上で上下に動かすためにはどうしたら良いでしょうか。
 1ドット上に進むためにはキャラ(ドット)のY座標を1小さくし、下に進むにはY座標を1大きくすれば良いというのは簡単に分かると思います。したがって、ボタンを押している時にYの値を1マイナスし、ボタンを離している時にYの値を1プラスするにはその2通りのIF文を用意すれば簡単に判定が可能というのも分かるでしょう。
 [A]ボタンを使って上下に移動させるプログラムは下記のようになります。

ドット移動サンプル(1)
CLS
GCLS
CLEAR
@LOOP
 B=BUTTON()
 IF B==16 THEN Y=Y-1
 IF B!=16 THEN Y=Y+1
 X=X+1
 IF X>255 THEN END
 VSYNC 1
GOTO @LOOP

 これで問題はないのですが、「プチコン50m走」におけるPRINTのように2つのIF文を1つにまとめることも可能なのです。
 それは常にYの値を1プラスし、ボタンを押している時だけYの値を2マイナスするというものです。ボタンを離している時はプラス1になりますが、押している時は1-2=-1で1マイナスとなります。

ドット移動サンプル(2)
CLS
GCLS
CLEAR
@LOOP
 B=BUTTON()
 IF B==16 THEN Y=Y-2
 Y=Y+1
 X=X+1
 IF X>255 THEN END
 VSYNC 1
GOTO @LOOP


 次に障害物について考えてみることにします。
 まずは、障害物を出す方法を考えてみます。ここは簡単にいくために無作為(ランダム)にたくさんのドットを表示することにします。ドットの表示はGPSET命令を使えばできますが、問題はその座標指定です。LOCATEとPRINTを使ってキャラクタ表示する場合はその座標はX座標が0〜31、Y座標が0〜23ですが、グラフィック画面では画面で表示される範囲はX座標が0〜255、Y座標が0〜191になります。
 ランダムに表示する場合はRND関数が必要になります。RND (10)とすることで、0〜9の10種類の数を無作為に作りだすことができます。先ほどのプチコンのグラフィック画面の座標を考えるとGPSET RND (256),RND (192),12(最後の「12」は黄色を意味するので好みに応じて変えてもOK)とすることで画面上に無作為にドットを表示できます。さすがに1個では寂しいのでFOR〜NEXTを使ってある程度たくさん表示することにしましょう。

ドット移動に障害物表示を加えたサンプル
CLS
GCLS
CLEAR
FOR I=1 TO 100
 GPSET RND (256),RND (192),11
NEXT
@LOOP
 B=BUTTON()
 IF B==16 THEN Y=Y-2
 Y=Y+1
 X=X+1
 IF X>255 THEN END
 VSYNC 1
GOTO @LOOP


 障害物との当たり判定は色で見分けるだけで可能なのでGSPOIT関数で簡単に判定できます。障害物の色が黄色(12)の場合はA=GSPOIT (X,Y)としたときにAの値が12ならば障害物にぶつかったと見なすことが可能になります。
 ここで、このゲームの場合は1面をクリアしても画面消去されず自分が通過した軌跡が残り、その軌跡にぶつかってもゲームオーバーというルールにしてみましょう。その場合は自分の軌跡が黄緑(11)の場合はGSPOIT関数で調べた値が11の場合でも障害物にぶつかったという判定を入れる必要があります。つまり、障害物(12)と自分の軌跡(11)の2つの当たり判定が必要なのですが実は1つで済む方法があります。それは、何もない場所ならばセーフであるためです。  このゲームでは「背景色は0(透明色)」になっているため「(障害物や自分の軌跡のない)空白部分ならばGSPOIT関数の返す値は0になる」わけです。(事前にGCOLORで色を変えたゲームを実行していた場合にはこの限りではないので、開始時にGCLS(引数無し)ではなくGCLS 0を実行しておいた方がベター)
 つまり、このゲームの場合はGSPOIT関数の返す値が「11もしくは12ならばゲームオーバー」というのは「0でなければゲームオーバー」というのと同じになるわけです。GSPOIT関数は画面外を指定したときには-1の値を返すため「0以外かどうか」で判定しておけば同時に画面外に出たかどうかの判定も行うことが可能になります。

 これで、判定方法は分かりましたが、その当たり判定を置く場所については考える必要があります。(詳しくは後述)

 それでは、それを元に私が作った「ドットよけゲーム」を見てみましょう。



 まずグラフィックを使えるようにするためにはVISIBLEの第6引数(VISIVBLE 1,1,1,1,1,1,1 ← ここグラフィック画面を表示するように設定しなくてはなりません。そしてGPAGE 0とすることで「上画面でグラフィックを使う」という設定が必要になります。デフォ(プチコン起動時)では両方とも使えるように設定されているため省略は可能なのですが、直前に他のプログラムを使用していてこの内容が書き換えられている可能性を考えるとあまり省略はしない方がいいかもしれません。mkIIならばACLSを使うと良いです。コンソール、グラフィックだけではなく第2回で書いているスプライトやBGもすべて画面上から消去して、なおかつVISIBLE命令も初期化してくれます。したがって、ACLSを使えばVISIBLE命令についてはあまり考える必要がなくなると思います。

 当たり判定は見ての通り、自分のキャラ(ドット)を表示する前に行う必要があります。試しに14行と15行を入れ替えてみれば分かると思います。このゲームは当たり判定を自分のいる座標のドットの色で行っていますが上記のように空白部分(GCOLOR 0)以外は障害物に当たったと見なされます。しかし、当たり判定より先に自分のキャラを表示してしまえば自分がいる座標が空白で無くなるため自分の軌跡ではなく自分自身のドットを障害物と見なしてしまうためスタート直後にゲームオーバーになります。
 このように当たり判定を行う場合はその判定を行うタイミングによってゲームが正常動作しなくなる可能性もあるため注意が必要です。

 ゲームバランスの調整について書いておくとこのタイプのゲームは自分のキャラ(ドット)の動作する速度や障害物の数などを調整することで行うことができます。速度はVSYNCの数値を変えることで簡単に変更が可能になります。上記のリストではVSYNC 1だとやや速く感じたのでVSYNC 2にしています。
 障害物の数はFOR〜NEXTのループ回数で簡単に変えられますが、障害物を置く場所には注意が必要になります。開始地点、もしくは開始してすぐの場所に障害物があったら回避不能(下記のコラム参照)になるためスタート地点から一定距離の間は障害物を置かないという工夫が必要です。例えば開始地点から15ドット分は障害物を置かない(言い換えればX座標15〜255に置く)というようにするためにはRND (256)RND (241)+15に変えてやれば良いです。15〜255だと241種類の乱数が必要になり、それを15ドット分ずらす必要があるからです。(上記リストでは終了地点となる画面端にもドットを置かないようにX座標は15〜254にしている)

 私が今回作ったドットよけゲームにおいては自分の移動した軌跡を次のステージに持ち越すシステムにしています。こういったドットゲームは反射神経や運の要素が大きくてプレイヤーの上達が反映されにくいためです。今回のようなシステムにすることで高スコアを狙うにはいかに効率よく避けていくかという戦略性が生まれてくるため高スコアを取るためには上手いプレイが要求されるようになります。それと同時に上手い人でも序盤は簡単すぎて暇になるということはなくなります。
 一般的なドットよけゲームの場合はキャラの速度や障害物の数を増やすことのみで難しくしていますが、そのやり方によっては上手い下手(=プレイヤースキルが優れているか否か)よりも運の要素が強くなってしまいがちです。「運」と「プレイヤースキル」のバランスをどのようにするかがゲーム作りには重要になってきます。

※「プレイヤースキル」とは「反応力」「思考力」「応用力」「記憶力」などそのゲームをプレイするのに有利なプレイヤー側の要素を総括したものを示している。

コラム 反射と思考

 「ドットよけゲーム」というと一般的には反射型のアクションゲームと考えれており、思考型アクションゲームと考える人はまず居ないでしょう。ドットよけゲームは1ドット単位の緻密な操作が要求されるのですがそのまま進んだ場合に障害となるドットに当たるかどうかというのはよほど荒いドットで構成されていないと直前に来るまでは分かりません。

 もしも、反射神経(≒反応力)のみでドットを避けるのならば人間の反応速度は一般的に最高でも0.1〜0.2秒と考えられているために1秒間に5ドット進むくらいの速度(5fps=VSYNC 12くらい)に設定する必要があります。私が作ったドットよけゲームはVSYNC 2(30fps)となっておりこの速度では当たる直前に反射神経でドットを避けるのは不可能です。
 したがって、障害となるドットに「当たるか否か」ではなく「当たりやすいか否か」という判断によって障害となるドットがより少ない場所を通るように操作することになります。
 それぞれのドット同士の間隔が5ドット空いていれば反射神経だけで避ける場合に単純計算では5倍ほど速度が遅くなったのと同じになります。そのため反射神経だけでクリアすることは不可能ではありません。

 ただ、それも今回作ったドットよけゲームのように固定移動量のゲームにおいて言えることであり、慣性が付いたゲームの場合は反応ができてもそれを制御する時間が必要になります。したがって、反射神経だけではどうにもならない場面もあり「運の要素」が高くなりがちなので注意が必要です。

 ステージが進むごとに難易度を高めるため障害となるドットをやたら増やしたり、速度を上げるということは普通に行われていますが、これは人間の反射神経を超える行為となるためどんどん「運の要素」が高まってくるわけです。(「どちらに移動すべきかが分かる→その反応を行う→実際にその地点まで移動する」という一連の動作を行う時間と障害物に到達するまでの時間を比べ後者の方が長くなっていれば運の要素はほぼ無くなる)
 それと同じくスタート付近にすぐにドットを配置するのも反射神経を考えると避けられないためそういう配置がされないように配慮する必要があります。

 それでは30fpsで5ドットより狭い間隔で配置されている部分がある場合は運の要素が極めて高いのかというとそうではありません。というのもドットよけゲームというのは一般的には固定画面で全体構成が把握できているため上記のようにより安全なルートを選択するという方法があるからです。
 これは間隔の狭い場所はあえて通らずに別ルートを通ればいいということです。

 それに間隔が広い方が単純に通りやすいというものではなく確率を言えば2つのドットの間を通る場合にはその2つのドットを結んだ直線に対して垂直に近い角度で侵入できる方が確率が高くなってきます。リアルタイムでここまで思考できるようになれば反射神経で十分避けられる速度の場合はクリアは容易となりドットよけゲームはリアルタイム思考型ゲームの要素を含んでいると言えるでしょう。

 つまり、ドットよけゲームと単純に言ってもその障害物の配置や量、そして移動速度によって反射、思考、運の要素のバランスが変わってくるわけです。これはドットよけゲームに限らず他のさまざまなジャンルのゲームにおいて言えることなのでこのバランス調整というのはゲームにおいて非常に重要な要素といえます。


→第2回へ進む


RETURN

inserted by FC2 system