きゃすけっとに向けてゲーム制作

 縮小しすぎてよくわからないですが、背景の演出を追加しました。 特段特別なことはやっておらず、50個ほど星インスタンスを生成して、ゲームの進行に合わせて流れる速さと残像の長さを変えているというだけで、 それだけでそれっぽく（レトロっぽく）見えるようです。 昔のゲームはよく考えられて作られていますね。

ゲームをドメイン駆動で設計するということ

とりわけゲームという分野は、「面白さ」を第一として考えるがゆえに、 アプリケーションをどのように設計していくか、ということについての話題が薄いように感じられます。 実際問題として、アプリケーションがどのような設計であろうと、また、如何に保守しにくい状態であっても、 面白さこそすべてである以上、設計手法に話題が上らないのも当然といえるでしょう。 ではゲームでドメイン駆動設計を行うメリットとは何か？ それにはまずドメイン駆動設計でゲームを組み立てる例を取って考えましょう。 例えばシューティングゲームにおいてドメイン駆動設計に基づいて組み立ててみると、おおよそ以下のようになるのかと思います。 - __ゲームアプリケーション__ - タイトルサービス - __ゲームエンティティ__ - __ゲームワールド__ - __プレイヤー__ - 弾 - 敵 - オプションサービス プレイヤーに注目して考えると、プレイヤーはまずゲーム内での戦いの舞台である__ゲームワールド__に属しています。 そして、ゲームワールドはゲームエンティティに属しています。 ここでのゲームワールドは、文字通り架空の世界となり、プレイヤーが動いたり弾を撃ちあったり、といった世界を表現します。 一方、ゲームエンティティはその世界を如何に面白くゲームとして表現するかがその存在意義です。 つまり、ゲームの進行に合わせて、ステージクリアとなればワールドを取り換えたり、あるいはポーズをかけたりといったことを行います。 ドメイン駆動設計に基づいてゲームを設計すると、自ずとドメインの役割は明確に区切られます。 これによって、ゲームの変更が容易になるのです。 例えば、敵の数を増やしたい、となった時はワールド__のみ__を変更すればいいし、 ステージのクリア条件を調整したい、となった時はゲームエンティティ__のみ__を変更すればよいということになります。 勿論、このようなオブジェクトをどの粒度にするかはアプリケーションの規模によって適切に調整する必要がありますが、 ゲームにおいてもこのような設計手法を適用可能であるということは重要なことと思います。

きゃすけっとに向けてゲーム制作中

---- プログラムを書き始めてからかれこれ十年以上経ち、 今までツールやWebアプリといったものを作ってきましたが、未だに安定して作り上げることができていないものがあります。 ゲームです。 今回、PeerCastでは毎年恒例となっている「きゃすけっと2013春」に向けて、シューティングゲームを制作中です。 今回は*オリジナリティーは一切排し*、作ることに集中することでまともなゲームを作りこむことにしてみました。 元ネタはPC-98で大変有名かつ名作のフリーソフトです。  ネーミングから配色までかなりそのまんまです。 今回はそういったところに労力をかけず、 ゲーム作りでいかに満足の行く設計ができるか、をテーマにした故の妥協です。 まだキャラクターを表示しているだけで動かないですが、少しずつ形になってきました。

MVCとは何だろうか？

MVCはその言葉自体はすでに多くの方に認識されてると思います。 Model-View-Controllerの３種に分けて設計することで、変更に耐える安定したアプリケーションを構築するという考えです。 しかしながら、このそれぞれの意味が正しく認識されてない、あるいは意味があいまいになっている事が多々見られるようです。 これはMVPやMVVMなど、MVC派生のアーキテクチャパターンでも同じことが起こっていますが、根底は同じはずです。 以下に私のMVCについて認識を整理するので、皆様のご理解のご参考になればと思います。 # Viewとは？ 画面に関する情報です。JSPやhtmlと言えばわかりやすいですね。 __ビジネスロジックをViewに含まない方がよい__という約束があるのは皆さんご存知かと思います。 具体的にはここで「コネクションを貼ってSQL文を書いて実行結果をパースして…」といった処理は書かない方がよいということです。 含めるものはせいぜい_書式の変換_程度です。 JavaScriptで動的にリストのフィルタリングをする、といった場合はその処理もViewに含めていいのかもしれません。 必要なものはあらかじめすべてControllerで用意してもらいましょう。 # Controllerとは？ Controllerは、ユーザーからの入力をもとにModelを操作してViewに伝えるのが役割です。 Webアプリケーションであれば、HttpServletを継承して作るクラスがこれに当たります。 ここでも__ビジネスロジックを含めない方がよい__という約束があります。 「コネクションが～」といった処理を書く必要はありません。それはModelの役割です。 # Modelとは？ 以上、ViewとControllerに含まなかったものはすべてModelです。 Modelでは好きなだけビジネスロジックを書いてもいいですし、もちろん好きなだけデータベースへアクセスをしてもいいです。 -------- よくRailsとかRailsとかRailsなどのフレームワークで、データベースに収納する単一のオブジェクトを「モデル」と呼ぶこともありますが、 _MVCで言うModelとは別物_だという事を押さえておきましょう。（modelを英和で調べてみましょう。modelは元々曖昧な言葉です） このアーキテクチャパターンに従うと、Modelにロジックが集中することになります。 その為、大きなアプリケーションの場合はModelが煩雑になり理解しにくくなります。 ModelはModelの中で別のアーキテクチャパターンを適用して煩雑化を避ける必要があります。 例えばドメイン駆動設計（特にその中のモデル駆動設計）の一部を取り入れるとModelを整理することができるでしょう。 -------- MVCのアーキテクチャパターンは誤解が多く見受けられますが、適切に理解すれば<del>どんなアプリケーションにも</del>色々なアプリケーションに適用できます。 (3/17 12:40 補足) Apache WicketのようにControllerに当たる部分を完全に隠蔽しているものもあるので、適用できないものもあります。 勿論MVCだけではなく、MVP・MVVM・あるいはそれ以外にもアーキテクチャパターンはあるので、 それぞれがどういったパターンになっているか抑えることで、 皆様のアプリケーションの設計の手助けになるでしょう。