ぼら猫パズルシステム解説その１ 歩行システムを流用したパズル作り

ウディコンに出すためにぼら猫パズルというゲームをきみのなまえをよばせてくださいで作りました。

このゲームを遊んで下さった方の中でなおかつウディタでの制作に興味のある方に向けたシステム面の話を数回に分けてかかせてもらいます。

まだ遊んでない方はよかったら一度遊んでもらって、このゲームはどう作るかという視点でこの文章を読んでもらえたらと思います。

なお、ぼら猫パズルは非暗号化で公開しているため、興味のある方は遠慮なく中をご覧ください（ただし素材の使用は禁止です）。

では解説記事一回目はあのパズルの描画をするためにウディタデフォルトの歩行システムをどう流用したかを書きます。



パズルのカーソルは、実は主人公の位置にあるのです。
主人公は実はウルファールの画像を仮に設定してあるのですが、「パーティーメンバーを透明に」しています。
そしてパズル実行中は常時主人公の位置を取得し、その座標を基準にした位置にカーソルをピクチャ表示させています。

デフォルトの歩行のシステムはとても便利なものです。
これを自作しようとしたら大変です。
方向キーの入力を監視しないといけないし、マスに来たら止まるとかもしないといけない。
ありあわせの機能を活用して、ずいぶん楽をさせてもらいました。


また、全てのますはマップイベントです。
マップイベントを２５枚並べています。
それぞれにページを５つ設定しています。
イベント画像を５色の正方形に設定して、起動条件となる変数の値によってページを変え、色が変わるようにしてあります。
これまた自作していたら手間のかかるところでした。

さらには、カーソルがパズル範囲から出てしまわないためにはパズル範囲の周囲や足元に敷き詰めたイベントのすり抜けオンオフ機能を使いました。
周囲は通行不可のイベントで囲んだのは言うまでもありません。
それに加えて、カーソルの一部が周囲に食い込まないようにするのも同じ機能を使っています。
カーソルは縦と横に向きを変えますが、透明の主人公の位置はカーソルが横向きなら左側、縦向きなら上側なのです。
なので対策を講じないと、例えばカーソルが横向けの時には右側が周囲の通行不可マスにかぶってしまうのです。
それを防ぐためにパズル枠内、通行可能範囲の右端、および下端に、イベントを並べました。
起動条件を「その時のカーソルの向きを示す変数」にしてすり抜けは不可にし、そのイベントが存在する時だけそちらには進めないようにしました。
また、カーソルを切り替えた時に枠に食い込むような位置にいた場合は、「場所移動」で透明の主人公を隣のますに瞬間移動させました。
何というか非常に泥臭い方法ばかりですが、それらのおかげで非常に簡単に作れました。

このようなパズルを作る時にここまで歩行システムやマップイベントを活用するというのはひょっとしたら珍しいかもしれないので、少し詳し目に書いてみた次第です。

ただ、既存のシステムを流用したことによる弊害もなかったわけではありません。
一番大きいのは、パズル範囲を画面中央に表示できないことです。
ウディタではどの画面サイズを取ろうとも縦・横に敷き詰めるマスの数は偶数です。
なので画面中央に一つのますを表示することは難しいし、奇数マスからなる何かを中央に置くのも大変です。
マップを使うゲームを作った経験のある方は、画面上下の部屋の出入り口などの幅が偶数ますだと偏るので困った方も多いと思います。

一応これには解決方法もないわけではないです。
全ての地形をイベントで配置し、マップが始まる直後に全てのイベントを半歩横へ移動すればいいです。
そのためのコモンも公式コモン集にて公開されていたと思います。

ただ今回のぼくの場合はそれも使えませんでした。
主人公の半歩移動が使えないからです。
マスを選択するためのカーソル移動なのに、カーソル位置がマスにぴったり重ならなかったら話になりませんもんね。

まあシステムを改造して、デフォルトの移動幅を半歩にしながらも停止位置がマスの真上なら強制的にさらに半歩進ませることもできるでしょうけど。
でもそこまでするとせっかく歩行システムを使っている利点がなくなってしまいそうだし、そうはしませんでした。（めんどうだし！）

おかげでパズル画面はわずかに右に寄っています。
そういえば「エフェクト」などを使って画面の表示位置を半歩分横にずらすこともできるのかも、とはちょっと思ったのですが。
でもぼくはエフェクトは苦手なのでやりませんでした。
エフェクトってピクチャ表示と相性が悪いじゃないですか。そうでもない？
今なんとなく思いついたけどウディタの描画演出をするのにピクチャ派とエフェクト派がいるかもしれませんね。
どっちも使いこなせたらそりゃいいけど、片方で事足りるケースが多そうな気もします。
まあぼくだってたまにはエフェクトも使いますけどね。
今回のぼら猫パズルでは・・・うーん、多分どこにも使ってません。

