Introduction

Prerequisites

Readers are required to read and use as a reference the Ground Zero Format GZF Standard version 1.0. The GZF standard describes the basic formatting rules to be followed within a GZF compliant file and describes the notation that this document uses to define the Full Thrust FT game profile rules. The GZF standard contains a description of the general concepts within a GZF file and their general application. A working knowledge of its contents is prerequisite to understanding the FT profile.

Scope

This document describes file encoding rules for the transfer of FT game data between players and applications. The encoding is known as a game profile. The game profile attempts to describe various models that can be used to hold game state and system design information in a common way.

From the GZF standard the concepts of block-types are used to describe the important elements in an FT game. This as always is a matter of data abstraction, which is reducing a game object, to those essential parts, which are required for playing and designing in the FT universe. The FT game profile also adds user defined fields to the GZF header block.

Association

This profile expands the concept of component association. This is the way that a contains relationship is modelled in the file format, for example an A-Battery is a component of a Ship as the Ship contains the A-Battery. This component relationship is modelled by the association of different block-types in the file or by a foreign key field.

Association by simple file order, is for absolute relationships, where there is no ambiguity in the association. As block-type B follows block-type A in the file, and these two block types have a defined absolute component relationship, then block A always contains block B.

Example

Ship: EUS Huron System: A-Battery System: Sensors Ship: EUS Reliant

In this example, the relationship is defined that a Ship block type has an absolute component association to a Weapon block type and a System block type. All blocks that are of the required types following the Ship block are always interpreted as components of the Ship. The association continues until a non associated record is encountered (in the example another Ship block) or the end of the file. The one exception where the absolute association does not apply is when the component blocks appear before the owning block types. This allows for the case when weapons and systems can be defined as a generality and not in association with a specific ship instance.

The second form of component relationship is an optional relationship and this is modelled by the component block having a field that identifies an associated block( a foreign key field). As the relationship is optional the field may or may not exist or point to an actual associated block.

Example

Ship: Bogey 1 Fleet: Unknown

In this example the Ship has optional relationship with the Fleet block. In this case we don't know which fleet the bogey is in so the field doesn't point to an actual Fleet block.

The ordering of blocks is only mandated in the GZF standard for the header block to be the first block in the file. The FT profile expands this concept with suggestions of what should be a logical block ordering within an FT profile. Although these are not hard and fast rules they are strong recommendations. The recommended block order is the same as the order of the block specifications that follow.

In each block specification the first field is always the block type identifier and must be the first field in the block. All field names and defined field-body values are case insensitive. All field names and defined field body values are spelling sensitive. Spelling of common words will accept America and British English spellings and any parser must cope with both. This is the list of known exceptions:

GZF User Defined Extensions

This profile adds two user-defined extensions to the GZF header block.