Fluchthelfer の記録アーカイブ

AIの変換処理を磨き込む方針をやめ、「絵の仕上げは人の手、制限のチェックは機械」という分業に切り替えた。

自動補正を重ねるほど別の崩れが生まれ、手で直す方が速いと分かったため。

自動化の価値は素材と判断材料を作るところまでで、絵の最終品質は人の目と手の領分。その境界を引き直した途端、完成まで一気に進んだ。

タイトル画面の上に空を継ぎ足して、カメラが壁を見上げながら昇っていく演出を組む。

作者クレジットの隣に、一緒に作っている相棒AIの似顔絵を小さく描き込みました。この遊び心はアリだと思いますか?

「シミュレーションで動かす」と「絵で見せる」を行き来した末に、両方のいいとこ取り——物理で計算して、絵で見せる——に落ち着いた。

揺れの計算がいくら正確でも、画面上の数ドットでは情報が潰れる。発生源の物理は捨てず、伝え方を絵の表現力に委ねた。

シミュレーションの価値は「動きの情報を作ること」で、それを画面に伝える手段は別問題。細部が潰れるなら伝達側を絵に替えればいい。もう一つ、配色の不具合は形の不具合に見える(ちぎれて見えた)ので、疑う順番を間違えないこと。

夜の画面を土台に、本番ステージの構築へ。

動くドットが尾を引く実機液晶の残像を、「味」として許容するか、抑える方向で設計するか。

感触の微調整に入る前に、一度立ち止まって物理の更新レートそのものを安定させる工程を挟んだ。

手触りが核のゲームでは、測る土台が揺れたまま数値を調整しても意味がないため。

プレイヤーの体感報告は正確な計測データだった。感覚と理屈が食い違ったら、どちらかを疑う前に計測で裁定する。そして遊び比べから「操作が忙しい=補正し続ける必要がある方が、上達の余地があって面白い」という設計上の発見が出た。不具合調査が結果的にゲームの方向性を決めた。

安定した土台の上で落下・上昇の気持ちよさを再調整し、本番ステージの構築に入る。

構想段階から、動くもので手触りを確かめる段階に進んだ。

操作の手触りがこのゲームの面白さの中心なので、絵や物語より先に検証すると決めたため。

ツールの挙動を推測で扱わず中身まで確認しながら進めたことが、不具合の切り分けと方式選びの両方で効いた。手触りが核のゲームでは、数値調整の前に「方式の構造が狙いと合っているか」を見るのが先だった。

落下の速さをわずかに強める調整を入れて、もう一度手触りを確かめる。

「思い通りに止まれない操作」は、遊びの魅力として伝わりそうですか?