The central library is the G Core System (GCS). 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, Form, Any number of agents. Energy gives an element a certain characteristic and it 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 core system as GCS::GForm. Additional form information is usually in the GCS::GElementData. It is the responsibility of the application or the agents to create this information there. 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 class, GCS::GElementData which can hold any desired additional data of the element. 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. The GCS::GObject class also stores the ID of the connected element. Every element normally has an element it is particularly connected with. This is always the element of interest and towards the actions of this element are directed. The concept of connected elements is quite fundamental to the G System. Everything in the world is somehow connected with each other. This idea is represented by the connection ID of the element. Agents perform all of the behaviours of elements, which includes all laws that the element is affected by. No agents are defined in the core system itself, the core system 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. Please keep in mind that all data that should be persistent must be stored in the element data object, GCS::GElementData, that is contained in the element's GCS::GObject. Agents basically have two responsibilities: creating influences responding to influences 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 normally 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. From 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 of 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 some of the received energy amount. The energy that is not absorbed is returned to the sender. 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. Agent behaviour depends on the energy of the element. If the energy changes then the behaviour of the agent can change as well. This depends on the design and implementation of the agent. Sending or radiating influences can thus be a means to change the behaviour of other elements. If the rules the other element adhers to are known, then it is possible to control the behaviour of other elements. This is just the way reality works! Everything acts according to its energy, and things can only be modified by influence. Please note that this is a quite radical view of reality and there are many different ways to look at it!! The G System just tries to build a model-able simulation framework of reality and has also more to offer than just this very point of view. In particular you should have a look at the Philocorner. A lot of thoughts are collected there about philosophical aspects of life and evolution. 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.