Dynamically loading sublevels, Version 2.0
March 2, 2005.

By Dirk Mittler
Email mdirk@sympatico.ca

This suggested C-Script tool should be used with CREDIT given to its author, because its nature implies a more serious type of game-development. Its function is to provide a mechanism which will allow only parts of a HUGE game level to load at any time, while additional areas of that level will load as game-play continues. To use this C-Script tool requires the most recent versions of the game engine (A6.31 suggested), and also requires that the game-sublevels be designed graphically with this one strategy in mind.

If this poses an understandable problem to the recipient, I would suggest reading no further.

The method this script supports would be, for the game author to subdivide his huge game level, which is at present allowed to span 100,000 quants. Each sub-part of this larger game level will be referred to as a sublevel. The sublevels will contain all the intricate details that the player expects to see throughout the game. But the game-author will replace the sublevels in his or her game with matching empty boxes which are called 'createboxes' in this system.

To load a very large game level at once requires considerable main memory + graphics memory, that players can often not be expected to install on their computer. But to load a game with Invisible, Passable creatboxes should require much less in resources, because the createbox will only be defined as an empty box, with exactly the same outer measurements as the subevel it represents. It's understood that the game level will contain these createboxes as Map Entities (not Model Entities) from the moment it loads, and that each createbox will be given an action in the World Editor which acts as an interface to this tool.

It's also important that each createbox will have its origin located accurately where the corresponding sublevel has it (to within 0.001 quants suggested). This could be acheived by selecting a bounding box from the sublevel, copying it in the World Editor when that sublevel is almot done, and pasting this block into a new Map Entity by itself. There, the Properties dialog for the block can be given the same coordinates that were read from the view with the sublevel.

Thus, both createboxes and sublevels will be Map Entities with only the action/s in this script as possible.

For each sublevel, the game-author must create an interface to this script as demonstrated behind comment marks. Because loading a Map Entity through a scripted function does NOT load Model Entities and some other details located in the defining Map (which loading from the main level would automatically include), a list must be prepared of all Model Entities which must load only once when their sublevel first loads. And then another list must be prepared of Entities which must be loaded again every time the sublevel loads. These Entities must have actions which behave correctly when their sublevel goes out of scope again.

This means, that Entities which must only load once can include those that pose an obstacle which prevents the player from proceeding further. But more importantly, if these Entities die in combat, for example, then their state must also prevent them from falling endlessly when the player moves on. *To conserve memory* as much as possible, a game plot might be best in which the player can scavenge them for trophies before moving on, but in which the bodies will have vanished if he or she comes back to this earlier position.

Create-once Entities which follow the player into other sublevels are perfectly legal, but will represent the corresponding memory cost.

Entities which are recreated each time the sublevel is, represent lesser details, but must also remove themselves each time the sublevel is quit and vanishes again.

And an empty list can be represented as a named action which simply does nothing:

action canyon_details { RETURN; }

The absence of such an action will prouce an ugly error message.

Each sublevel must be given a stub of code in which its name as a .wmb file is defined, as well as an ACTION for each category of Model Entities just decsribed. Each of these actions (not functions) must call on ent_create() as often as needed to put the Models into the sublevel from the script.

And I have done none of this development for you. You should not need to credit me for that, only for the basic mechanism.

The present code allows fog to limit the player's view of distant sublevels which are not loaded, by setting the Detection range of each createbox automatically and using its dimensions as well as the 'camera.fog_end' parameter. A safety-factor of 400 quants allows for a CD-ROM to spin up for ~5 seconds, and for the player to be running with a force of 5.0 (quants per tick). But, special considerations or an artistic effect of scenery appearing for a moving player can be accomodated by the game-authors' setting the range themselves. As a non-zero 'Skill1' for any or none of the createbox Map Entities from the World Editor.

-Dirk
