Prev: Re: Storage & Transportation Next: Re: Storage & Transportation

Re: FTF Standard File Formats for PBEM/Utilities

From: Alun Thomas <alun.thomas@c...>
Date: Thu, 29 May 1997 10:30:36 -0400
Subject: Re: FTF Standard File Formats for PBEM/Utilities

Tim.Jones @ Smallworld.co.uk wrote:

> I know the thread to design a standard format spluttered out some time
ago 
with no
> conclusion, but I'm into equine flagellation. 

Good to see you back Tim.

> I'm thinking about building a file parser/writer for use by ftmap to
read a 
standard
> game description and produce the map from it. The current version uses
a 
fairly
> proprietary and difficult format, it would be great if it could just
be run 
off PBEM game
> reports directly. 

Yeah, I tend to use awk scripts to read PBEM reports and convert them
into 
ftmap input.
The main reason for this is that the format isn't defined rigidly enough
to 
code into
ftmap - I'd have to change it weekly to keep up ;-)

[...]

> My initial thoughts are the format should be object based, what this
means is 
that the
> various records and fields within the report are represented by a set
of self
> contained data and the functions to act on them. For example instead
of 
having a
> record for an FT ship we might abstract this to be a Game Object. A
Ship is a 
type of
> Game Object but so is a Base or an Asteroid or a Fighter Squadron. The

abstract
> class of Game Objects, all have certain data in common such as a
> Position/Heading/Facing/Velocity. A Ship is a type of Game Object
which will 
inherit
> the values for the generic Game Object record but add its own fields
for 
things that
> are to do with ships such as Thrust Rating. This model can then be
applied
> throughout the entire FT game structure. What is required is a full
set of 
the objects
> within the game and the data associated with each that is important
for the 
use of that
> object in a human report or a utility data file.

Hmm, I'd drop the mention of "functions to act on them" - it makes it
sound as 
if code
to manipulate the objects would be included in the datafile with them.

Would you pre-define the object classes (Ship, Base, etc), or allow a
file to 
define
new classes ( eg. Base is an Object without Speed ) ?

Would you allow a file to refer to another file for some definitions? 
(eg to allow a set of ship class definitions to be used without having
to 
include them
in the datafile for every turn of a PBEM game)

> The other point is how the data is tagged. A tag in this context is a
text 
value that
> delimits certain words as special, e.g. in html the tag <H1> warns
that the 
next item is
> a Heading. I'm not proposing to use html tags as anyone who has used
them 
knows
> they aren't human readable, I suggest something along the lines of

> Ship:
> Fighter:

Seems reasonable, how would you expect (for example) a complete ship to
look ?

Something like :

Ship: Binky
ShipClass: Battlecruiser
Location: (12, 20.4)
Speed: 15
Heading: 6
Manouver: P1+1
Damage: {0/0/5}
EndShip:Binky

FighterSquadron: T-1
FighterType: torpedo
FighterStrength: 6
FighterEndurance: 1
Heading:5
Speed: 12
Facing:6
Location: (12,90)
EndFighterSquardon: T-1

> Lastly the way that data types are delimited and represented, examples
of data
> types are list, position, numeric value and  string. The damage rows
of a 
ship could
> be represented by a list (vector) of numeric values in several
alternative 
ways e.g.

> Damage: {5,5,5}
> Damage: 5/5/5
> Damage: 5,5,5

The first of these might be easier to check, but there's not much in it.

It might be worth noting that something like damage could be a list of
numbers,
OR a descriptive value (eg LIGHT or CRITICAL from Dean's current game)
Also that these two types of damage information could be mixed in the
same
report (ie I know the exact damage for the ships under my control, but
only
approximate values for other people's ships).

[Sorry I'm getting a bit behind on this thread :-) I'll try to catch up
]

Alun.

Prev: Re: Storage & Transportation Next: Re: Storage & Transportation