はじめに
ゲーム開発においてMVPパターンを導入する事例はよく見られる。しかし果たしてゲーム開発にMVPパターンを導入することは十分な恩恵を得るに値するものであろうか。ここではMVP導入のメリット・デメリットを比較しその有効性を検証したい。特に筆者は長年Unityを用いた開発に携わってきたため、Unityでの導入を念頭に論じていきたい。
なお、あくまでゲーム開発における有効性を論じるものであって、それ以外のシステム開発での有効性は基本的に想定していないことをあらかじめお断りしておく。
また他にMVCパターンやMVVMパターンというものも存在するが、はっきり言ってどれも似たようなものである。ひとまず煩雑さを避けるためにMVPパターンを対象に論じるが、同じことはMVC、MVVMパターンにも当てはまるのでそれらを含んだ内容と認識していただいて問題ない。
MVPパターンとは
まずMVPパターンとは何かを簡単に解説する。
Model-View-Presenterを略したもので設計パターンの一つとされる。
- Model - データを取り扱う階層。
- View - 視覚的に見える部分を取り扱う階層。
- Presenter - ModelとViewを仲介する階層。
つまり何らかの機能を実装する際、上記の3つに階層を分けて実装しようというのがMVPパターンの主眼といえる。
MVPパターンのメリット・デメリット
MVPパターンに関しては様々なサイトで解説されている。興味深いことに多くのサイトでメリットだけを記載せずデメリットも併せて記載しており、安易な導入を戒める注意喚起も同時に行っている。
ここではゲーム開発に限って論じると先に断ったが、どうやらMVPパターンの導入に注意を要するのは広くIT業界全般にわたって共通のことなのかもしれない。
改めて様々なサイトの解説を参考にしつつMVPパターンのメリット・デメリットをピックアップしてみよう。
メリット
- GUIの開発に有利。
- テストコードが書きやすく単体テストが容易になる。
- 疎結合な実装が可能になる。
- 関心を分離しクラスの責務が明確になる。
- コードの再利用性が高まる。
- 分担がしやすくチームでの開発に適している。
デメリット
- 最低でも3つのクラスを用意するためファイルが増える。
- コード量が増え複雑化する。
- MonoBehaviourと相性が悪い。
- MVPパターンに属さないクラスの扱いに混乱をもたらす。
- オーバーヘッドが発生しパフォーマンスが下がる。
概ね上記にまとめることができるのではなかろうか。
MVPパターンのデメリットについて
まずはデメリットから見ていこう。
1,2ついてはゲーム開発に限定された問題ではなさそうだ。どの業界においてもファイルやコード量が必要以上に増えてうれしいことはないだろう。
3についてはUnityでの開発が前提となる。そもそもUnityではInspector上に様々なファイルをアタッチして参照する実装方法が基本である。InspectorはMVPではViewにあたりアタッチされるファイルはModelにあたるだろう。つまりView上に直接Modelが張り付いているのである。ViewとModelを切り離しPresenterで媒介させようというMVPの思想と根本的に相容れない。これはMVCでもMVVMでも同じことだ。
そこでMVPを信奉する者達は脱MonoBehaviourを目指しピュアC#で実装することこそ至高とする傾向が見られるが…。それならもう「Unity使うの辞めれば？」と言いたくなる。
4,5についてはとりわけゲーム開発においては顕著だ。そもそもViewとModelに単純に分けられるものがゲームには少ない。
例えばアクションゲームなどだとキャラクターの位置座標や向き、大きさといったデータがあるが、これはViewに属するのかModelに属するのか？データである以上Modelで扱うとするなら頻繁に変化する値を常時監視しViewに通知するということを行わねばならない。そして当たり判定なんかはどうするというのか。ではViewに置けばどうなるか。すべてViewで完結するためModelの存在意義がない。当然ながらこれらを媒介するPresenterなどただの空気だ。
そしてゲーム開発においてパフォーマンスは最優先で解決すべき課題である。カクついたりローディングに時間がかかったりしてはそれだけで評価を下げる。安易にModel-Presenter-View間をメッセージでイベント通知するような実装を行うとパフォーマンスが下がるばかりでなく不具合も誘発するため慎重な実装が必要になる。
このようにデメリットに関してはどれもゲーム開発において当てはまるもっともな点と言える。
MVPパターンのメリットについて
ではメリットについてはどうか。
1についてだが、本当だろうか。後述するがMVPパターンとはGUIアプリケーションの開発現場で生まれ、Webサービス業界で発展してゲーム業界に輸入されたものだ。UI、特にキャラクターや装備品の強化合成などのアウトゲームの部分はWebページの開発手法が応用できなくもなく一見すると有効なように思える。しかしゲームはWebページよりはるかに複雑である。例えばキャラクターの頭上に名前やHPなどの情報を常時表示するUIがある。キャラクターの移動に追従してこのUIも移動するというものだ。
これらはゲームでは一般的だがWebページでは一般的に見られるものではない。これの実装にMVPがどれほど有効だろうか。前項で触れたようにキャラクターの座標というViewかModelかの切り分けの難しいものを常時監視し、UIに反映させねばならない。もちろんキャラクターのHPがゼロになってやられてしまえばUIを消滅させるような処理も必要になるだろう。そこにViewとModelを分けてPresenterで仲介して…というデザインパターンが何の貢献をするというのだろうか。
2についてだが、長年ゲーム開発に携わってきて、およそテストコードとか単体テストなる言葉を現場で聞くことがない。TDD（テスト駆動開発）とかナニソレ？状態である。
そもそもテストコードなるものを書かねばならない業界とは非GUIな界隈のようである。プログラムを実行した結果、計算結果だけ返されるようなCUIなシステムの開発で役立つものだ。その計算結果が本当に正しい計算結果なのか、たまたま期待した値が返ってるだけなのかよく分からない場合、テストコードで実証する、そういったものではなかろうか。
しかしゲームはグラフィカルそのものである。いちいちテストコードなど書かなくても実際に動かしてみれば分かることである。というか動かしてみないと分からないことの方が多い。そしてゲームは様々なデータを基盤にして動作する。キャラクターのHP、攻撃力、防御力、機動力、必殺技等々。それらのデータは一旦読み込む処理を挟んだ上でないと動作確認は難しい。一部を切り取った単体テストなどゲーム開発では現実的ではない。
3についてはよく聞く言葉ではある。お題目のごとく口を開けば疎結合、疎結合と発するエンジニアは少なくない。しかしゲーム開発において疎結合など不要な概念である。これについては後日改めて記事にしたいと思う。
4はいわゆるSOLID原則に通じる考えであろう。これはデメリットの1,2,4と表裏一体の関係にある。ゲーム開発においてそうそう都合よく分離できるものではない。SOLID原則については後日改めて記事にしたいと思う。
5についてはMVPパターンにしたから再利用性が高まるというものではない。MVPパターンを用いずとも再利用性のある実装は可能であり、結局は実装者のセンス・技術力次第である。
6については色々な開発現場を見てきたが、チームの担当割は機能ごとに分担が多く、Aさんはキャラクターの強化合成担当、Bさんはガチャの担当…といったものである。インゲームを複数人で担当することもあったが、これもキャラクターの動作部分とUI部分を分ける、といったものであった。そこにMVPパターンの有効性は見いだせない。
このようにメリットとされる部分も、他の業界ならば有効かもしれないがゲーム開発において有効と言えるものはほとんど見受けられない。
MVPパターンの成り立ちとゲーム業界に浸透した経緯
上記で見たようにゲーム開発においてMVPパターンは、デメリットはとかく際立ち、メリットはほとんど無いのが実情である。
それではなぜゲーム業界でMVPパターンが浸透しているのだろうか。その誕生と経緯を見ていこう。
1970年代にSmalltalkのGUI設計パターンとしてMVCパターンが生まれた。
その後1990年代にTaligent社がMVCを発展させる形でMVPパターンを生み出した。
元はGUIアプリケーションの設計手法として生まれたものであり、それがWebアプリケーション開発に取り入れられ広まったものと考えられる。
ここまでの経緯でゲーム業界とは直接的な関連はない。コンピュータゲームの誕生は1900年代初頭に遡りその歴史は長い。MVCとかMVPとか無関係に発展してきたのである。ではなぜゲーム業界にMVPパターンが入ってきたのだろうか。
きっかけはソーシャルゲームの誕生に始まる。2007年にFacebook、次いでGREEが発表したソーシャルゲームがその起源である。その後DeNAやコロプラといった企業が参入してくる。
これらは元来ゲーム会社ではない。またプラットフォームもゲーム機ではなくガラケーと呼ばれた携帯電話である。彼らは元々ガラケー向けのWebサービスを展開していた。そこからソーシャルゲームが生まれたのである。
つまりソーシャルゲームの起源はWebサービスなのである。そのためゲーム業界、とりわけソーシャルゲーム業界ではMVPパターンが用いられてきたというわけである。
ソーシャルゲームの今後
周知のことであるが現在のソーシャルゲーム業界はコンシューマーゲーム開発の老舗といえる企業も参入している。プラットフォームもガラケーからスマートフォンに代わって久しい。そして中華系・韓国系のアプリが市場を席巻している。
そのような環境の中でガラケーアプリ時代の手法であるMVPパターンがいまだ用いられているのは結局のところ、競争力の低下をもたらすだけではないのかと危惧する次第である。
余談：そもそもWebアプリケーション開発ではMVPパターンは有効なのか？
事前にゲーム業界に限って論ずると断りながらこのようなことを書くのも恐縮であるが、余談と思ってお付き合い願いたい。
Webアプリケーションでも余程単純明快なホームページの開発程度にしかMVPパターンは使えないと思われる。
例えばECサイトを開発する場合、フィルターやソート機能はマストだろう。商品を発売日順に並べ替えたり、星5評価の商品だけ表示するといった具合である。さてMVPパターンでこれをどう実装する？
ある人は「フィルター・ソートはModelで行うべきだ。Viewは結果をそのまま表示するだけでいい」と言い、またある人は「見た目だけの問題であるからViewだけで完結するのが望ましい。Modelのデータに手を付けるべきではない」と言うだろう。このように意見が割れる時点でデザインパターンとしては欠陥だ。そしてこれらは統一されずプロジェクトごとに実装が異なり、アサインするエンジニアは異動するたびに困惑する様子が目に浮かぶ。
まとめ
MVPパターンは机上の空論と呼ぶにふさわしく、ModelとViewに綺麗に切り分けられるシステムの開発であれば効果を発揮するが現実にはそのような単純明快なシステムは少ない。特にゲームのシステムは複雑であるため、導入するメリットは皆無に等しいと言える。
にもかかわらずゲーム開発に広く用いられているのはWebサービスを前身とするソーシャルゲーム業界がその開発手法を引き継ぎ、それが後続の他社にも広がったと考えられる。