The central library is the GCS (G Core System). It defines the basic structure of world content. Every such piece of world content is called an "element", represented by the class GCS::GElement. This class uses other classes like GCS::GObject to store information about the element.

Basically an element consists of three things:

Energy gives an element a certain characteristic and is fully defined in the core system as GCS::GEnergy. Energy can take an important role for agent behaviour as some agents behave differently for different energies.

Form defines the element's geometry, the basic form attributes are defined in the GCS as GCS::GForm. The GCS::GElementData object optionally contains a setting for a 3D datafile, usually a 3D modell in the X3D file format.

The GCS::GObject class holds all data of an element. This includes the energy, the form, the ID of the element, the IDs of children and the parent ID as well as the ID of the element this element is connected to. There is also a generic data container which can hold any desired additional data of the element. This data is stored in an XML structure. All agents have access to this data and should use it to store ALL persistent data. This data gets also automatically transported by the GWE through the network and into the database.

Agents perform all of the behaviours of elements, which includes all laws that the element is affected by. No agents are defined in the GCS itself, it only provides the framework in GCS::GAgent to allow easy creation of new agents. Have a look at the basic elements library for some examples.

What the agent exactly does is completely up to the agent designer. Every agent is executed as a separate thread. Additionally the agent has read and write access to all data of its own element and read only access to other elements for which the IDs are known. When working with element data the agent designer has to keep in mind that there can be more active agents in the element which are also working with element data. For proper synchronisation most element data can be locked. It is highly recommended to use this locking mechanism when developing agents. To avoid deadlocks the order of locking is always:

Please keep in mind that all data that should be persistent must be stored stored in the GCS::GElementData object that is contained in the element's GCS::GObject. The GCS::GElementData class already provides methods to work with element data. These methods have the prefix xml.

Agents basically have two responsibilities:

The response mechanism is implemented by reimplementing a virtual receive method of the GCS::GAgent class. The parameter of this method is the influence itself.

GCS::GAgent inherits QThread which means that the agent itself is a thread. In its execution the agent can work with and process element data and can radiate influences or send influences to specific destinations (often the connected element). This is where most of the actual logic of the agent is usually defined.

An element can globally be started or parked, which means that all agent threads of that element get started or parked.

See the documentation of the GCS::GAgent class for more details.

An influence is represented by the GCS::GElementInfluence class. Agents can send out influences, either by radiation of influence or by influencing a definite destination element (this is where the ID of the "connected" element comes in). As soon as the agent has created such an influence, the agent can send it out and the GWE is then responsible for bringing the influence to the destination(s). When an influence is sent out, some other element will receive an influence. A virtual method of every agent of every receiver element is called and the influence is the parameter. Using this method the agent can define the reactions to the influence. The reaction can either be a simple modification of element attributes - or even just internal agent attributes - or more complex things that are handled in the agent's thread (instead of handling the reaction directly in this influence receiving method).

The GCS::GElementInfluence class is independent of an GCS::GElement instance, but is used by elements for interaction. By limiting interaction to one general way, it is possible to create general rule systems that apply to all kinds of interaction.

The only attribute that is transported with an influence itself is energy. In early versions of the G System it was common to subclass GCS::GElementInfluence to provide additional information to the receiving agent. But this brings a close dependency between sender and receiver of the influence. Starting with version 0.5 agents are able to access data of remote elements (for reading only) and thus it is not necessary to transport any additional information with the influence itself. If for example an receiving element needs to react to the sender's position then the agent would simply fetch the additional information through the GCS::GWorldData interface.

Influences always carry energy from the source element with them. This means that an element that sends out an influence puts a certain amount of its own energy into that influence, which can be thought of as the strength of the influence. If more than one element receive the influence, the GWE automatically distributes the energy among all receivers. Every receiving element absorbs the received energy amount.

The kind of energy that is received with an influence also determines whether the influence is at all recognised. Only if the energies are somewhat alike the influence is received at all. Further improvements on the GWE could result in the GWE making decisions about how much energy is received by what element.

The element data of IDs proposes a hierarchical world structure, and in fact this is what is used. Every element is in itself a complete unit to the outside and can have a very complex subhierarchy - solar systems are good examples. First, we have the whole solar system that can be seen as a complete unit ("one element") to the rest of the galaxy. This element has some child elements, which are included in itself (in terms of position). These children are the planets, asteroids, large space stations and space ships and so on. Every such element again holds a complex subhierarchy - continents - oceans. Continents hold landscapes and cities. They hold either houses, individual beings or whatever. Individual beings are again a very complex entity - which is probably a topic for our Philosophical Corner (philocorner).

Please note that an element does not have any direct reference (or pointer) to other elements, only their ID. Thus it is not necessary to have the other elements in the same system process - they can even be on a remote machine connected through the network. Large applications probably even should be distributed hierarchically among a network. Reflecting the element hierarchy of the virtual world in the hierarchy of the computer systems used is often a good idea. See the chapter about GWE for further details.