#はじめに
これは個人の意見であり、且つMV＊を否定したりする話ではありません。
またMV＊を導入したり推奨する人間を否定したりする話でもありません。
もちろん仕事で導入が決定されているような場合は、”仕事”としてMV＊の概念に則ってプログラミングしましょう。
追記
ありがたい事に、こんな愚痴のような内容に"いいね"やコメントがつきまして、自分の伝える能力のなさに反省しきりです。
もう少しだけ、内容を掘り下げたいと思います。
(以降の太字は追記です、最初の文章はTypo以外は手を入れないようにしてます)
#なぜそう思うのか
まずゲームの表示について列挙します。
- 2D表示(UIやFontやSpriteなど)
- 3D表示(モデルデータや頂点情報を直など)
- エフェクト(パーティクルやShaderなど)
項目としては3つですが、昨今のゲームグラフィックスは昔に比べて高度な処理が増えています。
(ライブラリやミドルウェアを使用しているので手軽になっていますが)
そこでMV＊の考えが出来た当時や、最近出てきた亜種と言うか新しい概念だろうと、その仕組みが追いつかないと感じています。
表示と処理を分ける的な思想は賛同できますし、行うべきだと思います。
しかし複雑な表示制御を、MV＊など数百行程度で説明できる方法を導入して全て良くなってメデタシとなるでしょうか？
MV＊の形に沿えば自動的に良くなるとは思えないのです。
むしろMV＊に沿わない表示処理などを無理やりMV＊に押し込める違和感や、たった数行で済む処理をdeledateやEventを使って回りくどいとも言える処理にしてしまう感、それらの方が目立つと感じています。
ゲーム開発者の仕事は、各職種で”ゲームを完成させる”事だと思うのです。
華麗なコーディングや技術を駆使した実装でも、受けが良い企画書を書く事でも、綺麗なグラフィックを作る事などでは無く、それらは経過でありゴールでは無いはずです。
そこでトータルで考えた時に、自分の裁量以外でプロジェクトでMV＊を強制導入して苦しい実装になる事のデメリットの方が大きいと感じたのが違和感を指摘したいと思ったきっかけです。
自分で言うのも何ですが苦しんでるならまだマシです、訳もわからず何ちゃってMV＊風なコーディングが大量発生してるチームなんて目も当てられないですよね、、
この処理ってMV＊では当てはまらないよね？とか感じたり発言があったら、この文章を読んでいただければと思います。
#私の根拠
例えばMV＊を導入した場合で、そのMV＊のMやVって流用してますか？
おそらく流用はしてないと思うんですよ。
(してる方いたら、私の事を残念な子とでも思ってください)
これはMV＊や設計、コーディング能力とかの問題ではなく、ゲームとはそういう物だと思うのです。
流用可能なレベルまで分解したら、ボタン１つのレベルでButtonViewとか作らなくてはないのでしょうか？
(と言うか、そんなレベルならライブラリやミドルウェアが用意してますよね？)
ゲームの表示なんで全てユニークな物だと思うんですよ。
そこにMV＊のデザインパターンとしての流用性は当てはまらないような気がしています。
さらにButtonViewとか例を出しましたが、最近のライブラリやミドルウェアはある程度の機能は用意しています。
そもそもOpenGLやDirectXのDraw系のメソッドを直接コールしているなんて今時コンシューマでも無いと思います。
つまり、そのライブラリやミドルウェアが用意している表示系のコンポーネントやObjectって多機能で色々なメソッドや操作機能が用意されています。
言ってしまえば、もうMとしての機能を持った物だと思うんですよ。
(ドメインロジックであってビジネスロジックでは無いと言う異論は認めます)
で昨今のスマフォゲームが話をややこしくしてるとも思っています。
具体的にはタッチ入力です。
タッチと言う事は表示領域に強く結びつきます。
つまりVが入力イベントを持つとかになる事です。
V -> C(or P) -> M -> C(or P) -> V
なんで？と思います。
Vでイベントを監視してるなら、
V -> なんらしらの処理 -> V
で良いじゃんと思うのです。
これが数種類のステート切り替えで表示をチェンジするだけのような物なら尚更です。
特に Unity なんかは表示コンポーネント(Vと思われている物)にシリアライズで切り替えリソースを登録したりするので
(この時点でVとは言えない、データ持ってるじゃん、と)
余計にMとか別なところに定義や処理があって、さらに何かの仕組みを経由して処理なんて回りくどさ爆発だと思うのです。
ここで問題は、MV＊を導入する時のVにデータやロジックを持たないと言う話なんですが、
ぶっちゃけ今時のゲーム業界は実装してみてデザインを評価するなんてしてないと思うんですよ。
実装時にはAdobeやらのデザイン側の外部ツールでインタラクション含めた評価は終わっていて、実装後にはそれらで想定されなかった修正をするだけ、大どんでん返しはほとんど無いと、
つまりVにデータやロジックがあっても問題無いのでは？と、なぜなら最初に言ったように流用なんてほとんどしないのですから、、、
私10年以上ゲーム作ってますが、MV＊で作られたプロジェクトを流用して他のプロジェクトで助かったとか見た事無いです。
(と言うか、そのレベルはUnityなどのConponentが担っているのだと思っています)
さらに踏み込むと、MV＊の仕組みでVからデータやロジックが分離されていると言う理屈は机上の空論なんじゃないかと思っていて、Vだけ入れ替えるなんてしますか？ロジックだけ流用して別ゲーム作るなんてしますか？実際にほぼ0の確率で行わ無い事を理由に成り立ちますか？と思うのです。
(もちろんコードレベルでは整理されているべきなのは否定しませんし、逆に必須だと思います)
もしプログラマの自己満足でしかないレベルならば、と言う前提なんですが、
だったら最初に言ったゲームを完成させと言う理屈からいえば、回りくどさ爆発してMV＊の仕組みに乗らない処理に悩むとかあるくらいなら使わなくて良いじゃん、と。
ただし明確な理由があるなら別です。
Disる訳ではありませんが、企画やデザイン側がアレ(?)でコロコロ仕様が変わるのにスケジュールは伸びない等、且つMV＊を導入する事でやり直し級の作業に対応できる”方法が確立”されている場合は、大いにMV＊を活用しましょう！と思います。
(実際には、そんなレベルはMV＊でも吸収しきれないんですけどね、、)
#私の考え
私はMV＊などは問題や不便を解決するソリューションだと思うのです。
それで問題が解決したり不便がなくなれば良いのですが、プログラマ個人や賛同する集団のみが自己満足レベルでしか効果を得られていないなら本末転倒だと思うのです。
表示処理とロジック処理を分けるのは良いのですが、それがMV＊とかと思いません。
例えば、Unityの例になってしまって汎用的では無いのですが、、、
- partial修飾子
- ファイル命名規則
これだけで良いと思ってます。
具体的には
MyView.cs
とあったならば、partial修飾子を使って 2 ファイルに分けます。
MyView.cs
MyViewModel.cs
で、MyViewModel.cs側のファイルに、自分がロジックやデータを思うものを宣言や記述していけばよく
partial修飾子を使っているので同じ class なので、呼び出しは delegate や Event を使う事なく、必要な箇所でメソッドやデータを呼べば良いだけです。
つまり、MyView.csには表示に関する処理のみを書いて、MyViewModel.csを消すなりコメントアウトするなりしてもコンパイルが通る状態にしておくのです。
(これってMV＊のVと同じはずです)
さらに言うまでもありませんが、MyViewModel.csで他でも使う処理が出てきたら、その処理を切り出しましょう。
(これはMV＊とか以前の話だと思いますが)
これってもはや感覚的なMV＊と言うか同じ事なんですが、MV＊とかよりファイル数やclass数、処理経路とか諸々が大分簡素になるはずです。
ここでデータの呼び方次第ではMyView.csにデータを持つ事と同じとか、色々とご指摘等があるとは思います。
しかし、そのような指摘はMV＊を導入した所で設計を出来ない人は出来ないのと同じで、個人の力量の範囲の問題で仕組みの問題では無いと思うのです。
そう言うご指摘には、MV＊でも作り次第では起こる問題ですし、そうしないように作れば良いと言う事だと思うのです。
そう、つまり人間のアナログ作業はどんな仕組み(MV＊)で縛っても間違いは起きるのです。
ならば、超簡素でシンプルな方法が言いと主張したいのです。
無理やりこじつけな部分がある等の異論は認めます(笑)
しかし私はMV＊は導入すれば無条件で良くなる的な論調に疑問を感じているので、少しでもアンチテーゼとして意見を言いたかったのです。