Introduction

We have ambitious goals for MilOps. One of them is its “scale”. Instead of a couple of square kilometres, tens of thousands of square kilometres. This brings new challenges to game development. Many facets are affected; game-play, rendering, communication with the player, behaviour of the units, hardware demands, etc… It is the impact on the technical side that this article will focus on, and in particular the software technology.

A note on (software) design.

A good design in our view is one that fits many of your requirements naturally, rather than picking a requirement one by one and forcing their solution on the others.
In short, one solution that solves many problems opposed to many smaller solutions that need to be merged.

The challenges for MilOps

What are our requirements?

• No artificial limits, the whole planet is our playground. World War 2 didn’t get its name by mistake.

• From orbit to street level detail. Depending on the position of your command in the hierarchy, you need to make plans spanning several countries or just the best way to cross a river and everything in between.

• A continuous experience, no level loading. If all positions in the hierarchy should ultimately be available for you to command, there should be no delay or jump when switching viewpoints. Time is continuous, movement is, and zooming is too.

• Many RTS games are actually much more about tactics than strategy. We want to make the player feel (s)he is a general, commanding thousands of units. So we need to simulate thousands of units.

• There is no reason why a serious war-game with depth could not also feature high quality visuals. We want that too.

• Many game-play issues arise from shortcuts in scope and scale. It’s no problem moving your troops from Berlin to Paris if those cities are next to each other. Try the same in a realistic setting and things get complicated. We want to make sure those complications are in the game for the player to confront.

• The same goes for modelling of game systems. If fuel consumption is not modelled, the player can try crazy things that would never be possible in real life. We want to make sure the important aspects are properly simulated.

• And all this running smoothly on your gaming system.

Most engines focus on visual detail. For many years there has been a race for detail. Engines understandably followed (and promote) this demand.
We needed an engine that allowed us freedom of scope. We set out to develop “Metis”, the technology that meets our requirements.

Back to the beginning

In a game, the software is simulating an artificial environment, generating input for our sensors (eyes, ears, etc). The player’s input (mouse, keyboard, etc.) changes the artificial environment. The user moves around in the environment in a continuous manner. Walking, driving a car or maybe riding a horse. Meanwhile, the user is only able to sense part of the entire environment. His vision is limited as is the range of his hearing. So the software needs to only provide simulated input for the user’s sensors for a limited and predictable part of the environment.

Meeting the requirements

Let’s see how it is possible to meet our requirements given the described assumptions about the behaviour of the user.

The AOI concept

We need a way to manage the huge scope without waiting for levels to be loaded. We need true streaming, preparing only that part of the environment that is of interest to the player. Introducing; the “Area Of Interest” (AOI) concept. It is an area surrounding the user’s location that is of interest to that user. When we assume the AOI will only gradually change (no teleporting), we only need to deal with relatively small changes. This is a valid assumption for continuous movement like we are used to in the real world where every change and movement takes time.

Space partitioning (tiles)

To manage the changes of the AOI we need a unit to describe parts of the environment leaving the AOI and parts entering the AOI. We need to partition the global scope into predictable chunks. For this a grid of tiles is used. This grid covers the entire planet. For every location on the planet it is possible to calculate the tile containing that location with a simple formula.

Level of detail (quad-tree)

An AOI and tile-grid alone is not enough. We want to zoom-in to street level but also zoom-out and watch from orbit. There is no one tile size for the grid that will fit both extremes and makes the scope manageable. We need a way to describe a “Level Of Detail” (LOD).

Instead of using one uniform grid for the entire planet, we will partition the planet surface area using a quad-tree. Starting with one tile describing the entire globe (lowest LOD 1). Then dividing this tile into 4 equal tiles (LOD 2). Every LOD2 tile can also be subdivided into 4 tiles, etc. This can be repeated until the required detail level is reached.

Controlling streaming

The next step is to prepare all the information needed to simulate and render the game world and distribute it over the tiles. The global tile will contain information about the entire world, but very very coarse. The next level contains tiles that span a quarter of the world, smaller and more detailed. Subdivision is continued until, for example, level 20 where a tile covers only 25×25 meters but in much more detail.

For our streaming solution to work it is very important to make sure that the amount of effort to process a tile is the same for every tile, regardless of its location and LOD. This is the sacred rule for all processing!
It guarantees the streaming is smooth which makes the game-play and rendering smooth.

Conclusion

Why not use one of the existing game engines? High quality engines have become available with attractive licenses.

All engines make assumptions about their use, the kind of games a developer wants to create and how. And that’s fine. Actually, that is the added value of an engine. Functionality shared between different developments so your project can benefit. However, if your requirements differ too much from the assumptions made by the engine, your development will not be helped but be handicapped. We concluded this was the case for MilOps.

Comments and reactions to this blog entry can be made on our forum.