印刷用ページ       送信     
クリックして評価とフィードバックをお寄せください
MSDN
MSDN ライブラリ
テクニカルドキュメント
Coding4fun
Coding4Fun: ゲーム開発
 Coding4Fun: はじめに
Coding4Fun: はじめに
ゲーム開発入門

Derek Pierson
3Leaf Development

難易度:
所要時間: 1 ~ 3 時間
費用: 無料
ソフトウェア: Visual Basic または Visual C# Express Editions, DirectX SDK
ハードウェア: なし
サンプル コード
Part I - はじめに

日本語版最終更新日 2007 年 4 月 5 日

この記事は、Microsoft .NET Framework および マネージ DirectX 9.0 を使用したゲーム プログラミングの入門シリーズの最初の記事です。

このシリーズは、.NET Framework および DirectX を使用するゲームの開発に興味がある、初級プログラマ向けです。このシリーズの目標は、ゲームを楽しんで作成し、その中でゲームの開発および DirectX について学習することです。ゲームのプログラミングおよび DirectX には特有の用語および定義があり、理解するのが難しいですが、しばらくするとコードを理解し、その新しい機能を利用できるようになるでしょう。ここでは、内容をできるだけ簡単にし、用語は、そのつど解説するようにします。学習曲線のもう 1 つの部分は、DirectX を扱うために必要な数学に関連しています。この記事では、途中で、読者の理解を深めたり、学習したりすることに役に立つ情報源、または DirectX を理解するために必要な数学の知識について紹介します。

このシリーズでは、簡単なゲームを作成して、市販のゲームのさまざまなコンポーネントを示します。ここでは、見栄えのよいグラフィックを 3D で作成する方法、ユーザーの入力を処理する方法、ゲームにサウンドを追加する方法、人工知能を使用してコンピュータの敵を作成する方法、および実世界の物理的現象をモデル化する方法について取り上げます。また、作成したゲームをネットワークでプレイできるようにする方法、ゲームのパフォーマンスを最適化する方法についても説明します。途中で、オブジェクト指向開発の原理をどのように適用しているかについて示し、洗練され系統立ったコードを作成するうえでの経験についてお話しします。

ツール:

最初にゲームを作成する前に、使用するツールについて説明する必要があります。

すべての開発者にとって、最も重要なツールは、統合開発環境 (IDE) です。これは、コードの記述およびデバッグで多くの時間を費やす場所であるため、強力かつ高速でなければなりません。

