HeadQuarter

HeadQuarter is a framework for distributed simulations. A distributed simulation deals with 'things' from the real world that are modelled within a networked computer enviroment. These things may have very different attributes like 'position', 'name' or 'health' that represent its state. Simulating things means to maintain and manipulate their state over time. In a distributed environment the resp. states have to be communicated to all participants that may be concerned. Thereby some of the attributes change very often, some rarely. E.g. in a traffic simulation, positions change frequently whereas the brand of a certain car is very unlikely to change at all. Additionally, a simulation system may consist of different applications. Not all of them necessarily need to be interested in the same set of attributes. A 'radar screen' application e.g. might be very well interested in the positions of things, but not in their types at all. This means that real world objects state cannot be modelled as a single structure of data, but divides into different aspects. Also, different kinds of information need different kinds of treatment. Some change that often that they cannot be communicated over a network continously. Position again may be a candidate. Here, a dead-reckoning scheme might be applicable. This allows to approximate position states on all sites participating and only transfering data if some error limits get violated. For positions, this is a good mechanism - but absolutely useless for e.g. a damage value.

Most common simulation systems consist of distributed sets of object located on communicating hosts. Thereby each object holds its complete state concerning all aspects of its being. It may have a position, a simulation state, an owner, a certain look, a set of weapons and so on.

The simulated object is wrapped up completely and could live comfortably even in a non-distributed environment on a single host. When distribution comes into play, a set protocols is implemented in order to let objects communicate their states. To achieve that, very different architectures are typically used. Most of them serve the goal to reduce communication overhead to save bandwidth and/or latency.

The picture should not induce that each host talks to each other directly through a network connection, but only show the principal communication path between distributed objects. The arrows transport different things at different times or in different situations. Sometimes it might be a position update, sometimes a weapon-fired event. It is naive to say an object communicates its state - it only communicates some substate. Distribution pathes and requirements may vary for each kind of the substate.

In order to keep these simulations scalable, the system is subdivided. This typically is done by grouping object together somehow. Type or topology are well-known criteria for subdivision.

Additionally, there always will be some entities that keep an birds-eye view of things: a AI system e.g. needs to know about all the object places and some aspects of theire types and state in order to make its decisions. Of course, these systems do not like the subdivision as mentioned above or they are subdivided by the same criterium. Each frontend will have to display more than one object and therefore also needs to gather specific information about certain aspects of each object.

The basic idea here now is to do a priori subdivision - not in the space of objects but in the space objects states. A single object is divided into a set of 'facettes' that all together make the objects state. Now the facettes, not the objects, are clustered together into subsystems. This means not to distribute the entities, but each single object!

A subsystem always has a designated task and a certain type of information to maintain. This e.g. allows a geometry subsystem to implement spatial indexing very effectivly.

The newly introduced term 'facette' describes a certain aspect of an objects being. Facettes have to be designed to be as independent of each other as possible in order to avoid communication needs among subsystems.

The benefits of this approach are:

• Protocols have to be designed only between subsystems and can be highly problem specific.
• Clients typically can come along with certain facettes of an object and can therefor easily interact with clearly defined hosts. This keeps network topology simple. E.g. a radar-screen viewer can register only with the geometry subsystem and ask only for the presence of objects in a certain, geometric area. A geometry subsystem is a perfect place to filter the request and a single peer-to-peer connection is enough to observe a whole bunch of objects.
• New facettes can be added to the system without change of existing programs. This can be done by just adding new subsystems.
• Objects and object behaviour can be composed or changed at any time. E.g. a tank needs a geometry facette to be moved, a weather-object does not. For all clients that don't care for a position (maybe a reporting system), these object can be treated the same. Object do no longer have one type, they have as many as they have facettes!
• Client implementation can work with slim interfaces they need from the appropriate subsystems. This should keep dependencies within the implementation and the source low and allow to easier divide the development tasks.