もぐりの日記

雑日記

Unity 1 week game jam [2] 参加記録 エターナルよ永遠に

Unity 1 week game jam お題 "2" でエタった記録です。

つくりたかったもの

2面で進めるプロポーズノベルゲーム。 f:id:sumogri:20210516143047g:plain

交際記念日の今日、プロポーズすると決めた男女。 煮え切らない2人が、プロポーズするまでの1時間を描いたゲーム。

シナリオテキストはこちら。 https://gist.github.com/sumogri/3781d9d1055dc6898945760c50e77504

作業ログ

スケジュール

  1. シナリオ制作 (1week)
  2. システム制作・組み込み (2week => エタ)

本来は、仕様シナリオ5日・実装2日の予定が、もろもろ盛大に伸びた.

遅延原因1 仕様のぼんやり具合・残り続けた致命傷

初動で"2面以上ノベゲ"というアイデアをすぐに決め、シナリオを練った。

草案.

  1. 過去作"Exit with……"チックな、CoCライクな2面探索
  2. 選択肢が出るたびに、画面分割して並列に展開させられるノベゲ

つまりは、草案段階では、シミュレーションに近い内容になっていた。 が、実際にログライン・プロットに着手すると、早々に問題点にぶち当たった。

  1. 2面にする意味。バディものとして、キャラA/Bを同時操作させる理由。つまりは、"ピクミン2"のように、切り替え式にしない理由。
  2. 複数面にする場合、それぞれの面が同時に存在する意味。つまりは、ほかの画面のもつ役割。プレイヤーが、どのようにその注意リソースを向ければよいのか?

特に、2については、決定稿でも解消できていない致命傷である。

左右をつなげて読ませる、シンクロ的な面白さを狙って緩和を狙ってはいるが、結局は、体験としては2本を同時に読ます必然性・インタラクションに欠ける。 将棋の2面差しなど、多数の画面を使用する遊びは、結局は注意リソースの分散による難易度上昇がキモであると考える。

その点、本企画は、"ノベルゲーム"という、集中・注意をいかに向けさせるか? が体験に落とし込むのが難しいジャンルで、あえてリソースを分散させる手を取るチャレンジであった。 シナリオ上、同じ時系列の2人を動かすので、"それぞれの話がリアルタイムにシンクロする"というある種のカタルシスは狙え、完成さえしていたのなら実現できていたと思う。 (ただし、これは視点を切り替える群像劇系のADV、近年では十三機兵防衛圏などでも十分に成り立つ遊びであり、画面を分ける意味とするには、やはり少し足りない印象。)

また、実装段階でもやらかしたため、作業量が単純に2倍になるなど、ことに"1週間"の企画としては、洗練すべき課題を抱えていた。

遅延原因2 シナリオ量に比例する実装

過去の自作ADV"Exit with……" では、"部屋"ごとにテキストを持つ仕様であった。 そのため、

  1. 部屋のシリアライズオブジェクトに、"部屋に入った時のテキスト"・"初回探索したときのテキスト"・"2回以上探索したときのテキスト"などを記入。
  2. シリアライズオブジェクトを元に、部屋に入った時のテキスト表示・BGM・画像の切り替えなどを作成。

つまりは、"部屋"オブジェクトに基づく、データドリブンな実装、データ増やして、部屋のゲームオブジェクト足せば、簡単に1部屋ができていた。

一方の今回は、シーンごとに、スクリプト上で直書きに近い実装になっている。 これは、それぞれのシナリオで柔軟にスクリプトを呼べる状態を担保しようとしてのことであった。 が、この方針では、当然の結果として、"シナリオをコピペれば、とりあえず最低限動く"というような状態にはならない。 "データを用意したうえで、それをさばく専用のメソッドをこしらえる"必要ができた。

これが、べらぼうに時間を食った。

たとえば、企画していたシーンに、"チキンレース対決"があった。これを実装したメソッドが下記になる。 https://gist.github.com/sumogri/6e7b79fc6557e1e15ae760dfaf3a2e32

チキンレースシーンは特に分量が多い方のシーンではあるが、それでも平均値の130%程度である。 これが男女それぞれ10シーン近く存在した。(以下のように、10:00のシーンから、10分刻みで選択肢による分岐が発生する仕様。) f:id:sumogri:20210516152126j:plain

このように、スクリプト作成する方針では、オブジェクト操作やメソッド操作がやり放題であるメリットがある。 一方で、それのみに頼ると、量産に向かない。特に1週間では厳しい結果になる。

個人的には、"シナリオ"のmarkdownをそのままソースとして使うことができればベストでなかろうかと思う。 1枚の"本"を、アドレスとステート管理して読む。さながらゲームブックである。

遅延原因3 アニメーション実装方針のミス

本企画でのアニメーションは、たいていスプライトイメージのステートをポチポチして、手作りクリップを作っていた。 それも、

  1. シナリオ上の全シーンを、一つのAnimationControllerで管理。
  2. 各シーンで単純なキャラの出し入れから、個別に作成。

していた。このため、

  1. コントローラー内の遷移がぐちゃぐちゃ。ほかのアニメーションが全く無関係なオブジェクトのパラメータを拘束して、予期せぬ挙動祭りに。
  2. 簡単な操作もクリップから作るため二度手間。

という問題が発生。つまりはつらい。

対策として、

  1. アニメーションコントローラーをつけるなら、なるべく独立したオブジェクト単位に区切る。予期せぬ動作により、ほかのアニメーションにぶっ壊されるので。
  2. オブジェクト間の調和は、タイムラインなど、より包括的な仕組みを使う。

があげられる。 これ自体、まぁまぁ出会ったことのあるトラブルであったが、毎回なんとなくお茶を濁していた点を、バスっと切られた形であった。 急がば回れである。

まとめ

  1. 多面ノベゲの可能性と、ある程度形になったとき、それでも問題になる点を洗えた。
  2. 物量をアテにしてはいけない、物量が欲しいものはだいたいエタる。
  3. 3週間かけてエタったのでつらい。

今後の課題

  1. 物量によらない、システム面・体験の面からの発想法の訓練。キャッチアップ。
  2. そのうえで、エゴを乗せる逆算の組み込み。
  3. ちゅーのを、締め切りに間に合わせる計画性。