はじめに
システム開発を行っていると疎結合という言葉を聞くことは少なくないだろう。ゲーム開発においても然りである。しかし果たして疎結合を意識した設計がゲーム開発において利益をもたらすものなのだろうか。そもそも疎結合とは何であり何の目的で疎結合を意識して開発を行うのか、それを正しく理解して取り入れているエンジニアはどれほどいるのだろうか？
ここではゲーム開発における疎結合の有効性を論じる。それ以外の業種での有効性は基本的に考慮の対象外であることをあらかじめ断っておく。
疎結合・密結合のメリット・デメリット
疎結合の対義語は密結合である。そしてこれらは表裏の関係であり一方のメリットはもう一方のデメリットとなる。
あらためて一般的に双方のメリット・デメリットとして解説されているものを洗い出してみよう。
| 疎結合 | 密結合 | |
|---|---|---|
| 保守性 | 高い | 低い |
| 再利用性 | 高い | 低い |
| テスト容易性 | 高い | 低い |
| コードの複雑性 | 複雑 | 単純 |
| 管理容易性 | 難しい | 易しい |
| パフォーマンス | 低い | 高い |
概ねこんなところと言える。前半が疎結合のメリットで後半が密結合のメリットということになるだろう。
まずは上記を踏まえた上で次へ進める。
疎結合は何のためか
それにしても疎結合（loose coupling）…奇妙な言葉である。無結合や非結合というわけではない。結合してそうで結合していない少し結合している状態である。0か1かの厳格に白黒を付けるシステム開発の世界でこんな曖昧な表現がまかり通っているから不思議だ。
ともかく疎結合とは何なのか、調べてみるとこのような説明を見かけるだろう。
疎結合とはモジュール同士の関連性が低く互いの独立性が高い状態のこと
モジュール…？
この言葉、IT関連の技術解説などではよく聞くもののゲーム開発の現場ではほとんど聞くことがない言葉である。これまた果たしてこの言葉の意味を正しく理解しているエンジニアはどれほどいるのだろうか？
モジュールとは
モジュール（module）の意味を調べると「部品」という言葉が出てくるがこれでは余計意味が分からない。するとちょうど部品を表す英語の使い分けを解説しているページを見つけたのでそちらを参考にさせていただきたい。
「部品」の英語を使い分け parts→components→moduleの違いを把握しよう
- parts(パーツ)は個々の部品
- components(コンポーネンツ)はpartsがいくつか合わさって機能を持った状態
- module(モジュール)は装置を構成する機能としてまとまった交換可能な構成体
つまりモジュールとはある程度機能が独立して動作するようになったパーツの集合体と言えるだろう。ここでエアコンを例に解説してみたい。
- パーツ…ネジやフィルターなど
- コンポーネンツ…冷却装置や電源など
- モジュール…リモコンなど
ネジなどそれ以上分解できないものはパーツにあたり、冷却装置や電源など特定の機能を有するようになった集合体であるが本体から分離不可能なものはコンポーネンツにあたり、リモコンのように本体とは独立して動作が可能になったものをモジュールと呼ぶのが妥当ではないだろうか。
そして部品をパーツからコンポーネンツそしてモジュールへと昇華させようとした場合、必要となってくるのが疎結合と言えるだろう。
ゲームにおけるモジュールとは
さてモジュールの意味を抑えた上でゲームの構造を見ていきたい。ゲームにおけるモジュールとは何だろうか？
ゲームはかつてのゲームウォッチであったりあるいはアーケードゲーム機のようにソフトウェアとハードウェアが一体になっているものが多くあった。ソフトはハードと分離不可能なコンポーネンツだったのだ。
それがファミリーコンピュータの登場でソフトとハードが分離されるのが一般的となった。ゲームハードがあればゲームソフトを入れ替えるだけで様々なゲームを楽しめるようになったのである。これはゲームソフトのモジュール化と言えるだろう。つまりゲームソフトそのものがモジュールなのである。
そして現在のゲームソフトはデジタルコンテンツ化が進んだものの今でも光学ディスクやカセット形式で販売しているものもあるが、いずれにせよ1ソフトにつき1個体である。分離してそれぞれ独立して機能するようなものはない。（中にはディスク2枚組とかで販売しているものもあるが、分離できるものではなく2枚合わせて1ソフトである。）
疎結合が適用できるのは物理的に分離できるもの
つまるところ、ハードとソフトの分離こそゲームにおける疎結合の最たるものである。そもそもエアコンにおける本体とリモコンの関係においても、物理的に分離できるものにおいて疎結合は初めてその意味があると言える。
その意味で分離不可能なゲームソフト内のシステムを疎結合化しようというのは、その試み自体が馬鹿げている。
実際のところ、ゲーム内のものは全て密接に関係しあっている。キャラクターがいて装備品やアイテムがあって、それらは全てゲーム中で用いるものである。それらは仕様の段階ですでに密結合している。無理に疎結合化しようとしても開発を進めればすぐに破綻してしまう。
疎結合のメリットはゲーム開発でも有効か
改めてこちらで触れた疎結合のメリットとされるものを見ていきたい。疎結合にすると保守性と再利用性が高まるそうだ。それはゲーム開発でも当てはまるのだろうか。例を挙げて見てみよう。
エンジニアのあなたはあるチームでアクションゲームを開発している。そのゲームは敵を倒しながらステージを進めるというもので、操作するキャラクターにはステータスがあり、HP・攻撃力・防御力の3種がある。また装備品があり、装備するとこれらのステータスのいずれかが上昇するというものである。
ところが開発を進めていると、現状の仕様ではゲームとして物足りないという結論が出た。そこでプロデューサーは梃入れのため次のような仕様変更を決めた。「魔法を使えるようにしよう！そのためにはキャラクターのステータスに魔法攻撃力・魔法防御力を追加する！」
さて開発現場では何が起こるだろうか。保守性と再利用性を考えたシステムを組んできたあなたはこう考えるだろう。「簡単簡単、パラメータの変数に魔法攻撃力・魔法防御力を追加するだけ。」
しかし実際はそんな単純なものではない。魔法を使うとなったらキャラクターに魔法を使うモーションが必要だ。さらに魔法使用によるエフェクトも必要となる。ここではクリエイティブアーティストの出番だ。彼らがモーションやエフェクトを製作してくれる。そしてそれを組み込むのはあなたの仕事である。
次にステータスだ。変数に魔法攻撃力・魔法防御力を追加して終わりではない。それを画面上で確認できるようにする必要がある。キャラクターのステータス画面というのはどのゲームでも付き物だ。そこに既存のHP・攻撃力・防御力に加えて魔法攻撃力・魔法防御力の項目を追加しなくてはならない。ここではデザイナーの出番だ。彼らが最適な画面になるようデザインの調整を行う。そして調整された画面に追加されたデータを反映させるのもあなたの仕事である。
→
同様に装備品についても変更が発生する。装備品の強化・合成なんてあったならこれらも変更の対応を行わなければならない。
そしてこうした追加によってゲームバランスが変わってしまう。そこで既存のキャラクターや装備品のステータスの調整を行わなければならない。ここはプランナーの出番となる。ダメージの計算式も変更する必要があるかもしれない。その時もあなたの仕事である。
はい、やることが見えてきましたね。さあみなさん！お仕事の時間ですよ！…で何の話だったっけ？ああ疎結合ね、それなんか意味があったっけ？
システムで少しばかり疎結合を意識してみて保守性・再利用性が多少なりとも上がったとしても現実はこんなものである。
また疎結合にするとテストが容易になるという。単体テストやテストコードのことを指すのだろう。これもこちらの記事で触れたがゲームにテストは不要である。また単体テストなるものもやはり物理的に分離できる単体で初めて用をなすものだ。エアコンのリモコンも温度設定や風量調整の動作確認はリモコンだけで行える。それが単体テストでありエアコン本体に接続して行うのが結合テストになる。
そしてデメリットのコードの複雑性・管理容易性が悪化するのは非常に厄介だ。IDEで参照関係が追えなくなっていたりすると最悪である。そしてパフォーマンスはゲーム開発で最優先で解決すべき課題であるから、これが低下してしまうのはもってのほかである。
サーバーサイドとクライアントサイド
ところでゲームソフトは分離不可能な1個体と書いてきたが実は例外がある。それがサーバーサイドの存在である。昨今のゲーム、特にソーシャルゲームはサーバーサイドとクライアントサイドで構成されていることが多い。クライアントサイドとはフロントエンドとも呼ばれユーザーの手元にあるアプリやゲームソフト本体のことで、所有するユーザーないし生産されたパッケージの数だけ存在する。対してサーバーサイドはバックエンドとも呼ばれ数個程度のサーバー（ゲームの規模による。APサーバーとDBサーバーがあり、それらが複数ある場合に振り分けるロードバランサーなどがある。）で全ユーザーのデータを管理している。しかし基本的にユーザー側が介入できる領域ではないため、通常はサーバー・クライアントが意識されることはない。
この二つは物理的に分離されており、疎結合であることが望まれる。というか、使用している言語も違うことが多いので疎結合にならざるを得ない。
まとめ
疎結合とは部品をモジュールに昇華させるための概念で、物理的に分離できるもので初めて効果を発揮する。ゲームにおいてはソフトウェアとハードウェアに分離された時点で疎結合化は達成されており、他にクライアントとサーバーで疎結合化がなされている。
ゲームソフトの内部システム間で疎結合を目指す行為は、そもそも仕様のレベルであらゆる要素が密に関係しあっているためナンセンスと言わざるを得ない。むしろコードが複雑化したりパフォーマンスが低下するなどの悪影響が目立つ。
改めて疎結合とは何なのか、疎結合という言葉だけ一人歩きしていないかを振り返ってみる必要があるのではないだろうか。