【Unite 2017 Tokyo】Unityで出来る『見える開発』のススメ 〜スマホゲーム「ららマジ」開発事例〜
3.7K Views
June 07, 17
スライド概要
講演者：奥村 典史(グリー株式会社)
こんな人におすすめ
・UnityでAIが必要なゲームを開発している人
・Unityで複雑な画面遷移のあるゲームを開発している人
受講者が得られる知見
・ゲーム開発におけるビジュアルプログラミングの使い所
講演動画：https://youtu.be/leweFrRHrrw
リアルタイム3Dコンテンツを制作・運用するための世界的にリードするプラットフォームである「Unity」の日本国内における販売、サポート、コミュニティ活動、研究開発、教育支援を行っています。ゲーム開発者からアーティスト、建築家、自動車デザイナー、映画製作者など、さまざまなクリエイターがUnityを使い想像力を発揮しています。
関連スライド
各ページのテキスト
Unityで出来る『見える開発』の ススメ 〜ららマジ開発事例〜 奥村 典史
プログラムを見える様にしましょう
ららマジで使われている３つの ビジュアルプログラミング ①AI（攻撃パターンの選択） ②画面遷移 ③キャラクターステートマシンのコード生成
①AI
AIが何を考えているのかわからない
目で見えるととっつきやすい
AIを実装しようとしています・・・ ゴーレム作ってよ このゴーレムは攻撃Aを連続で使用しているときは全然歯がたたないんだけど攻撃Bを打った後は攻撃が当たるようにしたい 歯がたたないとはどういう意味ですか？連続で使用するという話ですけど攻撃Aは何秒間隔で使用する のでしょう？攻撃Bを打った後は攻撃が当たるようにしたいって言うことは攻撃の後の隙がでかいという話だ と思うのですが、何秒間待つのでしょう？ わからないからとりあえずやってみて
AIを実装しようとしています・・・ やっぱり0.5秒は長すぎた。 0.7秒にしたらどうなる？ 攻撃Bの後で隙が出来るのは弱すぎるから 2発くらい喰らったら攻撃Cで反撃をしよう 攻撃Cってどこから出てきてん
AIを実装しようとしています・・・ コミュニケーションコスト大！
考える人≠作る人
考える人≠作る人 考える人＝作る人！
そこでVisual Programming
何をしているのかわかれば怖くない
ステートマシン(状態遷移) 現在の状態と 入力条件(何が起こったか) 攻撃A 攻撃Bが終った によって次の状態が決まる 5回攻撃した 攻撃B ゲームでは良く使われる
ステートマシンを実装するために ステートマシンを Unity上で図として 作れます
例えば アクション 説明 ぐるぐるパンチ 手をぐるぐるさせて一撃 ワン・ツー・頭突 き 右パンチ、左パンチ頭突き のコンビネーション
動きの企画
実際の実装 考えたことをそのまま書いてもらう！
Demo：AIの開発環境
プログラマーは最低限のコードを書く 小さく 単機能で！ 部品（コンポーネント）の提供
AIコンポーネント：ジャンプ 引数 初速 着地時に遷移 Y軸方向に飛び上がります 説明 敵キャラクターが ジャンプするときの初速
AIコンポーネント：攻撃 引数 種類 説明 攻撃の種類を選択します １：ぐるぐるパンチ ２：ワン・ツー・頭突き 攻撃終了時に遷移 対応する攻撃を出す
AIコンポーネント：待機 引数 なし 動きを止めて待機モーションになります 説明
AIコンポーネント：ランダム 引数 Weight ランダムに遷移します 説明 ランダムで抽選するときの 確率。
組み合わせで増える要望 ジャンプしながら0.5秒で遷移したい ジャンプしながらプレイヤーの方向に近づきたい ジャンプしながら30％の確率で攻撃を出したい →組み合わせ爆発！
複数のコンポーネントを配置 企画者自信が組み合わせる 事ができる！ →プログラマーの作る コンポーネントの数が 最小限になる！
頻出するAIパターンの問題 ジャンプをしながら◯◯ ジャンプをしながら◯◯ ジャンプをしながら◯◯ ジャンプをしながら◯◯ ジャンプをしながら◯◯ たくさん編集するはめに・・・
頻出するAIパターンの問題 ジャンプをする 一つだけの変更でOK ＋ ◯◯する
頻出するAIのパターンの問題 出現付近をうろうろ
頻出するAIのパターンの問題 出現付近をうろうろ 複数のAIでうろうろする行動パターンが頻出
階層型のステートマシン 同じ挙動をPrefabとしてまとめる プレハブ化 出現付近をうろうろ 再利用
階層型のステートマシン ・共通化できる ・複雑な遷移になりづらい ・途中キャンセルの挙動が実装可能に
Demo：階層型ステートマシン
見えるようにすると・・・ ・企画者が機能の組み合わせを発明します ・企画者がプログラムを理解してくれます ・実装指示が具体的になります →AI開発の工数がぐんとへります
②画面遷移
問題：この画面のソースコードはどこで しょう？
ソースコードの探し方 ・エントリポイントから辿る ・TeamEditとか勘で検索してみる ・UIの名前を検索してみる
こういうイメージ TeamEditState StrengthState HomeState DressListState StrengthState
画面遷移を見える化しよう！ • ゲームが今どのコードを実行しているのかわ かる • 現在の画面にどこから来たのかわかる
ステートマシンの実装 ArborFSMを貼り付ける
ステートの実装 １つのコンポーネントと して実装 C#でロジックを書く
画面遷移の階層の実装 画面遷移の状態は重なって存在する ＋ →階層型ステートマシン ＋
Demo：画面遷移
複雑な画面遷移図 ドレス一覧 ホーム 詳細画面 チーム編成 強化画面
カードの詳細画面の遷移図 ドレス一覧 詳細画面 チーム編成 強化画面
２つ以上の戻り先がある問題 • 前のステートを覚えな いといけない • 使う箇所が増えると コードも書き変えないと いけない
画面遷移の混線の解消① A ☆ B これだと☆を経由して A→☆→Bと遷移出来るように見える A ☆ B ☆ ２つのステートに同じ Componentをつける
強化画面の遷移図 ドレス一覧 強化画面 チーム編成 ※強化画面は複数画面遷移を持っている
画面遷移の混線の解消② 同じ挙動をPrefabとしてまとめる プレハブ化 一連の画面遷移 再利用
大量の戻り矢印問題 A１ A２ A３ B１ B２ B３ ☆
大量の戻り矢印問題 A１ A２ A３ B１ B２ B３ ☆
複雑な画面遷移図 ドレス一覧 ホーム 詳細画面 チーム編成 強化画面
整理された画面遷移図 詳細画面 詳細画面 ドレス一覧 強化画面 チーム編成 強化画面 詳細画面 詳細画面 ホーム
見えるようにすると・・・ • 目的のソースコードを簡単に見つけられる • 見通しが良くなり保守性・可読性が上がる • 構造の整理がしやすくなるのでバグが減る
③ステートマシンのコード生成
ステートマシンをC#で書く • 某ビジュアルプログラミングツールの実行 速度が遅かった • 開発当初メカニムにStateBehaviour等の 仕組みは無かった
C#のステートマシン メリット：実行速度が速い デメリット：編集しづらい
C#コードの自動生成で編集しやすく メリット： 実行速度が速い （ランタイムはC#なので速度が落ちない） 編集しやすい （編集はArborなので見ながら編集可能）
自動生成データ作成用コンポーネント Initializer:ステートに入った時 Controller:毎フレーム実行 Disporser:ステートから出る時
自動生成データ作成用コンポーネント リフレクションで 関数名を選択させる InitializeStateOnWalk InitializeStateOnDash InitializeStateOnJump InitializeStateOnStay
自動生成データ作成用コンポーネント 遷移先にも関数をする 遷移先の個数は可変
自動生成データ作成 生成データ作成用 コンポーネント で構成された 1レイヤーごとに ステートマシンを 貼り付ける ステートマシン
コードの自動生成 エディタース クリプトで自 動生成
見えるようにすると・・・ ・コードの編集しやすさが上がる！ ・C#で書く時と ビジュアルプログラミング用Assetを使う時の良 い所を同時に取れる
ビジュアルプログラミングをすると • プログラムを扱える人が増える事で • コミュニケーションコストが減る • 見通しが良くなることで コード品質が上がる • コード量を少なくすることで 実装コストやバグが減る
ビジュアルプログラミングで 本当に面白いところを開発しましょう
ありがとうございました！
同じツールを見ると言うこと
ビジュアルプログラミングの良い所 ・テキストのコード量が減る ・扱える人を増やしやすい ・見通しが良くなる
プログラムを見える様にしましょう
②画面遷移
ららマジの画面遷移のアーキテクチャ Model use State （Controller） FSM View 複数の遷移を持ちState間を 遷移させる ↑この部分を見える化します
もっと見える様にするために Arborの StateBehaviorは MonoBehaviorと 全く同じやり方での拡 張が可能
StateBehaviorのインスペクター拡張 さらに見えるAI開発を！ ダメージが終わるまでの時間を表示する