つぶやく［GTMF］ゲームデザインをUMLで。専用ツールがゲーム開発にもたらす効用とは？
 |
まず，UMLとはなにか？
UML（Unified Modeling Language）は，ソフトウェア設計のための標準的な図法である。
エンジニアであれば当然だいたいのところは把握しているだろうが，今回のセッションではもっと上流の部分，デザイナーやプランナーなどがUMLを活用すべきだというものであった。エンジニア以外ではUMLという単語自体に慣れてない人のほうが多いだろう。「languageなのに図法？」といぶかしむ人もいるかもしれないが，とりあえずフローチャートの超進化版みたいに考えておけば理解しやすいだろう。
UMLは，さまざまなオブジェクトを定義し，その振る舞いを図として記述するためのものだ。ゲームの構造をUMLで記述することによって，エンジニアとの意思疎通も簡単になる（はず）。
今回登壇したスパークスシステムズジャパン代表の河野岳史氏は，今回初めてGTMFに参加した理由を，同社のツールがゲームの設計にも使えるものではないかと考えたからだと説明した。
もちろん，UMLというのは汎用なもので特定のジャンルのソフト開発にしか使えないようなものではないのだが，とくに活用が進んでいる分野には，
- どんどん複雑になっている
- 考慮すべき点が多い
- 多人数で設計・実装をする
- バグによる被害が大きい
といった共通点があり，これはゲームでも同じなのではないかと考えたのだそうだ。複雑なものをきっちり設計するときにはUMLで描こうというような風潮はある。すでに同社のツールを導入しているゲーム企業などにヒアリングを行った結果，ゲームでも使えるのではないかと確信を深めたようだ。
ゲームの構造をモデリングしてUMLで記述し，共有する。それは意義のあることかもしれないが，単にUMLを描くのに同社のツール（Enterprise Architect）のようなものは別に必要はない。
河野氏は，UML用のツールを，単に図を描くツールとモデリングツールに分け，モデリングツールが持つさまざまな機能について紹介していった。
- 文章や表よりも分かりやすい
- 世界統一の表現
といった点で優れており，UML用の教材などもWeb上に豊富であることから，「UMLで描かれている」というだけで，独自の記法で必要になる説明を省くことができる。
では，UMLを実際にゲームで使うとどのようになるのかが実例で紹介された。まずはユースケース図を使った登場人物の管理についてだ。
登場人物クラスの下にA国，B国，C国といったクラスがあって，アクターとしてそれぞれのキャラクターが配置されている。
 |
クラス図の記法からすると，両方向の点線矢印は関連を表し，A国とB国の関連は敵対だと分かる。
点線の矢印は依存関係で，A国はC国を支配下に置いており，C国はB国に協力を申し出ている。菱形矢印は集合（合成？）を示し，どっちにしても矢印の先にあるものの一員であることが示されている。
アクターのフレンドーさんをクリックすると，実はA国のスパイであることが分かるのだがここでは気にしないでおこう。フレンドーさん関連のストーリーなど，フレンドーさんが出てくる部分はLocationに一覧されている。フレンドーさんに変更を加えたときに影響を受けるモジュールだ。
ストーリーの記述もUMLで行える。シーケンス図で，A，B，Cの3国がどのような関係にあり，そこにプレイヤーがどのように関わるのかが，時間の流れ順に記述されているのが分かる。
 |
ゲーム起動からの状態遷移については，ステートマシン図を使ってメニューの内容を説明していた。
 |
ゲーム内のパラメータの関係を管理するのにはクラス図が使われている。
 |
戦闘時のキャラクターごとの処理フローを示すのにはアクティビティ図が使われていた。具体的な戦闘部分ではなく，戦闘シーン全体の流れを示している。
 |
分かる人は分かるのだろうが，おそらくこういった図を見てもさっぱり分からない人もいるだろう。それでもなんとなくそれぞれのつながりは分かるはずだ。UMLの記法を少しだけ学べば，もう少し細かい部分も見えてくるだろう。
 |
UMLを使っている企業でも，多くは初期設計をきっちりやるために図に起こすのだが，その後はあまり使われることがないという。河野氏は，更新などの管理でもUMLの活用が有効であり，同社のツールがそれをサポートすることを示していた。
同社のEnterprise Architectのような専用モデリングツールは，単にUMLのダイアグラムを描くだけのツールとどう違うのだろうか？
まず，シナリオと登場人物の管理についてだ。シナリオはシーケンス図で表されることはすでに示したが，アクター同士のやり取りが中心となる。さまざまなキャラクターがさまざまなシナリオに登場することになるのだが，規模が大きくなるとシナリオライター一人ではまかないきれず，かといって大勢で分担して作っていくというのは齟齬が生じる可能性が上がる。そういった場面でも，UMLツールでは管理が可能となる（UMLというよりはツールの機能だが）。
 |
