継走迷路 製作過程 その1

Home PC-6001mkII Program etc

 このページでは、作成開始からメイン処理の実装までを書いています。

継走迷路 製作過程 Top


2012/08/04:きっかけ
 8月になってHSPプログラムコンテストも始まった。さて何を作ろうか?

 何気なく、「どこかに良いネタ落ちてないかな?」とツイートすると、オリンピックという返答が。ああ、ちょうど旬でいいかも。

 そう思ってはみたものの、オリンピックの競技を1つや2つピックアップしただけではオリンピックには見えないんだよな...。あと何かオリンピックっぽいものというと...聖火リレーか。リレー走者を操って聖火を届けるパズルゲームでどうだろう。

 暫定的なルールとしては、こんな感じでいこうか。
  1. 画面内の走者を1マス以上動かして、次のランナーに聖火をつなげる。
  2. 走り終わったランナーは動かなくなる。
  3. ランナーは走れる距離に制限がある。
  4. 画面内の全てのランナーに聖火をつないだら面クリア。
  5. 壁や走り終わったランナーの部分は通れない。
  6. 岩は1つだけ押せる。
 ここまでは一気に思いついたが、一つの不安があった。これだけのルールで、果たして難しい面が作れるのだろうか?

2012/08/05〜11:ランナー
 不安はあるが、先に進もう。とりあえず、ランナーのキャラクタを作るか。

 操作中のランナーと待ち状態のランナー、そして走り終わったランナーを、HSPの素材から生成する。

 待ち状態キャラは、昨年の「RoaDrawer」と同様に、キャラクタの各点の色情報をRGBに分解し、R成分がB成分より大きい場合にRとBを逆転させる。これで、全体的に青っぽいキャラクタになる。

 走り終わったキャラは...燃え尽きたイメージで灰色が良いかな?同じようにキャラクタの各点の色情報をRGBに分解し、今度は NTSC系加重平均法で色の明るさを求める。この明るさデータをR,G,B全てに適用させると、グレースケールのキャラクタの出来上がりだ。

 Webで調べると、R × 0.298912 + G × 0.586611 + B × 0.114478 でNTSC系加重平均法による明るさが求まるようだが、そこまで厳密にする必要もないだろう。という事で、簡略化して( R × 3 + G × 6 + B )÷10 でおおよその明るさを計算する。

 出来上がったキャラクタはこんな感じとなる。まあこんな雰囲気かな?

画像


2012/08/17〜19:仮表示
 ランナーのキャラクタも作成したし、とりあえず表示までこじつけるか。

 今回は、面構成を8x8マスで考えている。画面の縦が480ドットだから、1マスあたり60x60ドットか。と思いきや、ランナーを64x64ドットで作っている事を思い出した。

 できるだけランナーはそのままの大きさで表示させたいな。とすると、壁や地面を先に書いて、上部分をはみ出させる感じでランナーを表示すれば良いかな?とすると、ランナーのはみ出す分だけ上に空間を空ける必要があるから…えーい、1マス56x56ドットでいいや。

 という事で、地面と壁を元の64x64ドットから56x56ドットに縮小したものを生成する。壁はそのままでは地面との区別がつきにくいので、少しレンガ色っぽくするか。色をまたRGBに分割し、B成分の値にG成分の値をコピーする。

 あと、どうせ岩も必要になるだろうから、岩のグラフィックも生成する。最初に塗りつぶし円を白で描画し、白色部分に水面(?)のグラフィックを貼り付ける。

画像

 これでキャラクタが揃ったので、仮画面を作成する。地面と壁部分は面が変わるまで変化がないので、はじめに作成しておいて表示画面に作成済の画面をコピーする。その他のキャラクタは、逐次表示画面に貼り付けていく。

画像

 まあ、概ねイメージした通りかな。

2012/08/26〜27:残像キャラ
 仮の面を考えつつも、ルールについてまだ悩んでいる。

 ランナーの走行距離制限をどうするか?あまり長すぎると、自由度が高すぎて面が作りにくくなりそうだしな...。とりあえず、5マス分まで走れるようにするか。

 今回、ランナーは通った道を戻れないルールにしようと思っているが、なにか視覚的にわかる仕掛けが欲しいところだ。なんか輪郭のみある残像的な表示にするかな?という事で、もう一種類キャラクタを生成する。

 前回、グレースケールで算出した明るさ情報を使って、明るさ0以外で一定以上暗い部分に色を塗る。元の絵が縁取りされた感じだったので、概ね思った通りになった。

画像

 合わせて、ランナーの動きに走行距離制限と仮の面を入れて様子を見る。見た目はこんな所かな?

画像

 この調子で、果たして面にバリエーションが出るだろうか...?まだ悩んでいる。

2012/09/02〜05:走り放題
 プログラムと並行して、面の作成も開始する。しかし、どうも面作成が滞る。

 5マスという走行距離制限だとキャラクタを回り込むだけで終わる距離なので、動きのパターンにすぐ限界が来る。今回は10面程度作成する予定だが、10面どころか3,4面くらいで面のネタが尽きるんじゃないだろうか?

 面の作り直しになるけど、制限を緩和するかな?8マスとか。でも走行距離を増やすと、今度はプレイヤーが歩数を勘定する手間が増えてパズルに集中できなさそうだし...。

 ...やめるか、走行距離制限を。

 別解が出やすくなるリスクはあるが、肝心の面ができないよりはマシだろう。という事で、プログラムから走行距離制限を外してみる。

画像

 その他、面に制限をつけるため、もう一つ「最後のランナーが画面外に出るとクリア」というルールを加える。このルールで、また面を作り直すか。

2012/09/02:向き合い
 ランナーの交代時は、やっぱりランナー同士が向き合っていた方が良いか。という事で、待ちランナーの向き合い処理を入れる。

 最初は、プレイヤーの操作ランナーの隣にいる待ちランナーのみ向きを変えようかと思ったが、結局全待ちランナーをプレイヤーの操作ランナーの方に向かせることにした。このほうが、待ちランナーが待ち焦がれている様子がわかるのではないだろうか?

 画面上の全待ちランナーについて、今走っているランナーとの位置関係を調べ、縦方向の差分が横方向の差分より大きい場合に上下方向を向かせ、それ以外は左右方向に向かせる。

 動きを確かめてみると、プレイヤーの操作ランナーの動きによってコロコロと待ちランナーの向きが変わる。いいんじゃないだろうか。

2012/09/08:アンドゥ
 やっぱりこういう系統のパズルにはアンドゥは必要だろう、という事で、アンドゥの機能を実装する。

 一手戻しは、3年前に作成した「フルーツミラージュ」とほぼ同じで、面のはじめとランナー交代時の面データをそっくり配列変数に格納して、アンドゥ時に覚えてあった配列変数から面データを戻す。

 今回はさらに、アンドゥした面データを元に各ランナーの座標をランナー用の配列変数に格納し直す。これで理屈上はうまく行くはずだ。

 いざ試してみると、アンドゥ時にプレイヤーの向きがおかしい。

画像

 ああ、面データにはランナーの向きに関する情報はないから向きは変更してないんだった。とりあえずこの辺りの対策は後回しにしておこう。


継走迷路 製作過程 その2