Organizing Levels

Blitz3D Forums/Blitz3D Programming/Organizing Levels

En929 (Posted 2010) [#1]

I'm working in BlitzPlus (and am still pretty much a beginner), but I was wondering is it a good idea to break levels up into different Functions, instead of making them all in one big strand within the program? Is that common practice? Thanks

Zethrax (Posted 2010) [#2]

Game levels are normally data-driven using external data files to define the level. This allows you to add new levels, or mod existing ones, without needing to re-compile the code. If you're hard coding the levels, then try to make the code as modular as possible. Avoid integrating the level code too tightly with your main code, so that you can manage them more easily without conflicts, and so you convert them to a data-driven approach if you decide to do so later. Functions are probably the best choice for this.

En929 (Posted 2010) [#3]

I was wondering if a player goes away from a level (but has to come back to it eventually), is it necessary to delete that level (to save memory) and then reinstate it when the player comes back to it)?

Yasha (Posted 2010) [#4]

That depends on your definition of a level, really. How self-contained are they, and how big? eg. One extreme would be the Hitman games: massive, extremely detailed levels that have no entry or exit points and each represent a single chapter of the story. It makes sense to free these when you're done, even if the story will come back to the same level later, as it will be several minutes or even hours away (and you can hide the loading behind a cutscene). On the other hand you might have something like the Elder Scrolls, which is big and detailed but with absolutely no borders and totally free access: for this kind of gameplay to work, you'd need to be caching the level data for the areas around the player as well so that the transition from one to another is totally seamless. The other extreme might be something like Final Fantasy 7: the "levels" are essentially single screens and very quick to load because they're flat panels. You could reasonably go either way here, as you need quick access but they're also pretty fast. Basically, it comes down to how long you think it will be before a user wants to come across a transition and how smooth that transition has to be (obviously you'd want it to be seamless in any case, but this isn't always an option) so that the style of gameplay is uninterrupted. If you need seamless gameplay, you should be considering keeping the last level accessed in memory, and possibly some kind of background-loading system so that the next one will be ready as well by the time the player gets there (at which point you could free the level one back as the player is far enough away that you have time to reload it if necessary). If you don't need seamless gameplay, just free everything and reload it again at the start - and come back to this as a potential area for improvement once the majority of the game is done.