SpeedGame_作品紹介資料

「SpeedGame」
DirectX12及び、DXTK12・DirectXTex・FBXSDK・ImGuiを用いて作成しました。

Transcript

2. 目次 01:実行環境 02:操作方法 03:作品の概要 04:作品でこだわったところ ・ゲーム部分 ・スピードの上昇ギミックと駆け引き ・ハートの配置とレベルデザイン ・技術部分 ・Unityライクなエンジン設計 ・データの保守性と受け渡し処理 ・各種シェーダーとパイプライン ・ImGuiによるデバッグ機能
3. 実行環境 / 実行手順 実行環境：Windowsでの実行をお願いいたします。 実行手順： 01:Zipファイルを解凍の後、「SpeedGame」フォルダを開く 02:「SpeedGame_Build」フォルダを開く 03:フォルダ内の「SpeedGame.exe」を起動の後、 ゲームをお楽しみいただけますと幸いです。 操作方法 ※プレイにはキーボード/マウスが必要となります。 WASDキー ：移動 スペースキー ：ジャンプ マウス右クリック：視点変更 Eキー ：ImGuiのウィンドウ表示/非表示切り替え
4. 作品の概要 『ゲームを制作しようと思ったきっかけ』 “ゲームエンジンなしでどうやってゲームを作るんだろう”という興味から始まり、 ゲームエンジンを使うだけではなく、どのように動いているのかを知り使いこなすことが出来れば、 より細かい表現や動きを作ることが出来るのではないかと考えたためです。 そのため、ゲームエンジンの中身を知り勉強するという意味も含めて、今回の制作を行いました。 開発にかかった期間：約9か月 所要時間数の概算：約250時間 開発メンバー数：1名(個人製作) 自身の担当範囲：アプリケーション全般 使用ツール：DirectX12/DXTK12/DirectXTex/FBXSDK/ImGui
5. 作品の概要 制限時間90秒の中で、全3ステージをクリアするまでのタイムを競うゲームです。 このゲームでは各ステージに10個のハートが設置されており、それらを取得してポイントを集める ことでステージをクリア出来ます。 またハートを取得するとポイントが貰えるだけではなく、プレイヤーの速度も上下していきます。 ハートにはそれぞれの色ごとに特徴があり、 「プレイヤーの速度を上げる代わりにポイントが少ないハート」や、逆に「速度を下げる代わりに ポイントが多いハート」など、ハートの特徴を駆使して、“いつ、どの場面でどのハートを取るか” といった、選択やタイムの中での駆け引きを楽しんでいただけると幸いです。
6. 作品制作でこだわった所 ゲーム部分 ・スピードの上昇ギミックと駆け引き ・ハートの配置とレベルデザイン 技術部分 ・エンジン ：オブジェクト指向とコンポーネント指向を取り入れた Unityライクなエンジン設計 ・アプリ ：データの保守性を保った受け渡し処理 ・グラフィック：スペキュラー/ノーマルマップを使用した 各種シェーダーの実装とパイプライン ・その他 ：ImGuiによるデバッグ機能の実装
7. ゲーム部分：スピードの上昇ギミックと駆け引き 1つ目は”ハートを取るとスピードが上がる”ギミックです。 このゲームでは赤・青・黄色の3種類のハートがありますが、それぞれで取得した際の 特徴が異なります。 黄色：スピードが20~50％増え、クリアポイントが1増える 赤 ：スピードが50％減るが、クリアポイントが3増える 青 ：スピードが0％になるが、クリアポイントが5増える こうしたハートの特徴と、90秒で3ステージを攻略するというゲームの中で、例えば “今は2ステージ目だからスピードを温存しよう”であったり、 ”最終ステージだからスピードが減っても高いポイントのハートを取ろう“や、 ”このステージでタイムをロスしてもスピードを稼ごう“といった、 各ステージやタイムといった、状況が変化し続ける中での選択と駆け引きをプレイヤーに 楽しんでもらえるような仕組みを作ることが出来たと考えています。
8. ゲーム部分：ハートの配置とレベルデザイン 2つ目は各ステージのハートの配置とレベルデザインです。 各ステージにも、それぞれにゲームを楽しんでもらうためのコンセプトを設定し、 そのコンセプトに沿う形でハートの配置を行いました。 ステージ１は「ゲームを知ってもらう」をコンセプトに、 全てのハートをスピードが上昇する黄色のハートのみで構成しています。 またここでスピードが上がっていく仕組みを感覚的に伝え、 同時にスピードの値を貯めて次ステージを楽しんでもらうためにデザインしました。
9. ゲーム部分：ハートの配置とレベルデザイン ステージ２は「赤・青ハートに触れてもらう」をコンセプトに、 初めてデメリット効果を持つ赤と青のハートを配置しました。 新しいギミックに触れてもらうため、クリアに必要なポイントを8に設定して黄色の ハートの配置を5つに設定しています。なのでこのステージは、赤か青のハートを必ず 1つ以上取得してクリアへと進んでもらえるよう設計しました。 これによって新しいハートのギミックをプレイヤーに伝えつつ、 最終ステージへと進んでもらえるようにしました。
10. ゲーム部分：ハートの配置とレベルデザイン ステージ３では「リソースとの勝負」をコンセプトに、 ハートのほとんどを青と赤で構成しています。 プレイヤーはステージ1、2で手に入れたスピードをいかに持続させつつ、ハートを 取っていくのかを考えるようなステージにできたのではないかと考えています。 また3ステージ目の構成によって、基本的に1回目よりも2回目のプレイ時の方が良い タイムが出るような構造にもなっており、繰り返し遊んでもらえることで タイムの更新が行われやすい設計にも出来たのではと考えています。
11. エンジン：Unityライクなエンジン設計 SpeedGameではエンジンに相当する部分と、 アプリケーション部分の2層に分かれて構築されており、 それぞれに設計やこだわりを入れて作成しました。 エンジン部分では、既存のゲームエンジンであるUnityの設計を参考に、 オブジェクト指向やコンポーネント指向を取り入れて制作しました。 今回の設計では、GameObjectのインスタンスをベースに、 GameComponentを追加していく事でそれぞれの機能を持ったオブジェクトを生成します。 また、GameComponentにはStartやUpdateの機能に相当するメソッドを持っており、 それらをGameObjectを通して制御することで、呼び出しタイミングの制御も エンジン側で一括で行えるよう実装しました。
12. アプリケーション：データの保守性と受け渡し処理 SpeedGameを作る際に意識したこととして、 データの保守性と受け渡しの部分にこだわって制作しました。 ほとんどのデータをその役割を持ったクラス内で管理できるよう、 グローバル変数はほとんど使わず、また静的変数等の使用を極力減らせるような形で制作しました。 また使う場面に関しても悪影響が出ないよう、デバイスのポインタなど その役割から考えて問題ないであろう場面でしか使わないよう徹底し、 データのやり取りに関しても保守性を保ちつつ簡易にアクセスできるようにしました。 また、様々なデータを扱うインゲームシーンでは、インゲームに必要なデータの管理と、 そのデータを使ってゲーム進行を行えるクラスを作成しました。 これによって、拡張性と保守性を保った状態で作成できたと考えております。 この実装によって様々なデータにアクセスするインゲームシーンでも、 効率的なデータの管理とインゲームシーンの処理が可能になりました。
13. グラフィック：各種シェーダーとパイプライン SpeedGameのグラフィックでは、 スペキュラー/ノーマルマップに対応したフォンシェーダーや、トゥーンシェーダー などを実装しています。 また、スペキュラー/ノーマルマップがなかったとしても フォンによる陰影の計算が行えるようなパイプラインの設定や、 ランバート反射での計算やハーフベクトルを使用したフォン反射の計算など、 それぞれの特徴や役割に応じてシェーダーを適応できるようなパイプラインを構築しました。 このパイプラインによって、ステージにはランバート反射を適応し、プレイヤーのモデルには フォン反射を適応するといったシェーダーの使い分けが簡易に行えるようになったほか、 他のシェーダーによる陰影計算を追加実装する際にも、容易に拡張できる拡張性を保った状態で実装 を行うことが出来ました。 またその他にも、シャドウマップによる影の出力や、MipMapテクスチャの実装など、 グラフィックの表現を追求するための試みも行っております。
14. グラフィック：各種シェーダーとパイプライン ランバートシェーダー反映時 フォンシェーダー反映時 トゥーンシェーダー反映時
15. その他：ImGuiによるデバッグ機能の実装 今回の作品には、ImGuiライブラリを使用したデバッグ機能を実装しました。 この機能の実装によって、ハートの位置調整や表示・非表示の切り替え、 パラメータの調整やシーン遷移、各種シェーダーの割り当てなど、 ゲーム本編やグラフィック等、幅広いケースでの実行結果を把握できるようになりました。 ※今回の作品ではEキーでデバッグ用のウィンドウの表示/非表示が行えます。
16. その他：ImGuiによるデバッグ機能の実装 また、デバッグを実行する処理とゲームアプリに関わる処理をなるべく分離し、 結合が起こらないようにもしています。 どのようにデバッグするのかは各種コンポーネント側で記述を行い、 エンジンの設計と同じようにStartとUpdateに相当する呼び出し関数を実装しています。 それらの関数をアプリケーション側で記述して呼び出すのではなく、 Managerクラスを使用して一括で呼び出し等の制御を行っています。 これによりアプリケーション側でデバッグ用に記述する処理を最小限に抑えつつ、 デバッグ処理が行えるよう実装しました。