9
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

入門書を読み終わったらゲームを作ろう #3 シューティングゲームを作る 1/3

Last updated at Posted at 2017-01-29

#前回までのあらすじ
ようやくそれらしいゲームが出来たけど、まだ何か物足りない。具体的には、操作感や爽快感、すなわちリアルタイム性が足りていないような気がする。

#課題の前に
課題に入る前に、以下の準備を行うこと。

段階0 ウィンドウの表示
ウィンドウを表示し、Escapeキーを入力するとウィンドウが閉じるようにせよ。

今回からはよりゲームらしく、プレイヤーの入力をリアルタイムに読み取って操作を行う。言語やライブラリ等は一任するので、キーボードの読取りができるようにしておこう。筆者はC++をベースに、基本的なライブラリとしてDXLibを用いた。

#今回の課題
それでは、基本的なシューティングゲームを制作しよう。シューティングゲームは次の基本動作を実装する。

  • プレイヤーの操作するオブジェクトを「自機」とする。
    • 自機は、ゲーム画面内を上下左右に移動することができる。
    • 自機は、特定のボタンを押すと画面右方向に弾を発射する。
    • 自機が弾を敵に当てると、得点が1増える。
    • 自機が敵の弾に当たると、ゲームが終了する。
  • プレイヤーを攻撃するオブジェクトを「敵」とする。
    • 敵は、画面の右方向から左方向へ移動する。
    • 敵は、ランダムになタイミングで画面左方向に弾を発射する。
    • 敵が自機の弾に当たると、敵はその場で消えて新しい敵が右端に誕生する。
    • 敵がゲーム画面内左端に到達すると、ゲームが終了する。
  • 自機や敵が発射するオブジェクトを「弾」とする。
    • 弾は、ゲーム画面端に到達すると消える。
    • 自機の発射する弾は、同じ画面に5個まで存在できる。
    • 敵の発射する弾は、同じ画面に10個まで存在できる。

##ゲームの完成図を予想する
以上の実装を聞いて、ゲーム画面を想像することができるだろうか。オブジェクトの色は?速度は?動きは?大きさは?と、考えることが無数に出てくるだろう。このまま作ると大変な目に遭うので、コーディングをする前にゲームの設計をしよう。

##ゲームの設計図「仕様書」
これから、各オブジェクトを「クラス」として扱う。それぞれのモノが何を持ってるか、そして何ができるかを与えてゲームを作っていこう。

###自機
自機は、自分自身の大きさや速度、色や得点を知っているだろう。これらの値を列挙しよう。

自機
大きさ / 速度 / 色 / 得点

そして、移動と弾を発射することができる。下段に行動を列挙する。

自機
大きさ / 速度 / 色 / 得点
・移動する ・弾を発射する

また、自機は「自分が何発弾を発射したか」も知っているだろう。
さらに、何かに対して「自分は何かに衝突をしているか?」を確認できるはずだ。

自機
大きさ / 速度 / 色 / 発射数 / 得点
・移動する ・弾を発射する ・衝突しているか?

ゲームの構成という意味で、自分自身を画面に表示する機能も追加しよう。

自機
大きさ / 速度 / 色 / 発射数 / 得点
・移動する ・弾を発射する ・衝突しているか? ・描画

これが、今回のゲームで作る自機の要素となる。

###敵

についても同様に作ってみよう。最低限、以下のようなものが必要になるだろう。
自機の要素から得点を引いたものができる。

大きさ / 速度 / 色 / 発射数
・移動する ・弾を発射する ・衝突しているか? ・描画

###弾

が弾を発射することがないので、敵からさらに発射に関係するものを削除するとよいだろう。
発射数などは自機などが管理するので、弾自身が弾の数を知る必要はない。

大きさ / 速度 / 色
・移動する ・衝突しているか? ・描画

###共通部分を抜き出す
「自機」「敵」「弾」の3種類のオブジェクトが完成した。これらには共通する値や処理が多く存在している。それらをまとめてインターフェース化してみよう。各オブジェクトはこの要素を必ず持つことになる。

インターフェース <<オブジェクト>>
大きさ / 速度 / 色
・移動する ・衝突しているか? ・描画

###更に技巧的な話
ここから更に3つの要素を追加しよう。

1つめはオブジェクトの形を司る矩形クラスだ。衝突判定の際に、その形だけを情報として渡すと後々都合がよいので、始点と終点を与えた矩形をつくる。

矩形
始点 / 終点

さらに、弾の管理をするための弾テーブルを作る。
自機が自分の弾すべてに指示を出そうとすると後で面倒なことになる。ましてやどの弾が生きているかを判断する機能まで備えると訳が分からなくなる。そこで、弾についての情報を一元管理するクラスを作成し、それに命令を出すようにしよう。弾テーブルは次のような形になる。

弾テーブル
現在の弾数 / 最大弾数
・描画 ・移動 ・弾の生成 ・弾の削除 ・弾が画面外に出たか? ・弾の矩形生成

同様に、複数の敵の状態を管理する敵テーブルも作ろう。

敵テーブル
現在の敵の数 / 敵の最大数
・描画 ・敵の生成 ・敵の削除 ・弾の発射 ・敵の矩形作成

###ゲーム全体を管理するクラス

最後に、ゲームそのものを作る基底クラスを作る。この中で各オブジェクトが活動する。
今回、基底クラスはタイマーの役割も兼ねることとする。

基底クラス
タイマー / カウント / ウィンドウ生成関連ステータス
・ウィンドウを作る ・タイマーを進める ・指定された間隔で信号を送る

#今回のまとめ
今回はコーディングから離れて、以下のクラスを考えた。階層構造は以下のとおりである。

基底クラス
│
├自機<<オブジェクト>>
│└矩形
│
├敵テーブル
│├敵<<オブジェクト>>
││└矩形
│├敵<<オブジェクト>>
││└矩形
│:
│
└弾テーブル
 ├弾<<オブジェクト>>
 │└矩形
 ├弾<<オブジェクト>>
 │└矩形
 :

先にこのようなゲームに必要な要素を考えだすだけで、行き当たりばったりのコーディングよりよほど快適にゲームを作ることができる。これらのクラスは必要なものがあれば随時追加することを考慮しているため、必要最小限に留めていることを忘れてはいけない。

次回はこれらを用いてコーディングに入ろう。

#あとがき
今回の内容は非常に自信がないので、改善提案があればどんどんコメントやリクエストをお願いします。

9
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?