Hi all
I know the thread to design a standard format spluttered out some time ago
with no conclusion, but I'm into equine flagellation.
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.
In addition other people have done work along this track with the Java Battle
Computer using the Mark Kochte PBEM reports. What I hope to design is
something that can be easily parsed by a computer but also is a nice format
for PBEM games for humans to read.
In my real job I at times write translators for vector graphic files such as
DXF. The great thing about standards like DXF is that everyone agrees on it
and so the exchange of data between diverse applications is possible. Now DXF
isn't a human friendly form but it's the spirit of this I'm looking for.
Another analogy is the RTF format used by word processors. I intend to call
this new format FTF (Full Thrust Format).
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.
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:
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
If you are interested in this I invite you ideas and opinions via private
email or on the list if you deem this is an appropriate thread.
Sincerely
I have used the following format on my Full Thrust Ship Registry pages with an
eye toward the same goal. There are 177 designs posted in this format. Roger
West also has a "Full Thrust Portable Format" which he designed with the same
purpose.
Chicago class Battlecruiser Brian Bell Mass: 40 Type: Capital Clas:
Battlecruiser Move: 4 FTL: Std Tech: Human Hull: Military Strm: None Prot: 2
Screens Cost: 381 Damg: 20
5
5
5
5
Syst: FCS FCS FCS Screen Screen AA Mega Battery F A Beam PFS A Beam PFS ADAF
This is a class I used in trying to make a full thrust ship designing
program. It was written in C++. Equipment is a class that contained the
name and properties of the various equipment. I had planned to add this
to a sub-class that would add velocity, heading, etc.
class ship { Str255 name; int tons; int tonsUsed; int speed; int screens; int
fireCons;
int shipClass; //
1=escort,2=cruiser,3=capital,4=carrier
equipment slot[51]; // slot[0]=#of filled slots
public: int changeTons(CommandT); int changeName(CommandT); int
changeSpeed(CommandT); int addEquip(CommandT); int delEquip(CommandT); int
addScreen(); int subScreen(); int newShip(CommandT);
};
Tim Jones;
I have no idea what you sent me, but my PC says it's un-readable
binary data. What's up?
Randy
I have been working on a program to help manage FTMAP inputs for a while
now... Though far from finished it has definately got as far as being useful.
The program is written in VB5 (cos it's easy and my brain fails it's
threshold check before C/C++) and so if unfortunately quite big thanks
to those massive runtime modules. I haven't zipped it yet, but unzipped it is
about 4MB.
The program uses a standard FTMAP input file, and places the data in one
of three windows (oh that's another thing - it's Win95). The first
allows you to set map options such as title etc and is the data in the first
part of the FTMAP header file. The second window allows you to manage ship
classes, and to add new ones. Finally the window you use most - the
orders window will allow you to give orders to your ships (including a limited
use of real thrust movement if you so desire). Having done all this you can
generate a new input file for FTMAP. If anyone wants a 3MB file emailed to
them:) just ask.... I will put a web site up soon (by soon I mean this
year...).
-Entropy
,----- Michael Hodgson < mkh100@unix.york.ac.uk >
,-----
| __/ <hodgson@yorvic.york.ac.uk> |
__/
l_F-< A_A_A,-mmmmm--=_ =---<==r==-
l_F-<
L \ _ _H_H_H_,-------|..|-,_,--| L
\
r-i ) I I=L|==L<_ >L|: : : :|..|>|_<>:II r-i )
I
\ " / H H H `-------|_ |-' `--' \ "
/
`---' U U U
`---'
> Brian Bell writes:
@:) I have used the following format on my Full Thrust Ship Registry @:) pages
= with an eye toward the same goal. There are 177 designs @:) posted in this =
format. Roger West also has a "Full Thrust @:) Portable Format" which he =
designed with the same purpose.
@:)
@:) Chicago class Battlecruiser @:) Brian Bell @:) Mass: 40 @:) Type: Capital
@:) Clas: Battlecruiser
@:) Move: 4
@:) FTL: Std @:) Tech: Human @:) Hull: Military @:) Strm: None @:) Prot: 2
Screens @:) Cost: 381 @:) Damg: 20
@:) 5
@:) 5
@:) 5
@:) 5
@:) Syst:
@:) FCS
@:) FCS
@:) FCS
@:) Screen @:) Screen @:) AA Mega Battery F @:) A Beam PFS @:) A Beam PFS
@:) ADAF
I think this is a step in the right direction. My only complaints would be
that it doesn't follow FT terminology (Move instead of Thrust, eg) and that
there's no real need for the abbreviated nature of the format (Spelling out
"Class" instead of "Clas" doesn't save that much space). Oh and the first line
contains a redundant mention of the class type. Anyway, overall I think it's
pretty good. My only
question would be how adaptable it is to rules modifications -
remember how important optional rules are to FT. For example, maybe the FTL
drive should be mentioned under systems. Maybe the damage row should mention
how many rows are present (so computers can more easily read the format).
In article <199705222308_MC2-1724-34B6@compuserve.com>, Brian Bell
<PDGA6560@compuserve.com> writes
> I have used the following format on my Full Thrust Ship Registry pages
I like the idea of a standard format for ship descriptions. I'm just about to
start work on a ship design program in Java, but as an application and not an
applet.
It might be a good idea to give each system a ship carries a unique
identifier, such as a number, to clarify what system a DCP might be working
on. Also, I think that each system should show what fire arcs are valid, as
well as the state of the system, ie destroyed, damaged, empty(scatterpacks
etc.)
> Thomas Heaney writes:
@:) It might be a good idea to give each system a ship carries a @:) unique
identifier, such as a number, to clarify what system a DCP @:) might be
working on. Also, I think that each system should show @:) what fire arcs are
valid, as well as the state of the system, ie
@:) destroyed, damaged, empty(scatterpacks etc.) --
These are actually very useful attributes for a file format to be used by game
play aids. For ship construction programs much of this stuff is obviously not
important.
The firing arcs are typically included in any of the "standard" FT text
formats. 2xB(PF), for example is one way of representing two B batteries that
fire port and front.
Destroyed/damaged is good and here is one place where you start to
run into compatibility problems. Maybe somebody's got an optional rule that
allows batteries to be damaged and fire as the next lower
class - should that be handled in this file format somehow? Maybe not
specifically, but perhaps there's a way of keeping the format general enough
that this information could be contained in it somehow.
Actually if there was just a generic "system" spot in the format, it could be
used to house any kind of weapon. If you want to use batteries that degrade
over time, give them a new name and any program that doesn't know about them
will just ignore them. That'd be neat.
Here's a top-of-my-head example of a possible system description.
I'm sure I've left stuff out.
weapon Name: B Battery Arcs: PFS DP: 1 Repairable: yes
/weapon
weapon Name: Degradable B Arcs: PFS DP: 1 Repairable: yes Degradable: yes
Degrades To: C Battery
/weapon
The idea here is that your program could be reading through my ship
description and find that I'm supposed to be carrying a "Degradable B",
whatever that is. Your program could just ignore the weapon, or complain if
appropriate. My program would continue reading in the weapon statistics, and
would specifically note the "Degrades To" line which it would be expecting to
see.
> Tim.Jones @ Smallworld.co.uk wrote:
> I know the thread to design a standard format spluttered out some time
Good to see you back Tim.
> I'm thinking about building a file parser/writer for use by ftmap to
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
abstract
> class of Game Objects, all have certain data in common such as a
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
> Ship:
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
> 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
]