In the past I've used a singleton design pattern for such things as graphic systems, input handlers, image managers/banks, etc. In C++ its quite easy to use templates and multiple inheritance to have many singleton classes with very little effort (see bomberman and ISO projects). However C# currently lacks template support and does not allow multiple inheritance. While a singleton pattern is still trivial to implement in C#, it becomes messy and lots of code ends up being copied and pasted.
A better solution seemed to be to keep all classes that would normally be singletons inside of a central game class. However to distinguish between the outside "shell" that communicates with the rest of our game world and the inner logic that regulates gamestates, timers, events, etc I created a GameShell and GameCore class. And although my OOP professors might kill me for this, I used inheritance (GameCore inheriting from GameShell) to make this relation cleaner and easy to read.
As shown in the picture above, objects and the rest of my engine understand how to communicate with game shell, while game core remains inside of the shell and handles all engine logic. Certainly not a complex design pattern, but I felt it really helped to keep things straight and in order for this project.
Selected Source: [GameCore.cs] [GameShell.cs]
Gamestate Manager and the Level Editor
Gamestates have been wrapped inside their own self containing classes. This allows them to be specified at runtime to allow for easyily mod-able games. Furthermore the level editor has been treated as just another game state. A new C# project was created and only a Panel is passed to the engine instead of a Window. The game engine function identical to how a game would, instead it renders to the designated window panel instead of a full screen or full window. The map editor then is just another game state like everything else. This gives us a huge advantage of being able to simply switch gamestates and test the game, just as it would if being run from the game's normal executable, without ever having to modify or write extra code.
Also, more than one gamestate may be active at once. This allows for "high level" gamestates that are active, but still allow for "primary" gamestates to run in the background. An example of this is during a multiplayer game, the game does not pause if a player is typing something at the console or is in an option menu; his character ceases to update input, yet he should not leave his current game. Gamestates are can activated, deactivated, paused, and told to run in the background.
Selected source: [GameStateManager.cs] [EditMapGS.cs] [MainGameGS.cs]
Game Objects: rendering, collision detection, updating, etc
As seems to be standard with object orientated game programming, all game objects inherit from a base game object. Additional classes and mechanisms are then littered through out the engine to make things like rendering, collision detection, and event handling and updating standardized for all objects. For example the game renders the screen through a camera class, which can be "attached" to any game object; to follow the object around the game world. This allows things like a weapon that fires a user controlled rocket (think Unreal Tournament's reedemer) to be implemented almost effortlessly. Forces such as gravity or wind can be attached or added onto each appropriate object and said forces will act behind the scenes on the object. All of these classes help to make the game engine easy to work with and easy to modify.
Selected source: [GameObject.cs] [PhysicsObject.cs] [GameObjectManager.cs] [BasicObject.cs]