How do you guys handle intros?
Hello you gameprogrammers!
I''m working on a game, but now there''s a problem I can''t solve:
I don''t know how to program an intro! You might think:"How can
this idiot ask such a question?!" Well, let me try to explain it:
My game''s main loop looks something like this(pseudo c):
int GameMain()
{
LoadSprites();
LoadSounds();
...
//Here should be something like an intro
//Intro();
while(Active)
{
...
GameLogic();
...
DrawEverything();
}
UnloadSprites();
...
}
(I use a fixed step time-system using GetTickTime to run the GameLogic 30 times per second and render how fast the system allows.)
The problem is that I want to have an intro programmed as easy as:
void Intro()
{ StartMusic();
DrawText("HELLO");
PlaySound("explosion");
MovePacManFromLeftToRight();
Delay(3000);
DrawText("TO MY GAME...")
Delay(2000);
...
}
Yes, I could do this BUT I have to update the screen(flip surfaces) while intro() is running(in order to see something ;-). I think that it would be bad to do it like this:
DrawAnything();
FlipSurfaces();
DrawSomethingElse();
FlipSurfaces();
...
I tried to solve it with having one thread for flipping the whole time and the other one to do everything else what made my game unplayable slow.
How do you guys handle such things?
THX skrwX
I just do another loop inside of Intro(). Here is the general format I might use:
|
I wrote a short article on doing progress bars and intro screens, i think its here on gamedev somewhere
basically you need an UpdateProgBar() call that incrememnts the prog bar and does a Blit/Flip, and you call this after each chunk of your loading from your Intro() function.
http://www.positech.co.uk
basically you need an UpdateProgBar() call that incrememnts the prog bar and does a Blit/Flip, and you call this after each chunk of your loading from your Intro() function.
http://www.positech.co.uk
The best way to program something like that would to be to use a state machine. A state machine is perfect for game programming for more than just an intro. Here is an example of a simple state machine that has on three states.
First you want to enumerate the game states.
enum GameStates {
GAME_INTRO,
GAME_PLAY,
GAME_PAUSE
};
Then you do your main loop something like this
GameState g_state = GAME_INTRO;
InitStuff();
while(1) {
if( GameLogic( g_state ) == TRUE )
{
if( Render( g_state ) != TRUE )
break;
}
else break;
}
ReleaseStuff();
Now GameLogic() and Render() can work based on your state.
BOOL GameLogic( GameState& state )
{
// Change states here say if the user pressed ''P''
// one might toggle GAME_PAUSED and GAME_PLAY
switch( state )
{
case GAME_INTRO:
// use escape to bypass maybe
break;
case GAME_PLAY:
// main game logic
break;
case GAME_PAUSE:
// don''t do any logic
break;
default: return FALSE;
break;
}
return TRUE;
}
BOOL Render( GameState state )
{
switch( state )
{
case GAME_INTRO:
// draw credits, movie or menu
break;
case GAME_PLAY:
// Now draw your main action
break;
case GAME_PAUSE:
// maybe draw a game paused screen
break;
default: return FALSE;
break;
}
return TRUE;
}
And that''s how you would use a state machine. Of course you would probably have hundreds of states in a large complex game.
Regards,
ReikoX
First you want to enumerate the game states.
enum GameStates {
GAME_INTRO,
GAME_PLAY,
GAME_PAUSE
};
Then you do your main loop something like this
GameState g_state = GAME_INTRO;
InitStuff();
while(1) {
if( GameLogic( g_state ) == TRUE )
{
if( Render( g_state ) != TRUE )
break;
}
else break;
}
ReleaseStuff();
Now GameLogic() and Render() can work based on your state.
BOOL GameLogic( GameState& state )
{
// Change states here say if the user pressed ''P''
// one might toggle GAME_PAUSED and GAME_PLAY
switch( state )
{
case GAME_INTRO:
// use escape to bypass maybe
break;
case GAME_PLAY:
// main game logic
break;
case GAME_PAUSE:
// don''t do any logic
break;
default: return FALSE;
break;
}
return TRUE;
}
BOOL Render( GameState state )
{
switch( state )
{
case GAME_INTRO:
// draw credits, movie or menu
break;
case GAME_PLAY:
// Now draw your main action
break;
case GAME_PAUSE:
// maybe draw a game paused screen
break;
default: return FALSE;
break;
}
return TRUE;
}
And that''s how you would use a state machine. Of course you would probably have hundreds of states in a large complex game.
Regards,
ReikoX
May 31, 2001 08:53 PM
State machines work best if you have only one input and one output to the state.
But what if you have two different menus that can jump to the same menu?
How would it know where to return because you now have two return paths?
In this case, I would use something like a parent-child linked list of
states.
But what if you have two different menus that can jump to the same menu?
How would it know where to return because you now have two return paths?
In this case, I would use something like a parent-child linked list of
states.
1. Global FSM: IN_GAME, IN_ATTRACT_MODE, IN_INTRO, IN_MENU
2. For menus, each "screen" has its own FSM, the heirarchy is automatic, each screen just has its own current state. If organised in a C++ heirarchy too it all works nicely.
Thats actually rougly the way we did the front end on Pac-Man:Adventures in Time (for Hasbro)
--
Simon O'Connor
Creative Asylum Ltd
www.creative-asylum.com
Edited by - S1CA on June 1, 2001 11:06:48 AM
2. For menus, each "screen" has its own FSM, the heirarchy is automatic, each screen just has its own current state. If organised in a C++ heirarchy too it all works nicely.
Thats actually rougly the way we did the front end on Pac-Man:Adventures in Time (for Hasbro)
--
Simon O'Connor
Creative Asylum Ltd
www.creative-asylum.com
Edited by - S1CA on June 1, 2001 11:06:48 AM
Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement