To bridge the gap between the offline world editor and our runtime game
object model, we need a way to load world chunks into memory and unload them when they are no longer needed. The game world loading system has two main responsibilities: to manage the file I/O necessary to load
game world chunks and other needed assets from disk into memory and to
manage the allocation and deallocation of memory for these resources. The
engine also needs to manage the spawning and destruction of game objects as
they come and go in the game, both in terms of allocating and deallocating
memory for the objects and ensuring that the proper classes are instantiated
for each game object. In the following sections, we’ll investigate how game
900 15. Runtime Gameplay Foundation Systems
worlds are loaded and also have a look at how object spawning systems typically work.
15.4.1 Simple Level Loading
The most straightforward game world loading approach, and the one used by
all of the earliest games, is to allow one and only one game world chunk (a.k.a.
level) to be loaded at a time. When the game is first started, and between pairs
of levels, the player sees a static or simply animated two-dimensional loading
screen while he or she waits for the level to load.
Memory management in this kind of design is quite straightforward. As
we mentioned in Section 6.2.2.7, a stack-based allocator is very well-suited to
a one-level-at-a-time world loading design. When the game first runs, any
resource data that is required across all game levels is loaded at the bottom of
the stack. We’ll call these load and stay resident assets (LSR) for the purposes
of this discussion. The location of the stack pointer is recorded after the LSR
assets have been fully loaded. Each game world chunk, along with its associated mesh, texture, audio, animation and other resource data, is loaded on
top of the LSR assets on the stack. When the level has been completed by the
player, all of its memory can be freed by simply resetting the stack pointer to
the top of the LSR asset block. At this point, a new level can be loaded in its
place. This is illustrated in Figure 15.11.
While this design is very simple, it has a number of drawbacks. For one
thing, the player only sees the game world in discrete chunks—there is no
way to implement a vast, contiguous, seamless world using this technique.
Another problem is that during the time the level’s resource data is being
loaded, there is no game world in memory. So, the player is forced to watch a
two-dimensional loading screen of some sort.
0 Comments
Please Comment for any further query :