Unity横スクロールアクション制作記録：操作とカメラを直す

技や演出を足す前に、人物を思った方向へ動かせるか、次に乗る床が見えるかを直す必要がありました。 横スクロール探索アクション「錆都の潜行者」では、試遊から「カメラが動いて酔う」「通れる場所が分かりにくい」という指摘がありました。

この記事は、操作と画面を直した制作記録です。完成ゲーム一式を組み立てる手順ではありません。数値は本作の人物寸法や地形に合わせたもので、そのまま別のゲームの正解になるものでもありません。

錆都の潜行者を直接遊ぶか、操作と三区域の紹介を見るから開始できます。

区域が変わると、同じ入力でも動きが変わっていた

最初の搬送路では、斬撃の向きを保持しながら後退できます。ところが昇降塔と炉心では、一部の操作が以前の仕様のままでした。回避の終了後に残る速度や、次の攻撃を予約できる時点も揃っていませんでした。

敵や足場の違いを覚える場面で、操作まで覚え直させていたわけです。三区域に共通の操作設定を適用し、違いは敵の役割と経路へ持たせました。

予約された攻撃は通常の斬撃です。早くから押しておくだけで槍弾きや返弾まで成立するようにはしていません。被害・中断・再挑戦では予約を消します。入力を受け付けやすくすることと、敵の攻撃に合わせる判断を自動化することを分けました。

追従を遅くする前に、カメラを動かす条件を変えた

人物の位置へ毎回追従すると、向き直りや低い跳躍でも背景が動きます。本作では、画面内の一定範囲で動く限り、カメラの移動先を変えない形にしました。

横方向の余白は2.3、縦方向は2.5です。余白を越えた時に追従先を更新し、区域の範囲へ制限してから、0.32秒を指定したSmoothDampで移動します。速度に応じた先読みと、戦闘のカメラ揺れは入れていません。

// 本作のFollowCameraから。追従先を決める部分の抜粋。
// actorが余白を越えたときだけcurrentを動かす。
public static float FollowAxis(
    float current, float actor, float margin, float min, float max)
{
    if (actor > current + margin) current = actor - margin;
    else if (actor < current - margin) current = actor + margin;
    return Mathf.Clamp(current, min, max);
}

低い跳躍で上下に動かないことと、高い足場から下の敵が見えることは、別々に確認しました。 復帰時は安全な出発位置へカメラも戻します。中断・敗北・区域完了では追従を止めます。これらの検査を通しても、人が酔わないことを保証したとは扱いません。

足場の上面だけでは、通れる場所が伝わらなかった

床の絵があっても、その下を通れるのか、側面にぶつかるのかは分かりません。最初の足場では、歩いて側面へぶつかる、跳んで上へ乗る、背景の支柱を横切る、を別々に操作して確認しました。

画面では、床上面の縁と、通れない側面を描き分けています。背景の支柱は暗く引き、通行判定のある床と同じ強さにしない方針です。上段経路では人物だけを大きく見せるより、下の敵・射線・着地点が同時に入ることを優先しました。

操作を揃えると、以前の検査操縦も変わる

回避後の余分な滑りをなくしたところ、炉心の検査操縦が中間棚へ着地し、高い棚の側面へ歩き続けました。ここで壁を消したり、回避距離を延ばして検査を通したりはしていません。

実際の接地と移動停止を確認し、通常の跳躍で登り直す操縦へ直しました。目的の足場へ到達する条件はそのままです。最初の検査は454件中4件が失敗し、旧仕様を期待する2件、攻撃方向を渡していない検査1件、この移動の検査1件を分けて記録しました。

修正後はUnityの編集用454件、実行時79件が成功しています。短い横画面で保存案内が開始ボタンに隠れた問題も見つけ、開始ボタンの下へ移しました。保存なし・保存拒否・帰還済みと、画面の高さを変えた状態で重なりを確かめています。ただし、これはブラウザの操作や、人の初見理解を代わりに証明する数字ではありません。

