Product/RectAttacker

Top / Product / RectAttacker

操作方法 (How to operation)

  • カーソルキー(Arrow key) : 移動(move a ship)
  • Zキー(Z key) / Spaceキー(Space key) : ショットを撃つ("Shot": fire a bullet)
  • Xキー(X key) / Shiftキー(Shift key) : シールドを前に出す("Shield": prevent the bullets)
↑

遊び方 (How to play)

ショットとシールドを駆使して画面上部にいるボスを倒します。 ショットは前方へ強力な攻撃をすることができます。 シールドは敵の弾を防ぐことで、ホーミング弾として相手を攻撃します。 ただし、エネルギーが必要となるため、どちらのアクションも一定時間使い続けると使用できなくなります。 エネルギーは時間経過で回復するので、効率よく使い分けして高レベルを目指しましょう。

You defeat the boss who is at the top of the screen and making full use of the shield and shot. Shot can be a powerful attack to the front. By preventing the bullets of the enemy, shield will attack the opponent as homing bullets. However, since energy is required, you will not be able to use it and continue to use a certain time of the action either. Since the energy recovery over time, it will aim at the high level by proper use efficiently.

↑

更新履歴 (History)

  • 2014.6.11 : v1.0.0 リリース
↑

ソースコード (Source Code)

↑

使用したゲームライブラリ (Game Library)

























↑

製作期間

5日 : 2014/6/8〜2014/6/12

↑

KPT

反省点や課題、次の目標

  • Keep
    • 演出周りは凝りだすと開発が長くなりそうだったので、割りきって作ったのは正解だった
    • CSVモジュールを使用し、ボスのAIをタイムラインテーブル化できたのは楽だった
      • ただし同一タイムのアクションが設定できなかったので改善が必要
    • 使って便利だった処理
      • FlxTweenのTweenアニメーション制御
      • FlxTrailのトレイル・エフェクト
      • デバッカでのコマ送り
  • Probrem
    • HaxeFlixelをそのまま使うと冗長な記述となるものがある
      • Flx*を継承する、Utilモジュールを作る、などしてコードを短くしたい
    • wavから、mp3 / ogg の変換が面倒
      • 簡単に変換できるツールを導入したい
    • サウンド関連のProject.xmlの編集が面倒
      • 自動で更新できるツールを作りたい
    • ボスのTimerがレベル更新時にリセットされる
      • 各パターンごとに、1000フレーム(≒36秒)のアクションを用意したのだけれども、全然そこまで到達しないので、もっと少ないパターンを作るだけでよかったのかもしれない
    • クラスの関数テーブルにthisポインタが渡ってこない
      • 引数渡しで渡せるけどメンバ変数へのアクセスの記述が長くなってしまうので、引数渡しはしたくない……。Haxeはそもそも渡せない仕様なのか？　よく分からず調査に時間かかりそうだったので関数のテーブル化は止めました
  • Try
    • タイムラインテーブルを改善したい
    • FlxTweenのFlxEaseの活用法を調べたい
    • FlxBar でボスの体力バーを表示したい
    • HaxeFlixelを使いやすくするクラスライブラリの作成
    • Project.xmlの自動編集ツールの作成
↑

感想

ゲーム作りは、

  1. まずシステムの構築があり、
  2. それを使ってレベルを設計、
  3. そしてゲームプレイで手応えを実感する

この3つが大きな流れであることを改めて実感しました。 開発手順として、

  1. システム構築
    1. プレイヤーのショット・シールドシステムの構築
    2. 各オブジェクトの関係を構築（衝突判定）
    3. ボスの敵生成CSV（タイムラインテーブル）システムを構築
  2. レベル設計
    1. CSVデータの打ち込み
    2. 敵の行動パターンを記述

という手順だったのですが、今回は、まずガッツリシステムを作って、レベル設計やゲームプレイは後回しにしました。 そして、このやり方は開発時間を大幅に短縮できるメリットある、ということを理解しました。

例えば、少しずつ作っては遊んで、というやり方もいいのだけれども、どうしても時間がかかってしまうので、開発時間の短縮、という意味ではあまり良くないのかもしれません。

でも、このやり方は、システム構築時点でゲームプレイまでがある程度イメージできる、くらい（同様のシステムを作った経験がある）でないと難しいかも。 今回は昔作ったSTGの焼きまし程度のもの、という方針で作ったので完成イメージはある程度予測できていました。 これが完成イメージが湧かないのにシステムだけ作りこんで、もし致命的な失敗をしたら、作り直しなどの戻り作業が発生するリスクがあるのかもしれないですね。

あとレベル設計も、RectWinder?で作成したパターンを使いまわして必要になりそうなものをがっつり作って、ゲームプレイは後回しにしました。 これによりレベル設計の時間を大幅に短縮できた気がします。 （ただし、通常のゲームプレイでは到達できない、無駄なタイムラインデータが存在しているのは失敗でした）

しかし、HaxeFlixelは本当に開発効率が良くて便利でした。 タイトル画面なんか、5分くらいで作りましたからね……。