RE: Full Thrust Format for Email games

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:
>@:) On Fri, 30 May 1997, Joachim Heck - SunSoft wrote:
>@:)
>@:) > [ 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.
>
>-joachim

Jerry McVicker

"Don't worry soldier, weapons will be available in a moment."

Blackwind and Raddix Gaming
http://www.imagixx.net/~bnrgames
bnrgames@imagixx.net