That's very near exactly my technique. Only it kinda breaks when you do things like having a level editor. It's easier to code a level editor separately, and you may wish to use the editor again somewhere else. Suppose you have a graphic editing tool, I mean, you wouldn't build high octane photoshop utilities into your game. It's kinda like that.
im a single frame builder as well. i think most of us are.
but i do put menus and sorts into their own frames for a more clean building enviroment.
but the actual game resides in a single frame and usually uses global values/strings when doing level jumps ect.
...all typos belongz to me... ...yes all of em... ...oi handz off my typoz...
My last project: DTV Boxes was.
Just like AmyS3 I had the menu in another frame.
And the level selector, which then jumps to the level frame to load a level from the levels folder.
But most of my older games where made with multiple levels, mostly platform games in KnP/TGF, for which I could use the build in level editor.
The number of objects that can exist in a frame is limited by fusion itself, so there is that.
Off-screen objects that are set to only be active when they're in the frame seem to have no effect on the framerate since their collisions and other things aren't calculated. That's a trick I've used before to squeeze extra performance out of the runtime.
Most of the time though since I build everything in a separate editor, it's just a matter of splitting larger levels into smaller chunks and having the frame load it in when it's needed.
Originally Posted by -UrbanMonk- The number of objects that can exist in a frame is limited by fusion itself, so there is that.
Off-screen objects that are set to only be active when they're in the frame seem to have no effect on the framerate since their collisions and other things aren't calculated. That's a trick I've used before to squeeze extra performance out of the runtime.
Most of the time though since I build everything in a separate editor, it's just a matter of splitting larger levels into smaller chunks and having the frame load it in when it's needed.
Build everything in a separate layer? What exactly do you mean?
So the question I have now is, if I were to build a single frame game with at least 10 levels each with randomly generated areas within, how would I go about transitioning between levels in the single frame? (An example file would be greatly appreciated)
Normally what I do is place all my levels in separate frames, while that is simple and effective, it is a bit too linear for my taste, and I want to try something new this time around.
No example needed, consider these frames for a platformer:
1 title
2 menu
3 world map
4 level
5 game over
6 end
The names of the frames speak for themselves.
In frame 4, to level that will be loaded for play there is a level ending condition.
Once that condition is met, the game can jump to frame 3, the world map and the player
can select the next level to play, which will be loaded in frame 4.
I learnt my lesson with Tormishire, part of the reason the first attempt died was because of using lots of frames. Very silly way of doing it but it was before I knew how to make a level editor at the level of complexity I needed for the game. Big Sky was 13 frames, each settings screen had its own frame. But that was sloppily made too.