構築1 †
Rubyを使ってAIやゲームロジックについてのプロトタイピングをおこなってきました。 いよいよこからは、Webアプリケーションとして動作させるための、構築作業をしていきましょう。
Webアプリケーションとしてプログラムを動作させるためには、
- ユーザーインターフェース・プログラム
- サーバーサイド・プログラム
の二つの独立した機能を実現し、双方のインテグレーションをしなければなりません。 プロトタイププログラムは、機能がクラスで分離されてはいますが、サーバーとUIの 役割を一まとめにした密結合で原始的な状態です。 それぞれの部位で使う技術の選択と実現方法を順次検討していきます。
外部仕様 - UI - の検討 †
ユーザーインターフェース(UI)の設計は、外部仕様の一部分として再度検討します。 本ゲームは単純なものですが、ゲームのように対話性が高いプログラムのUIを 行き当たりばったりで作成するのは効率的ではありません。 実現すべき表現がどのようになるか、シンプルでもよいので、画面設計をしておきましょう。
まずは、ゲームを開始する前のルール選択画面のレイアウトです。
続いてゲームプレーにおける画面レイアウトです。
画面設計は、特別なツールを使って描く必要はありません。紙とペンでレイアウト すれば十分です。必要なコンポーネントがもれなく入っているか、表示したときに 見えなくなってしまったり、情報が多すぎて分かりにくかったり、使い勝手が悪かったり しないか、想像力を働かせて描いてみましょう。
最終的にプログラムにしたときに、設計に不備が見つかったり、よりよいアイディア が出てきて、元の設計と異なることもあるでしょう。システムを完成させる上で、 全体の方針がぶれたりしないように、UIについてもプログラミングをはじめる前に きちんとした準備をしておくことが重要です。
本セクションの作業は、Walter Fallプロセスでは早期フェーズでやっておく作業 の一つです。Webアプリケーション開発では、採用する技術の妥当性や、環境の 変化に柔軟に対応できるように、 (今回の製作でも採用している) XP + Aglie Modeling などの反復的な開発手法 が適しています。ここで、今まで曖昧にしていたUI設計や、以下のセクションで 設計するシステムのシーケンス定義をおこなうのは、方針決めのフェーズを再び おこなうことです。また、この時点て定義している部分も、厳密さよりも今の 時点で十分なことだけを設計して、後の変更を受け入れる覚悟をしておきます。
相互作用設計 †
本システムには、Player, フロントエンド(Web Browser上で動作するUI部分), バックエンド(サーバーサイドで、ゲームロジックやAIを担う)、 の三つのアクターが存在します。 これら三つの中で、どのようなタイミングで、どのようなメッセージのやりとりをおこなうか、概要を設計しておきます。 それぞれのアクター間のやりとりは、UMLのシーケンス図を使って記述します。
Webアプリケーションは、プログラムで意図的に状態を保持しなければ、 サーバーサイドに到着するリクエストは、 毎回独立したリクエストと解釈されます。 これを、ステートレスなプログラムといいます。 サーバーは、前回の接続状態を覚えていませんので、 ゲームなどでは、前の手番で何を指したのか、といったことも、 そもそも誰が接続に来たのかも、すっかり忘れてしまいます。
ステートレスな状態ではいろいろと不便があるため、プログラム を組む上で工夫が必要です。 一般に、サーバーサイドで、ユーザー状態を保存するには、 セッションという、利用者の接続をユニークに識別する情報を、 リクエストごとにフロントエンドとバックエンドの間でやりとりする手法を用います。 セッションを保存するには、CoockieやHTTPのPOST (セキュリティ的はお勧めできませんがGET) メソッドなどの引数として情報をやりとりします。
と、ここまで振っておいて何なのですが、本システムでは、セッションを用いません。ゲーム局面、ルール、プレーヤー情報ををリクエスト毎にやりとりしても、 nimであつかう情報量は、たかだか数100byteで足ります。また、AIについても、 ゲームのコンテキストをまったく考慮しないでも問題ないことは、ここまでの 分析から明かです。以下のシーケンスは、セッションを用いずとも、 ゲームの進行ができるようにメッセージを定義しています。 セッション管理をしない分、プログラム構造をシンプルに保てます。
シーケンス図:ゲーム開始時
シーケンス図:ゲームプレー中
このように、シーケンス図を使うことで、アクター間で、どのようなタイミングで情報のやりとりが必要か、浮き彫りにできます。 ゲームのようなリッチ・インターフェース・アプリケーション(RIA)は、フロント・エンド部分でイベント駆動型の アーキテクチュアを採用しますので、アクター間の相互作用を意識しておくことで、作り上げるサブシステムに 必要なAPIを明確にでき、サブシステムごとの独立したテストがやりやすくなります。
次のフェーズでは、UI部分の実装を開始しましょう。
- ...つづく (2009/5/18)