うちではこうやってます

UI構築のルールと

Playmakerを使った画面遷移

株式会社マーベラス

松田裕太

1

自己紹介：松田裕太 いろいろやってきました。雑食エンジニア。

最近はUnityでアプリを作ることが多いです。

マーベラス時代

世に出ていない試作や、名前は出せないプロジェクト

ジー・モード時代

フライハイトアレスティア、パネローグなど

某アニメ制作会社時代

アニメ@wikiというサイトにまとまってました

https://www7.atwiki.jp/anime_wiki/pages/13912.html

某携帯キャリア会社時代

ガラケー用アプリのライブラリ仕様策定など

2

今回のお題

うちではこうやってます

UI構築のルールと

Playmakerを使った画面遷移

マーベラスのすべてのプロジェクトで行っている

手法というわけではありません

今作っているアプリではこうやってますよ

というのを紹介します

3

目次

目的

画面遷移

UI構築ルール

作業フロー

おまけ 4

目的

画面遷移

UI構築ルール

作業フロー

おまけ 5

画面量産の仕組みが欲しかった

今回のプロジェクトは期間に対しての物量が多く

さらに人数が「じわじわ」と増えることが予想された

人が増えるたびに新メンバーの学習のコスト負担になる

悩まずに画面や機能を量産する仕組みが欲しかった

6

0

5

10

15

1 2 3 4 5 6 7 8 9

エンジニアの増減

人数

経過月数

画面を量産するためには

導入時（人が増えたとき）

・ルール説明しやすいこと

・ルールが少ないこと

実装時

・他の実装から真似できる

・担当者が変わってもぱっと見でわかる

7

目的

画面遷移

UI構築ルール

作業フロー

おまけ 8

基本構成

uGUI（Unity5.3.4）

＋

Playmaker

9

基本構成：uGUI

Unity標準の2D用UI機能のことを勝手にこう呼んでいる

おそらく公式な呼び方ではない

Unity4.6以前はNGUIという

UI構築用エディタ拡張アセットがスタンダードだった

しかしUnity4.6でNGUI相当の機能が標準で入ったので

区別するためにuGUIって呼んでいたら

いつの間にか定着していた気がする

10

基本構成：Playmaker

みんな大好きPlaymaker

大人気のエディタ拡張アセット

グラフィカルなステートマシンエディタ

https://www.assetstore.unity3d.com/jp/#!/content/368

PlayMakerなのか

playMakerなのか

Playmakerなのか

よくわからない

11

画面遷移の方式

Unityでの画面遷移の実現方法は大きく分けて２つ

プレハブ入れ替え方式

シーン入れ替え方式

うちの場合は（基本的には）シーン入れ替え方式

（ひとつのシーンをみんなで触るのは危険）

12

シーン内のオブジェクト

各シーンに初期配置されているオブジェクトは１つ

13

コンポーネントは２つのみ

PlaymakerFSM ＋ シーケンスマネージャ

シーンの種類

シーン入れ替え方式でのシーンは2種類

メインシーケンス ゲーム全体の画面遷移を管理するシーン（FSM）

ゲーム起動時から終了までずっと生きている

シーンシーケンス 各画面用のシーン（FSM）

画面遷移で入れ替えられ、破棄されていく

14

シーンの親子関係

15

メインシーケンス

シーンシーケンス

シーンシーケンス

シーンシーケンス

シーンシーケンス

シーンシーケンス

シーンシーケンス

シーンシーケンス

シーンの親子関係

16

startup

ho

me

men

u

party

ad

ven

ture

Lo

g

battle

pictu

reB

oo

k

op

tion

Playmakerを使ったステート管理

Playmakerはグラフィカルなステートマシンとしてだけ利用

アクションはシーケンスマネージャを呼ぶCallMethodだけ

ただし、一部の処理はカスタムアクション化している

17 メインシーケンス シーンシーケンス

ステートの色

18

黒：基本

赤：シーン遷移

橙：通信待ち

紫：チュートリアル

緑：ユーザー操作待ち

ステートの配置

19

上から下へ、左から右へ

１画面に収める

処理のかたまりを意識する

各ステートで行うこと

シーケンスマネージャに用意したメソッドをCallMethodを使って呼ぶ

シーケンスマネージャにはFsm～～～という名前でPlaymakerのステートから呼ばれるメソッドを用意

