はじめに
様々な言語で「デザインパターン」の本が世の中にありますが、筆者個人の経験では
いまいちピンとこない例 いまいちピンとこないコード で説明されてることが多く、
結局これっていつ使うの？ という疑問に答えるには仕事仲間等との議論をしないと
辿り着けないことが多々ありました。
そこで特に「ゲーム開発ではどう使うか？」にフォーカスを当てて、実践的な例を交えて
デザインパターンの説明の需要があると思い記事を作りました。
デザインパターンを学ぶ理由
デザインパターンを学ぶ理由としては
- 車輪の再発明の防止
- 長文で読みにくいコード（可読性の低いコード）を減らす
- コードを疎結合にして変更に強くなる(変更時のコスト・変更箇所を減らす)
- モジュールとして使いまわせるように、コードの再利用性を高める
といった効果を期待できます。
対象読者
Unity 全くの初心者(インストールしただけで触ったことがないような方)はお断りです。
最低限以下のことは理解・経験を積んでおくことが必須になります。
- MonoBehaviour 継承クラスでコードを書いたことがある
- C# のピュアクラスを用いた自作クラスを作ったことがある
- クラスの継承という概念は知っている
そのため、脱・初心者 中級者へのステップアップ として デザインパターンを学ぶ のが良いと思います。
デザパタ記事リンク
生成系
構造系
様態・ふるまい系
- Chain of Responsibility パターン
- Command パターン
- Interpreter パターン
- Iterator パターン
- Mediator パターン
- Memento パターン
- Observer パターン
- State パターン
- Strategy パターン
- TemplateMethod パターン
- Visitor パターン
Adapter パターンについて
Adapterパターンとはあるクラスが特定のインターフェースを持っておらず、そのクラスを編集不可能な状態のときに特定インターフェースを使えるようにするデザインパターンの一つです。
Adapter パターンの使い所
ゲーム開発においては「売り切り（買い切り）」のゲームではかなり効果が薄いデザインパターンです。
しかし、「運用系ゲーム」および「外部SDKを多用する開発現場」では特に威力を発揮するデザインパターンです。
SDKの共存
ゲーム開発でSDK_Aを利用していたところ、別のSDK_Bも追加で使うなんていう場面があったりします。
スマホゲームならSNS連携などがまさにこの事例ですね。
TwitterAPI, Facebook, LINE, Instagram... 特にビジネス都合でアプリ側に連携を対応してほしいと急遽開発現場に飛び込んでくるのは炎上プロジェクトあるあるかと思います（2敗)。
このときSDK_AのAPIを利用するためにインターフェース経由でGameアプリ側が利用していましたが、SDK_Bには同じインターフェースは存在しないことがほとんどです。
そこで、このSDK_Bを改変せずにインターフェースを実装するのがAdapterパターンです。
具体的にはSDK_Bを内部に保持して目的のインターフェースを実装した新規クラスを用意する形です。
先ほどのクラス図に適応すると以下のようになります。
クラス SDK_B_Adapter がAdapterパターンそのものです。このように実装すればSDK_Bに手を加えることなく 開発者側で自由にコードを組むことができます。
ゲームロジックの応用例
レアケースではありますが、例えば「スキルの転用」という意味では先ほどの例に近いものがあります。
たとえばPassiveSkillとActiveSkill でスキルが分かれてる時に、片方のスキルで実装したのをもう一方のスキルとして利用したい場合などでもAdapterパターンは有効です。
（まぁスキルをちゃんと抽象化しておきましょうという正論は置いておいて）
他にも「武器（装備）にスキルスロットが追加された」等、長年運用をしているゲームだとよくある新機能の要素で
既存機能の組み合わせで無理やり表現する時などに役に立ちます。
まとめ
Adapterパターンは特にSDKの組み込みで威力を発揮するデザインパターンです。
インターフェース・SDK双方に手を加えることなく自然に繋げる効果としては非常に大事なデザインパターンなので
覚えておくと損はないでしょう。