20時間超の物語をVRで！『ALTDEUS: Beyond Chronos』の制作を支えた”Uranus”の制作過程と機能紹介 [CEDEC2021] / Introduction of ALTDEUS' VR ADV tool "Uranus", CEDEC2021

2021/08/25、CEDEC2021にて行われた発表の講演資料です。
動画を含むスライド等に一部注釈を加えています。

20時間超の物語をVRで！『ALTDEUS: Beyond Chronos』の制作を支えた”Uranus”の制作過程と機能紹介
https://cedec.cesa.or.jp/2021/session/detail/s6058637b527da

Transcript

1. 20時間超の物語をVRで！ 『ALTDEUS: Beyond Chronos』 の制作を支えた ”Uranus”の制作過程と機能紹介
 MyDearest株式会社 中地 功貴 / 下嶋 健司 / 増谷 海人
2. 本資料について
 本資料は発表後すぐに SpeakerDeckにて公開いたします。 本講演に関するSNS投稿は大歓迎です。 #CEDEC2021 と #アルトデウスBC で ツイートしてもらえると嬉しいです！ W IP
3. PV (動画)
4. VRインタラクティブストーリーアクション • 「VRゲームならではのインタラクションと物語 体験」を両立した作品 • 2020年12月リリース • Oculus / Steam / PSVRで発売中 🏅ファミ通・電撃ゲームアワード2020 　　アドベンチャー部門 最優秀賞 🏅Oculusストア内ユーザー評価 世界No.1 　　 (Road to VR調べ) ALTDEUS: Beyond Chronos（アルトデウスBC）
 W IP
5. 長編物語の制作を支えたイベントエディタ 『Uranus』の制作過程と機能について アルトデウスBCの20時間以上におよぶ長編の物語の制作は、前作 に当たる『東京クロノス』の開発時に生まれた"Uranus"というイベント エディタの存在によって支えられています。 本セッションでは、"Uranus"の制作過程と機能紹介を中心に、アルト デウスBCの制作過程を余すことなく紹介します。 本講演で話すこと
 W IP
6. 1. Uranusの紹介
 2. Uranusの誕生と変遷
 3. シナリオデータの変換ワークフロー
 4. Uranus内部的な仕組み
 5. デバッグ機能
 6. CI環境
 アジェンダ
 W IP
7. 登壇者紹介

8. 登壇者について - 中地 功貴
 W IP W IP VRエンジニア 中地 功貴 / Nakaji Kohki 上級バーチャルリアリティ技術者 (日本VR学会認定) 著書: 技術評論社『VRエンジニア養成読本』共著 作品: 『Crevasse』『至近距離ガールVR』 2020年1月にMyDearestへ入社し、 『アルトデウス:BC』のインタラクション の実装全般とCI整備を担当 Twitter: @nkjzm
9. 登壇者について - 下嶋 健司
 W IP W IP リードボードゲーマー 下嶋 健司 / Shimojima Kenji 2018年４月にMyDearestに入社し、 『東京クロノス』『アルトデウス：BC』 のリードプログラマー的な何かを務める。 個人製作も昔から継続してたりしてなかったり。 作品：『アニュビスの仮面』『ウルタールの化け猫』 『ジュン少年の事件簿』等 Twitter: @ookumaneko_XD
10. 登壇者について - 増谷 海人
 W IP W IP 放浪エンジニア 増谷 海人 / Masutani Kaito 2018年にMyDearestへ入社し、 『東京クロノス』『アルトデウス：BC』 のプログラマーとして活躍。 幼少期からプログラミングに興味を持ち、 個人でのゲーム制作を日々続けている。 Twitter: @(休止中)
11. イベントエディタ”Uranus”で出来ることを、動 画で分かりやすく紹介します。 • Uranusとは • Uranusで作成したADVパートの紹介 • Uranusエディターの紹介 1. Uranusの紹介

12. • VRADVを作る為の システム
 
 • 会話を作る為の専 用エディター
 
 • GUIベースで誰でも 作れるのが目標
 Uranusとは？

13. Uranusで作成した シーンのデモ動画
14. Uranusエディターデモ動画

