Documentation - Units
Version: a0.04

Contents

Requests:

Contents

General description

In the model proposed here, everything that can exist on the map during the game (terrain, resources, objects and units) are all considered the same type of objects. Objects are made up of modules which interact through connectors. One connector can interact at most with one connector. Between theconnectors are established different kind of joins, depending on the types they provide. For each type provided by a connector, the behavior should be described depending on its attributes and also on the attributes of the connector on the other part of the join.

For example, let us consider an object made up of a man with a sword in his hand and sitting in a boat. The modules that make up this object are: man, sword, boat and the terrain under the boat. The man has two connectors: one for the sword, let's call it hand and the other for the boat, legs. The sword has one connector: handle. The hand connector can provide several types of joins: joins for handling swords, shields, for carrying other modules, start working on other modules etc. We suppose that the handle connector provides two kinds of joins: one for carrying the sword and the other for using the sword. The man and the sword interact one with each other through hand and handle. The description for the behavior of the sword will take under consideration the attributes for using the sword as well as the attributes for using the sword from the hand connector. Therefore, if the connector handle will not provide any kind of using weapons, the sword won't attack anymore.

Contents

Detailed description

Structure

Each xml must start with:

<?xml version="1.0" standalone="yes"?>
Followed by:
<!DOCTYPE sow SYSTEM "sow.dtd" [
 <!ENTITY % types SYSTEM "[types].dtd">
 %types; ]>
where [...].dtd is the structure of the used types (see description of the element modules).

The structure of xml can be deduced from sow.dtd. The root element of the structure must be called sow. This contains two elements: modules and objects

Inside the modules are described all the modules that objects will be made of. The description of the modules contains connectors which provide the kind of joining they support.

Inside the objects are defined the objects that the game will start with. Also, a predefined object will be automatically modified during the game. For example, while moving, the module that is under the module of transport will change, or during the extracting of resources, the module of extracting will connect the module that provides resources, thereby resulting one object. After the extraction is complete, the modules will disconnect, obtaining the initial objects.

Structure of the element modules

The element modules contains an unlimited number of module and dmodule elements. The element module is used to define new modules, and the dmodule element is used to define new modules from modules already defined, by adding new connectors, types of joins at the connectors already existent or to modify the properties of the joining types. The module element has the following structure:

&ltmodule name="UNIQUE_NAME">
 &ltconnector name="CONNECTOR_NAME">
  &ltJOIN_TYPE ATTRIBUTE/>
  &ltlink with="MODULE_NAME"
          ancestors="..."
          descendants="..."
          interface="..."> ( 0 or more )
  [... other types of joins ...]
 </connector>
 [... other conectors ...]
</module>
JOIN_TYPE is one of the elements defined in [types].dtd file included at the beginning of the document. To define each type of join, the following structure will be used:
<!ELEMENT type_name>
<!ATTLIST type_name
  property1 property_type default/#REQUIRED/#IMPLIED/#FIXED value
  property2 property_type default/#REQUIRED/#IMPLIED/#FIXED value
  [...]
  propertyn property_type default/#REQUIRED/#IMPLIED/#FIXED value>
where More information about the dtd structure: http://www.w3c.org

At the end of the file the entity deftypes must be defined, which is a list of all types of defined joins, which will be used to describe the connectors. If one of the types defined above is not included in this list and the type is used to define a connector, the document will be invalid.

The definition of deftypes entity is acomplished like this:

<!ENTITY % deftypes "( type_name1 | type_name2 | [...] | type_namen )">

After the description of a joining type, you can specify to which's components and interfaces the properties are applied, using link elements. A link element has the following attributes:

The dmodule element has the following structure:

&ltdmodule name="UNIQUE_NAME" base="MODULE_NAME">
 &ltconnector name="CONNECTOR_NAME">
  &ltJOIN_TYPE ATRIBUTE/>
  &ltlink with="MODULE_NAME"
          ancestors="..."
          descendants="..."
          conector="..."> ( 0 )
  [... other types of joinings ...]
 </connector>
 [... other connectors ...]
</module>
where UNIQUE_NAME is the name of the new module, and MODULE_NAME is the name of the base module. This new module will have all the connectors and the description of the base module, and also new ones or the updates.

Structure of the objects element

The objects are made with more object elements. Each object element is made up of two elements: parts and connections. The parts elements are more part elements which have two attributes: name of the module and 'alias', the name inside the object (aliases are useful when there are more than one module of the same kind; for example, a body has two hands). An element connection has four attributes: module1, connector1, module2 and connector2 which describe the modules connectors.

Examples

tank.xml
tank.dtd

tank.gif

Another example more complex :
complex.xml
complex.dtd

Contents

Dictionary

terms

Contents

Comments

To Do

Contents

SourceForge.net Logo