ゲームエンジンとMVC
- 2. 自己紹介 ● 松田理孝（マツダヨシタカ） ● エンジニア ○ サーバやったりクライアントやったり ■ サポートやったりWebAPIやってたり ● いろいろやってます ● 使ったことあるゲームエンジン ○ Unity ○ Cocos2d-x ○ XNA（MonoGame） ○ Flash（ゲームエンジン？）
- 4. はじめに ● セッションの動機 ○ ゲームエンジンを活用する上でMVCは必須 ○ ゲーム業界ではMVCに対する理解が浅い
- 5. はじめに ● セッションの目的 ○ MVCとは何かを知ってもらう ○ ゲームエンジン別に設計が変わることを知ってもらう
- 6. アジェンダ 1. MVCとは 2. そもそもなんでMVCをするのか 3. MVCの各役割 4. MVCした後にできる事、すべき事 5. ゲームエンジンとMVC
- 7. MVCとは ● MVC（Model View Controller モデル・ビュー・ コントローラ）は、ユーザーインタフェースをもつ アプリケーションソフトウェアを実装するための デザインパターンである。 ○ Wikipediaより
- 8. お前は何を言っているんだ
- 9. MVCの前にPDS ● PDSとは ○ Presentation Domain Separation ● Presentation層 ● Domain層 ○ に分離して考える
- 11. ドメイン固有言語？
- 12. ドメイン固有言語とは ● ドメイン固有言語（ドメインこゆうげんご、英: domain-specific language、DSL）とは、特定の タスク向けに設計されたコンピュータ言語を意 味する。
- 13. お前は何を言っているんだ
- 14. ドメイン固有言語の例 ● とある表現を記述する事に特化した言語 ○ WEBだとHTML ○ FlashだとMXML ○ Cocos2d-xだとgui定義するlua ○ Unity ■ シーンファイル ○ 色んな所で ■ XML系（AXMLとか、XAMLとか） ■ JSONとか ○ makefile ■ makeに特化してる
- 15. PSDとは Domain層Presentation層 ● ドメイン固有言語 ○ HTML ○ XML ○ JSON ● 汎用言語
- 16. 汎用言語？
- 17. 汎用言語 ● プログラム言語、スクリプト言語 ○ C ○ C++ ○ Java/Scala ○ Haskell ○ C#/F#/VB ○ Python ○ ruby ○ PHP ○ JavaScript ○ ActionScript
- 18. PSDとは Domain層Presentation層 ● ドメイン固有言語 ○ HTML ○ XML ○ JSON ● 汎用言語 ○ C++ ○ C# ○ ActionScript 分離
- 19. 分離できたのは良いが ● P層だけではアプリはできない ● 同じくD層だけでもできない ○ makefileみたいなmakeのためだけに存在するドメイン 固有言語はD層なんか当然必要ないが ● ゲームクライアントのようなリッチなアプリケー ションは 繋ぐ必要がある
- 21. アジェンダ 1. MVCとは 2. そもそもなんでMVCPDSをするのか 3. MVCの各役割 4. MVCした後にできる事、すべき事 5. ゲームエンジンとMVC
- 22. 僕たちが基本無料でお金を稼ぐには
- 26. 変更しようとすると ● ２種類のバグが出る ○ ロジックのバグ ■ そもそも正常に動かなくなった ■ 正しく操作しているのに落ちた ● 頑張って直してください ● そもそも出しにくくする ○ テストするとか ○ UXのバグ ● 正常に動作はしているけども...... ■ UIが使いにくくなった ■ ゲームバランスが崩壊した ■ 動作がもっさり、重い
- 27. なので
- 30. つまりPDSとは 汎用型特化型 ● ドメイン固有言語 ○ HTML ○ XML ○ JSON ● 汎用言語 ○ C++ ○ C# ○ ActionScript ここのやり取りを 標準的なインターフェイスに基づいて 接続させる
- 31. やりたいこと GUI CUI struct Character { public int Level; public int HP; } class Battle { void Attack() { character.HP = 0; } } 標準的な インターフェイス
- 32. アジェンダ 1. MVCとは 2. そもそもなんでMVCPDSをするのか 3. MVCの各役割 4. MVCした後にできる事、すべき事 5. ゲームエンジンとMVC
- 35. Viewってこの中でどっち？ GUI CUI struct Character { public int Level; public int HP; } class Battle { void Attack() { character.HP = 0; } } 標準的な インターフェイス
- 36. View ● ユーザが直接見る部分 ○ HTML ○ DirectX ○ MXML
- 38. Model ● (3Dとかのモデルではない) ● アプリケーションの処理を行う部分 ○ ダメージ計算したり ○ 座標計算したり ■ Modelって名前意味不明だよね ● PDSのDomainも意味不明だよね ● ロジックとか言われてる
- 41. 今までの知識で MVCを整理
- 45. Controllerの仕事 1. ModelとViewの橋渡し a. ContollerはModelとViewを持っている b. Viewが表示する内容を取得できるようにする
- 46. ユーザ View ユーザの見せる部分 Model 計算する部分 Controller ５０！！ ダメージは５０やで Controllerさんに教えてもらった Modelさんの計算結果見ちゃお 仲良し
- 48. Controllerの仕事 1. ModelとViewの橋渡し a. ContollerはModelとViewを持っている b. Viewが表示する内容を取得できるようにする c. Modelの更新通知をViewに投げられるようにする
- 59. Viewのもう一つの役割
- 61. View ● ユーザが直接見る部分 ○ HTML ○ DirectX ○ MXML ● ユーザが直接入力する部分 ○ ボタン ○ テキストボックス ○ タップ（クリック） ○ ドラッグ＆ドロップ
- 63. Controllerの仕事 1. ModelとViewの橋渡し a. 描画部分 i. ContollerはModelとViewを持っている ii. Viewが表示する内容を取得できるようにする iii. Modelの更新通知をViewに投げられるようにする b. 入力部分 i. Viewによって呼ばれたイベントと、実際に行う Modelの処理を関連付ける
- 65. アジェンダ 1. MVCとは 2. そもそもなんでMVCPDSをするのか 3. MVCの各役割 4. MVCした後にできる事、すべき事 5. ゲームエンジンとMVC
- 67. 汎用言語側 ● ちゃんと動作保障できたDLL単位で分離できれ ば、資産になる ● コードを共通化することで保守部分が減る ● 車輪の再発明も少なくなる ライブラリ化の恩恵を 受けやすくなる
- 68. ドメイン特化言語側 ● ゲームエンジンUnityを使用しないツール ○ 汎用言語側を使いまわして作成 ● 運用ツールを効率よく作成 ○ .NETの十八番な ■ PowerShellでさえDLL使える ● 設定ツールを共通化 ○ 設定ツールが吐き出したテキストの読み書きのインター フェイスとかスタジオ内で共通化しても良いレベル ツール作成が楽に！
- 70. クライアント サーバ
- 72. View ● クライアントから受け取る部分 ○ ユーザからイベントを受け取るのと一緒 ● クライアントへ通知する部分 ○ ユーザに見せるのと一緒
- 73. ● 実はPDSはクライアント側だけで適応される概 念ではない ○ 似たような考えはサーバでも必要 ○ プロトコル受け取った部分にロジックを書くのはナンセン ス ■ もっとも、この辺は最初の設計思想などが深く絡んで くるので、後からやりづらい部分もある ● そもそもフレームワークはこのレベルで考えてなきゃダメ ○ ツールでも使うもの多いよね ■ 確率とか調べるのツール絶対いるよね ● ガチャとかスキルとか ○ デバコマとかナンセンス ライブラリ化
- 75. ● 統合開発環境 ○ VisualStudio ○ XCode ○ Eclipse ■ なんかいろいろある IDE
- 76. ● MVC化はそもそも単純にファイル数が増える ○ 手間を嫌ってMVCやらない選択肢は無い ○ ファイル数増える分を吸収するためにIDEを使う ■ ここにおけるGUIの威力って実は凄い ○ IDEだとGUI作成機能だってある ■ ゲームだとゲームエンジンによっちゃうけど ● 効率よく良い物を作り上げられる なぜIDEが必要か
- 77. ● 汎用言語を最大限活用できる ○ C#なんかは言語そのものがIDEにフレンドリー ■ 入力補完 ● 当然のようにエラー出ててもインテリセンス効く ● 型やスコープ、履歴から最適な候補を選んでくれる ● typoも補正してくれる ■ 自動実装系 ● スマートタブ ○ メソッドの自動実装 ○ クラス名から判断して自動でusing ○ インターフェイスや抽象クラスの自動実装 ● スニペット ○ for/foreachは当然 ○ switch(enum)で全case列挙してくれる ■ 当然break;まで なぜIDEが必要か
- 78. ● ライブラリ化 ● IDEの使用 ● テスト MVCを理解した後にすべき事
- 79. ● そもそもテストはテストが目的ではない ○ バグを出さないようにするのが目的 ■ チーム全体でバグを出さない自信があるならテスト は必要ない テスト
- 80. ● 単体テストしやすい環境って言うのもある ○ ただBooleanでやれば良いってモノでもない ○ 単体テスト書く時にIDEの力を借りると ■ テストファースト ● メソッド関数の自動生成機能とかある ■ テストのデバッグ ● ブレークポイント打つだけ ■ いくつか選択してテスト ● チェックリスト付けるだけ テスト
- 81. ● 他のテストとか ○ いろいろ各環境で考えなきゃいけない部分 ○ コストと成果のトレードオフ ■ 自動化！自動化！ ● リファクタリング ○ PDSしてるとこの辺も楽になる ○ ロジックのリファクタリングは当然 ● 分離してれば各コンポーネント毎でタイマー使っ てパフォーマンス計測もしやすくなる テスト
- 82. ● ライブラリ化 ● テスト ● IDEの使用 ● インターフェイスのテンプレ化 ○ 開発者はとあるラインに沿って開発できるべき ■ 基本的にRailsと同じ方針 ● DryとかYagniとか良いと思う ○ この辺のインターフェイス作成は経験者の仕事 ■ ノウハウが活きる部分だと思う MVCを理解した後にすべき事
- 83. ● ツールの作成 ○ ロジックが分離できるメリットは大きい ■ rubyでもPythonでも ■ .NETならより幅広いリッチなツールが作れる ● Unity起動せずにオンライン戦闘デバッグとかできる ○ できるだけじゃなくて、楽にツールが作れるのが大事 ■ C++でもJavaでも ● ロジックなんて環境依存なもの少ないはず（だよね？）だから、コ ンパイラ依存少ないと思う MVCを理解した後にできる事
- 84. アジェンダ 1. MVCとは 2. そもそもなんでMVCPDSをするのか 3. MVCの各役割 4. MVCした後にできる事、すべき事 5. ゲームエンジンとMVC
- 85. ● ゲームエンジンによってMVCパターンは違う ○ ドメイン固有言語が変わるのだから当然 ○ というかそもそも設計方針が違う ● 今回紹介するエンジン ○ Flash ○ Unity ○ Cocos2d-x ゲームエンジンとMVC
- 86. ● やるべき事は一緒 ○ PDS ■ 見た目とロジックの分離 ○ すべてにおいて大事な概念 ■ ViewHelper ● XAML/C#だとコードビハインド ● 汎用言語で書かれるのが普通 エンジンごとに方針は違うが
- 87. ViewHelper テキストボックス View ViewHelper <GUI> <TextBox name=”textbox1”/> </GUI> TextBox textbox1; == textbox1 = getComponent(“textbox1”);
- 88. ViewHelper ほげふが～～ View ViewHelper <GUI> <TextBox name=”textbox1”/> </GUI> TextBox textbox1; == textbox1 = getComponent(“textbox1”); == textbox1.text = “ほげふが～～”;
- 90. ViewHelperとModel なにもないよ ViewHelper Model class TextBox : IObserver { private TextBox textbox1; private Character character; public void Update() { textbox1.text = “HPは” + character.CurrentHP; } } class Character : Observable { public int CurrentHP { get; } public void Start() { CurrentHP = 50; Observable.Update(); } }
- 91. ViewHelperとModel なにもないよ ViewHelper Model class TextBox : IObserver { private TextBox textbox1; private Character character; public void Update() { textbox1.text = “HPは” + character.CurrentHP; } } class Character : Observable { public int CurrentHP { get; } public void Start() { CurrentHP = 50; Observable.Update(); } } 標準的なインターフェイス
- 92. ViewHelperとModel なにもないよ ViewHelper Model class TextBox : IObserver { private TextBox textbox1; private Character character; public void Update() { textbox1.text = “HPは” + character.CurrentHP; } } class Character : Observable { public int CurrentHP { get; } public void Start() { CurrentHP = 50; Observable.Update(); } }更新通知
- 93. ViewHelperとModel HPは50 ViewHelper Model class TextBox : IObserver { private TextBox textbox1; private Character character; public void Update() { textbox1.text = “HPは” + character.CurrentHP; } } class Character : Observable { public int CurrentHP { get; } public void Start() { CurrentHP = 50; Observable.Update(); } } 描画
- 94. ● IMXMLObjectインターフェイス ○ MXMLにタグ付けできるViewHelper ○ あんまり使ってるとこ見たこと無い ■ というかMXMLのscriptに直接書く人いる ● そりゃスパゲティになる Flash
- 95. ● MonoBehaviour ○ 実際に動くモデルに付随する「ViewHelper」 ■ コルーチンを使うロジックなんかにも使うけど ○ 当然ここにロジックを書くべきではない ■ 結構やっちゃいがち ● 物理エンジンとの棲み分けもあるし ■ というかサンプルが微妙い Unity
- 96. ● 自前のViewHelper ○ ViewHelperを作りやすい構造は必須 ■ ただどうしてもViewの要素が多くなるとしんどい ● Flashでも変わらないけど ○ 自前で書くハードルが高い ■ というか知識が無いのにいきなり書けない ● MonoBehaviour,IMXMLObjectみたいに用意されてない Cocos2d-x
- 97. ● イマドキの開発でPDSの考え方は必須 ○ みなさんP層にロジック書いてませんか？ ○ どうしようもなくてstaticにしてませんか？ ● IDEのサポート受けていこう ● MVCは使う環境に則った方針でやる ○ 新しいエンジン触るときはまず最適解を ■ あとから変更とか絶対無理 ● 経験ある人の大仕事 ○ ViewHelperを作ろう まとめ
- 98. ● 理想 ○ UIデザイン ■ デザイナーがダミーデータでUI/モーションを作る ■ エンジニアが繋ぎこむ ■ 完成 ● デザイナーさんの協力も必須になってくる ○ そもそも無くしたい ■ 突然ボタンが効かなくなるとか ■ 旧コンポーネントの使い勝手が悪いから新コンポー ネントへの移行とか ● 旧コンポーネントがそもそも改修できないとか ■ 似たUIなのに挙動が違うとか ● なんで同じの数回も実装してんの？ 将来的には
- 99. Let's 疎結合
- 102. Mvvm Cross
- 104. ViewModelとは ViewModel View ● 汎用言語 ● 使用するModelの読み込み ● Viewに合わせて変換 ○ enum Week.Sunday ■ 日本：日曜日 ■ 英語：Sunday データバインディング
- 105. Mvvm Crossとは ● Xamarin（Mono）で使われる技術 ● Crossのとおり、マルチプラットフォームで MVVMを達成しようというやつ ○ Windows(.NET) ○ MacOS X ○ Android ○ iOS
- 106. Viewは各プラットフォームに合わせる ● Windows：XAML ● Android：AXML ○ XamarinのAndroidのUIエディタ凄い良い ● iOS：StoryBoard
- 108. Portable Class Library(PCL) ● PortableなDLL ● iOSやAndroidなんかでも使えることを保障 ○ 自作できる ■ 自分でどの環境に対応させるか選べる ● DLLごとコピペ移動で使える
- 109. PCLで共通化 ModelView ViewModel Portable Class Library
- 110. MvvmCross ModelView ViewModel Portable Class LibraryView View Mvvm Cross ViewModelも共有化できる！
- 111. ご静聴ありがとうございました