Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

うちではこうやっています UI構築のルールとPlaymakerを使った画面遷移

27 311 vues

Publié le

2017/03/09に弊社で開催された技術勉強会、まべ☆てっくvol.3「Unity®のお道具箱」の登壇資料です

Publié dans : Technologie
  • Soyez le premier à commenter

うちではこうやっています UI構築のルールとPlaymakerを使った画面遷移

  1. 1. うちではこうやってます UI構築のルールと Playmakerを使った画面遷移 株式会社マーベラス 松田裕太 1
  2. 2. 自己紹介:松田裕太 いろいろやってきました。雑食エンジニア。 最近はUnityでアプリを作ることが多いです。 マーベラス時代 世に出ていない試作や、名前は出せないプロジェクト ジー・モード時代 フライハイトアレスティア、パネローグなど 某アニメ制作会社時代 アニメ@wikiというサイトにまとまってました https://www7.atwiki.jp/anime_wiki/pages/13912.html 某携帯キャリア会社時代 ガラケー用アプリのライブラリ仕様策定など 2
  3. 3. 今回のお題 うちではこうやってます UI構築のルールと Playmakerを使った画面遷移 マーベラスのすべてのプロジェクトで行っている 手法というわけではありません 今作っているアプリではこうやってますよ というのを紹介します 3
  4. 4. 目次 目的 画面遷移 UI構築ルール 作業フロー おまけ 4
  5. 5. 目的 画面遷移 UI構築ルール 作業フロー おまけ 5
  6. 6. 画面量産の仕組みが欲しかった 今回のプロジェクトは期間に対しての物量が多く さらに人数が「じわじわ」と増えることが予想された 人が増えるたびに新メンバーの学習のコスト負担になる 悩まずに画面や機能を量産する仕組みが欲しかった 6 0 5 10 15 1 2 3 4 5 6 7 8 9 エンジニアの増減 人数 経過月数
  7. 7. 画面を量産するためには 導入時(人が増えたとき) ・ルール説明しやすいこと ・ルールが少ないこと 実装時 ・他の実装から真似できる ・担当者が変わってもぱっと見でわかる 7
  8. 8. 目的 画面遷移 UI構築ルール 作業フロー おまけ 8
  9. 9. 基本構成 uGUI(Unity5.3.4) + Playmaker 9
  10. 10. 基本構成:uGUI Unity標準の2D用UI機能のことを勝手にこう呼んでいる おそらく公式な呼び方ではない Unity4.6以前はNGUIという UI構築用エディタ拡張アセットがスタンダードだった しかしUnity4.6でNGUI相当の機能が標準で入ったので 区別するためにuGUIって呼んでいたら いつの間にか定着していた気がする 10
  11. 11. 基本構成:Playmaker みんな大好きPlaymaker 大人気のエディタ拡張アセット グラフィカルなステートマシンエディタ https://www.assetstore.unity3d.com/jp/#!/content/368 PlayMakerなのか playMakerなのか Playmakerなのか よくわからない 11
  12. 12. 画面遷移の方式 Unityでの画面遷移の実現方法は大きく分けて2つ プレハブ入れ替え方式 シーン入れ替え方式 うちの場合は(基本的には)シーン入れ替え方式 (ひとつのシーンをみんなで触るのは危険) 12
  13. 13. シーン内のオブジェクト 各シーンに初期配置されているオブジェクトは1つ 13 コンポーネントは2つのみ PlaymakerFSM + シーケンスマネージャ
  14. 14. シーンの種類 シーン入れ替え方式でのシーンは2種類 メインシーケンス ゲーム全体の画面遷移を管理するシーン(FSM) ゲーム起動時から終了までずっと生きている シーンシーケンス 各画面用のシーン(FSM) 画面遷移で入れ替えられ、破棄されていく 14
  15. 15. シーンの親子関係 15 メインシーケンス シ ー ン シ ー ケ ン ス シ ー ン シ ー ケ ン ス シ ー ン シ ー ケ ン ス シ ー ン シ ー ケ ン ス シ ー ン シ ー ケ ン ス シ ー ン シ ー ケ ン ス シ ー ン シ ー ケ ン ス
  16. 16. シーンの親子関係 16 startup home menu party adventureLog battle pictureBook option
  17. 17. Playmakerを使ったステート管理 Playmakerはグラフィカルなステートマシンとしてだけ利用 アクションはシーケンスマネージャを呼ぶCallMethodだけ ただし、一部の処理はカスタムアクション化している 17 メインシーケンス シーンシーケンス
  18. 18. ステートの色 18 黒:基本 赤:シーン遷移 橙:通信待ち 紫:チュートリアル 緑:ユーザー操作待ち
  19. 19. ステートの配置 19 上から下へ、左から右へ 1画面に収める 処理のかたまりを意識する
  20. 20. 各ステートで行うこと シーケンスマネージャに用意したメソッドを CallMethodを使って呼ぶ シーケンスマネージャにはFsm~~~という名前で Playmakerのステートから呼ばれるメソッドを用意 FsmGetHome()、FsmMakeUi()、FsmShowHelp… 各Fsmメソッド内でPlaymakerのイベントを呼び ステートの遷移を行う 明示的に呼ばない場合はFINISHEDが自動的に発生 20
  21. 21. 各ステートで行うこと 21
  22. 22. ステートで行うこと 22 ①make ui に到達 ②FsmMakeUiAdventureLog を実行 ③UiAdventureLog.Create() でプレハブをインスタンス化 次のステートへ
  23. 23. 目的 画面遷移 UI構築ルール 作業フロー おまけ 23
  24. 24. UIプレハブという概念 ホーム画面ならUIHomeプレハブ オプション画面ならUIOptionプレハブ メニュー画面ならUIMenuプレハブ といった形で各画面(シーン)用にプレハブを用意 プレハブにはそのプレハブ専用のクラスを用意 ホーム画面ならUIHomeクラス UIHome.Create()でプレハブを生成、画面に配置。 1シーン、1プレハブ、1画面が基本 24
  25. 25. 25 ホーム もどる ヘルプ クエスト パーティ ずかん オプション メニュー 設定 例えばこんな画面(メニュー)
  26. 26. 26 例えばこんな画面(メニュー) ホーム もどる ヘルプ クエスト パーティ ずかん オプション メニュー 設定 UIHeader UIFooter UIMenu
  27. 27. 27 UIMenuプレハブの構成
  28. 28. 28 ホーム もどる ヘルプ 道具 メニュー 設定 例えばこんな画面(リスト) 武器 防具 こんぼう ナイフ かしのつえ AK-47 はがねのつるぎ てつのオノ
  29. 29. 29 ホーム もどる ヘルプ 道具 メニュー 設定 例えばこんな画面(リスト) 武器 防具 こんぼう ナイフ かしのつえ AK-47 はがねのつるぎ てつのオノ UIHeader UIFooter UIItemList
  30. 30. 30 ホーム もどる ヘルプ 道具 メニュー 設定 親子関係を意識して分割 武器 防具 こんぼう ナイフ かしのつえ AK-47 はがねのつるぎ てつのオノ
  31. 31. 31 UIItemListプレハブの構成
  32. 32. 画面内での処理のながれ イベントは親へ 指示は子へ 32
  33. 33. 画面内での処理のながれ TabAはUITabAreaへイベントを発行する ↓(親へ) UITabAreaは受けたイベントをUIItemListへ渡す ↓(親へ) UIItemListは受けたイベントを判断 UITabArea、UIContentsAreaへと指示 ↓ ↓(子へ) ↓ UITabAreaの各Tabの色が変わる。 UIContentAreaのScrollViewの内容が更新される。 33
  34. 34. 目的 画面遷移 UI構築ルール 作業フロー おまけ 34
  35. 35. 仕様作成から実装までのフロー 35 仕様書作成 仕様確認 UIプレハブ作成 スクリプト開発 UIプレハブ修正 FSM開発 企画 デザイナ エンジニア エンジニア エンジニア 全員
  36. 36. UIプレハブはデザイナさんが作る デザイナさん専用の UIプレハブを作成するためのシーン UIEditorTemp UIMenuEditor UIHomeEditor UIPartyEditor などなど 36
  37. 37. デザイナ用ブランチ ブランチの切り方 37 エンジニア用ブランチ develop マージ マージ
  38. 38. 目的 画面遷移 UI構築ルール 作業フロー おまけ 38
  39. 39. 通信とエラー処理 APIのレスポンスのコードを独自に指定している。 500(通信エラー) 490(アプリ更新要求) 491(リソース更新要求) 407(アカウントバン) 405(サーバータイムアウト) 403(メンテナンス中) 200(正常)201(準正常) 200、201はAPIをコールしたシーケンスで受け取る。 それ以外は、メインシーケンスが受け取る。 39
  40. 40. 通信とエラー処理 40
  41. 41. 正常、準正常とは APIごとに、200、201を規定している。 201がないAPIもある。 例えばgetOtherPlayerProfileというAPIがあるとして 200(正常):対象プレイヤーが存在するとき レスポンス:他プレイヤーのプロフィール 201(準正常):対象プレイヤーが存在しないとき レスポンス:エラーメッセージ 41
  42. 42. 正常、準正常とは 200のレスポンスは各APIで違う 201のレスポンスは各APIで共通(エラーメッセージのみ) 201が発生する条件は各APIで違う 201発生後の挙動は各シーンシーケンスが自由に行える 500、40x系はメインシーケンスが処理するので シーンシーケンス側では触れない 42

×