15. エディタ上のデモ動画
16. Uranus誕生までの経緯と、東京クロノスからアル トデウスBCへの変遷を紹介をします。 • シナリオエディタ作成の経緯 • Excelベースのプロトタイプ • Uranus ver 0.1が生まれるまで • Uranus ver 0.2で追加された機能 2. Uranusの誕生と変遷

17. Uranusが出来るまで
 東京クロノス～アルトデウスまで

18. 作るきっかけ
 ～東京クロノス編～

19. 会話メインでプレイ時間10時間以上

20. だが人数は少ない
 プロデューサー
 音楽
 ディレクター
 プログラマー

21. 可能な限り効率を
 求める必要がある

22. 楽に作れて調整しやすい
 開発環境を作ろう！

23. 要素の洗い出し

24. • カメラ設定 • キャラ操作 • テキスト表示 • 背景指定 • サウンド指定
 最低限必要な要素の洗い出し

25. 作らなくて良いなら
 作りたくない！

26. 既存のシステム調査

27. • RPG等のゲームではよくある
 • 独自言語の場合も
 • 敷居が高い
 – 初心者の手は借りられない
 スクリプト言語

28. • NScripter、吉里吉里、等
 • 3D空間前提で使うのは試行錯誤が辛い
 • こちらも敷居が高い
 – 初心者の手は借りられない
 ノベルゲーム固有スクリプト

29. • GUIベースで制作
 • 方向性は近い
 • 3Dの敷居が高い
 – 初心者の手は借り られない
 ノベルゲーム開発ソフト
 https://b.tyrano.jp/
 https://tkool.jp/lngmv/ 

30. • Unityのエディター拡張で制作
 • Unityで完結するのは良い
 • 3Dの敷居が高い
 – 初心者の手は借りられない
 Unityアセット
 Fungus
 https://assetstore.unity.com/packages/tools/game-toolkits/fungus-3418 4
 宴
 https://assetstore.unity.com/packages/tools/game-toolkits/utage3-unit y-text-adventure-game-engine-version3-80727

31. 中々これって言うのが
 無い・・・

32. じゃあ 作ろうか！
33. ゲーム業界皆大好き
 Excelベース
 （諸説あり）

34. 宴に近い形式で試す

35. 作ってみたプロトタイプ

36. 結果・・・

37. 「「「Excel辛い！！」」」

38. 何が辛いか？

39. Excelを眺め続けるのが辛い

40. Excel→3D空間のイメージが難しい

41. Excel⇔VRの行き来が面倒

