Over the last few days, I've picked up my games programming project once again.
Where I was up to was to implement trigger zones and manage level changes.
I've now done the triggers, however the problem area now lies within the way I thought about implementing the level changes. This is as follows:
- Level class
- Overall level object which holds the current level instance
- The level class has a "nextmap" filename
Once the "End" trigger is reached, the current level will unload it's self and create a new instance which gets assigned to the overall level object. This then will load the new level - one problem here is that there will be no loading screen as a result of this, however I feel like I know a method of implementing that.
I feel like there is a problem in doing this however I'm not entirely sure what it is.
5 replies to this topic
Sponsor:
#2 Crossbones+ - Reputation: 1242
Posted 16 April 2012 - 03:28 PM
Have a search for state machines, as these will fix your issue here, there is more to a game then just a level.
A simple game based state machine code look like this:
Menu State (contains press start screens and main menu and the likes)
Loading State (takes care of level loading and unloading)
Level State( this is the container for the current level being played)
Game loop would look like
Menu state -> loading state -> level state -> loading state. After this you can either go back to menu state or level state.
This allows you to move the loading of the level away from the actual level and game code. In each of these states you can run another state machine again, eg Menu state could have a main menu and options menu between which you can transition.
A simple game based state machine code look like this:
Menu State (contains press start screens and main menu and the likes)
Loading State (takes care of level loading and unloading)
Level State( this is the container for the current level being played)
Game loop would look like
Menu state -> loading state -> level state -> loading state. After this you can either go back to menu state or level state.
This allows you to move the loading of the level away from the actual level and game code. In each of these states you can run another state machine again, eg Menu state could have a main menu and options menu between which you can transition.
#4 Crossbones+ - Reputation: 5345
Posted 16 April 2012 - 05:50 PM
It takes hardly any time at all and is the proper way to go.
One level should not know about any other level. If a level has a file name for the next level, you are doing it wrong. Save that kind of information for a higher-level structure.
What if you want to get to level 3 via a save feature? Do you have to load levels 1 and 2 to get the file name for level 3 or do you have to duplicate the level table? It doesn’t make sense that levels know about other levels.
L. Spiro
One level should not know about any other level. If a level has a file name for the next level, you are doing it wrong. Save that kind of information for a higher-level structure.
What if you want to get to level 3 via a save feature? Do you have to load levels 1 and 2 to get the file name for level 3 or do you have to duplicate the level table? It doesn’t make sense that levels know about other levels.
L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
#6 Members - Reputation: 105
Posted 16 April 2012 - 08:29 PM
and with regards to your comment about a map not knowing what map is next, I've changed it so that each "end" trigger has an attribute which contains the next map's information. Obviously leading to me creating a hubworld and utilizing this method of going about things.
This approach is also good because I can then have the player load into the hubworld every time, then enter the level where they left off.
This approach is also good because I can then have the player load into the hubworld every time, then enter the level where they left off.