ビルド成功でも、そのまま採用できなかった

公開候補の最初のビルドは337.430秒で終了し、エラーは0件でした。ただし、未コンパイルの変更を含むという警告が出ています。再コンパイルの窓口は「更新不要」と返しましたが、Editorが読み込んでいる設定コードを調べると、旧版の定数が残っていました。

コンパイル中でもエラー中でもない、という値だけでは反映を確認できませんでした。 アセットの再取込みとコンパイル要求を行い、読み込まれた設定コードが新しい版へ変わったことを確かめてから、増分ビルドをやり直しました。こちらは4.263秒で、未コンパイルの警告はありません。フル相当の最初の所要と、増分の所要を混ぜて短く見せないよう記録しています。

最終配信で、全編と連続戦闘を確認した

公開前には、炉心の区画名が戦闘前から番人名になっている表示も修正しました。実画面と既存の実行時検査で区画名を確かめ直しています。

画面修正後の最終ビルドは308.879秒、Brotli配信4ファイルで10,804,609bytesでした。前節の4.263秒の候補とは別です。この配信でPCと純タッチの各51地点を新規開始から通し、三区域・能力取得・実保存からの再読込・番人三形態・帰還を確認しました。「炉心をもう一度」と、開始画面の「最初から」の取消し・確定も分けています。

純タッチは再読込前の履歴も累積し、512イベント、最大2指、キー入力0。両入力で画面例外と意図しない中断はありませんでした。保存の破損・未知版・別タブ競合・読書き拒否など8条件、縦向きの回転案内と停止、横へ戻しても勝手に再開しない動作も確認しています。

性能は、Windowsの表示ありChrome、RTX2080Ti/D3D11、PC上の2つの画面サイズで、各場面を60秒以上ずつ3回測りました。fpsは3回の平均値のうち最低、P95は3回のうち最大です。

混成は、確認用の有効な炉心入口の保存から、地上5秒→通常の跳躍・回避で上段へ退避→射撃を避け続ける経路です。盾兵・突進兵・射撃兵は生存したままですが、最大の地上混成へ60秒留まる検査ではありません。番人は全編操作で得た実保存から復帰し、第三形態の斬撃・射撃・床の過熱を動かした状態で測りました。耐久や攻撃周期は書き換えていません。

12回すべてで平均55fps以上・P95 25ms以内を満たしましたが、最長約18.3msの間隔もありました。 ブラウザのRAF間隔であり、GPUの処理時間ではありません。性能測定だけはページの焦点状態をエミュレーションし、通常の中断・全編検査とは分けています。812×375もPC上で、操作は両幅ともキー入力です。

ローカル配信の起動は、新規ブラウザ・HTTPキャッシュ無効の12回で1.46〜1.76秒、同じブラウザでの再読込は0.74〜0.89秒でした。配信元はno-storeで、再読込をHTTPキャッシュの効果とは断定していません。インターネット経由の所要や実スマホの発熱・快適さ、人の初見理解を、この数字から保証することはできません。

個別の成功から、全編の流れへ戻る

制作中は、弾き、返弾、背後への回り込みなどを一つずつ試しました。個々の操作が通るほど検査は増えましたが、それだけでは戦闘・移動・休息のつながりは評価できませんでした。

旧版のPC操作では、標準の地上攻略が混成戦で敗北した一方、上段経路は三区域・番人の三形態・帰還まで通過しました。どちらも既知の状態を読む自動操縦です。この結果から、人の成功率や、上段経路の方が面白いとは結論づけていません。

公開版の仕上げでは、新技の追加を止めました。開始から帰還までの入力、保存と再読込、敗北からの再挑戦、実際の画面と性能を同じ候補版で揃えることを優先しました。次に何をしたくなるか、失敗した後に何を変えようと思うかは、通行できるかとは別の確認として残します。