| Name | Description |
|---|---|
| BackgroundScreen | The background screen sits behind all the other menu screens. It draws a background image that remains fixed in place regardless of whatever transitions the screens on top of it may be doing. |
| BooleanButton | A special button that handles toggling between "On" and "Off" |
| Button | Represents a touchable button. |
| Constants | |
| GameScreen | A screen is a single layer that has update and draw logic, and which can be combined with other layers to build up a complex menu system. For instance the main menu, the options menu, the "are you sure you want to quit" message box, and the main game itself are all implemented as screens. |
| GameStateManagementGame | |
| GameplayScreen | This screen implements the actual game logic. It is just a placeholder to get the idea across: you'll probably want to put some more interesting gameplay in here! |
| Gate | |
| Highscore | |
| InputAction | Defines an action that is designated by some set of buttons and/or keys. The way actions work is that you define a set of buttons and keys that trigger the action. You can then evaluate the action against an InputState which will test to see if any of the buttons or keys are pressed by a player. You can also set a flag that indicates if the action only occurs once when the buttons/keys are first pressed or whether the action should occur each frame. Using this InputAction class means that you can configure new actions based on keys and buttons without having to directly modify the InputState type. This means more customization by your games without having to change the core classes of Game State Management. |
| InputState | Helper for reading input from keyboard, gamepad, and touch input. This class tracks both the current and previous state of the input devices, and implements query methods for high level input actions such as "move up through the menu" or "pause the game". |
| LoadingScreen | The loading screen coordinates transitions between the menu system and the game itself. Normally one screen will transition off at the same time as the next screen is transitioning on, but for larger transitions that can take a longer time to load their data, we want the menu system to be entirely gone before we start loading the game. This is done as follows: - Tell all the existing screens to transition off. - Activate a loading screen, which will transition on at the same time. - The loading screen watches the state of the previous screens. - When it sees they have finished transitioning off, it activates the real next screen, which may take a long time to load its data. The loading screen will be the only thing displayed while this load is taking place. |
| Particle | |
| ParticleEngine | |
| PhoneMainMenuScreen | |
| PhoneMenuScreen | Provides a basic base screen for menus on Windows Phone leveraging the Button class. |
| PhonePauseScreen | A basic pause screen for Windows Phone |
| PlayerObject | This is the player game component. |
| Program | |
| Score | Keeps track of the number of points that the player scored. |
| ScreenFactory | Our game's implementation of IScreenFactory which can handle creating the screens when resuming from being tombstoned. |
| ScreenManager | The screen manager is a component which manages one or more GameScreen instances. It maintains a stack of screens, calls their Update and Draw methods at the appropriate times, and automatically routes input to the topmost active screen. |
| SpriteManager | |
| WorldLine | A line is the most basic component of the world. |
| WorldObject | Keeps track of the world that the user builds. |