コンテンツ パイプラインを使用すると、テクスチャをバイナリでコンパイルできます。これにより、スペースを節約し、読み込み時間を節約し、アセットを編集や無許可の使用から保護することができます。逆に、アセットを編集可能にしたい場合 (テクスチャ パックなど)FromFile()
は効果的です。もちろん、通常の使用では、ファイルは予想されるディレクトリに存在する必要があります。
これは良い方法ですが、最終的にはコンテンツをどこにロードするかを決定します。コンテンツの読み込みにはディスクからの読み取りが必要であることに注意してください。これは、すべてのフレームで確実に実行したいことではなく、ゲーム中に実行したいことでもありません。ゲーム自体ではなく、ロード画面またはゲームの起動中にコンテンツを完全にロードできるように、ゲーム状態管理をセットアップする必要があります。もちろん、これはまさにレベルのロード画面の目的です! 非常に頭が良ければ、メトロイド プライムの「ドア ローディング」のように、ゲームプレイの一時停止中にこっそりロードすることができます。ただし、ゲームのスコープとアセットによっては、そのように動的にロードする必要はありません。
最後に、アセットのダンプについて: 答えは、OO プログラミングの偉大な比喩である抽象化です。メンバーの編成に問題がある場合は、必要に応じて継承されたクラスまたはサブクラスに移動します (賢明な場合のみ)。私のゲーム設計では、クラスごとに 2 つ以上Texture2D
の s、 1 SoundBank
、およびおそらくVertexBuffer
/を使用することはめったにありません。IndexBuffer
うまく設計できていれば、これらは「スプライト」などの基本クラスに格納され、そこからビジュアル オブジェクトが継承されます。私の最新のツール セットでは、1 レベル深くなり、実際のテクスチャにアクセスしたい場合Player.base
は " (Sprite です) " のように見えますが、すべてのアニメーション/描画がクラス.Animation.Texture
によって完全に処理され、、、などAnimation
とともに Sprite によって更新されます。Position
Rotation
Scale
Bounding
したがって、ゲームをオブジェクトに分解します。クラスに andTexture2D PlayerTex
をVector2 PlayerPos
格納し、で描画している場合は、オブジェクト指向プログラミングを利用していません。プレーヤーの他のすべての側面と動作 (メソッド) も定義するクラスに格納します。必要なのはだけで、を呼び出します。あなたはさらにそれを取ることができます!ほとんどすべてのゲームが持ついくつかのクラスがあります: (すべての動的オブジェクトの基本クラス)、(シーナリーと各レベルを保存し、それらの相互作用を処理します)、(それぞれの完了時にそのメンバーを保存してインクリメントします)、 (のスタックを保存しますGame
Draw
PlayerTex
PlayerPos
PlayerTex
PlayerPos
Player
Game
Player myPlayer
Draw
myPlayer.Draw(SpriteBatch .. etc)
Entity
Level
Entities
GameScreen
Level
ScreenManager
Screen
s to update, like GameScreen
, but also MenuScreen
, PauseScreen
, LoadingScreen
)... リストは続きます。この時点で、Game1
クラスが行うことは updateだけです。からScreenManager
継承する場合は、それを行う必要さえありません。ScreenManager
IDrawableGameComponent
OO 101 の奥深くまで掘り下げていないことを願っていますが、メイン クラスのすべてのメンバーを追跡するのに問題がある場合は、物事を分解することから始めてください。これは基本的な OO スキルです。
他のすべてが失敗した場合は、#region <name>
/#endregion
タグを自由に使用することを学びます。正直なところ、とにかくそれらを使用すると、すべてが改善されます。