【出張ヒストリア2018】Caligula Overdose 開発ワークフロー アラカルト

Caligula Overdose 1 開発ワークフロー アラカルト （株）ヒストリア 馬場 俊行 二階堂 透

2 はじめに  自己紹介 馬場 俊行 株式会社 ヒストリア エンジニア／レベルデザイナー 二階堂 透 株式会社 ヒストリア エンジニア

3 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ☜イマココ

プロジェクト概要  2016年に発売されたPS Vita専用ソフト 「Caligula-カリギュラ-」に新しくキャラクターやシナリオ、 ダンジョンを追加し、UIなどを一新したPS4へのリメイク版  PS4へのリメイクに伴いUnreal Engine 4 を採用  リリース時のバージョンはUE4.18

5 INDEX  プロジェクト概要  イベントスクリプト ☜イマココ イベントスクリプトとは スクリプトシステムの機能 その編集環境 スクリプト制作ワークフロー（まとめ）  技動作スクリプト  デバッグ機能

イベントのできるまで① 2017/05 6 PSVita版のスクリプト（C言語っぽい）あるから ほぼ使いまわせるようにしてな。 作り直す時間とかないからね。 あとExcelで編集したい。僕エクセル大好き！ Oh…まあ何とかなるかね。 ぼく 某SSK

7 INDEX  プロジェクト概要  イベントスクリプト イベントスクリプトとは ☜イマココ スクリプトシステムの機能 その編集環境 スクリプト制作ワークフロー（まとめ）  技動作スクリプト  デバッグ機能

8 イベントスクリプトとは  各種イベントシーンの挙動を記述するデータ  実行されるべき命令を並べたもの 「台詞/文章を表示する」 「キャラクターを移動させる」 「アニメーションを再生する」 Etc…  RPG/アドベンチャーゲームで単に「スクリプト」と言ったら 多分コレのこと

9 イベントの例

10 INDEX  プロジェクト概要  イベントスクリプト イベントスクリプトとは スクリプトシステムの機能 ☜イマココ その編集環境 スクリプト制作ワークフロー（まとめ）  技動作スクリプト  デバッグ機能

11 実装された機能 ～ランタイム機能～  命令の実行  分岐  数式評価  不揮発変数（フラグ）の参照・書き換え  スクリプト内での命令(関数)定義  スクリプト内での変数定義  マルチスレッド  レガシースクリプト対応  実行時インポート（開発用）

12 実装された機能 ～事前処理①(C→CSV)～ スクリプトの変換（独立ツール） C言語ライクなスクリプト(PSVita版のデータ)を コマンドの羅列(CSV形式)に変換 ・実行システムの実装が比較的容易 ・Excel上での閲覧/編集に適する

13 実装された機能 ～事前処理① (C→CSV) ～ スクリプトの変換（独立ツール）

14 実装された機能 ～事前処理① (C→CSV) ～ スクリプトの変換（独立ツール）

15 実装された機能 ～事前処理① (C→CSV) ～ スクリプトの変換（独立ツール）

16 実装された機能 ～事前処理② (CSV→UASSET) ～ UnrealEditorへのインポート CSV形式から実行時に用いる形式まで変換 コマンドオブジェクトの配列

17 実装された機能 ～事前処理② (CSV→UASSET) ～ UnrealEditorへのインポート

18 実装された機能 ～事前処理② (CSV→UASSET) ～ UnrealEditorへのインポート

19 実装された機能 ～事前処理② (CSV→UASSET) ～ UnrealEditorへのインポート

20 実装された機能 ～事前処理②～ UnrealEditorへのインポート

21 実装された機能 ～事前処理③(コマンドリスト)～  コマンド定義システム  スクリプト実行のためのデータ二種類で構成される  各種コマンド定義クラス  BP/C++対応  たくさんある  コマンドリスト（DataTable）  コマンド名→コマンド定義クラスへの変換テーブル

22 実装された機能 ～事前処理③ (コマンドリスト) ～ コマンド定義システム コマンドリスト 各種コマンドの定義（BP）

23 実装された機能 ～事前処理③ (コマンドリスト) ～ コマンド定義システム コマンドリスト 各種コマンドの定義（BP）

24 実装された機能 ～事前処理③ (コマンドリスト) ～ コマンド定義システム コマンドリスト 各種コマンドの定義（BP）