メニューの一覧から項目をクリックすると，それぞれのダイアグラムに切り替えることができる。下の写真を見ると，それぞれでフレンドーさん関連の部分が選択されていることが分かるだろう。
 |
 |
 |
ここで空きになっているストーリー2の部分にストーリーを加えると，マトリクス上で該当部分に登場キャラクターのチェックマークが追加されていることが確認できる。
 |
 |
これはあらゆる部分で同様に動作する。パラメータからアクティブスキルを選択してどこで使われているかを見ると，バトルと攻撃フローの部分で使われていることが分かる。ゴチャゴチャしがちな部分では，フィルタリングを適切に使うことで，影響範囲を確実に把握できるようになる。
 |
 |
 |
 |
 |
このように，どこがどこと関連しているかが感嘆に表示できるので，要素を追加・偏光する際にはどこに修正が必要になるのかなどが明確になり，メンテナンスにも有効だということだ。
そしてもう一つの使い方の例として示されたのが，ゲーム内容以外の要素を付け加えることで，プロジェクトの管理をサポートするというものだ。
下の図は，実装時期の情報を色分けして表示したものだ。初期実装時のものが灰色，最初のアップデートが黄色，その次が水色と，どの機能をどの時期に実装したのかが確認できる。
 |
もう少し遡って，リリース前の開発中の時期の進捗状況をまとめて確認しているのが次の図だ。機能ブロックごとに開発状況が色分けされている。
 |
こういった進捗をまとめた形で出力することもできる。
 |
このような付加情報は，なにを入れてもかまわないのだろうが，担当者の情報を加えることで，誰がどの程度の負荷になっているのかなども把握しやすくなるだろう。
 |
 |
 |
 |
UMLはゲーム以外の分野ではさまざまなプロジェクトで使われているシステムなので，ゲームのモデリングができないということはまずないだろう。複雑で大規模なプロジェクトほど，UMLを使ったモデリングが有効になるというのもほぼ間違いない。各部で仕様変更などが発生したときに，どこを修正して，どこに影響するのかなどをツールが教えてくれるというのも生産性を上げる要素である。
そして，ゲームに関わる人員がすべてUMLでのダイアグラムを理解できるようになれば，デザイナーが意図することを，文章などよりも正確に記述できる。そのゲームでなにをやりたいのかというのは，結局のところデザイナーしか正確に把握していない。エンジニアが実装時に判断に困ったときに，エンジニアに問い合わせなくてもUMLを確認することで，より正確に意図が伝わるようになるだろうと河野氏は語っていた。
UMLそのものが持つモデリング能力と，UMLを共通言語とすることによる組織内での明確な意思疎通の確保，そしてツールが提供するさまざまな生産性向上要素。なかなか魅力的な提案かもしれない。ちなみに，
 |
ただ，そのままではデザイナーなどに使ってもらうのは難しいだろうと感じるのも事実だ。UMLダイアグラムの機能を理解していないと，どのダイアグラムになにを描けばいいのかすら分からない。デザイナーがその意図を正確にモデリングすれば，これ以上ないほどの強力なツールとなりうるが，適当な矢印でつながれたクラス図を見てエンジニアが頭を抱えるところまでは容易に想像ができる。小規模でも実際のゲームでのサンプルを用意するなり，入力補助用のフロントプロセッサを用意するなりは必要だと思われる。
ちなみに，「Enterprise Architect」というなにやら大仰な名前のツールだが，かつてのラショナルのツールなどと比べると1桁安い（10年以上この手の話題から遠ざかっていたので最近の状況に疎いのはご了承を）。一般的なバージョンが2万7000円（税別）というのは，機能から考えるとお得なのかもしれない。評価版もあるようなので，興味のある人は公式サイトを見てみよう。
かつては「全部自社で作る」といった，なにかと古い文化を残したゲーム開発業界だったのだが，アジャイル開発が試され，ゲームエンジンが使われ，ミドルウェアも活用されと，だんだん近代的な流れをもっと取り入れるようにもなっている。今後，UMLが一般化するような未来もくるのかもしれない。
