changing game "scenes"?
Blitz3D Forums/Blitz3D Programming/changing game "scenes"?
| ||
| hey I need help with something very important. See, I have been trying to figure out how to change "scenes" in my games. For example, take a look at the video link below http://www.youtube.com/watch?v=ry5epXZATW0 When not in a battle, mario can run around and stuff explore. When you touch an enemy, the game switches to it's "battle" scene. When in here, the gameplay completely changes. I had an idea of deleting the objects(such as mario and the free roam world) and loading the battle scene objects(the battle stage and battle mario) which would all be coded completely differently,but when the battle is over, you would have to re-appear in the same spot as you were when you bumped into the enemy and continue to explore. That's what got me. Switching scenes and then switching back. How would you bring the free roam world type mario back after your done with battle type mario? Same thing goes with changing rooms. When you leave a room, you come out where you came in from, and vice versa. I had some ideas on making it work, but I think i'm gonna need some help with this one. |
| ||
| Three separate things come to mind: deleting the objects(such as mario and the free roam world) and loading the battle scene objects(the battle stage and battle mario) Don't delete anything you know you're going to need again. Loading is an expensive operation, so you should do it only when necessary. These days, memory is the cheapest resource available to you, so use it to take the load off the CPU and disk as much as possible. Instead, when you want a scene to temporarily disappear, remember that HideEntity affects all children as well. Pause all of the various moving/thinking objects however is appropriate (if your actors don't have a "paused" state, add one), and hide a pivot that has been parented to everything in the scene (use a new root pivot for each scene, rather than having one "scene control" and having to change the parent of lots of things at once. Make it a standard component of your scene setup). That way, when you want to show the scene again, you can just ShowEntity and resume animating, which will be very fast by comparison to loading. you would have to re-appear in the same spot as you were when you bumped into the enemy and continue to explore. Since you know that battles 1) will dump you back to the level and 2) will happen several times, both the level and the battle screen count as "need again" scenes. Hide the level, set the battle scene to the start position (you could do this manually, but remember that animation can be applied to any hierarchy so you can use it to position entire scenes simply by animating the scene root, if you have it set up correctly) and engage the battle loop. Once that's done, pause all actors in the battle scene, hide it, show the level, and resume. Since nothing in the level moved, you get the continuation for free. Same thing goes with changing rooms. When you leave a room, you come out where you came in from, and vice versa. Actually depending on your game structure it may not be the same. Assuming the game is played by moving from level to level, at some point the user won't be returning to earlier stages, so level transitions aren't necessarily a "need again" switch. Levels are also likely to be a more involved stage than battles since the player can move freely. I would have two suggestions for them: 1) Maintain a level cache stack. Keep the last N levels loaded and ordered, adding the scene root for the last room the player left to the top of the stack. If the stack exceeds N rooms, throw away the one on the bottom (the oldest one and therefore the one they're least likely to return to), using whatever means you use to free scenes. You may want to make exceptions for "special" areas (e.g. say you had a playable main menu that the player will always return to or something). 2) Returning to a room really depends heavily on how your game works, but rather than relying on Not-Mario not having moved (you'll probably have moved him from scene to scene, anyway), you could have a list of exits for each room linked to entry points in other rooms, so that the game knows which door you enter from based on which door you used to exit the previous area. You can then use this information to help setup the scene (e.g. Not-Mario left room 4 through door F, therefore he enters room 5 through door C, which <lookup> is located at Blah, Blah, Blah, and sets the room state to Blah). All very vague and general... but I'm afraid it was a rather general question! |
| ||
| I agree with Yasha regarding "Don't delete anything you know you're going to need again" - I was trying to be all clever managing resources, etc. with an element of the application I'm developing in blitz but after it moved on from half a dozen instances of an objects to 200-300 instances where I was deleteing and reloading some objects started to take up CPU time until I was in a situation where some frames the code for that could hog 400-500ms alone which isn't good. By hiding them when not needed it dropped to 2-3ms which is perfectly acceptable and the increase in memory footprint was only 19MB nothing like as bad as I'd feared it would be. |
   |