Menus can be very diffrent from each other. Some games implement very complex menusystems while other rely on basic systems.

I have a simple yet effective menusystem where the base is a Menu-class. I let the Menu-class have attributes which keeps track of where the "cursor" of the menu is and where the in the menusystem that the user currently is.
And whenever the user press Enter I ask Menu where the cursor is, and menu answers me. This is basicly how it works (pseudocode):

while( true){    if( gamestate == menu )        _menu.update(); // this class checks for keypresses itself    if( gameState == inGame )    {        if( keypress == Esc )            gameState = menu;        _game.update();    }    if( keypress = Enter )    {        if( _menu.getNewState() == cursorAtNewGame )        {            gameState == inGame;            _game.newGame();        }    }}

You can add complexity to this code to fit your needs. The good thing about this is that even though the user gets back in the menu, the state of _game will be the same, so you can easily implement a "Resume" feature in which you just begin updating the _game-class instead of creating a new one.

Then you have the standard render() methods etc so you actually see something [smile]

My sprite engine isn't finalized, but here's how I'm doing it: I used D3DXSprite for all 2-D graphics because it handles caching and optimization on its own, and that's fine by me. My GUI consists of a variety of control classes that basically work like ActiveX controls. They have scripts to define their behavior, and this ties into the scripts that control the game, so it all works seemlessly. The actual sprites used by these control classes are very generic and behave exactly like sprites in-game. Sprite behavior is controlled using states, which are issued by the game.exe itself, but the sprite manager is responsible for processing these states. I use XML-style definitions to describe the behavior of a sprite in a given state.