MORPH Syntax

ObjectClasses are listed here to allow the early-bound instance document to modify them. Object attributes and object inheritance are not defined within the <ObjectClasses> element. See the Attributes/Parameters section.

In the early-bound model, this element's name would be the name of the class itself. For example, in a chess game, a class might be named "Piece" and thus the element under <ObjectClasses> would be <Piece> as well.

This allows the product to give this class a display name, which would be used in end-user software such as simulations (games) and editors. This attribute is optional and may be left out at a DSL's discretion. Display names allow an easy way to use names with spaces and other characters disallowed from the actual class name.

This attribute, if provided, is used within MORPH as well as designed to be used in editors. In MORPH, this name is used rather than appending "Set" to the class name, if provided. Also, it could be used in end-user software. For example, a map editor for an RTS game may list characters under a category known as "Units." By providing the plural name here, the editor is able to display the category correctly just based off the MORPH model, without any domain-specific knowledge. Note: PluralName is of type string to allow for it to match the class's DisplayName; however when used in MORPH, spaces and other disallowed characters will be removed from the name.

AttributeOverride is used to allow the early-bound instance document to modify DSL-defined aspects of attributes. The example given is "DisplayName" which would allow the product to alter the visual name of the attribute. It is up to the DSL what may be altered here, and this element may be left off entirely by some models.

Identifies the attribute to be modified. This value must reference one of the attributes defined in the Attributes section.

This optional attribute would allow the product to modify the visual name of the attribute (that is shown to the end user during the simulation) without altering the semantics of the attribute itself. For example, an RTS game may call an attribute "Health." However, a particular product wishes to use the term "Hit Points" during the actual game. This is an easy way to alter all visual displays of the name of the attribute (such as when displaying the unit's statistics to the gamer) to "Hit Points." Note also that display names may have spaces, whereas attribute names may not.

The UserAttribute element allows an early-bound instance document to add attributes to classes, in addition to attributes that the DSL itself declares. Internally, these are represented by an array of variants, so they are not true attributes and do not need RTI engine information. They are also thus limited to being only datatypes which can be represented by a variant.

The name of the user attribute. Must conform to HLA name restrictions.

The name of an HLA or DSL declared datatype. The specified datatype must be one which may be represented as a variant. In particular, record and array types are not valid. In some cases, this restriction can be circumvented by using a string type, and encoding the desired data into a string.

This optional attribute would allow the product to modify the visual name of the attribute without altering the semantics of the attribute itself. Not all DSLs allow display names.