イベントのできるまで② 2017/06 25 これシステムはだいたいできた。 あとは各コマンドの定義やな・・・ ぼく うん、無理やね（100個以上あるし これにかかりっきりになるわけにもいかない。 それ以前に3個くらいで飽きｒ） おまかせください！ 某新米エンジニア まじ助かる（まじ助かる）。 ぼく

26 INDEX  プロジェクト概要  イベントスクリプト イベントスクリプトとは スクリプトシステムの機能 その編集環境 ☜イマココ スクリプト制作ワークフロー（まとめ）  技動作スクリプト  デバッグ機能

27 イベントスクリプトの編集環境① ～概要～  Excelを活用 命令の羅列として展開したことにより可能になった マクロ/VBAにより編集作業を補助 コマンドの種類でセルを色分け パラメータ中のIDを元にキャラクター名、テキストを表示 コマンド候補リスト→デフォルトパラメータの自動入力 スクリプト作成担当者の技量と気合でできている

28 イベントスクリプトの編集環境② サポート情報の表示 実データ （パラメータが数値・IDから構成される） サポート情報 ID指定のデータを可視化

29 イベントスクリプトの編集環境② コマンドリスト

30 イベントスクリプトの編集環境② コマンドリスト

31 イベントのできるまで③ 2017/08~ 長き戦いへ あとはたのんだで・・・ Excelの編集システムを作った人 （つよいプランナー） ぼく 某新米エンジニア スクリプト制作チームの皆さん 量産体制の確立

32 INDEX  プロジェクト概要  イベントスクリプト イベントスクリプトとは スクリプトシステムの機能 その編集環境 スクリプト制作ワークフロー（まとめ）  技動作スクリプト  デバッグ機能 ☜イマココ

33 スクリプト制作ワークフロー（まとめ）  最終的に量産されたものは以下の二つ  コマンド定義（BP/C++）  ほぼBP  スクリプト

34 スクリプト制作ワークフロー① コマンドの定義  各種コマンドの定義（BP/C++）  そのコマンドのリスト制作（DataTable）  担当：主にエンジニア 某新米エンジニア

35 スクリプト制作ワークフロー② スクリプトの記述 ①C風スクリプト（存在する場合）からCSV形式への変換 ②CSV形式スクリプトの編集（Excel） ③UnrealEditorでのインポート  担当：主にプランナー（スクリプト制作チーム） スクリプト制作チームの皆さん

36 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト ☜イマココ 技動作スクリプトとは 技再生システムの機能 その編集環境 技動作スクリプト制作ワークフロー（まとめ）  デバッグ機能

バトルのできるまで① 2017/08 37 そろそろバトル作ろうね。 （各キャラクターの先行入力した技がタイムラインに登録され その動きの未来予測を見られたりする面白システムだよ！） 詳しい仕様についてはPSVita版のゲームをやってみてね。 Oh…まあ何とかなるかね。 ぼく 某SSK

38 こんなバトル

39 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト 技動作スクリプトとは ☜イマココ 技再生システムの機能 その編集環境 技動作スクリプト制作ワークフロー（まとめ）  デバッグ機能

40 技動作スクリプトとは  その名の通り、技の動作を定義するデータ  時間に沿って動作コマンドを並べたもの アニメーション サウンド・ビジュアルエフェクト 攻撃判定 移動・回転 Etc…  AnimCompositeとして作成

41 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト 技動作スクリプトとは 技再生システムの機能 ☜イマココ その編集環境 技動作スクリプト制作ワークフロー（まとめ）  デバッグ機能

42 技再生システムの機能①  コマンドの実行  アニメーション再生、移動、攻撃判定発生など  AnimComposite内の各Notifyが一つの命令に相当する

43 技再生システムの機能①  コマンドの実行  アニメーション再生、移動、攻撃判定発生など  AnimComposite内の各Notifyが一つの命令に相当する

44 技再生システムの機能①  コマンドの実行  アニメーション再生、移動、攻撃判定発生など  AnimComposite内の各Notifyが一つの命令に相当する

技再生システムの機能① 45  コマンドの実行  アニメーション再生、移動、攻撃判定発生など プレビュー用 CompositeTrack （実行時は使わない）  AnimComposite内の各Notifyが一つの命令に相当する 実行時に使われるデータ （各Notifyが1つのコマンド）

46 技再生システムの機能②  アニメーションの抽象化  たとえば「弱攻撃」「強攻撃」「ダッシュ」のように アニメーションが抽象化されている  動きの異なるキャラクター間で技動作データを共有するため

