マウス用に作ったゲームをスマホで動かす

ブラウザゲームを開く人の多くは、スマホから開きます。それはわかっていたのに、Salt & Stone（岩だらけの何もない島で街をつくり、内海を越えて交易するゲーム）はマウス前提で作っていました。カメラも、建物の配置も、選択も、すべてマウスイベントに頼っていたのです。

スマホでは何ひとつ動きませんでした。マップをスクロールすることも、何かを置くことも、選ぶこともできません。経営ゲームは見ただけでは操作方法がわからないので、マップを動かせなかったプレイヤーはそのまま閉じてしまいます。

これがないと何も始まらない1行

いまはポインターイベントを使っていて、マウスもペンも指も同じ処理を通ります。ただ、それだけではスマホでは何も変わりません。ブラウザのせいです。

ブラウザは標準で、1本指のドラッグをページのスクロールに、2本指のドラッグをページのズームに使います。ゲームの canvas には、ジェスチャーがキャンセルされたという通知が届くだけです。直し方は、canvas に touch-action: none という CSS を1行足して、ここでのタッチはページ側で処理するとブラウザに伝えることです。これはスタイルシートに書く必要があり、あとからスクリプトで設定しても間に合いません。

指にない3つのもの

どれにも専用の答えが要ります。マウスの操作に1対1で置き換えても、うまくいきません。

ホバーがない。 マウスなら、クリックする前から建物の「ゴースト」がポインターについてきて、その場所に置けるかどうかを見せてくれます。指は触れるまで、どこにもありません。そこで、建物を選んだ状態ではゴーストをドラッグして、指を離すと配置されるようにしました。確定する前に、建物とそこに収まるかどうかが見えます。タッチ画面でホバーにいちばん近いのは、このやり方です。

指ではスクロールと狙いを同時にできない。 マウスならポインターとマップを別々に動かせます。建物を持っているときは、1本指で狙い、2本指でスクロールとピンチ操作。何も持っていないときは、1本指でマップが動きます。みんな最初にそれを試すからです。

ホイールも右ボタンもない。 この2つは、建物の回転と、建物を手放す操作に使っていました。タッチでは56ピクセルのボタン2つになり、何かを持っているときだけ出てきます。それ以外のときに画面をごちゃごちゃさせないためです。

画面の幅ではなく、端末の種類を見る

ボタンも大きくする必要がありました。よくあるのは画面幅のメディアクエリですが、今回はどちらのケースでも逆の結果になります。タブレットは幅1024ピクセルあっても指で押せる大きさのボタンが必要で、パソコンの細いブラウザウィンドウには必要ありません。

そこで、ウィンドウの幅ではなく、メインのポインターが coarse（指のような粗い入力）かどうかでサイズを切り替えています。タッチ端末では、ドックのボタンが28から46ピクセルに、建物カードが56から84ピクセルになります。

スマホ向けのルールがもう1つあります。横向きのスマホは背が低いので、画面の高さが520ピクセル未満なら、建物トレイは自動では開きません。開くと画面の半分以上を覆い、建てる場所を選ぼうとしている町の部分まで隠れてしまうからです。

アクションゲームでも同じ教訓

Husktide は別の問題を抱えていました。16:9の固定の枠に描画して、その枠を画面に合わせて拡大縮小していたのです。スマホを縦に持つと、画面の真ん中に帯が1本あるだけで、上下は真っ黒。ゲームが使えていたのは画面の26%だけでした。

修正では、ゲームが始まる前に、画面の形から枠の形を決めるようにしました。総ピクセル数は変えないので、レイアウトの寸法はどれもそのまま使えます。縦持ちのスマホでも、いまは99.9%を使っています。

すると、2つ目の問題が見えてきました。すべてをゲーム独自の単位で描いてから縮小しているので、高さ52単位のボタンが、横向きのスマホでは実寸27ピクセルになることがあります。これでは確実には押せません。いまはタップできる要素をすべて、実際の倍率から計算した1つの数値をもとにサイズを決めていて、画面上では必ず44ピクセル以上になります。

ほかのゲームにも言えること

ホバーするポインター、ホイール、2つ目のボタンを前提にした操作系は、指向けに設計し直す必要があります。最後にやるより、最初にやったほうが楽です。最初のテストはいちばん地味なものでもあります。スマホでゲームを開いて、プレイヤーが最初にやりそうなことをやってみてください。

Salt & Stone を遊ぶ。手元の端末でどうぞ。