A Question of the proposed FTF (Full Thrust Format)
There seem to be two goals one is to encapsulate system/ship design
information. The other is to hold game state. Are these two concepts logically
compatible in the same file format or should they be separated.
i.e.
In a game report do I want to wade through lots of system specifications
should they even be in the same file?
In a ship design I don't need to know about game information.
If all records are optional then you have to know the purpose of the report
file (i.e. is it a game report or a design), if records aren't optional then
reports will be filled with unapplicable mandatory junk.
Sincerely
> Tim Jones writes:
@:) A Question of the proposed FTF (Full Thrust Format)
@:)
@:) There seem to be two goals one is to encapsulate system/ship
@:) design information. The other is to hold game state. Are these two @:)
concepts logically compatible in the same file format or should @:) they be
separated[?]
I think they should be separated. It might be worthwhile coming up with
standard formats for both but they're not the same thing and I don't think all
the extra information should be required when it's not needed. Also I think
the game state information does not require a standard format as much as the
ship design information. It would be nice to be able to build a ship in one
person's program, save it to a file, and then bring it up in another person's
program. What seems less useful is to fly a ship around inside an FT simulator
and get it damaged and then move it into another FT simulator, complete with
damage (and position?) information and continue to use it. What's the point?
On Wednesday, May 28, 1997 1:42 PM, Joachim Heck - SunSoft
> [SMTP:jheck@East.Sun.COM] wrote:
The intent is to allow a PBEM GM for example to send out a turn report and
this to be read by a map making or a Java battle computer playaid as well as
the players in the game who just have a rules and pencil.
The issue is about the transfer of the relevant state information between
different applications.
Any PBEM GM's got anything to say on this subject?
> The intent is to allow a PBEM GM for example to send out a turn report
If keywords are being used to define ship heading, facing, speed and and
turns, then the rest of the file need not matter, as the map program is
concerned with movement. Providing the program can extract these elements (by
searching for headers), surely the rest of the file format is not inportant to
the mapping program....
Other systems and damage etc. only become important if the computer begins
rolling die etc, for you aswell. Is this the intent?
It seems to me that the first step towards defining a standard FTF file format
is to decide what it will actually be used for.
-Entropy
> Tim Jones writes:
@:)
@:)
> @:) On Wednesday, May 28, 1997 1:42 PM, Joachim Heck wrote:
@:) >
@:) > What's the point?
@:) >
@:)
@:) The intent is to allow a PBEM GM for example to send out a turn @:) report
and this to be read by a map making or a Java battle @:) computer playaid as
well as the players in the game who just have @:) a rules and pencil.
You know, you'd think a guy who wrote one of these very programs would be
capable of remembering why he did it! Yes of course this is sensible reason
for this kind of format. I still think it should be seperate from the basic
ship design information.
> M. Hodgson writes:
@:) If keywords are being used to define ship heading, facing, @:) speed and
and turns, then the rest of the file need not matter, as @:) the map program
is [only] concerned with movement.
Actually some map programs (Daryl Lonnon's and mine for example) do use the
damage information, if nothing else. This allows you to click on a ship and
find out how hurt it is. Handy.
@:) It seems to me that the first step towards defining a standard @:) FTF
file format is to decide what it will actually be used for.
I agree. I think we're getting some good ideas out - with a little
luck we'll actually see something useful come out of it.