DirectX 弾幕シューティング開発とりあえず一区切り ~振り返りと反省~
あいさつ
どうも、はかせです。
今日大体11月くらいから開発し続けてきた
シューティングを課題として提出しました。
ということで今までの開発を振り返って反省とかしていきます。
そもそもなぜ始めたか
簡単に言うとDirectX11の勉強とその結果を誰かに見せるための作品作りです。
今回作った弾幕シューティングではなによりも
パフォーマンスに気を付けなければなりません。
そういった部分は私がいままでUnityで開発してきて
あまり深く意識したことがない部分でした。
なのでその部分の勉強も兼ねられるということで作るゲームを決めました。
よかった点
何をやってきました～とかここでこう詰まりました～とかは
全てこのブログにあげているので割愛します。
気になった方は是非このブログの過去記事をご覧ください。
ここではそう言ったことではなく全体でみて
私がこの開発をやってよかったな学べたなという点を書きます。
画面描画の基本を学べた
これはシューティングに入る前の話も入ってしまいますが一緒に書いてしまいます。
私はいままでエンジンを使った開発しかしてこなかったのでどういう原理で
画面にオブジェクトが描画されるのか理解していませんでした。
それこそ行列さえろくに理解していませんでしたし、
ディスプレイに表示されるということの意味も理解していませんでした。
今回の開発でゲーム上のオブジェクトがディスプレイに描画されるために
必要な処理がある程度イメージできるようになった気がします。
悪かった点
光あるところには影がある。
何かやったらいい点と悪い点が出てくるのは当たり前です。
正直目をつむりたくなりますが、
ここにしっかり向き合わないと成長はありません。
スケジュール管理ができていなかった
一番の問題です。
ゲーム開発ということはゲームを作ることも大事ですが、
それと同じかそれ以上に納期までに完成品を作って納品することが必要なわけです。
今回最初は11月から初めて約1ヶ月でと作り始めました。
確かに1ヶ月で最低限は出来たものの
正直ゲームとして遊べるものではありませんでした。
ということでワンモアおかわりをして
納期を伸ばしてもらい今日提出したわけです。
今回は学生で勉強目的があったから許されましたが、
実際の仕事なら絶対許されないことだと思います。
なんでこんなことになってしまったかなんですが、
理由は単純明快です。
私がDirectX11を使って単位時間あたりにどれだけできるという
自分の作業能力を全然把握できていなかった、
もっといえば過信していたからです。
描画だとかの基礎は始まる前に勉強して
ある程度出来るようにしておきました。
基礎が出来ているならばあとはUnityと同じだろうという安易な考えのもと
スケジュールを立てたため能力不足が顕著に出て大幅な遅れにつながってしまいました。
またタスクの切り方も粒度がデカすぎました。
敵を作る、一言にこういっても敵を敵として成立させて管理するためには
一言では済まないほどの作業があります。
それを一言で済ましてしまったため追加でやらなければならないタスクが大量に発生しました。
対策
作業量を把握していなかった問題は今回の開発でDirectX11使ったなら
○日でどれくらいできるみたいなのは肌間でなんとなくわかったので
そこが主原因で遅れることはないと思います。
じゃあ今回の最初みたく把握できていないときはどうするかなんですが、
これはネットで見かけた余力を残すをやってみようかなと考えています。
今回は自分の能力を把握できていなかったのも問題ですが
自分のベスト状態で出来るマックスを基準に立てたのも
主原因の1つだと考えています。
これでは突発的なタスクが発生、自身の能力見積もりのミス、
体調不良(途中で私もなりました)になったりしたときにも
作業に遅れが確実に出てしまいます。
なので常に自分の出せる全力の20～30％ぐらいの
余力を残してスケジュールを立てる。
こうすれば突発的なタスクや見積もりミスがあっても余力があるので
余力を使って対処できます。
体調不良なんかで作業に遅れが出ても他の日で余力を使って取り組めば
取り返すことが可能だと思います。
テストプレイが全然できなかった
これも前述のスケジュール管理のミスに
絡んでくるところではあるのですが、
テストプレイに時間を全然さけませんでした。
最低限遊ぶために必要な機能の実装と
実装に伴うパフォーマンスチューニングに
時間のほとんどを取られテストプレイして
結果をフィードバックする時間を全然取れませんでした。
問題の80％ぐらいは前述のスケジュール管理のミスによる
時間の喪失ですが残り20％ぐらいは私のテストプレイ軽視があったと思います。
今までの私の開発経験は
・学習目的の個人開発
・ゲームジャムやハッカソンのような短期開発
・4～5人でのチーム開発
この3つが主流でした。
1つ目は自分の学習目的なのでひたすら機能実装をしてきました。
2つ目ではそもそもテストを行う時間がないことが多くしないことがほとんどでした。
3つ目では私は機能実装をメインに担当しておりテストプレイやスケジュール管理は他のチームメンバーにお願いしていました。
こういった開発経歴からみてもわかるように
私自身がスケジュール管理を行い、
テストプレイまですべてやるのは今回が初めてでした。
そしてすべてにおいてテストプレイは後回しにしがちでした。
なのでテストプレイをするというタスクの重要度をかなり低く設定してしまいました。
対策
基本は前述のスケジュール管理でもあった
余力を持ってスケジュールを立てるになります。
理由もほぼ同じですが余力を残すということは能力的にもですが、
期間的にも余裕をもって取り組むということです。
期間に余裕があればもちろんその分テストに回して作品のクオリティアップに使えます。
また他にも都度プロトタイプをビルドして知人や可能ならネット上に公開したいと考えています。
現状開発中のデバッグビルドでテストしようとすると私自身の開発環境がテストで使われてしまうため
テストしながら開発を進めることが出来ませんでした。
なので
①最低限の機能を付けた段階でプロトタイプをビルドして配布
②プロトタイプのテスト結果を受けてフィードバック
③場合によってはスケジュールの見直しなどを都度行う
④フィードバックをしたものをプロトタイプとしてビルドし配布
こうすることで開発の手を止めることなく
テストプレイを行うことが出来るのではないかと考えています。
あとがき
今回は反省会でした。
全力でやって終わった直後はよくやったなーとか思いましたが、
少し時間をおいて冷静に振り返ると全然ダメでしたね。
特に悪かった点。
これは2つとも常日頃から口酸っぱく言われてるのに
今更かよって感じになってしまいました。
今回は全体を見ていい点・悪い点をまとめましたが、
見る範囲を狭めればもっと別のいい点や悪い点が出てくると思います。
この後も私の過去記事やgithub等を見返したりしながら
しばらく反省したいと思います。
そして今回の反省を次回に活かせるようがんばります。
それでは今回はこの辺でノシ