FsmGetHome()、FsmMakeUi()、FsmShowHelp…

各Fsmメソッド内でPlaymakerのイベントを呼び

ステートの遷移を行う

明示的に呼ばない場合はFINISHEDが自動的に発生

20

各ステートで行うこと

21

ステートで行うこと

22

①make ui に到達

②FsmMakeUiAdventureLog

を実行

③UiAdventureLog.Create()

でプレハブをインスタンス化

次のステートへ

目的

画面遷移

UI構築ルール

作業フロー

おまけ 23

UIプレハブという概念

ホーム画面ならUIHomeプレハブ

オプション画面ならUIOptionプレハブ

メニュー画面ならUIMenuプレハブ

といった形で各画面（シーン）用にプレハブを用意

プレハブにはそのプレハブ専用のクラスを用意

ホーム画面ならUIHomeクラス

UIHome.Create()でプレハブを生成、画面に配置。

１シーン、１プレハブ、１画面が基本

24

25

ホーム

もどる ヘルプ

クエスト

パーティ

ずかん

オプション

メニュー 設定

例えばこんな画面（メニュー）

26

例えばこんな画面（メニュー）

ホーム

もどる ヘルプ

クエスト

パーティ

ずかん

オプション

メニュー 設定

UIHeader

UIFooter

UIMenu

27

UIMenuプレハブの構成

28

ホーム

もどる ヘルプ

道具

メニュー 設定

例えばこんな画面（リスト）

武器 防具

こんぼう

ナイフ

かしのつえ

AK-47

はがねのつるぎ

てつのオノ

29

ホーム

もどる ヘルプ

道具

メニュー 設定

例えばこんな画面（リスト）

武器 防具

こんぼう

ナイフ

かしのつえ

AK-47

はがねのつるぎ

てつのオノ

UIHeader

UIFooter

UIItemList

30

ホーム

もどる ヘルプ

道具

メニュー 設定

親子関係を意識して分割

武器 防具

こんぼう

ナイフ

かしのつえ

AK-47

はがねのつるぎ

てつのオノ

31

UIItemListプレハブの構成

画面内での処理のながれ

イベントは親へ

指示は子へ

32

画面内での処理のながれ

TabAはUITabAreaへイベントを発行する

↓（親へ）

UITabAreaは受けたイベントをUIItemListへ渡す

↓（親へ）

UIItemListは受けたイベントを判断

UITabArea、UIContentsAreaへと指示

↓

↓（子へ）

↓

UITabAreaの各Tabの色が変わる。

UIContentAreaのScrollViewの内容が更新される。

33

目的

画面遷移

UI構築ルール

作業フロー

おまけ 34

仕様作成から実装までのフロー

35

仕様書作成

仕様確認

UIプレハブ作成

スクリプト開発

UIプレハブ修正

FSM開発

企画

デザイナ

エンジニア

エンジニア

エンジニア

全員

UIプレハブはデザイナさんが作る

デザイナさん専用の

UIプレハブを作成するためのシーン

UIEditorTemp

UIMenuEditor

UIHomeEditor

UIPartyEditor

などなど 36

デザイナ用ブランチ

ブランチの切り方

37

エンジニア用ブランチ

develop

マージ

マージ

目的

画面遷移

UI構築ルール

作業フロー

おまけ 38

通信とエラー処理

APIのレスポンスのコードを独自に指定している。

500（通信エラー）

490（アプリ更新要求） 491（リソース更新要求）

407（アカウントバン） 405（サーバータイムアウト） 403（メンテナンス中）

200（正常）201（準正常）

200、201はAPIをコールしたシーケンスで受け取る。

それ以外は、メインシーケンスが受け取る。

39

通信とエラー処理

40

正常、準正常とは

APIごとに、200、201を規定している。

201がないAPIもある。

例えばgetOtherPlayerProfileというAPIがあるとして

200（正常）：対象プレイヤーが存在するとき

レスポンス：他プレイヤーのプロフィール

201（準正常）：対象プレイヤーが存在しないとき

レスポンス：エラーメッセージ

41

正常、準正常とは

200のレスポンスは各APIで違う

201のレスポンスは各APIで共通（エラーメッセージのみ）

201が発生する条件は各APIで違う

201発生後の挙動は各シーンシーケンスが自由に行える

500、40x系はメインシーケンスが処理するので

シーンシーケンス側では触れない

42