Nuclex.Game contains generic game-related classes that do not fit into another, more specific category. This includes variants of the
classes that do not require a reference to the
class, traditional binary serialization,
using QuadTrees and R-Trees, high-compressed content loading and game state management.
If you really want to trim your game's content down, the LZMA content manager enables you to use LZMA compression (as known from
) for your content files, typically reducing them to 66% of the size XNA's built-in compression can achieve.
Rectangle packing is the art of arranging different-sized rectangles in an area while minimizing wasted space. Game programmers typically encounter this problem when they want to place multiple sprites (or letters from a bitmap font) onto a larger texture so
the game doesn't have to switch textures continuously when rendering.
The Nuclex.Game assembly provides several rectangle packing algorithms with varying degrees of space efficiency versus runtime performance.
Sometimes, XML serialization just doesn't cut it. If would want to persist the state of an entire world, XML serialization might be too slow, too large or simply inadequate to apply to your object model. Here is a simple helper that makes it easier to persist
game objects in binary form:
If you have thousands of objects flying around in your game, checking any object versus any other object to do collision detection just won't work. Spatial partitioning helps you to reduce the number of checks by enabling you to query which objects can
The best known data structures on this topic are the QuadTree and Octree, but the Nuclex.Game assembly also provides variants of the R-Tree, are data structure that doesn't suffer from the drawbacks of a fixed world size and static node boundaries.
- R-Tree (plain, hilbert, priority)
Game State Management
Game states are a popular way to organize your game's state changes. State changes occur whenever the game enters a different mode of action - for example, your game's main loop does something entirely different when displaying the Menu in contrast
to when the game is being played.
One problem of the
classes are that they require a reference to the
class to do their work.
This dependency on Game is arbitrary and prevents you from using GameComponents in XNA applications that are not based on the Game class, a typical case being a map editor where you use WinForms. Nuclex.Game provides two replacement classes that are identical,
except that their constructors are satisfied with only a