47 技再生システムの機能②  アニメーションの抽象化  たとえば「弱攻撃」「強攻撃」「ダッシュ」のように アニメーションが抽象化されている（モーションと呼んでいた）  動きの異なるキャラクター間で技動作データを共有するため

バトルのできるまで② 2017/09 48 バトルシステム何となくできた。 あとは技スクリプトのコマンド定義やな・・・ ぼく （なんだかんだで30個ほどは実装が必要だけ ど多分3個くらいで飽きｒ） ・・・ﾁﾗｯ 忙しいっす 某新米エンジニア ですよね～ ぼく （しゃーない自分でやろ） そしてこの作業は開発終盤まで続く

49 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト 技動作スクリプトとは 技再生システムの機能 その編集環境 ☜イマココ 技動作スクリプト制作ワークフロー（まとめ）  デバッグ機能

50 技動作スクリプトの編集環境  PSVita版の技動作スクリプトをAnimCompositeに変換  UnrealEditorのAnimCompositeエディタをそのまま用いる

51 技動作スクリプトの編集環境 この1行が1コマンド  Caligula(PSVita)の技動作スクリプト(csv)をAnimCompositeに変換  UnrealEditorに備わるAnimCompositeのエディタをそのまま用いる  ただし実行時には独自の再生システムを用意

52 技動作スクリプトの編集環境  Caligula(PSVita)の技動作スクリプト(csv)をAnimCompositeに変換  UnrealEditorに備わるAnimCompositeのエディタをそのまま用いる  ただし実行時には独自の再生システムを用意 AnimNotify1個が1命令

53 技動作スクリプトの編集環境  Caligula(PSVita)の技動作スクリプトをAnimCompositeに変換  UnrealEditorのAnimCompositeエディタをそのまま用いる  （専用エディタを作るのに比べて）大幅な工数削減  ただし機能不足は否めなかった（特にプレビュー）

54 技動作スクリプトの編集環境 デモ  デモ：技動作スクリプトの編集

55 技動作スクリプトの編集環境

バトルのできるまで③ 2017/10~ 56 技データの編集にはコレ使ってね。 ハイ、ありもののAnimCompositeエディタ・・・！ ぼく プレビューがだるい エフェクト担当 アーティスト プレビューがだるい ごめんやで ぼく 量産体制の確立 バトル担当 プランナー

57 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト 技動作スクリプトとは 技再生システムの機能 その編集環境 技動作スクリプト制作ワークフロー（まとめ）  デバッグ機能 ☜イマココ

58 技動作スクリプト制作ワークフロー  技動作に関して量産されたものは二つ  技動作のためのコマンド定義  技動作スクリプト

59 技動作スクリプト制作ワークフロー① コマンド定義  AnimNotifyStateを継承  C++で実装  目コピーと解析の組み合わせ  担当：エンジニア ぼく コマンド一覧

60 技動作スクリプト制作ワークフロー① コマンド定義  AnimNotifyStateを継承  C++で実装  目コピーと解析の組み合わせ  担当：エンジニア コマンド一覧

61 技動作スプリプト制作ワークフロー② スクリプト作成 ①PSVita版データ（存在する場合）からの変換 （AnimCompositeへ） ②UnrealEditorで作成/編集  担当：プランナー（バトル担当） アーティスト（エフェクト） バトル担当 プランナー エフェクト担当 アーティスト

62 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能  スクリプトの移植について ☜イマココ

63 スクリプト的なシステムの特徴 コマンド定義 （辞書） スクリプト （文章） 実行システム （読み手） 動作する （意味が分かる）

64 スクリプトを移植することについて コマンド定義 （辞書） スクリプト （文章） 実行システム （読み手） 動作する （意味が分かる）

65 スクリプトを移植することについて コマンド定義 （辞書） 依存 スクリプト （文章） 実行システム （読み手） 動作する （意味が分かる）

66 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ☜イマココ ローカル環境でのiniファイルの変更 デバッグメニューについて デバッグ表示について QAについて デバッグについてのまとめ

67 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ローカル環境でのiniファイルの変更 デバッグメニューについて デバッグ表示について QAについて デバッグについてのまとめ ☜イマココ

68 ローカル環境でのiniファイルの変更 ～iniファイルとは？  簡単に言うと設定ファイル  設定した各パラメータを保存しておくファイル  UE4内のデフォルトのパラメータから プロジェクト固有のパラメータまで 好きに追加設定する事が可能

