aoitaku/8

DXRubySTG制作8時間タイムトライアル

8's Issues

2nd refactoring

前置き

オープン・ソース流というのは多分、コードを送りつけてから議論が始めるのがやり方なのでしょう。
今回はリファクタリングが主題なのでコードより前に合意を取り付けていこうと考えています。
ゲームということもあり_隠された拡張性_を失わないようにしたいと思います。

リファクタリング狙いの箇所

メインループはGame.instanceとだけ関係をもつ

　メインループ中ではGame.instanceを呼び出すだけとします。
　そのためにGmae singleton class にインターフェイスとなるメソッド群の追加とGame設定を反映させるためのアクセッサーを追加します。

Game singleton class内のコンテナ・アクセスへのインターフェイス

　Game singleton class の持つコンテナーへのアクセスは、コンテナーがArrayインスタンスであることに依存しています。
　これを、アクセッサー経由としコンテナーの実装を隠蔽します。
　現在、コンテナーは格納要素の種類ごとに分離されています。この実装は望ましいと考えています。
　よってコンテナー・アクセッサーはcase文による実装になるかもしれません。

ゲームオブジェクトの統合モデル

　Player, Enemy, Bulletといったゲームオブジェクトを統合したクラスにまとめることができると思います。
　もちろん、継承先ではオーバーライドして固有の特性を持つことになります。
　実装においてはBulletにもdurabilityを入れる。といったことです。
　現状のクラスを壊さずともForwardableを使うなどの方法も考えています。

mainとゲーム・データーの分離

　ファイル分けです。
　スコープの関係があるので実装の工夫は必要です。

将来の3rd refactoringに行おうと考えていること

Itemの登場

　あおいたくさん、ゲームデザインに関わる部分です。おねがいします。

vanishタイミングの変更

　耐久度0 = vanishということですが、これを変更することになると思います。
　現時点では適切な遅延タイミングおよびvanish実行者（vanisher）が誰なのか決定できません。

ゲーム演出の強化

　スコアー表示や背景、OP、ED、etc...それらを可能とするシステム実装を行っておく。
　ゲーム演出の決定自体は、その次になると思われます。

Game#setup 内の tap ブロックの削除

Game#setup メソッドにおいて、tap ブロックを使って self をローカル変数に束縛しているが、現在は Game がシングルトンオブジェクトになっているため、self をローカル変数に束縛することなく Fiber の内側から Game オブジェクトにアクセスすることができる。
Game オブジェクトをローカル変数に束縛する必要がなくなったため、不要な tap の削除を提案する。

設計変更についての提案

リファクタリングを行うにあたって設計変更を伴うものがあります。コードを提出する前に設計者である　あおいたくさん　の確認を取りたいと思います。

Enemy, Playerクラスにあるhitメソッド内のcase判定が不要

　Gameインスタンス内で@player, @Enemies, @Bullets, @shotsとグループ別けされており、
　かつ、判定の組み合わせ方がコード化されている。
　よって、敵同士がぶつかる、自分の弾にぶつかる、といった判定は発生しません。
　現時点ではcase文によるオーバーロードは不要な機能となっています。

　このcase判定の削除すべきです。

durability処理をカプセル化する

　現在はdurabilityにかかわるコードを書く際にdurabilityインスタンス変数が親クラス側で定義されているため、アクセッサーを利用する必要があります。
　カプセル化の観点から言えばインスタンス変数の管理側に必要な処理を受け持たせるべきでしょう。
　処理の分離をするならば、メソッド名はdemolishを提案します。
　また、処理の分離が不要であればhitメソッドを親クラス側で定義してはどうでしょうか。

Gameインスタンスをシングルトン化する

　今現在はGameインスタンスは1ゲームごとに生成するようになっています。
　これをシングルトン・クラスとして実装し、グローバル情報の集約オブジェクトとしてはどうでしょうか。
　
　フロー内で注目を集めるのは、プレイヤー・オブジェクトだと考えられます。
　敵が弾を撃つ際にプレイヤーを引数に取っています。=>Enemy#fire(player)
　Gameシングルトンが存在すれば

def fire(player)
  self.gun.fire(player)
end

を

def fire
  self.gun.fire(Game.instance.player)
end

と書くことができ、fireメソッドの引数構成をPlayer#fireと揃えることができます。
　結果としてインターフェイスの整合性が取れます。

　ニュー・ゲームごとのGameシングルトンの初期化についてですが、これはGame#setupとしてすでにコードが分離されています。これを流用すればよいでしょう。

デグレード：スプライトがアニメーションしない

手動マージ時のミスによってエンバグ。スプライトのアニメーションが機能しなくなっている。

自機の画面外への移動

自機を画面外へ移動させることができてしまう。
自機の衝突判定領域が画面外に出るとその分衝突判定領域が狭くなるので、自機の衝突判定領域が画面外に出ないようにすること。