Well, for the health bar you could take a look at some ideas in this discussion:
http://www.gamedev.net/topic/522979-hit-bar/
(Actually that site has a wealth of interesting articles you may find helpful on various topics of graphics and game programming. ) . Essentially, usually for a standard type of health bar you'd want to have a bar that changes in size depending on the health points of your character. So the width would be maximum when HP is, and it would be 0 when HP is 0. You could get the bar as a solid rectangle that's drawn on the screen and it's length is manipulated by
|
currLength = ((current_HP * barLength)/max_HP);
| |
This could be a textured rectangle, and you might even make a non-rectangular bar by making the part of the rectangle that lies outside of the bar to be transparent (using alpha blending). Another approach, for more complex bars, meters and HUD elements, could be to have a spritesheet of animation for them and to simply animate them the same way you animate an entity (so you could have animation clips for "health up", "health down" etc).
Regarding combos, they are pretty much an extention of player states. See this thread for a discussion on player states, it should give you some idea on how they work (in conjunction with the SDL tutorials I linked earlier).
http://www.cplusplus.com/forum/windows/84950/
For the menu, you would have to draw a user interface and then draw it on the screen in the same way and using the same functions and programming tools as when drawing in your in-game mode. You should program options to highlight and open menus (animate them to open, etc) upon the player highlighting them with the mouse, or pressing a keyboard key etc. . It really depends on what you want to do. Generally, you should have a good idea of what you want your gameplay and interactivity to be like, and then translate it into programming terms. An example: for a simple menu of "New Game", "Load Game", "Options" and "Quit" with no animation but simple highlighting (and no mouse support for the user -- only keyboard), you'd have to draw a background and then draw the 4 choices in the foreground. Then you'd have to keep track of the currently highlighted choice (using an enum, perhaps). Then, supposing your menu is vertical, and supposing that "New Game" is the default choice and is highlighted by default upon starting the game -- this means that the top choice -- being "New Game" -- should be drawn using it's highlighted version rather than it's unhighlighted version (you should have these pre-drawn in a graphics program and use the appropriate one depending on the enum's current value). Then, by pressing down-arrow-key, the program should respond to that keyboard input by updating the currently highlighted element of the options list to be "Load Game", and then upon rendering time, the program should now draw a non-highlighted version of "New Game" and a now highlighted version of the "Load Game" option -- which is where the player's current option has been placed because the down-arrow key was pressed.
Doing the same with mouse support would involve checking the x,y coordinates of the mouse and seeing if they are over any of the available options' bounding rectangles (which are also defined in the same coordinate system). Then you'd have to update the enum, and highlight and unhighlight accordingly upon frame-rendering time. That's pretty much how this goes. Then, if you had an animated menu, you would also have to manage animation clips for each option (rather than a simple bool flag that has a true or false value).
Also -- a note on SDL, now that I remembered. SDL does not have layers or a notion of screen depth, since it is 2D. This means that all your rendering/drawing is done from the furthest back elements to the nearer ones, so that the ones that are nearer are drawn after the ones that are behind them -- and effectively on top of them in terms of the frame buffer. So, for the helath bar for instance, you'd draw that on top of everything else, so that it is always in the foreground in relation to everything else.
Combos, and other more specific gameplay elements, are just more specific and complex applications of the basic ideas presented in tutorials like the ones I linked earlier. You're just handling more animation clips, defining more player states, making more comparative checks and updates in every game loop.
A book on SDL sometimes referred to is Pazera's "Focus on SDL". You might find that helpful too.
Hopefully this post will be of some help to you (and possibly not too hastily written!). I suggest you check out gamedev and the SDL tutorials (and try reproducing the effect in code yourself, from first to last), as you'll understand a lot of the mechanics for this type of programming and this type of game engine by doing so.
Ogoyant