Visual Studio 2005 (またはコードネーム "Whidbey") は、.NET Framework ベースのアプリケーションに対する標準 Microsoft IDE の 3 つめのバージョンです。Visual Studio 2005 は Express の多くのバージョンを導入しています。これらのバージョンは、より上位のバージョンのほとんどの機能を提供していますが、初心者、趣味で開発を行っている人、および学生の開発者向けに簡潔になっており、価格も安くなっています (ASP.NETを使用して、VB、C#、C++、J#、および Web Developers で利用できる express のバージョンがあります)。このシリーズでは、Visual C# Express と Visual Basic Express の両方を使用します。まだダウンロードされていない場合は、http://msdn.microsoft.com/express (英語) から C#、または Visual Basic Visual Studio Express IDE をダウンロードしてください。

見栄えのよいゲームを作成するために、2 番目に重要なツールは、グラフィク アプリケーション プログラミング インターフェイス (API) です。このような API がないと、PC のグラフィック機能にアクセスすることは難しくなります。ここで使用する API は、DirectX API です。この API を使用すると、Windows プラットフォームで強力なマルチメディア アプリケーションを作成することができます。ゲームで使用するには、http://www.microsoft.com/windows/directx/default.aspx (英語) から最新の DirectX SDK をダウンロードする必要があります。ここで、ランタイムではなく、必ず SDK をダウンロードしてください。SDK には、DirectX を使用して開発するときに非常に役に立つサンプル、およびその他のユーティリティが含まれています。

ゲームの開発中には、いくつかのポイントでグラフィックの作成や修正が必要になります。Microsoft Windows のすべてのバージョンは Microsoft Paint を備えています。これは最も強力なプログラムではありませんが、既にこれを所有しており、また、大半のニーズを満たすにはこれで十分です。

DirectX についてより深く学習し、3D モデルやサウンドを扱うようになると、イメージ ファイルやサウンド ファイルを操作するための他のプログラムが必要になるでしょう。これらのトピックスについて取り上げる場合には、Web 上の無償または安価なプログラムおよびリソースを紹介します。

最後に、ヘルプ情報を入手できる場所を知っておく必要があります。最も役に立つものとして、パブリック ニュースグループがあります。ここでは、あなたが質問をして、同じことに興味を持っている人から回答をもらうことができます。Microsoft の MVP および従業員もこれらのニュースグループを見ており、彼らからもサポートを得ることが可能です。ゲーム プログラミングでおもしろいニュースグループには、次のものがあります。

他にも、ゲームのヒントやヘルプになるサイトとして、次のものがあります。

 おもしろいゲームを作るためのポイント

私が最初にコンピュータを使用したのは、1981 年、Sinclair ZX Spectrum でした。最初の 5 年間のコンピューティングでは、ひたすら Sinclair 用のゲームを作成および修正し、その後は Commodore 64 に没頭していました。皆さんは 10 代の頃に何か他のことをしていましたか。ハードウェアの機能、および利用できる API については多くのことが変わりましたが、優れたゲームの特性は変わりません。

最近のゲームは非常に複雑になっており、多数の開発者、グラフィック アーティスト、テスター、および経営上の諸経費が必要になっています。これらのゲームは、複雑さの点では市場の企業アプリケーションに匹敵しており、開発して市場に出すまでに数百万ドルかかります。ただし、その投資に対する回収額も莫大で、ハリウッドの大ヒット映画の売上に匹敵します。「Halo 2」は 100 万ドルの売上を、リリースの初日に記録しました。  

すべての成功するゲームに共通していることは、際立ったいくつかの特徴があることです。

  • ヒットするゲームの主な要因は、ゲームのアイデアです。グラフィックがどんなに格好よくても、音楽がすばらしくても、アイデアが悪ければ、そのゲームをする人はいません。
  • 2 番目の重要な特徴は、ゲームのプレイアビリティです。ゲームが難しすぎると、プレイヤーはすぐにフラストレーションを感じるようになり、プレイを止めてしまいます。反対に、ゲームが簡単すぎると、プレイヤーは飽きてプレイを止めてしまいます。優れたゲームには、複数の難易度が用意されており、プレイヤーは、非常に困難であったり、飽きたりすることなく次々とチャレンジできます。
  • 同時に、ゲームのアイデアおよびそのプレイアビリティは "ゲーム デザイン" になります (これは、"レベル デザイン" と混同しないでください。"レベル デザイン" は、全体のゲームデザインをゲームの特定の部分に適用したものです)。ゲーム デザイナも中には、天才的な技法を使用する人もいます。宮本 茂氏 (ドンキーコング、ゼルダ、およびマリオのクリエイター)、および Will Wright 氏 (Sim シリーズのすべて) の 2 人は、天才的なデザイナとして知られています。宮本氏の、1999 Game Developer's Conference における基調講演は、http://www.gamasutra.com/features/20030502/miyamoto_01.shtml (英語) で参照できます。また、Wright 氏の Spore におけるデザインの哲学 (http://www.gamespy.com/articles/595/595975p1.html?fromint=1 (英語) ) は、あらゆるタイプのデザイナにとってヒントになるでしょう。Raph Koster 氏の本 "Theory of Fun for Game Design" は、このコミュニティの中で優れた評論を受けています。
  • ヒットするゲームの 3 番目の要因は、グラフィック セットです。これらのグラフィックは、ゲームのアイデアおよびゲームのプレイをより良くするものでなければなりません。また、リソースを大量に消費したり、派手すぎると、ゲームの本質から離れることになります。
  • そして最後の要因はパフォーマンスです。遅いゲームなど、やりたい人はいないでしょう。筆者の Commodore 64 など、アドベンチャー ゲームでそれぞれのシーンを表示するのに 10 分もかかっていたことは、いまだに忘れません。ただし、言っておきますが、それでもこのゲームをしていました。というのも、ゲームのアイデアがすばらしく、遅くてイライラさせられたものの、他にやってみようと思うゲームはなかったのです。グラフィックとパフォーマンスは密に関連しています。ゲームに見栄えのいいグラフィックを追加するほど、パフォーマンスは遅くなります。パフォーマンスにおいて、次に大きな問題は AI です。現在、多くのゲーム開発では、処理を高速にする方法に焦点を合わせていますが、新しいアイデアがありません。ただし、ゲーム プログラミングなどの複雑なプログラミング テクニックを学ぶ場合には、尚早に最適化しないことが非常に重要になります。パフォーマンスのパイプラインを理解すること、およびクリーンなコードを記述し、それをプロファイルして改良するスキルは、どの単一の機能を最適化するよりも重要です。

この順序で、デザインの作業を適用すれば、あなたもすばらしいゲームを作成できます。Battlefield 1942 のように、洗練された一人称シューティング ゲームではないかもしれませんが、テトリスは、見栄えの良い 3D グラフィックもドルビー デジタル サウンドもありませんが、おそらく最も人気のあるゲームです。今日でも、Gish (http://www.chroniclogic.com/index.htm?gish.htm (英語) ) などのゲームでは、クリエイティブな独立系の開発者によって、もたらされるものについて示しています。ゲームのアイデアを示すのに十分なゲームが作成できたならば、大規模なゲーム会社があなたのゲームに興味を示すことも考えられます。Independent Games Festival はゲーム業界の "祭典" であり、同時にプロフェッショナルな Game Developers Conference を開催しています。これは最も注目を浴びているイベントです。

ゲームのアイデア

すばらしいゲームを作成するポイントが分かったので、次のステップとして、ゲームに対してプランを展開していきましょう。

アイデア: すべてのゲームでは、ユニークでクリエイティブなゲームのアイデアを思い付くことがポイントであるため、最初に出会った 3D ゲーム、Atari の Battlezone のアイデアを拝借して使用することにします (もし、私がすばらしいアイデアを持っていたとしても、そのすべてをあなた教えたりするでしょうか。) Battlezone は基本的な一人称シューティング ゲームであり、戦車のファインダから 3D の風景を見ることができます。このゲームの目的は、自分が破壊される前に、敵の戦車をできるだけたくさん破壊することです。この地形には、自分を隠すことができる無作為の物体があります。ゲームの画面には、敵の場所を示すレーダー、および現在の得点が示されます。

プレイアビリティ: このゲームは非常にゆっくり始まりますが、敵の戦車、および他の無作為な敵が常に追加されます。また、このゲームはスピードが徐々に早くなり、敵の知能も高くなっていきます。これらのすべての要因が、このゲームの意欲をそそりますが、プレイしやすいものにしています。

グラフィック: 元のゲームでは、プレイヤーが 3D の世界にいる気分になるのに十分なグラフィックを使用していました。ただし、1980 年に使用できたハードウェアの機能 (8 ビットのプロセッサを 1.5 MHz で実行する) により、3D のオブジェクトはワイヤー フレームとして表示されました。このゲームが最初に登場した当時は、これらのグラフィックは新型のものでしたが、DirectX のマジック (およびムーアの法則の 25 年のマジック) によって、改良を加えています。

Atari の Battlezone ゲームのスクリーンショット - ワイヤー フレームの山、戦車、さらにワイヤー フレームの月まであり、リアル感がアップ

パフォーマンス: このゲームは、その当時利用できたハードウェアの限界を打破していました。ワイアー フレームのオブジェクトを使用していることがその証拠です。もしオブジェクトを塗り込む用に書かれていたならば、このゲームはプレイ不可能になっていたでしょう。今日の進んだハードウェアでは、ずさんなコードを書いたりしない限りパフォーマンスの問題はまったく起こらないはずです。

ここまでで、ゲームについてさまざまなことが決まったので、次に、ゲームの目的について書きとめましょう。これは、形式ばったものである必要はありませんが、具体的に書くという単純な行為によって、アイデアがより明確になります。少なくとも、ここではゲームの目的、プレイヤーができることとできないこと、およびプレイヤーがゲームを使用する方法について決める必要があります。また、得点のシステムがどのようになるのか、どのようになれば勝ちなのかも決める必要があります。

このゲームでは、次のような簡単な仕様を考えました。

  • 3D の一人称シューティング ゲームである。
  • このゲームの目的は、できるだけ多くの敵を破壊することである。
  • プレイヤーは、通常の戦車と同様に地上の地形を移動できる。戦車は飛行できない。また、スピードを変えることもできない。
  • ゲームのプレイは、キーボードで移動とシューティングをコントロールする。マウスは、メニューにアクセスする場合、およびゲームを開始、停止する場合に使用する。ジョイスティックはサポートしていない。
  • プレイヤーは、敵の戦車が破壊された距離に基づいて点数が提示される。戦車の距離が遠いほど、点数が高くなる。発射するたびに、ターゲットに命中しない限り、設定した分だけ点数が減る。
  • このゲームはいくつかのレベルに分かれている。それぞれのレベルには、あらかじめ決められた数の敵がいる。すべての敵を倒すと、プレイヤーは次のレベルへ進む。レベルには上限がない。

これでコーディングをする準備ができました。通常は、アプリケーションの全般的なアイデアを書いておくのが最もよい方法です。事前に詳細なデザインに時間をかけることは、時間の無駄です。ゲームには機能を追加していくので、アイデアを具体化していくために、継続的に設計期間を少し取るようにします。このような反復的なアプローチでソフトウェアを開発することは、優れたソフトウェアにとっては最適な方法であり、非常に楽しいことでもあります。

ゲーム プロジェクトの作成

これでコーディングをする準備ができました。最初のステップとして、Visual Studio 2005 で新しいソリューションを作成します。

  • [ファイル]、[新規作成]、[プロジェクト] を選択し、テンプレート リストから [Windows アプリケーション] を選択します。ダイアログの下部の [プロジェクト名] フィールドで、デフォルトの [WindowsApplication1] を [BattleTank2005] に変えて [OK] をクリックします。

Visual Studio で、BattleTank2005 という新しいソリューションが作成されます。この中には、同じ名前の 1 つのプロジェクトが含まれています。

最初に、もっと分りやすい名前になるようクラスの名前を変更します。命名は、コードを系統立て、理解しやすくするための最も有効な方法です。名前は、常にそのアイテムの動作を明確に表すようなものを選択し、Class1 や Form1 のように意味のない名前を付けないようにします。

  • [編集] メニューから [検索と置換] を選択し、[クイック置換] を選択します。[検索する文字列] フィールドに 'Form1' と設定し、[置換後の文字列] フィールドに 'GameEngine'、[検索対象] フィールドに [現在のプロジェクト] と設定します (下の図を参照)。[すべて置換] をクリックして、この変更を有効にします (ここでは 5 つの変更が行われます)。
  • 次に [ソリューション エクスプローラ] で [Form1] を右クリックし、[名前の変更] を選択します。Form1.cs を GameEngine.cs に変更します。

Form1 のテキストを GameEngine に変更する (後で役に立ちます)

コードを整理しておくための、もう 1 つのポイントは、ソリューション エクスプローラのファイルを、その中に含まれているクラスの名前と同じにしておき、それぞれのクラスや列挙型などの明確な要素に対しては、常に個別のファイルを作成することです。

これで、実行できる Windows アプリケーションが作成できましたが、このアプリケーションは何も処理しません。フォームには、クリックできるボタンや、情報を表示するテキストボックスなどの他のコントロールがありません。通常の Windows フォーム アプリケーションでは、これらのコントロールをフォームに追加して、最終的なアプリケーションを作成しますが、このゲームでは、Windows フォーム API ではなく、DirectX API を使用してすべてのものを作成します。

実際には、Windows Handle のためだけにフォームが必要になります。Windows Handle は、基本的には画面上のその他のウィンドウの中での一意な名前です。このハンドルを使用して、この例の DirectX の描画面をセットアップします。フォームの他の使用法として、この中にレンダー ループを作成するためのイベントを含めます。

レンダー ループの追加

ゲームは、Microsoft Word などの通常のアプリケーションとはかなり異なります。Word では、タイプライターのページに似た画面がユーザーに表示され、ユーザーが何かアクションを実行するのを待ちます。このアクションとは、キーボードのキーを押す、メニューからマウスでメニュー項目を選択する、といったことになります。ユーザーがアプリケーションに対して操作を行うのを待っている間は、Word は何も処理しません (実際には、何もしないのではなく、バックグラウンドでスペル チェックや自動保存を実行していますが、ユーザーには何もしていないように見えます)。一般的には、Windows フォーム ライブラリを使用して記述したプログラムは概して同じ動作をします。つまり、ユーザーが何かするまで CPU 時間を消費しません (もちろん、Timer コントロールや System.Threading 名前空間の機能を使用して、ユーザーに関係なく処理をすることも可能です)。

ゲームは異なります。ご存知のように、ゲームにおいてスムーズな動きを実現するには、1 秒間に何度も画面を更新する必要があります。通常、静的なイメージがちらつき始める閃光融合閾 (ちらつき値) は 1 秒の 1/16 ぐらいですが、実際には照明によって異なり (コンピュータのモニタのように明るい照明では、フレーム レートが高くなります)、網膜の上でイメージが崩壊します (周辺視覚では、中心視覚よりも高いレートが必要になります)。映画は、1 秒間に 24 フレーム (FPS) が示されますが、ビデオ ゲームで許容範囲とされる最低の値としては、30 FPS とみなされています。ほとんどのアクションゲーム プレーヤーは、グラフィックを 60 FPS ぐらいに調整します。

レンダー ループは 1 秒間に何十回もコールされ、ノンストップで実行されるため、ゲーム プログラミングではほとんど常にレンダー ループをゲームの "ストップウォッチ" として使用しており、ループ内のすべてのものを計算しています。その対象はグラフィックだけでなく、物理的現象、AI、ユーザー入力のチェック、得点なども扱います (ここでまた、Timer クラスやスレッドを使用してマルチスレッド ゲームを記述することもできますが、このようにすると非常に複雑になり、明白なメリットがありません。また、.NET Framework の共通言語ランタイムにおけるマルチスレッド化は非常に有効ですが、わずかなオーバーヘッドによって、ゲームの FPS が減少します)。

では、コンピュータでループをどのように実行するのでしょうか。前に追加したフォームには、Paint イベントと呼ばれるイベントがあります。Windows フォーム オブジェクトの Paint イベントは、フォームを描画し直すたびにコールされます。これは普通、フォームを最大化する場合、または移動した他のフォームによってフォームが隠された場合に発生します。

すべての Windows フォーム プログラミングと同様に、ゲームのプログラミングもイベントベースになっているため、イベントおよびイベント ハンドラの原理を理解しておくことは重要です。イベントを捕捉して、それに対応する何らかの処理ができるようにするには、イベント ハンドラと呼ばれる特別なメソッドを作成する必要があります。

  • GameEngine クラスで、コンストラクタの後に次のコードを追加します。

Visual C#

protected override void OnPaint(PaintEventArgs e)
{

}

Visual Basic

Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs)

End Sub

これは、この例のイベント ハンドラです。これは、どのタイミングでコールされるかというと、"OnPaint"、つまり Paint イベントが発生するときです。ここではまだ、足りないものが 1 つあります。Windows および Windows フォーム ライブラリではイベントが自動的に発生しますが、Paint イベントをトリガすると予想していたアクションで、トリガしないものがいくつかあります。たとえば、ウィンドウを最小化しても Paint イベントはトリガされません。これは、Windows がフォーム全体を再ペイントする必要がないと見なしているためです (フォームを縮小したときには実際には画面表示はしないのですから、Windows は効率化をおこなっているだけです)。したがって、このように自動的に作成されたイベントに頼って、ゲームに必要なループを管理することはできません。

さいわい、フォームの Invalidate メソッドを呼び出して、Paint イベントをプログラムでトリガすることができます。このようにすると、Paint イベントがトリガされ、Windows は On Paint イベント ハンドラへ戻ります。次に、各フレームを実行させたいコードを実行し、Invalidate メソッドをコールして、すべてもう一度開始します。

ここで「OnPaint() に while (true) ループを直接追加して、ずっとそこから出ないようにすることは、どうしてできないのか」と思うでしょう。それは、ゲームのプログラマであっても、他の人と協調することが期待されるためです。OnPaint() にループを作成すると、システムで実行している他のプログラムが停止してしまいます。私たちのゲームでは FPS が少し増えるかもしれませんが、システムの残りの部分では見栄えが悪くなり、または最悪の場合は不安定になります。このため、直接ループする代わりに、基本的には、できるだけすぐにもう一度呼び出すよう "要求" します。

  • OnPaint メソッドで、次のコード行を追加します。

Visual C#     

this.Invalidate();

Visual Basic

Me.Invalidate()

これは、作成したレンダー ループです。ただし、もう 1 つ問題があります。すべてのペイントが OnPaint メソッドで行われるわけではありません。背景が消去されると、Windows フォームはもう 1 つのイベントをトリガし、デフォルトで、それに応答していくつかのペイント (消去) を実行します。この例のアプリケーションで、メソッド ハンドラ内でのみペイントするようにするには、アプリケーションにもう 1 行のコードを追加する必要があります。アプリケーションが開始されたときに、このコードが確実に実行されるようにする必要があるため、これは、フォームのコンストラクタ内に配置します。これは、このクラスで何らかのメソッドをコールする前に、このコードが必ず実行されることを意味します。

  • GameEngine クラスで、コンストラクタの InitializeComponent メソッド コールのすぐ後に、次のコード行を追加します。

Visual C#

this.SetStyle(ControlStyles.AllPaintingInWmPaint |
ControlStyles.Opaque, true);

Visual Basic

Me.SetStyle(ControlStyles.AllPaintingInWmPaint Or 
ControlStyles.Opaque, True)

ControlStyles を AllPaintingInWmPaint に設定すると、Windows で OnPaint イベント ハンドラのみを使用して画面を再表示します。2 番目のパラメータは、単純に、ウィンドウが透明になることはないことを Windows に通知しています。

これで、ゲームの基本的なフレームワークができました。これから作成しようとしているものはすべて、レンダー ループ内で発生するアクションです。

タイマに関するすべて

このタイプのループでひとつ問題になるのは、コンピュータがレンダー ループ内でタスクを実行できるスピードが、コンピュータによって異なることです。これは、同じコンピュータでも、あるタイミングにおいてそのゲームで使用できるメモリ量および CPU 時間によって異なります。これらの違いを明らかにして、どのような場合でも安定して使用できるように、いくつかの手段を講じる必要があります。そこで、各フレームを同じに扱うのではなく、フレーム間で経過した時間を計算し、その値を計算に適用するようにします。

Windows の時間の監視には、次のような方法があります。

  1. System.Windows.Forms.Timer: これは、Windows のプログラミングで使用される最も一般的なタイマです。これは簡単に使用できますが、精度は、1 秒間の 1/18 しかありません。最高で 1,000 FPS くらい設定できるので、この精度ではゲーム プログラムに不十分です。
  2. timeGetTime: この Windows DLL は、Windows のいくつかのバージョンでは 1 ミリ秒の精度を提供し、Windows NT では 5 ミリ秒の精度を提供します。これは非常に可変的であり、実際にはタイマ値を調整する必要があるかどうかを調べるために、ゲームを実行しているオペレーティング システムをチェックしたくありません。
  3. System.TickCount: このマネージ呼び出しは、ミリ秒の数を示すティック数を返します。これはニーズに近いものですが、もっと良い方法があります。
  4. QueryPerformanceCounter: これは、使用するうえで優れたタイマで、精度は 1 ミリ秒以下です。ゲーム開発で最もよく使用するタイマです。

最後のタイマは、Windows のローレベルの DLL を呼び出す必要があるため、記述するのに注意が必要です。さいわい、高精度のタイマのニーズは共通のもので、timer クラスは、DirectX SDK に含まれています。この timer クラスは、SDK のインストール ディレクトリの \Samples\Managed\Common ディレクトリにあります。ここで関係するファイルは dxmutmisc.cs というものですが、このディレクトリ内では、他のほとんどのファイルを使用します。

dxmutmisc.cs を追加する前に、次の方法で別のフォルダを作成します。フォルダを作成してソリューションを整理しておくと、関連する項目をグループ化することと、プロジェクトを系統立てておくことが簡単になります。

  • [追加]、[新しいフォルダ] を選択します。新しいフォルダに DirectXSupport という名前を付けます。このフォルダに、さまざまなサポート クラスを追加しますが、このプロジェクトを通じてこれらのクラスを利用します。

次に、既存のファイルをプロジェクトへ追加します。これにより、ファイルがディレクトリ構造に追加されます。

  • [DirectXSupport] フォルダを右クリックし、[追加]、[既存の項目] を選択して [C:\Program Files\Microsoft DirectX 9.0 SDK (February 2005)\Samples\Managed\Common] を参照し、dxmutmisc.cs ファイルを選択します。

必要な場合は、このファイルの内容を参照できます。ここにはさまざまなヘルパ クラスが含まれており、FrameworkTimer クラスだけでなく、多数のコードを自身で記述しなくても済むようになっています。

この timer クラスは別の名前空間に含まれているため、 using 文を追加して、そのつど "Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer" と記述しなくても、FrameworkTimer を使用することができるようにします。

  • クラスの上の using 宣言部分に、次のコード行を追加します。

Visual C#

Microsoft.Samples.DirectX.UtilityToolkit;

Visual Basic

Microsoft.Samples.DirectX.UtilityToolkit

次に、経過時間の値を保存しておく必要があります。この値は、deltaTime 変数に保存します。この変数は double として宣言することに注意してください。この変数を integer として宣言すると、すべてが整数に四捨五入されるため、強力なタイマの精度がすべて無効になります。

  • クラスの最後で、最後の 2 つの中かっこの上に、次のコード行を追加します。

Visual C#

private double deltaTime;

Visual Basic

Private deltaTime As Double

タイマは、レンダー ループの最後の可能なタイミングで開始して、できるだけ正確な時間を取得できるようにしたいと考えています。

  • OnPaint メソッドの最後で、this.Invalidate の呼び出しの直前に次のコードを追加します。

Visual C#     

FrameworkTimer.Start();

Visual Basic

Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.Start()

各ループの開始時に、経過 (またはデルタ) 時間を計算する必要があります。この時間は、以降に作成するほとんどの呼び出しで渡すためです。

  • OnPaint メソッドの先頭で、他のコードより前に次のコード行を追加します。

Visual C#

deltaTime = FrameworkTimer.GetElapsedTime();

Visual Basic

deltaTime = Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.GetElapsedTime()

これで、時間を追跡できるようになりました。特別に、次の記事ではこのタイマを使用して、フレーム レートを計算してみましょう。ソリューションがビルドできなくなっていることにことに気が付くはずです。これは、ファイルに追加したクラスで、DirectX を参照する必要があるためです。次の記事では、DirectX の必要な部分について取り上げます。

まとめ

この最初の記事では、多くのことを行いました。まず、マネージ DirectX のゲームを作成するために必要なツールを取り上げ、ゲームをおもしろくする要点について説明しました。次に、ゲームのアイデアを定義し、ゲームのプロジェクトを作成しました。その後、ゲーム全体で使用するレンダー ループを作成し、最後に、このプロジェクトに高精度のタイマを追加しました。

以降のすべてのステップでは、DirectX が必要になります。DirectX については次の記事で取り上げます。この最初の記事を読んで、いつも考えていたゲームを始めるきっかけになってくれることを願っています。ゲームの開発は、コンピュータ プログラミングの中でも最もおもしろい経験のひとつです。このシリーズを進めていく中で、目標を達成するために必要な基礎をすべてお教えしようと思っています。

top of page Top of Page

© 2009 Microsoft Corporation. All rights reserved. 使用条件 | 商標 | プライバシー
Page view tracker