昨年のウディコンでは画像音声部門で高い評価をもらえましたが、こういう手抜きをプレイヤーは見てるかも知れませんね。
ほんのちょっと中央から偏ってるってだけでも、高い緊張感が保てない気はします。
まあ今回のゲームはゆるキャラとだらだら続けてもらいたいから緊張感はあんまりなくてもいいか。


話がそれましたが、それ以外のデフォルトシステム流用による弊害といえば、移動速度のことでしょうかね。
ゲームプレイを続けるとある時からカーソル移動速度を変更できるようになります。
これは主人公の「移動速度の変更」機能を使っています。
でもこれは細かい調整ができなくってね・・・。
通常だと快適なんですが、一つ遅くすると遅すぎてイライラするし、一つ早くすると操作性がすごく悪くなるし。
なので完成間際まで変更画面で「通常以外はお勧めしません」とか書いてお茶を濁していたんですけどね。
でもテストプレイヤーさんに「速いだと操作しにくい！」と残念がられてぼくは目が覚めました。
そりゃそうですよね。せっかく速くできるようになったのにそれが使い物にならないなんてストレスのもと以外の何物でもなく、無い方がましなくらいです。
そこでぼくは本気を出してがんばって、移動速度が速くても誤操作が起きにくいシステムを作りました。
主人公の座標を常時監視して、主人公がマスの真上を通過しようとした瞬間だけ、動作指定で数フレームだけ瞬間的に足止めする、という方法です。
これをすることで、移動速度を速めても意図したのに近い操作ができるようになりました。
ちなみにこれを作るためには使えそうで使えない方法がありましてね。
このブログでも何度か取り上げた、システム変数の「主人公が移動中？」というやつです。
鏡コモンを作る時に詳細にみた通り、この変数は主人公がマスの真上にいるのかどうかを判定できるんですけどね。
理屈上ではぼくがわざわざ座標を取得してやっているのと同じことを判定できそうなのですが。
けれどもこれは移動速度が速い連続移動中はマスの真上も瞬間的に素通りしてしまうんです。
それを知っていたので使いませんでした。

そういうことを思うと移動っていったい何だろうと考えてしまいます。
移動速度というのはマスからマスへ何フレームかけて到達するかなのでしょうかね。
その速度で移動開始をしたら、１フレームごとに何ピクセル移動するかが決まっているんでしょうね。
そしてキャラの瞬間瞬間の厳密な座標によって、キャラが今の瞬間いるマスがどこかとか、マスの真ん中にいるかとか、決まるんでしょうね。

少し話がそれるけど、昔習った数学の問題を思い出しまいた。
「たかし君が時速Aキロで池の周りをまわって、１０分後にスタート地点にいる確率はいくらでしょう？」
これ、正解はなんと０％なんですって。これにはびっくりした！今でも忘れません。
たまたまそこにいることだってあるだろうと思うんですけどね。
よりによって、一ミリもたがわず、その瞬間にその場所にぴったりといるということなんて、もう限りなく０に近いくらいありえないことらしいです。
そうだとするならば、そりゃあマスの真上を瞬間的に通過していくキャラを、１フレームに一回しか判定されないシステム変数が捕捉できる可能性は低いのかもしれませんね。
そう思うと１フレームって限りなく瞬間に近い概念と思っていたけれども、移動距離との関係でいえば全然瞬間なんかじゃないんですね。

１フレームって、意外と粗い。
これは今回のぼら猫パズルの制作で身に染みたことであって、これ以外の所でもまた出てくる命題です。
それについてはまた明日とかに書きます。

一回目の今回は、パズルゲームであってもデフォルトシステムをフル活用したということを書いてみました。
書き忘れていることもあるかもしれないけど。
興味のある方は参考にしてください。
質問もお待ちしています。

それと全然関係ない話ですが。
今作で一つだけお借りしたコモンがあります。
表記の義務はなくスペースの都合もあってゲーム内などでは表示しませんでしたが。
ひげさんの文字表示拡張コモンを公式コモン集よりお借りしました。
制作に興味のある人しか見ないだろうこの場を借りてお礼申し上げます。
ありがとうございました。
ゲーム開始直後にタイトルが上から降ってきてプルプルなるのにこのコモンを使っています。
おかげでかわいらしい演出ができました。

では、続きはまた次回ということで。