RE: Full Thrust Format for Email games

Tim Jones writes:

@:) I'm happy to even take the FTF discussion off-line if you like.
@:) 
@:) Anyone else interested mail **me** (not the list) and I'll keep
@:) you in the loop.  I'll post the results in draft for for general
@:) feed-back later.

  Sounds good to me.

@:) As you say we to are coming to the conclusion that there are two
@:) main uses, design and game state. The FTF design hopefully will
@:) encapsulate both in some way.

  I was thinking about this in the shower this morning, the source of
all good ideas for me, and I think something like the format below
should be considered.

  An FTF file consists of a series of zero or more blocks, with each
block contained in curly braces.  Each block consists either of one
attribute value pair or of an attribute followed by a curly-brace
delimited set of attribute value pairs.

  I forget just how BNF looks so here is somethings similar.

  FTF -> [ { <block> } ]*
  <block> -> <attribute>: <value>
  <block> -> <blockname> {
		[<block>]*
		}

  Attributes, blocknames and values are text strings which do not
contain newlines.  Spaces and tabs at the beginning of the line or
between tokens are ignored.

  So that's pretty basic and doesn't really get you anywhere.  But it
is extremely general and easily machine-readable.  What's required is
a reference implementation for the standard Full Thrust game.  For
that, we have to define the possible attributes and blocknames.  I
won't include everything, just enough to get the point across.

  Full Thrust legal file format values

  <attribute> -> name | class | mass | thrust | streamlining
  <attribute> -> B-battery | Nova Cannon | ...
  <blockname> -> fighter group | hangar | main drive | ...

  Example ship design:

{
  class: silly
  mass: 28
  thrust: 2
  B-battery: PF
  B-battery: FS
  Wave Gun:
}

  Possible variant of same:

{
  class: silly
  mass: 28
  thrust: 2
  B-battery: 1 PF
  B-battery: 1 FS
  Wave Gun: 1
}

  Game aid variant of same:
USS Silly {
  class: silly
  mass: 28
  thrust: 2
  B-battery {
    arcs: PF
    status: undamaged
  }
  B-battery {
    arcs: FS
    status: destroyed
  }
  Wave Gun {
    status: repaired
    charge: 2
  }
}

  So that's my thought.  I think it's worth having a really simple
format that is very flexible, then defining a specific version of that
format for the basic game and allowing others to define their own
variants for their own games.  A parser would be expected to ignore
anything it didn't understand.

  Let me know what you think.

-joachim