42. 「 Excel見たくない・・・
 _:(´ཀ`」 ∠):_ 」

43. １フレーム内で完結する2Dゲームなら 想像が効かせ易いが

44. 3D空間、かつVR内でやるにはイメージ と調整が難しい

45. 初心者の手は
 借りられない

46. じゃどうしよう？

47. Unityのタイムラインは？

48. • 項目が多くなりそうで辛そう
 • 入力に合わせたテキストや演出に合わなさそう
 タイムライン感想
 https://docs.unity3d.com/ja/2018.4/Manual/TimelineSection.html 

49. 初心者の手は
 借りられない

50. じゃどうしよう？

51. 独自ツール作るか・・・

52. 一回要望のヒアリング

53. • 基本的にはUnity内で完結したい
 • GUIベースが良い
 • その上でボタンポチポチするだけにしたい
 • 1テキストウィンドウ毎に演出を付けられる様にした い
 • 初心者の手を借りられるようにしたい
 ヒアリング結果

54. ツールのGUI調査

55. https://b.tyrano.jp/
 ティラノビルダー

56. 素晴らしすぎる

57. これをUnityかつ
 VRADVに落とし込む

60. • Excelの仕組みのGUI化
 • １個１個が「コマンド」
 • ボタン１個で追加
 • 上から順番に再生する
 • 選択したコマンドの状態をプ レビューしたい
 
 
 方向性

61. 大体同じ方向性

62. 作ってみた

64. ここまでが前作
 東京クロノス

65. Uranusエディター 
 ver 0.2
 の機能詳細

66. イベント設定画面

68. イベント引き継ぎ機能

69. • 尺の都合で会話を別ファイルで区切る時がある
 • その際、配置位置を前のイベントと合わせたい
 • それを手動でやるのはそこそこ面倒
 • 自動化最高
 イベント引き継ぎ機能

70. イベント引き継ぎ機能のデモ動画
71. プレビュー系

72. キャラ状態リスト
 選択したコマンド時のキャラ状態リスト

73. パラメーター
 シミュレーター

74. • 分岐のプレビューを手軽に確認したい
 • フラグや変数を変えると即座に反映したい
 • 選択肢の結果も手軽にプレビューしたい
 パラメーターシミュレーター

76. シミュレーター結果がすぐに プレビューに反映されるデモ動画
77. 改善方法

78. 専用のslackチャンネル

79. 気になる事や要望が あれば些細な事でも すぐ書いてください これを何度も呼びかける

80. 何回も繰り返した事により
 意見を引き出せたが、
 まだまだ足りてはいなかった

81. Uranus Editorによりイベントシーンの 作成を比較的簡単かつ手軽にできた。 機能自体は改善を続けており、 今後もまた作り続ける予定ではあります 2. Uranusの誕生と変遷【まとめ】

82. 長編シナリオのテキストを様々なデータ形式に 変換するまでのワークフローを紹介します。 • GSS（GoogleSpreadSheet)ベース • Doc→GSS→ゲーム用データ変換 • Unity側からデータ取得 • 台本作成のワークフロー 3. シナリオデータの変換ワークフロー
 W IP
83. Uranusへ持ってくるデータの話

84. 表示されるテキストのデータ

85. データ変換の流れ
 テキストファイル GoogleDocument GoogleSpreadsheet ScriptableObject
86. • GAS(Google App Script)
 で変換
 • 変換先はシナリオと
 イベントのベースになる
 「字コンテ」ファイル
 • 書式ルールは大体
 クロノス準拠
 
 シナリオのGoogleSpreadSheet(GSS)化
 GoogleDocument （シナリオ） GoogleSpreadsheet （字コンテ）
89. セリフ コメント イベント区切り 選択肢 イベント毎に別シート
90. 字コンテGSS爆誕

91. 字コンテ？
 • シナリオに合わせて演出指示等が
 書いてあるファイル
 
 • シナリオは基本文字情報なのでそれのゲーム演出 への落とし込み
 
 • 絵コンテの文字版

92. • シナリオ/イベント系のマスターデータ扱い
 
 • これを元に色々なデータ書き出す
 – テキスト一覧
 – イベントファイルのテンプレ
 – イベント遷移一覧
 – 選択肢データ
 – 収録台本
 字コンテGSS

93. 字コンテGSS テキスト一覧 演出遷移一覧 イベントファイルの元(沢山) 台本（キャラ毎と通し）
94. マスターデータ運用
 の理由

95. 遷移の流れを追える、
 かつ設定を自動化
 したかった

96. イベントファイルに
 テキストが既に入ってるテン プレが欲しい

97. 台本制作の
 自動化がしたい

98. 書き出したデータ例

99. テキストデータ

100. イベント遷移

101. イベントファイル

102. Unityから
 GSSデータの獲得

103. Unity Google App Script リクエスト ダウンロード Scriptable Objectに変換
104. GAS側のエクスポート用意
 • リクエストが飛んで来たらデータを変換して渡す
 
 • イベントファイルと一部その他はCSV形式
 
 • それ以外は基本JSON形式

105. 実際にエディターで落とす

106. DL後に変換して保存

107. 台本作成

108. 通し台本

109. 抜き台本

110. 台本のテンプレートファイル用意

111. 台本作成時の流れ
 セリフとコメント抜出 テンプレートをコピー 字コンテGSS 台本テンプレ 抜き出したテキストを 入れ込む 新規台本 GASでゴニョゴニョする

112. フォーマット
 イベント毎に区切り、概要入れる

113. 抜きと通しの差
 • 特定キャラ 
 • コメントふくまない
 • 全キャラ
 • コメントふくむ
 抜き台本
 通し台本
 物量以外にはそんなに差は無い*

114. 問題点

115. GSSのフォントが
 超限定的

116. 縦文字が死

118. 変換時に縦に見える様に フォーマットは
 して見た・・・

119. 限界がありすぎる

120. 結果起きた事
 字コンテGSS 新規台本 Excelで台本編集 形式指定 ダウンロード
121. orz

122. GASの最大稼働時間は 30分
 （GSuiteの場合）

123. アルトデウス：BCは
 シナリオが膨大

124. ふくれ上がると
 予想した予想量を
 圧倒的に上回る

125. 台本変換が30分で
 終わらない orz

126. 作る台本を
 分割して対応

127. 1/3 2/3 3/3
128. orz

129. 想定以上の物量時の
 事前測定はやりましょう
 *当たり前の事をちゃんとやれ事案

130. GSSベースの仕組み
 全体的に良かった所

131. 共有と同時編集が
 楽だった

132. シナリオ、マップ、
 遷移先がセットに
 なってるので追いやすい

133. Unityからエディターでポ チっとして更新は楽

134. 台本自動作成は人権

135. 台湾にいながら
 システム作れた

136. GSSベースの仕組みを作る事で共有可能な色 んなデータの元を用意し、作業の効率化を達成 出来た • GSSのマスターデータを作成する • マスターデータからゲームデータに変換 • Unity側からデータ取得 • 台本作成の自動化 3. シナリオデータの変換【まとめ】

137. 生成された演出データがゲーム上 で動作するしくみを紹介します。 • Uranus の中身 • メインルーチンの実装 • コマンドの実装 4. Uranus内部的な仕組み

138. Uranus の中身
 • 役目：「演出ファイル」と「コマンド」を
 順番に実行する
 ◦ 演出ファイルには「コマンド」のリストがある
 ▪ 上から順番にコマンドを実行する
 ◦ 演出ファイルを実行すると結果が出力される
 ▪ 結果によって次の演出ファイルを決定

139. メインルーチンの実装
 ゲームスタート
 ↓★↓
 演出データロード ＆ ロード待機
 ↓
 必要なアセットをロード ＆ ロード待機
 ↓
 演出実行 ＆ 終わるまで待機 
 ↓
 演出後処理、次の演出データを決定 
 ↓
 ★に戻る…

140. メインルーチンの実装
 • 「処理の待機」が全体的に多い
 • 待っている間、別の処理もしたい (非同期処理)
 ▪ ロード画面の表示
 ▪ プレイヤーの入力受け付け
 ▪ オブジェクトの動作

141. メインルーチンの実装
 • Unity C#のプログラムコードは基本同期処理
 ▪ 関数上の手続き：1フレーム内の処理
 ▪ 手続きをそのまま書くことはできない

142. メインルーチン (前作の場合)
 • Update () 上で擬似的な非同期処理
 ◦ 1フレームごとに何を実行するか分岐させる

143. メインルーチン (前作の場合)
 • Update ()
 ◦ もし演出ロード中なら
 ▪ 演出ロード完了をチェック
 ▪ ロード画面処理
 ◦ そうでないなら
 ▪ もしコマンドが処理待ちフラグがONなら
 – コマンドの処理待ち
 ▪ そうでないなら、以下ループ
 – 次のコマンドを実行する
 – もしそのコマンドが処理待ちを要求したら
 » コマンド処理待ちフラグをON、ループ終了
 – もし次のコマンドがなかったら (演出終わり)
 » 演出をロード、ループ終了
 処理順？ どこから始まる？？
144. メインルーチン (前作の場合)
 • Update () 上で擬似的な非同期処理
 ◦ 1フレーム単位で何をするか書かないといけない
 ▪ 処理順がコード上で読みにくい
 ▪ メンテナンス性に影響
 ◦ コマンド処理は待機あり・なし対応のために
 条件分岐が複雑化

145. ALTDEUS でのメインルーチン
 • async / await ベースの非同期処理
 ◦ await 処理関数 = 処理が終わるのを待つ
 ◦ UniTask を採用
 ▪ Unity 上で async/await ベースの記述を
 可能にするライブラリ
 ▪ Coroutine と似た記述が可能で、より高機能

146. メインルーチンの実装
 • async メインルーチン
 ◦ while (次の演出がある)
 ▪ await 演出データロード
 ▪ await 必要なアセットロード
 ▪ 演出結果 = await 演出実行
 – await コマンド演出処理
 – return 演出結果
 ▪ 演出結果に応じて次の演出を決定

147. メインルーチンの実装
 ゲームスタート
 ↓
 演出データロード
 ↓
 アセットロード
 ↓
 演出実行
 ↓
 次の演出データロード
 ↓
 …
 ←これと同じ順番で処理を記述できた
 
 • 見やすい
 • コードメンテナンスしやすい
 • await 中は他の処理を並列で実行で きる

148. • コマンドが行う処理
 ◦ 演出ロード時
 ▪ ロード処理
 – 演出に必要なアセットなどを登録
 ◦ 演出中
 ▪ 演出処理
 – コマンドを非同期で実行
 ▪ ルーチン処理
 – 単純な順番以外で実行する場合の処理
 コマンドの実装

149. 演出中のコマンド処理
 • while (次のコマンドがある)
 ◦ await コマンドの演出処理
 ◦ IF
 ▪ コマンドが単純な遷移 -> 一つ下のコマンドへ
 ▪ 複雑な遷移 -> コマンドのルーチン処理

150. • テキスト表示コマンド
 ◦ ロード処理
 ▪ テキストIDをロードリストに登録
 ◦ 演出処理
 ▪ ボイスを再生・リップシンク再生
 ▪ テキストを表示
 ▪ await プレイヤーの入力を待機
 コマンド実装の一例

151. • 選択肢コマンド
 ◦ 演出処理
 ▪ await 画面を表示、アニメーション待機
 ▪ 選択肢を選択可能にする
 ▪ await 選択肢が決定されるのを待機
 ◦ ルーチン処理
 ▪ 選択結果に対応するラベルへジャンプ
 コマンド実装の一例

152. 今回の実装でわかったこと
 • async/await の利点
 ◦ 非同期処理と演出処理の相性が非常に良い
 ▪ 待機を含めてその手続きを順に書くだけ
 ▪ 可読性が高い　→　メンテナンスしやすい

153. 今回の実装でわかったこと
 • async/await の欠点
 ◦ 中断処理がかなり面倒
 ▪ async/await では特殊な例外で止める
 ▪ Coroutine より複雑
 
 

154. 今回の実装でわかったこと
 • プログラマー間での知見共有が重要
 ◦ async/await は比較的最近の記法
 ◦ 利用範囲がかなり広い
 
 

155. Uranusエディターで作られた 演出の実行方法を紹介しました • async/await 形式の実装で 演出の手続きをそのまま書ける • 扱いが難しい箇所もあり 情報共有が大切 4. Uranus内部的な仕組み【まとめ】

156. 実機での確認作業の効率化を図って作成したデ バッグ機能について紹介します。 • ゲーム内表示 • ログ表示とログ送信 • デバッグメニュー – イベント再生 – フラグ変指数編集 – 描画設定 – リプレイ 5. デバッグ機能

157. ゲーム内表示

159. FPS 背景 FPS
160. イベントツール
161. 現在の情報 背景
162. ログ表示

165. エラーログはslackに送信
 • 例外情報
 • アプリ情報
 • イベントID
 • スタックトレース
 
 等々を各ハードの実機から 送っている

166. デバッグメニュー

167. デバッグメニューのデモ動画
168. イベント再生機能のデモ動画
169. フラグ/変数編集
 フラグ・変数切替のデモ動画
170. 描画設定
 描画設定切り替えのデモ動画 実機上で解像感を確認できる様子
171. リプレイ
 • 記録開始で保存開始
 • 手・頭・入力を記録
 • イベント毎にファイル 保存
 • リプレイ再生で記録した位 置と入力で強制上書き
 • バグの再現用

172. ・・・基本使われなかった

173. 使われなかった理由
 • 認知が少なかった
 • 間違えて被ってる最中に再生すると酔う
 • 放置してしまうとデータ量が膨大になる
 • 外部テスターに強要は出来ない

174. VR内で使えるデバッグメニューと機能を用意した おかげで実機とエディター両方で楽に テストできる環境を用意できた 5. デバッグ機能【まとめ】

175. VRゲームならでは少し特殊なCI環境と、 その仕組みについて紹介します。 • ビルド環境 • 自動通しプレイ – 東京クロノスの場合 – アルトデウス:BCの場合 6. CI環境
 W IP
176. 東京クロノスの時の問題点
 設定の切り替えを各プログラマのローカル環境で行っていた • 前回うまくいったビルド設定が分からなくなる ◦ 様々なビルド設定が存在した（Defineの切り替えも併用） ▪ Oculus Go (Android） ▪ Oculus Quest (Android) ▪ Oculus Rift (PC) ▪ Steam (PC) ▪ PlayStation VR (PS4) • ローカルの意図しない変更がビルドに含まれてしまう • デバッグのたびに手動で端末にインストールする必要がある
177. 自動ビルド
 アルトデウス:BCでは自動ビルドの仕組みを導入！ • GitHubにpushするとJenkinsのジョブ(処理の単位)が動く ◦ ジョブが動くと自動的にビルドとテストが実行 ▪ プラットフォーム毎 ▪ 設定毎（debud/ staging / release） • ビルド失敗→ ビルドログをSlackに通知 • ビルド成功→ NASと各プラットフォームにアップロード ➡ Pushした数分後にVRHMD実機で動作確認が可能に！
178. 自動ビルド
 成功 失敗 NAS Polling push 社内の物理マシン
179. Jenkinsの流れ
 • 定期的にPollingして実行 • CLIでUnityのメソッドを呼べる ◦ ビルドとテストを実行 ◦ • 結果に応じて後続ジョブが実行 • Slackに通知する（右図） push通知 ビルド結果通知 (Rift/Dev) アップ完了通知 ビルド結果通知 (Quest/Dev) アップ完了通知
180. ビルドスクリプト
 Quest/Devの設定 • ジョブ毎のビルド設定機能 ◦ ScriptableObjectで実現 ◦ Platform / Symbols/ Build Optionsなど • エディタ上でも設定の切り替え等が可能
181. ビルド後の処理（アップロード等）
 • 後続ジョブを実行してバッチ処理を叩く ◦ Parameterized Triggerプラグインで引数を渡す • Oculusだとコマンドラインツールが提供されている
182. 自動通しプレイ

183. 東京クロノスの時

184. 自動通しプレイ

185. 再生して放置

186. 選択肢は？

187. 個別ルート 選択肢 You did it
188. エンディング 選択肢 エンディング
189. 選択肢 本ルート 選択肢に戻る
190. 再生して放置

191. 問題点

192. ハードの自動通しテスト
 • 位置と回転が物理
 • 動かすゲームの場合困る

193. 問題点2

194. 複雑な分岐の
 自動通しテスト

195. 完全なネタバレ

196. 選 選 選 選 選
197. 選 選 選 選 選 選 選 選 選 選
198. 問題点3

199. 手動で更新と起動を
 する必要がある

200. 自動テストを開始する手順
 1. gitプル
 2. Unity起動
 3. Unityで再生
 4. デバッグメニューでテスト開始

201. わざわざ操作する
 必要がある

202. アルトデウス：BC
 の場合

203. 自動通しプレイを自動的に起動する
 バッチでNAS上にある最新ビルドを定期的に自動起動 ➡ Gitへのpushから自動通しプレイまでが完全自動化 NAS Polling push 社内の物理マシン 社内の物理マシン Upload 自動起動
204. 自動プレイ • バッチでNAS上にある最新ビルドを定期的に自動起動 ◦ 3倍速で自動進行してクリアまで進めてくれる • プレイログ/クリアログをSlackに通知 • プレイの様子をOBSでストリーミング配信 ◦ 配信サービスの規約的にOKであるか確証がないので念のため伏せる ◦ Slackで「配信くれ」というとURL教えてくれる ~6:30 ➡ 常に進行不能等の不具合が、自動的に早期に検知できる ⬅Oculus Rift 自動プレイの様子 常に最新ビルドの 自動通しプレイが走っている
205. バッチの定期実行 • バッチをループ • 一定時間毎に プロセス起動と終了 自動プレイモード起動 • -auto引数を追加 （独自実装） • プレイスピード指定 自動起動の仕組み

206. 詳細は下記の記事を参照してください！
207. 自動通しプレイの
 ゲーム側対応

208. 自動通しプレイに必要な要素
 • 会話進行
 • 選択肢選択
 • 探索
 • ハンドインタラクション全般
 • 全エンディング踏破

209. 自動進行の流れ
 ソフト起動 自動進行オン 差し込み タイトル 自動進行 Jenkins経由
 Jenkinsから引数を 受けって起動
 自動進行中
 全場面自動進行

210. 会話進行
 • 基本決定ボタン連打
 • 入力機能にデバッグ機能 として押された判定を 挿し 込めるように
 • 会話中は常に挿し込んで 行く

211. 会話進行 - 強制入力
 VRInput Uranus Input DebugInput 入力来たら通知飛ばす 
 Uranus上の入力
 デバッグの入力
 強制入力
 入力来たら通知飛ばす 
 入力に反応
212. 自動選択肢
 • ランダムと特定エンド向けの選 択２種類
 • 会話と同じで強制入力を 入 れ込む
 ◦ 上下入力
 ◦ 決定入力
 • 上下移動はランダム回数 行 う

214. 特定エンドに向け自動選択肢
 • 各選択肢で選ぶ選択の一覧 データを作成
 • 基本はただのインデックスの 数値
 • 複数パターンを作って特定 ルートを辿る自動プレイを作 れるように

215. 自動探索
 • 基本ランダム
 • 全ての選択出来る物から 一つを選択する
 • 総当たりで潰していく

217. 自動インタラクション

218. ハードの自動通しテスト
 • 位置と回転が物理
 • 動かすゲームの場合困る

219. 自動で動かすハードがあ れば・・！

220. ハードは
 流石に作れない・・・

221. ハードの位置・回転適用 後に強制的に移動させる

222. 位置回転入力の更新
 手と頭の反映 自動で現在の 手と頭の位置指 定 HMDとコント ローラーの 更新適用 ハード毎の入力
 実際に見える要素
 自動進行
 手と頭の反映 HMDとコント ローラーの 更新適用 ハード毎の入力
 実際に見える要素
 通常

223. 自動インタラクションのデモ動画
224. インタラクションの種類は色々

225. 同じパターンで流用できる
 物はそれで流用

226. それ以外は・・・

227. 根性！
 （個別実装）

228. インタラクション毎にインタ ラクションの種類を送って いた

229. インタラクション開始時の流れ
 インタラクショ ン状態開始 インタラクショ ン特有処理開 始 自動進行 インタラクショ ン処理 Jenkins経由
 Jenkinsから引数を 受けって起動
 通知を飛ばす
 手や頭の移動
230. 自動でクリアしてくれるシ ステムは出来た

231. 一つ問題点

232. Oculus Riftの仕様上
 一定時間動かないと
 スタンバイになる

233. 解決策

234. 自動振動君 →スマホのアラームで 時々振動させて防ぐ荒業
235. エラーログはslackに送信

236. クリアログをSlackに送信
 • クリア時間
 • 周回数
 • アプリ情報
 • フラグ・変数の状態一覧

237. 修正がすぐに実機で確認できて便利だった • 修正→確認のサイクルが頻繁な テスト期間は特に有益だった 自動プレイ + Slack通知が仕組みよかった • Slackで自動プレイの進行状況がわかる • 最後までプレイできる状態が 常に担保されているのは精神的に良い 6. CI環境【まとめ】

238. • 物語VR作品特化のUranusの仕組みで、少人 数ながら効率的な開発を実現できた
 • 演出の手続き的処理の実装が
 async/await 形式と相性がよかった
 • デバッグ機能/CI環境で、作業の効率化とイ テレーションの高速化が図れた
 本セッションのまとめ
 W IP
239. 最後に

240. なんでこんな話をしたか

241. もっとストーリー系
 VRゲームが遊びたい！

242. ご静聴ありがとうございました！