Representing the game universe is a vital part of any location-based game engine; one in which the management of the players location, and the location of in-game artifacts is paramount to the mechanics of the game itself. There are games where this is not important, and while they might benefit from using similar technology or techniques, platform games, shoot-em-ups and driving simulators (for example) might not be built around a location-based game engine.
One obvious example of a tile based world is SimCity. In SimCity, we can actually envisage the tiles at work, and see how the underlying game engine might have been implemented. Other games such as soccer simulators might be based loosely around tiles, and any adventure-oriented game will probably have some form of location or tile based engine at the core.
We can think of 2 immediate styles of tile representation:
Thinking back to the magical days of Dungeons & Dragons, hexagonal tiles were very much the de-facto standard. They allow multidirectional navigation through all compass points, allowing, for example, diagonal movement. Square tiles, like SimCity, or chess, do not offer quite the same visual appeal and flexibility of movement. One can still travel diagonally, it is just a less aesthetic and elegant movement.
From the point of view of graphical representation, interlocking hexagonal tiles have their own issues, but they do look very good in isometric 3D (at a 45 degree angle). Square tiles are easier to display, and are best for a top-down style game. However, more recent versions of SimCity have managed to look visually appealing in isometric 3D, mainly by masking the fact that the world is still based around tiles and rendering it in high-resolution 2.5D.
The simplest approach to managing a tile based world internally is to use an array:
We assume in the above that we have a game universe of fixed dimensions. Each square could be represented by a constant value which would indicate the contents of that square. However, if we require a world based on hexagonal tiles, then we require a complex linked list:
In the above struct, the oDirection member contains an array of 6 pointers - one for each point on the compass, except east and west. One of the key advantages of this approach, which we can adapt for simple grids by using an array of 4 pointers, is that we can construct a dynamic game universe by allocating memory as it is required. Coupled with streaming data from a hard drive or CD, this approach can be very effective.
In order to build up the universe, we need to use overlays. If we take the SimCity example again, we could create an overlay for the actual terrain, which would be the base grid. We can then layer the buildings on top of that (including road and rail). Next, the utilities (electricity and water) can be in a separate overlay. Finally, we can have an event overlay for transient occurrences like traffic, disasters, flooding, etc.
The key to deciding the overlay system is in knowing how many different artifacts can be in the same place at the same time. It is perfectly possible for a grid in SimCity to contain road or rail and an electricity line at the same time, but not a house and an industrial estate, for example.
So, to create a tile based world game engine, we need to decide:
Then, we need to allocate overlay space, and choose between a dynamic world (with media streaming), or a static world created or pre-loaded at run-time.