原始的でありながら複雑なインベーダーゲーム
また、ここしばらく静かだったわけですが。
それもそのはずで、裏でしこしこと小さなゲームを作っていたのですよ。それについてはなんとか完成したのでこちらの「最萌支援奏」 (https://www.fumi2kick.com/tohomoe/) を参照して下さい。
まあ、こういうときサイトの更新がぺっとりと止まり如何に自分が並行作業できない人間かというのを痛感する次第でもあります(笑)。
あ、「また東方最萌トーナメントかよ」というツッコミは無しの方向でお願いします。
このゲームも毎度の事でオープンソースだし、趣味で作った小さなプログラムなのですが
、今回はソースだけでなく Doxygen によるドキュメントと UML 表記のクラス図が付いていたりします。
実はこっちの方が今回の制作の意図だったりするのですな。
ゲーム自体はインベーダーゲームクローンで、それにちょっとした弾幕が付いたというアレンジがなされています。とはいえやっぱりインベーダーゲームなので、構成要素はシンプルです。
なのでモデリングの規模として適当で、ゲームを UML 形式のモデリング手法を用いて、設計するといったサンプルにもってこいなのではないかと考えたわけですよ。
まあ、インベーダーゲームってゲームの原点であるくせに面倒な構成だったりもするのですが、これより簡単だとあまり解説する意味もないのでそういう意味でも丁度良いところでしょう。
ゲームを UML でモデリングしよう、という試みはいくつも google でひっかかりますし、良質な解説もたくさん見受けられます。
慶応大学にあった「オブジェクト指向分析入門」に置いてある「ユースケースの書き方(PDF)」 の中では実際にインベーダーゲームを題材にモデリングの解説をしていて、そのクラス図もなかなか良いところを突いていると思う。
しかし、これらの多くが UML 側からのアプローチでゲーム制作の現場からではないのですな。
なので、実際にゲーム開発をするにあたってクラスレベルでのオブジェクトモデリングを行い、それが完了してからコードを書き始めてみたのです。まあ、途中でメンバやメソッドを追加削除したりはしましたがクラスと構成は最初に書いたクラス図を維持したまま完成に至っています。
何はともあれ動いているゲームとソースコードがあるというのは大きな説得力になるのではないでしょうかね。
しかし、インベーダーゲームでこれくらいの規模になるのだから、今時のゲームを作ることを考えるとぞっとしますな。
コレより大きいと、さらに大きなモジュール単位での取りまとめとそのモジュールの管理になっていくので、モデリング手法としてはそんなに変化はないのですが。
ちなみに本業の方ではシーケンス図を多用かつ重視するのですが、今回シーケンス図は用いませんでした。
理由としては、ゲームは全てのオブジェクトが平行で動くのでシーケンス図として表記しにくいことと、もし書いたとしても多様過ぎて凄い数書かないとならないはめに陥るであろうといった所から。
シーケンス図が有効なのは input と output が明確な時と、モジュールが多く連携が複雑なとき、大きなステートの中の小さな流れを一つ説明する時ではないかと思うのです。
まあ、私自身が UML モデリングの勉強中なので線の引き方とか描き方とか怪しいところ満載ですがそれはご愛敬ということで。
UML にこだわる必要はないのだけれども、なんでモデリングなのかというとオープンソースに設計力をを持ち込み、設計の段階からオープンにしていくという目論見があるのですがそれはまた別の場にて。
—–