69 ローカル環境でのiniファイルの変更 ～iniファイルの共有  設定ファイルであるiniファイルはPerforceやSVNなどで バージョン管理して共有するのがわりと一般的

70 ローカル環境でのiniファイルの変更 ～iniファイルの共有  エディタ側でプロジェクト設定を変更した場合、 iniファイルが書き換えられる

71 ローカル環境でのiniファイルの変更 ～iniファイルの共有  その際にソースコントロールが設定されていると 自動的にチェックアウトされる

72 ローカル環境でのiniファイルの変更 ～iniファイルの共有  書き換えられたiniファイルは そのままサブミットする事で他のユーザーとその変更を共有  ローカル環境で試した設定を即チームに共有することが可能  便利な反面…

73 ローカル環境でのiniファイルの変更 ～iniファイルの共有の問題点  各セクションや担当パートによって デバッグ機能のON／OFFなど デフォルト設定を変更したい事はよくある  そこでデバッグ機能のみを 各ローカル環境で自由に設定できるような運用を採用

74 ローカル環境でのiniファイルの変更 ～実際の運用例  ローカル環境で自由に設定できる項目を追加

75 ローカル環境でのiniファイルの変更 ～実際の運用例  バトルパート担当者は… 最初に読み込まれるマップを専用のテストマップに設定  バトルにあまり関与しない別のパート担当者は… 敵とのエンカウントをデフォルトでOFFに  イベントパート担当者は… 起動中のスクリプトIDを常に表示する機能をデフォルトでON イベントトリガー用のボリュームを表示する機能をON

76 ローカル環境でのiniファイルの変更 ～実装方法  まずはプロジェクト設定の項目を新しく追加 （追加はC++で行う）  新しく追加した項目を全体に共有されないようにする

77 ローカル環境でのiniファイルの変更 ～実装方法  プロジェクト設定用のクラスを追加（MyProjectSettings.hを新規作成)

78 ローカル環境でのiniファイルの変更 ～実装方法  追加したクラスをSettingModuleに登録（MyProject.cppに追記）

79 ローカル環境でのiniファイルの変更 ～実装方法  弊社ブログで実装方法を紹介 [UE4] 「エディタの環境設定」や「プロジェクト設定」に項目を追加する http://historia.co.jp/archives/4095/ ブログは毎週更新してるよ みんなチェックしてね 某広報さん

• http://historia.co.jp/archives/4095/

80 ローカル環境でのiniファイルの変更 ～実装方法  上記ブログ内容をそのまま実装すると 追加した項目もローカルで変更すると共有されてしまう  クラス指定子に指定している「defaultconfig」を削除

81 ローカル環境でのiniファイルの変更 ～注意点  ビルド環境でローカル設定が変更されていると そのままパッケージにも反映されてしまうので注意が必要  ローカルでの保存先は[ProjectDirectory]/Saved/Config/[Platform]/

82 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ローカル環境でのiniファイルの変更 デバッグメニューについて デバッグ表示について QAについて デバッグについてのまとめ ☜イマココ

83 デバッグメニューについて  UMGによる作成で、簡単に素早く機能の追加が可能に  UMGはやはり処理が重いが、 常に表示させておくわけではないので問題無し

84 デバッグメニューについて ～実際の運用例

85 デバッグメニューについて ～実際の運用例

86 デバッグメニューについて ～実際の運用例

87 デバッグメニューについて ～仕組み概要  Toggle系の機能はチェックボックスのWidgetを使用  デバッグ機能の呼び出し系はボタンのWidgetを使用  他にも任意のマップへ移動、 任意のスクリプトを起動、 配置しているNPCの一覧など、 様々なデバッグ機能をこのメニューに集約している

88 デバッグメニューについて ～作成ワークフロー  デバッグメニューの基礎部分は一人が最初に作成 基礎の部分は私がやりました 某新米エンジニア  様々なパートの担当エンジニアが必要なデバッグ機能を実装  実装した本人がデバッグメニューに チェックボックスやボタンなどを追加していく

89 デバッグメニューについて ～実装方法 基礎部分編  追加するWidgetはデバッグメニュー担当者の方で事前に作成

90 デバッグメニューについて ～実装方法 基礎部分編  ボタンを押された時にEventがくるように Event Dispatcherを用意

