Dealing with Scene Changes(Intro->Menu->Lvl)

[ribot]

I'm hoping this will be a simple 'question-answer' scenario.

Here goes - I'm currently looking into the best(most simple) way to manage different scenes within a game.  I intend the game to use the LWJGL and was wondering how to extend on a simple one scene game.  The way I view a game by breaking it into a number of defined scenes, which could include the following:

1) Welcome screen (e.g spinning 3D logo or simple bitmap image)
2) Intro screen (e.g. a short peak 3-5secs each of a few of the levels using the in-game engine).
3) Menu screen (e.g. similar to that found in Alien Flux)
4) Game level 1 (in-game action at level 1)
5) Game level 2 ( " 2)
6) Game level n ( " n)
...

I'm basically trying to get my head around where to place all the display code for all of these scenes.  Should I have a core OpenGL renderer class and pop a scene object within the display() method? Or are there other more plausible suggestions to help slove my problem? :-)

Ideas would be much appreciated.

ribot.

[Orangy Tang]

I'm using a really simple system of game 'states' to handle this, and it seems to work pretty well. Basically you have a GameState interface with a few simple methods: show, hide, shutdown, update & render.

The main class cotains a single GameState which is being used, and fires off the appropriate events during the main loop. States themselves handle moving on to the next state - so a main menu could replace itself with an options state or the actual game scene state.

However having some kind or renderer that you can push states at is probably not a good idea - states usually are rendered in totally different ways, so you'd be better leaving it up to a state to draw itself. But that doesn't mean for something complex like an in-game state it can't have an associated renderer for scene drawing.

[ribot]

That's the idea I'm looking for Tang!  

I agree with you that it would be bad to push states to a single renderer due to the points you raise.  

I now just have to figure out how to handle the moving to a different state.  Do you have any examples?  Are there any drawbacks to the methods that you wrote about?

Games published by our own members! Check 'em out!

[Backmask]

Hi

I have built a framework that can handle just about "anything". It's so simple as it can get, with only two core framework classes.

CoreFrame - Is the frame where the game is being rendered. Handles switching to fullscreen, windowmode, input and the rendering loop with timing. Holds information about the size of the frame, if the rendering is started, fps count etc.

CoreEntity - A simple "thing" that lives withing the game. Can be a sprite, scene, a layer within a scene etc etc. CoreEntity is only an interface with four method, init(), tick(), display() and destroy(). When creating a new entity you just implement these methods and extends with the entity specific methods.

The thing is that CoreFrame can only render one CoreEntity, that is within the rendering loop if an CoreEntity has been set on the CoreFrame its tick methods is first called to update the entity followed by the display method.

So what about handling multiple scenes? Just create a new entity that implements CoreEntity and name it Scene. A scene should of course be able to handle rendering more than one entity so some sort of collection to hold the entities within the scene i nessessery. So in the display method of the scene just loop through the collection and call every entities display() method. The same with the other method. Set the scene on the CoreFrame, as it is an CoreEntity this i allowed. And when it is time to switch between scenes just exhange the current rendering entity in the CoreFrame with the new scene.

Why entities? Take the example of a large levelboss. It contains of many sprites, eyes moving, moving legs etc. If your rendering framework only can render sprites you have no logic way to connect the sprites with each other. But if you create a EndLevelEntity that contains all the sprites(that also are entities) you can only call the display() and it's EndLevelEntities responsibility to draw all sprites that the boss contains of.

I have extended the framework with the following classes for the moment.
Scene - As explained abow
Layer - If you need to control which entites that are rendered on top of others use a layer to group them and add it to the current scene.
Sprite - No explaination needed
All these classes implements CoreEntity.

Also I have a collision framework that work out collision between entites.

I have build a number of small rendering framework before and have always overbuilt them. Thats why I like this simple approch. Maybe it is something for you to?

Edit: typos

[Orangy Tang]

For my method, switching to a new state is just a call like:
Game.app.setGameState( new MainMenuState() );
Which then automatically calls .hide & .shutdown on the old state, and .show on the new state as it is swapped in. Actual state transions are pretty much hardcodes - pressing the 'options' button always swaps to the options states, the hiscore state always switched back to the main menu etc. It sounds a little restrictive but it doesn't cause any problems really.

I have tried having a stack of states before, where new states get pushed on or popped off. This means you can have an options state pushed on, and then just pop it off to reveal the previous state with the back button is pressed. Its probably a better idea if you've got lots of layered dialogs (an RPG inventory perhaps?) but it can get a little confusing.

The stack also means you can keep states in memory instead of recreating them each time, but theres no reason why you couldn't get the same effect with the first method and a pool of created states.

[blahblahblahh]

I have tried having a stack of states before, where new states get pushed on or popped off. This means you can have an options state pushed on, and then just pop it off to reveal the previous state with the back button is pressed. Its probably a better idea if you've got lots of layered dialogs (an RPG inventory perhaps?) but it can get a little confusing.

The stack also means you can keep states in memory instead of recreating them each time, but theres no reason why you couldn't get the same effect with the first method and a pool of created states.

I combined several things in my last framework (not necessarily better, but I found some of them particularly neat in practice):

NB: there was no explicit stack

- "default" state. Whenever a state exits and doesn't specify a new state to takeover, the default state takes over. Useful in lots of situations to have a top-level/root node that always takes over if needed

- delegateToState( ... ) causes the specified state to take over implicitly pushing the current state onto the stack (makes it a bit friendlier for people not accustomed to using stacks )

- switchToState( ... ) as for delegate, except does NOT push the current state onto the stack

- exit(). Depending upon how this state started, exits this state and chooses a different one (c.f. previous items)

I think there were some other things, but IIRC I found that the above simplified options were actually enough to do everything I wanted, and were a little easier to maintain than a stack (because the relationships between states were more explicit in the source code, and didn't place such a burden on the reader of mentally keeping track of the stack...)

One of my aims was making the source easier to understand "at a glance".

[tom]

A very simple solution:
Each scene is a function (runIntro(), runMenu() runLevel() etc). The function contains it's own main loop. It handles all its own input and rendering. It returns from the function when the scene is done.

[Orangy Tang]

Having explicit switchTo and delagateTo sounds like a good idea - one of my the main problems with the stack approach was with states that actually end. Menus etc. work great with the stack as they simply return to the previous bit, but actually moving 'sideways' from the end of one state (such as dying in game) to a hi score table was somewhat non-obvious in the code.

[Jacko]

The approach I'm trying at the moment (borrowed from Game Coding Complete) is to have an abstract Process class and a Kernel class. Processes are added to the Kernel which manages them, and ticks them every frame. State switching is done by a Process adding another Process, then killing itself. I have also set up some "next" type functionality, so that when a Process dies, it can kick off another process.

Oh, and the engine reads the name of the first process to start from a text file, so I shouldnt need to write much in the way of startup code again!

[blahblahblahh]

The approach I'm trying at the moment (borrowed from Game Coding Complete) is to have an abstract Process class and a Kernel class. Processes are added to the Kernel which manages them, and ticks them every frame. State switching is done by a Process adding another Process, then killing itself. I have also set up some "next" type functionality, so that when a Process dies, it can kick off another process.

Anyone happy with copying threading-systems paradigms  ought to have a look at co-routines (one of several alternatives to "threads" for running multi-process code). They have been used for decades to do multiple processes in a single thread, are simple and easy to use, and there's tons of literature around.

I got some of my ideas from co-ro's, incidentally.