Interesting theory for game structure

[bert]

Most games' level geometry is stored in a file and loaded when it is needed. This creates a need for loading screens and requires more storage memory where the level is located. However, if a level was to be built using predefined "blocks" similar to Legos, and the blocks were put together to create the level, then the blocks in the view of the user could be loaded into the scenegraph while the others could be freed up. This would be constantly happening so that loading screens would not be needed. This way you could make a large continuous level with no breaks. Also, it could lead to a fully interactive world. Because each block is stored individually, if for instace there was an explosion, all the blocks nearest to the blast could be removed and the next nearest set to a "charred" state, maybe with flames coming out or something. I think this approach could go a long way, but let me know what you think of this. I know the approach is not perfect and I am kind of new at 3D programming but if anyone sees any obvious benefits or drawbacks let me know.

[broumbroum]

I don't think so, your theory is kinda uncomplete in terms of data structure modelling. Say you want a simple Half-Life (you should know about this game, don't you ?) 3-Dimensional geometrical level to load as fast as possible, it doesn't matter how or when you want to display your level. As a first step, the main problematic is that one standard level involves more than geometric datas, that is, you have mainly the Texture's to load from file as well as Sound FX's and even Scenario's. That has much more to do with the compression you use than the amount of data you store. Then those Half-Life levels couldn't share more memory than the machine can, that means data is whether or not compressed, either loaded from files and put in cache/buffer but never let stored in their original files where the game Engine cannot manage each type of data to load on real-time if their type and compressed data don't get "normalized" or loaded previously to the real-time rendering begins.
As a matter of fact, a game-level is something you cannot "split out" if it ain't previously "swallowed", where the hazard is to get struggled with the amount of data your engine is using.

[darkprophet]

Already been done...Trackmania is a perfect example of that.

DP

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

[blahblahblahh]

This is also commonly used for the data parts of the level - google entity systems and/or property systems (although you'll get many false hits)

[CaptainJester]

Dungeon Siege also did it.  Scott Bilas wrote an article about the design. http://www.drizzle.com/~scottb/gdc/continuous-world.htm

[JAW]

Your block information needs loading as well. And you can use the same method of allocating and freeing on any other geometry structure as well. No need to load lego blocks. Just load an area of geometry data.

Generally, there are already some games that got rid of loading screens and created a seamless world. Chrome did so, it has huge levels and no loading. I wonder, doesn't Halflife 2 have as well no more loading screens?

-JAW