From procedural programming to better...
Author
I'm a c++ programmer and so far have done one game with SDL. The problem is that the code is kind of clumsy. I'd like to go from this (pseudocode):
Mainmenu_loop()
{
// Mainmenu code goes here.
Game_loop()
{
// Gamecode goes here.
}
}
To this:
Mainmenu_program()
{
switch(mainmenu)
{
case start_game: run game_program
case options: go to options_program
case quit: quit
}
}
If anyone knows any tutorials or such or could give any enlightening tips, please do so :) (I know, the answer might lay right in the pseudo-code I wrote but I have a picture it's not that simple. )
Thank you.
I recommend making your system class-based. That is, when you want to show the options dialog, pause the engine otherwise and use your option dialog class' method ShowOptions() (or something like that). This approach has the advantage that you can show the options dialog at any time during the game, not just the start screen.
Inside the ShowOptions method, handle the user's input and optionally draw the current game image to the background in addition to the controls that your dialog has. When the user closes the dialog, resume to the game loop as usual.
Inside the ShowOptions method, handle the user's input and optionally draw the current game image to the background in addition to the controls that your dialog has. When the user closes the dialog, resume to the game loop as usual.
Author
Thanks Nik02, good tip. What about the starting menu? Could it be coded into a separate file from the actual game code and use it to execute the game and change configurations and such? (Maybe a simple question, but I wonder how it is done)
*Added* I mean the execution part. Would a simple game function do the job?
[Edited by - wlicker on April 1, 2006 4:55:47 PM]
*Added* I mean the execution part. Would a simple game function do the job?
[Edited by - wlicker on April 1, 2006 4:55:47 PM]
Yes, the start menu could also be represented as a separate class. Here's a (greatly simplified) c++-based metacode of a game flow I have used:
In my start menu, I have used a "continue game" option so that when the player presses the "quit" key, he has the option to go back to the game if he wants. Also, the start menu should have "save game" and "load game" buttons as appropriate.
All of this can be done procedurally also, but with classes I find it much simpler. I tend to make any system class-based, because object oriented programming maps very nicely to real-world goals and objects (not always, though).
Initialize systemsLoop while user hasn't quit{ Show Start menu; Gameloop { if (user wants to see options dialog) {pause engine; show options;} if (user wants to quit) {pause engine; show start menu;} Handle game logic and i/o for the current frame; }}In my start menu, I have used a "continue game" option so that when the player presses the "quit" key, he has the option to go back to the game if he wants. Also, the start menu should have "save game" and "load game" buttons as appropriate.
All of this can be done procedurally also, but with classes I find it much simpler. I tend to make any system class-based, because object oriented programming maps very nicely to real-world goals and objects (not always, though).
While, Nik's solution is probably better, if you are OOP challenged (like I am), you can do what your pseudo-code suggests and create a case statement in the loop. That's generally what I do in my games. I set up constants for each portion of the game and then switch a game_state variable every loop. If the game state is in options, I am doing something completely different then in the running state. You can check my project Bounce Tennis! on my journal for the source code for how I pull it off.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