91 デバッグメニューについて ～実装方法 追加部分編  各パート担当者はメニューに用意されたWidgetを追加

92 デバッグメニューについて ～実装方法 追加部分編  ボタンを押された際に呼び出されるEventを追加して 機能を呼び出す

93 デバッグメニューについて ～まとめ  UMGの機能をうまく利用し、 手軽にデバッグメニューに機能を追加できるようにすることで、 用意したデバッグ機能を埋もれさせる事なく チーム全体に活用してもらえるようになる

94 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ローカル環境でのiniファイルの変更 デバッグメニューについて デバッグ表示について ☜イマココ QAについて デバッグについてのまとめ

95 デバッグ表示について  UE4にはデバッグに便利な機能やComponentなど 様々なものが用意されている  今回は普段あまり使用することがなかった Arrow Component を活用した例をご紹介

96 デバッグ表示について ～実際の運用例  今回とくに活躍したのはNPCのルート移動でのデバッグ表示

97 デバッグ表示について ～NPCのルート移動とは  一般生徒であるNPCは学校や施設などマップ上を巡回する仕様  巡回ルートは事前にマップ上に配置されているルートを検索し 移動する  ルートの配置はVita版のデータをコンバートして アクターとしてレベルに自動的に配置するような仕組み

98 デバッグ表示について ～必要性  ルートデータが壊れていないか、 また新規マップでもルートデータを新しく配置しやすくする ためにルートを視覚化する必要があった  そこで、今回はArrow Component を利用し、 ルート同士の繋がりを確認できるように

99 デバッグ表示について ～実際の運用例  エディタ上だけでなく、実行中も確認できるように

100 デバッグ表示について ～実際の運用例  ルートには始端と終端があるため、StartやGoal表示も

101 デバッグ表示について ～実装方法  Arrow Component はルート同士で繋がっている個数分 生成する必要があるので、ConstructionScriptで動的に追加

102 デバッグ表示について ～実装方法  Arrow Component はルート同士が繋がっている個数分 生成する必要があるので、ConstructionScriptで動的に追加

103 デバッグ表示について ～実装方法  Arrow Component はルート同士が繋がっている個数分 生成する必要があるので、ConstructionScriptで動的に追加

104 デバッグ表示について ～実装方法  繋がっているルートアクターへと矢印の向きを回転

105 デバッグ表示について ～実装方法  矢印の長さと幅はスケーリングで調整 長さはルート同士間の距離を見て算出し、 幅はNPCが移動する際の道幅設定に合わせた

106 デバッグ表示について ～実装方法  矢印の長さと幅はスケーリングで調整 長さはルート同士間の距離を見て算出し、 幅はNPCが移動する際の道幅設定に合わせた

107 デバッグ表示について ～実装におけるポイント  動的に生成しているため、 Shipping版では生成しないなど楽に対応可能  Debug版でもHidden in Gameフラグを操作すれば 必要な時のみ表示するように対応可能

108 デバッグ表示について ～まとめ  ComponentやActorはHidden in Gameのフラグで簡単に 表示非表示が切り替える事が可能なため、 デバッグ用に積極的に活用する  デバッグ専用に用意するComponentやActorは 出来るだけ動的に生成するように対応し、 Shipping版では生成しないようにする

109 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ローカル環境でのiniファイルの変更 デバッグメニューについて デバッグ表示について QAについて ☜イマココ デバッグについてのまとめ

110 QAについて  Caligula Overdose では開発中期からQA担当者を一人確保  早い段階からデバッグを行うようにして バグが大量に溜まっていかないように開発と平行して バグ修正を行っていった  開発後期のバグは少なくはなかったが、ゲームの規模にしては バグの量をある程度は抑えていた （もぐら叩きのように追加実装分のバグにだけ集中できた）

111 INDEX  プロジェクト概要  イベントスクリプト  技動作スクリプト  デバッグ機能 ローカル環境でのiniファイルの変更 デバッグメニューについて デバッグ表示について QAについて デバッグについてのまとめ ☜イマココ

112 デバッグについてのまとめ  人によって必要なデバッグ情報や機能は違ってくる →ローカル環境で最適なデバッグ環境になるようにする  デバッグ機能は開発において重要になってくるため 機能が増えがちになる →せっかく作った機能はわかりやすいように デバッグメニューに集約しておく  バグは放置すればその分埋もれていくので、 早めにデバッグ体制を整えて運用していく

113