I'm in the process of putting together a VB prog for this. I found that I
needed 3 seperate groups of info:
1) Basic ship design info - mass, thrust, etc
2) Ship systems/damage - weapons, FC, FTL, Engines(2), screens, etc,
etc, etc
3) Weapon stats (even if you restrict to basic weapons only) - range
bands, reuseability, to hit chance, damage, effect of screens, etc
Whats really needed is a linked list of linked lists :-) unfortunately
VB can't handle this, so I'm having to use objects (nice concept, pain
to code :-(. Of course, with my current work load, when I get home I
don't feel like cutting more code so things are on hold for a week or two.
I looked at getting Visual C++ but it costs $850 ($1800 for the full
version)
> I looked at getting Visual C++ but it costs $850 ($1800 for the full
Whoa, whoa, which version of VC++ is this? My version is Microsoft
Visual
C++ 4.0 Professional edition, which cost $130. (Cdn)
> On Thu, 29 May 1997, Rutherford, Michael wrote:
> Whats really needed is a linked list of linked lists :-) unfortunately
Oh yes it can. As usual, the question is not really what can be done, but what
can be done easily. Linked lists work if you just implement them first.
I did some experimental coding a while back. I'll throw you the source if I
can still find it.
> I looked at getting Visual C++ but it costs $850 ($1800 for the full
WHAT? - since when did you start paying for stuff you can snitch from
work :-}
> and IMHO the Microsoft Developer Studio and Visual C++ 5.0 are not
I have to agree with you. I am a VB5 user and bought Visual C++ as I
thought it was about time I learnt a "propper" language. Quite frankly I
wish I hadn't bothered. Visual C++ is not infact a visual language at
all. If you don't need one then I'm sure it's fine, but personally I'm hooked
on them.
VB is nice and easy and is capable of a wide range of things. It's a little
slow and clunky and produces nasty large files, but if you can live with that,
then I'd recomend it.
Delphi looks marvelous from what I have learnt so far. I'm still only on day 3
of my 21 day learning curve however.
> From what reviews I've read Borlands new Visual C compiler (I forget
-Entropy
> Rutherford, Michael wrote:
> I looked at getting Visual C++ but it costs $850 ($1800 for the full
> At 08:45 PM 5/30/97 -0700, you wrote:
Not on the full thrust list you can't no:).
Seriously, If people want to discuss the full thrust file format that's fine,
but I don't think discussions on the merits of various programming languages
are going to interest the majority of our members. And in any case such
discussions have a nasty habit of becoming advocacy flamewars, which I WILL
NOT stand for on this list.
It seems that from reading the discussion we actually need TWO formats -
a
standard way of recording ship designs and/or fleet members and another
to
describe the turn-by-turn action for PBM/PBEM games. I think trying to
do
both in the same file is an option - a ship design list would be a PBEM
file on turn one - but I think keeping them separate might make things a
bit simpler.
TTFN
Jon
> Alan Brain wrote:
Sure, if I plan to work for the government!;) I used ADA back in college,
but about all my professional work revolves around C/C++.
On Friday, May 30, 1997 10:38 AM, Absolutely Barking Stars THE LIST
GOD
> [SMTP:JW4@bolton.ac.uk] wrote:
Yo
I'm happy to even take the FTF discussion off-line if you like.
I think I've heard from all interested parties and they know where I live.
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.
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.
Too many flamewars of late :-/
> 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.
> On Fri, 30 May 1997, Joachim Heck - SunSoft wrote:
> An FTF file consists of a series of zero or more blocks, with each
Its probably counter-productive to use curley-braces as a
block-definition system; it makes parsing sequences a lot more complex
than necessary. A better method might be to use a nested RFC822 (the
UseNet format for email/news headers) structure.
The basic structure is this: you have a series of fields, each terminated by a
colon and a space, followed by a value. Each group of headers is followed by a
blank line. That's it.
Of course, to do iterations of things like weapon mounts, etc, you have to get
creative (check the first field, is it another weapon or
have we moved to the next descriptor-type?), but its easily doable and
libraries already exist for Python, Perl, C and other languages to parse
RFC822.
If you really wanted to get fancy, you could use RFC822 in concert
with a MIME structure, where each sub-module gets its own MIME section
and the program only parses out those sections it recognizes and the
RFC822 sections/fields within that it has understanding of.
Personally, I prefer the former option.
An example follows, of a DSII design instead of a FT ship, but this is a hint
that the formats may be extended later.;)
===
DSIIVehicle: Medium Battle Tank (Tracked)
Description: Standard MBT, relatively low-tech.
Class: 3 Mobility: Fast Tracked Powerplant: HMT Armour: 3 ECM: Enhanced PDS:
Enhanced
Weapon: HKP Class: 3 Number: 1 Turret: Yes Mount: Full Traverse
Weapon: RFAC Class: 3 Number 1 Turret: Yes Mount: Full Traverse
===
A relatively naiive but efficent way to parse this would be to take the whole
message and RFC822 it, turning the top block of fields into the accessed
header, and all following the first blank line into the Body. Parse the first
block, looking for your standard fields and consider any fields that may or
may not be present (like PDS).
Once you have the basic block headers parsed, look at the first field of the
Body, splitting it on the colon and considering what's on the line before it.
This should tell you what kind of block it is. RFC822 the Body (turning the
new block into the header to consider and the rest of the blocks into the new
Body) and parse for fields meaningful to the type of block you've already
determined it is. Once that's done, repeat recursively to the rest of the
message.
This algorithm has the advantage that the only static field that can't be
anywhere in the block is the one on the first line of the block that
determines what kind of block it is. It also is advantageous
that not only is the format human-readable, but human-writable as
well, just in case someone uses it in an automated PBeM turn-gatherer
at some point, and someone can't run the client that generates the file for
whatever reason. Another advantage is that, in necessity or for good reason,
multiple vehicles can be packaged in the same file (ie. if I read a block that
starts again with DSIIVehicle, I know its
time to start parsing a new vehicle and save/print/whatever the older
one). You could even, theoretically, store /multiple kinds/ of
vehicle in the same file (for instance, for documenting an entire Legion,
including Centuries and landing craft, plus tenders).
[Yeesh, can you tell I spend all day designing/implimenting stuff like
this?]
> Alex Williams writes:
@:)
@:) > [ stuff to the list]
I am having more problems replying to the right places these
days....
@:) Its probably counter-productive to use curley-braces as a
@:) block-definition system; it makes parsing sequences a lot more
@:) complex than necessary.
That's funny - that's just the problem I find with the system you
propose here. Braces, or any delimiter are nice because they make a recursive
parse easy to keep track of.
@:) A better method might be to use a nested RFC822 (the UseNet format
@:) for email/news headers) structure.
@:)
@:) ===
@:) DSIIVehicle: Medium Battle Tank (Tracked)
@:) Description: Standard MBT, relatively low-tech.
@:) Class: 3 @:) Mobility: Fast Tracked @:) Powerplant: HMT @:) Armour: 3 @:)
ECM: Enhanced @:) PDS: Enhanced
@:)
@:) Weapon: HKP @:) Class: 3 @:) Number: 1 @:) Turret: Yes @:) Mount: Full
Traverse
@:)
@:) Weapon: RFAC @:) Class: 3 @:) Number 1 @:) Turret: Yes @:) Mount: Full
Traverse
@:) ===
The only problem I have with this is that you need to use look-ahead
logic to parse it. Example: I have read in the data in your example. Now
imagine there's another DSIIVehicle: line in the file. In order to correctly
read in the information, I need to recognize that that line signifies not only
the beginning of a new vehicle description, but the end of the current
description. So I have to finalize my parsing of the current vehicle and begin
parsing the next one. This happens, unfortunately, after I've already read in
the first line for the new vehicle. Ideally (as far as I'm concerned) the
program would
never have to deal with two objects simultaneously - putting braces
around things allows this since a closing brace can always be matched with its
opening brace to figure out whether the description is finished or not.
I should point out that A) I don't do this for a living, and B) I
have something of an object-oriented perspective on these matters,
since the only FT parser I've written was OO. So the idea there was that I
could have objects read themselves out of a file. This scheme gets tricky when
the object has to prime the pump for the next object (about which it should
know nothing).
That might be a more complicated way of going about things than is necessary.
Actually, other than the delimiters marking the beginning and ending of
objects, our formats are quite similar.
NEW GAME IDEA!!!
BATTLE PROGRAMMERS!!!
Its a game where programers battle among themselves for supremecy in code! One
that most ordinary gamers wouldn't understand! You guys thought it would be
hard to make up scenerios for SGII, wait till you try BP!!
> Alex Williams writes:
> Gerald McVicker writes:
@:) NEW GAME IDEA!!!
@:)
@:) BATTLE PROGRAMMERS!!!
Yeah, Core Wars was getting kind of old and no longer fit the modern model of
"design first, then program". This is much more fitting.
> On Fri, 30 May 1997, Joachim Heck - SunSoft wrote:
> That's funny - that's just the problem I find with the system you
I've never really found that to be the case for my idiom (and I wrote
LISP/Scheme code for a long time; more delimiters than you can shake a
stick at). In either case, some flag retains information about whether or not
you've completed the current section; at some point
you've got to read the next data-section into memory (or operate on
the next 'chunk' if you just slurped the whole thing up as I'm prone to do).
> The only problem I have with this is that you need to use look-ahead
Actually, you don't have to do look-ahead processing at all; the way
to avoid it is to keep the 'chunks' (in this case, recursively smaller
pieces of the original message-data) in memory. You then extract the
currently active 'chunk', via whatever means, and examine its first few bytes.
If it matches a break for current processing, you finalize
the current object, store/save it and initialize a new object/item.
When you start processing the new object/item, you begin reading the
'chunk' from the beginning again, removing the necessity for true
look-ahead processing, you just draw up the next 'chunk' and dispatch
it to the right handler for that chunk, depending on its identification field.
> the new vehicle. Ideally (as far as I'm concerned) the program would
In my suggested processing algorithm, you don't. You always finalize the
current object being processed before initializing the next, at whatever level
you're working at. We assume that each block is 'finished' when its written
out to file; if its missing a 'vital field,' information that can't be
proceeded without in processing (such as a DSIIVehicle field or a Size field
in the same chunk), you signal an exception and abort processing. This
simplifies the processing and error checking immesurably. Braces actually just
act as 'syntactic sugar' in the evaluation since they don't add information to
the data you don't already have.
> I should point out that A) I don't do this for a living, and B) I
Instead of structuring it as Objects reading themselves out of a file, think
of it as a master application Object which draws up the next chunk, examines
it, then passes it as initialization data to a specific type of Object that
knows how to interpret that chunk to initialize its data attributes. Once that
chunk is done and an initial instance is created, the master ap Obj looks at
the next chunk, and if its another chunk it knows how to handle, it
dispatches. If not, it passes it to the last Object it instantiated which may
or may not know how to handle the chunk, and proceeds likewise. If the chunk
falls off the end of the instance chain, its a bad chunk and you raise an
exception; if it gets handled by an Object, you end up with a new instance of
an Object.
In this particular discussion, you might have an ApObj that recognizes chunks
that begin with 'DSIIVehicle', 'FTShip' or 'SGSquad'. Upon reading a chunk
that begins appropriately, it passes the chunk to the named Class and creates
an instance of the result. Subsequent unrecognized chunks, beginning with
'Weapon', for example, would be passed to DSIIVehicle, let's say, who would
then create instances of the Weapon class its module was aware of. A FTShip
instance might use a field of the same name, 'Weapon', but require different
fields and accept somewhat different formats.
Ths you have a fully OOP hierarchy with dynamic instance creation that
dispatches input the appropriate handling subclass.
> That might be a more complicated way of going about things than is
I'm not a big fan of delimiters anymore; after getting into Python (where
blocks are defined by indentation and every opportunity is made to simplify
syntax), its very difficult to see using delimiters when there is no
additional info encoded into the data itself in so doing.
> On Fri, 30 May 1997, Gerald McVicker wrote:
> NEW GAME IDEA!!!
Been done, multiple times over: Core Wars, CRobots, TclRobots, PRobots.
You think it sounds silly to discuss it, but just wait 'til someone writes a
PythonFTSim game where you write code to pilot an FT starship or fleet
cooperatively against a similar group of opponant programs
and you wish you'd have listened to our code-chat more closely as we
devestate you...;)
> M Hodgson wrote:
> >From what reviews I've read Borlands new Visual C compiler (I forget
For professional work I like the Alsys/Thomson Ada-83 compiler, a sort
of "Visual Ada". There's a Freeware Visual front end to the Freeware
GNAT Ada-95 'compiler' available at http://www.adahome.com but that
would take more effort to install than I feel like making.
May I HIGHLY recommend Ada as a programming language, BTW?