THE DIGITAL BATTLEFIELD
Play Miniature/Board Games on the Computer!
by Paul J. Calvi Jr.17JAN97
I've been working on a way to play board and computer games (including Full
Thrust, Dirtside 2, and Stargrunt 2 to name a few) on the computer, which, for
the sake of brevity, I will call the Digital Battlefield. I know that at least
one gentleman is in the process of programming a
JAVA-based program to play Full Thrust over the Web. Such a program will
be quite a boon to FT players everywhere, but until such a program(s) is
finished I think I may have a very workable solution (Note: this system works
equally as well with any miniatures game as well as any low
unit-density board game). I have worked on such a system for various
reasons. First, I wanted to be able to play these great games without
the need to purchase and paint miniatures--I know this is part of the
fun, but one only has so much time, space, and money to devote to a particular
series of miniatures as well as gaming in general. Second, I also wanted to be
able to keep a game setup for longer periods of time and taking up a table for
a long time is not always possible. Third, the
computer offers unlimited flexibility/customization and, of course,
allows one to play games over email.
=WHAT IS NEEDED=
All that is needed to use the Digital Battlefield is any vector-based
drawing program that allows multiple levels of zoom, the ability to group
objects, the ability to rotate objects, and preferably, the ability to import
and rotate bitmaps. I use Corel Draw 7.0 and Corel Xara because those are two
programs I have and they both work extremely well (Adobe Illustrator and
Macromedia Freehand are two other common drawing programs). Of these programs,
I would recommend Corel Xara because it does all that is needed and only costs
$100. If anyone knows of a cheaper program that has all these functions please
let me know.
Also a raster-based "paint" program is also helpful for unit and terrain
preparation/modification.
=ADVANTAGES= The advantages to playing games using the Digital Battlefield are
many:
* It allows a larger playing area than is practical on the table top. Both
Corel programs support page (and thus "table") sizes over 100in on a side.
This is a larger area than most people have available for normal
table top games with miniatures. The multiple zooms allow one to zoom-in
to greater than 1:1 scale and out far enough to view the entire "surface."
Centimeter and smaller scales are also easily used allowing even bigger play
areas.
* Because you are using a vector-based drawing program to play you can
play using anything you can draw. Obviously the better artist you are the
better your ships will look, but even the graphically challenged can easily
make respectable looking ships in just a few minutes. These drawings can be
scaled as needed to fit any scale and rotated in anyway to play the game.
* Extra units are infinitely available so you'll never run out of ships or
counters.
* The big advantage to the mentioned drawing programs is that they allow one
to import bitmaps (For FT players this allows you to use the beautiful B5,
etc. ship counters available on the Web).
* Another advantage for email play is that file sizes are very small.
With vector units, file sizes are about 20-50K for the largest battles.
With bitmap units, files get larger (200K+) but can be controlled by the
bitmaped files' sizes and color depths. Of course with compression programs
even these files could be made very small for transmission to your opponent.
=DISADVANTAGES= There are of course a few disadvantages to playing games this
way as well:
* The disadvantages will vary due to the computer system and program(s) used.
First of course is simply the loss of aesthetic beauty of a table top
miniatures game (or board game).
* Depending on your computer monitor size and video resolution, you will have
greater or lesser enjoyment with the Digital Battlefield. I play on a 17in
monitor at 1024x768 resolution and think it is just fine. When zoomed out to
max the ships are still distinguishable. Someone on a 14inch monitor at
640x480 resolution may not be so lucky.
* Also, depending on how big your game is, what you use for ships (vector vs.
bitmaps), and which drawing program you use, you may or may
not get satisfactory performance in scrolling and zooming-in/out while
playing the game. Processor speed, amount of RAM, video card speed, and
the graphics program itself are all factors here. On a P150 w/32MB of
RAM, game performance was excellent even with large numbers of bitmap units.
=HOW TO PLAY=
The first thing you need to do to use the Digital Battlefield is setup your
game environment. This involves choosing your play scale, setting up your page
in the drawing program, making your map, and making the play counters (unit
and administrative). After setup, play proceeds almost as it normally would on
the table top.
-Scale and Page Setup-
I've tested three setups for miniature play; first was an inch scale.
Everything works fine at this scale and it presents no conversion problems at
all, but the 100 inch limit is still a bit tight for larger
games. Another option is to use a 81/2 x 11" page size and use a 1mm =
1inch scale. This looks fine on screen and allows you to print your battles
onto a single piece of paper for reference (with a 600dpi laser printer the
units are very small, but discernible). My favorite setup uses a 140 x 140cm
page size. This allows maximum maneuver room and a good "true" size (Also, the
centimeter scale just happens to fit
perfectly with the graphic Babylon 5/Star Wars counters available on the
Web for FT.) Remember to turn your rulers on to aid in movement during play.
The Preferences or Options settings usually allow you to adjust the default
rotation of objects (15 or 30 degrees is probably the best choice). Most draw
programs have a grid scale you can turn on and adjust. I would recommend
turning the grid on. It also looks good as it can represent a "star"
background or make the map look like it is cut into military grid squares.
-Making the Map-
Because miniature games are designed to played without a hex grid the draw
programs scale and measurement functions work perfectly. If you are playing a
game that needs hexes (or you just want to use them) you can overlay the page
with a hex fill. Otherwise, you can just play on the bare page (you could make
a colored background, but this hides your grid and slows down scrolling). For
ground games (such as DS2 and SG2) you can either construct simple terrain as
you would on the table top (hills, forest areas, etc.) or make a very detailed
map to scale (this will slow down your game performance depending on how
detailed you got and your computer's hardware configuration). In either case,
it is best to make the map "layer one" and play on a second layer (if your
program supports layers). You can get as creative as you want here and use
bitmap objects for great looking terrain, use "landscaping" vector objects, or
just make simple geometric shapes. Once designed, the map should be saved as a
single object (group) or layer to prevent it from getting altered during play.
-Making the Units and Counters-
The easiest way to make units for games is to open a bitmap image of the units
(such as the FT B5, etc. ship counters available on the Web) in a paint
program, cut out the individual "pieces" and import them into the draw program
to use as counters (at the centimeter scale this works
perfectly for FT). The pieces can be "modified" with numbers/comments
either in the paint program or right in the vector program. During play they
can be moved and rotated as needed. The disadvantage to bitmap objects is that
they are larger (in file size) than most equivalent vector objects (but not
always) thus slowing down game performance and increasing game file size; they
also lose "resolution" at certain zoom levels making them harder to
distinguish and, depending on your play scale, may or may not scale well
without losing fidelity. Your own preferences and system setup will dictate
whether you wish to use bitmap objects or not. You can open any paint program
and make simple
administrative (move/shoot/command, etc.) counters for import into the
game. You can also copy/paste/duplicate/clone units easily to create
large numbers of units.
The alternative to bitmap objects is vector ones made in the draw program
itself. These are infinitely scaleable and rotatable and usually are very
readable at any zoom level. If you keep the objects simple they also give very
speedy game performance. You can add unit IDs, etc. to the units when you make
them. Remember to save the finished units as a single object (group) for easy
handling during play. Obviously you can
easily make simple administrative (move/shoot/command, etc.) counters as
well. Remember you can copy/paste/duplicate/clone units easily to create
large numbers of units.
You can make "damaged/destroyed" versions of any units. An alternative
with vector-made units is, when they take damage, to un-group them and
remove part of the design (say a warp nacelle or an individual fighter)
and then re-group them again. This adds some nice visual excitement to
the game and also aids in play. With either vector or bitmapped objects, as
units are destroyed game performance will increase.
As noted, you will need to make various administrative
(move/shoot/command, etc.) counters to play your games. An alternative
to the counters is to simply "write" on the play surface as and where needed
during play. Just type out what you want and scale it down to size. Depending
on your play scale and preferred zoom level this could be a convenient or
annoying alternative to premade "counters". You can also use this technique
for making notes to your opponent during email play. The grid scale and rulers
make judging distances and moving units easier, but I have also found that
making premade "movement templates" works very well. These are simple
rectangles of various lengths. To use them just drag the appropriate template
in front of your unit and then drag your unit to the other end of it and you
just made your move. The draw programs allow you to be as precise as you wish
(in fact, far more precise then you could ever get on the table top).
-Playing the Game-
Playing any of the games using the Digital Battlefield is done essentially the
same as you would play on the table top. You can use written record sheets and
normal dice or use computer forms or text
records and dice rolling programs for play-by-email games if you wish.
As with any manual (board) game, play-by-email may require various
modifications to the sequence of play to accommodate the lack of in-turn
player interaction. Also, and most importantly, this system has no game
protection so don't play with someone who you think may be tempted to cheat.
=TIPS AND TRICKS= **You can use the drawing programs text and other features
to make notes during play on the game board (or off to the side) or to show
other activities.
**Make "shadow" versions of units to show previous positions.
**If you have access to a color scanner, you can scan in your un-punched
counters, open them in a paint program, and then "cut" them into individual
units for import into the Digital Battlefield.
**In FT (or other space/naval games) you can use your programs line
drawing ability to create "course lines" that allow players to see a fleet's
maneuvers during the game. You can make these a very light color during play
so they are not intrusive and then darken them at the end to get the "big
picture".
**A seeming limitation to the Digital Battlefield is finding players with a
compatible drawing program. This limitation can largely be overcome using
common graphics formats. For example, Corel Draw 7.0 on Windows 95 can read
and edit Adobe Illustrator.eps files from the Macintosh. Thus, in this case,
players with completely separate, and seemingly incompatible, systems can
still play as if they had the same system.
=OTHER COMMENTS= HPS Simulations has a DOS "game" called Aide de Camp that
allows players to play any board game on a computer. It has many features that
my Digital Battlefield system does not have (dice rolling, unit tracking,
etc.) but also has many limitations (including a fixed sequence of play and a
poor aesthetic look). A Windows 95 version was supposed to be available soon,
but I recently spoke with Scott (the owner) and he said version 2 may be a
year or more away due to problems with the program's compiler. This is a real
shame as a professional, flexible system such as this is sorely needed.
Players should still give Aide de Camp a look, for many games it works very
well and a number of board game company's
sell pre-made ADC modules for their games.
A better long-term solution for some of us folks that will /never/
have a compatible drawing-program might be to plan a Java-based
web-supplied game-server for playing FMA-style games on. A very basic
two-player map-handling/icon-handling system would probably not be out
of the reach of a 3mo project for some alert lad. Once the basic framework's
in place, additional functionality shouldn't be too hard.
(Yes, I know, I still have to produce a DSII/SGII MU*. I'm working on
it, on and off, no worries. Unfortunately, my life keeps getting in the horrid
way.)
This sort of thing has been done for some of the PBEM games, see
http://scivax.stsci.edu/~kochte/ftgame.html
o Turn 10 Color Map
For a good example of this. The programs used to create these maps were
different but the best (because its free) is the one written by Alun Thomas
which is freeware if you have a C compiler. It only runs on unix systems but
hasn't been ported to Win95 or NT or Mac yet, I intend to do so (intel) when I
get my C compiler.
The color images were Mike Wikans and I edited then in Paint Shop Pro which is
a very common shareware program. The space images can be got from the Hubble
Space telescope public access images (Thanks Mark K.)
This makes setting up space games very easy as all you need is an ASCII data
file in the right format and map generation is automatic. Zooming can be
achieved by changing the pixels per MU in the ftmap program, you get a
different map for each zoom level, you can also use any GIF file for the ship
images, so you can use different symbology for zoom levels.
This sort of tool could be slaved to a Web applet to generate maps for online
games via CGI or java native calls.
For a raster format I'd choose GIF because its everywhere and there are very
good tools for transparency and animation available, although didn't some fool
company claim they had the patent for it and we weren't to use it without
paying royalties?
For a vector format CGM would be my favourite due to its level of support
across platforms.
> This sort of thing has been done for some of the PBEM games, see
Nice aint it?
> For a good example of this. The programs used to create these maps
Can anyone give me an address where I can get Alun's program as I have access
to both unix and windows and would love to try something like this. I am
working on A Visual Basic Program to work out movement, so with a bit of work
this could be made to accept an emailed input...
> timj@uk.gdscorp.com writes:
@:) For a good example of this. The programs used to create these maps @:)
were different but the best (because its free) is the one written @:) by Alun
Thomas which is freeware if you have a C compiler. It only @:) runs on unix
systems but hasn't been ported to Win95 or NT or Mac @:) yet, I intend to do
so (intel) when I get my C compiler.
For anyone considering writing an FT map-drawing program or a
program for working out FT movements, I strongly encourage that you take a
serious look at Java as the language to use. I think the community using this
list operates in quite a heterogeneous computer environment and to me it seems
that writing a Visual Basic program, or a program in a UNIX version of C would
only be wasted effort because not everyone would be able to use it. Better, in
my opinion to write the thing in a portable language. Of course I work for Sun
so you can take my statements with a grain of salt, but I really do believe
this is a perfect environment for Java.
Also anyone considering creating such a project in Java should probably talk
to me or Daryl Lonnon (if he still reads this list) about some of the stuff
we've done. Among other things, we created an
automatic map-generator with ship identification (including all ship
status), hypothetical movement calculation and range and arc determination.
The system works with Mark Kochte's FT data files and
is relatively bug-free but not perfect. However, it contains all
sorts of useful code - everything from how to get a firing arc from
two XY positions to how to move a ship given a standard FT movement
order as written in a normal (non-computerized) FT game.
So the point is that a lot of this stuff has already been done and if people
are really eager to get a finished product working they would probably do well
to build on the work of others. I don't think I really have enough time to go
back and fix up Daryl's and my system (and I think Kochte's data files are not
too great for computer interpretation) but the work is definitely doable.
> Joachim Heck wrote:
I agree, but then again I work at Sun also, Sun Microelectronics to be
specific. I suspect a lot of people use PC machines, with a few like me using
a Mac at home, and of course some at work on Unix systems.
> Also anyone considering creating such a project in Java should
I've though about doing such a project partly to use the program and partly as
an exercise to learn Java. Maybe it's time to get off my duff and do it. I'd
love to see your code, and I'll see what I can put together.
Enjoy,
> For anyone considering writing an FT map-drawing program or a
Don't forget us who are in the VMS enviroment!!
Mk
[...]
> about some of the stuff we've done. Among other things, we created an
[...]
> (and I think Kochte's data files are not too great for computer
Well, I made the data files primarily for human reading/interpretation,
partly because *I* didn't have access to, the resources for, or the full
coding skills to put together nifty little tools like you guys do. :-/
I've always been open to comments/suggestions/thoughts/opinions, and
have even changed some of my report formats to help when I could.
Mk
> Mark Kochte writes:
@:) [...]
@:) >(and I think Kochte's data files are not too great for computer @:)
>interpretation) but the work is definitely doable.
@:)
@:) Well, I made the data files primarily for human
@:) reading/interpretation, partly because *I* didn't have access to,
@:) the resources for, or the full coding skills to put together nifty
@:) little tools like you guys do. :-/
Indeed, and I didn't mean to suggest that the data files were anything less
than excellent in the task for which they were designed. I found them quite
easy to read, myself. It was my programming skills that didn't like them,
mostly because there were occaisional changes or variations in the structure
if the files. Any problems were minor and quite fixable.
@:) I've always been open to comments/suggestions/thoughts/opinions,
@:) and have even changed some of my report formats to help when I
@:) could.
And in fact I seem to recall that you made some changes to better suit my
needs, and did so in a prompt and effective manner. Then again, you were also
not above secretly and maliciously reverting the spelling of "Hangar" to
"Hanger" just to screw me up:)
> I'm telling you writes:
@:) >> For anyone considering writing an FT map-drawing program or a
@:) >> program for working out FT movements, I strongly encourage that you @:)
>> take a serious look at Java as the language to use....
@:)
@:) Don't forget us who are in the VMS enviroment!!
Ouch. I take it they don't have Java for VMS yet? Do they have X for VMS yet?
> @:) >> For anyone considering writing an FT map-drawing program or a
Not that I'm aware of. We *just* recently acquired Netscape-for-VMS a
couple months back, but it's still a little clunky (and version 2.02)
> Do they have X
X? X??
Isn't that something you center your target on?
Mk
On Tue, 21 Jan 1997, I'm telling you, the beard and mustache are... wrote:
> Not that I'm aware of. We *just* recently acquired Netscape-for-VMS a
Hmmm... does your VMS have a mouse?:)
> (and I think Kochte's data files are not too great for computer
Not that I was taking a defensive stance or anything; just if you got some
ideas, thoughts, suggestions, etc, about improving the reports - feed
me!!
I'm willing to do what I can but want to still keep them human-readable.
:-)
Mk
> >Do they have X
I saw a couple mouses running about the building when the weather got cold.
And got one hooked up to the workstation...though that one's a bit less furry.
Mk
> Joachim writes:
Well...*that* was just to keep you honest. ;-)
Mk "sure, I can introduce a bug if ya want!"
> joachim wrote:
-- For anyone considering writing an FT map-drawing program or a
--program for working out FT movements, I strongly encourage that you
--take a serious look at Java as the language to use.
Having taken a serious look I find the java GIF manipulation tools lacking in
the raw JDK. However it's certain someome will have written a package to do
the sort of job as the gd library that ftmap uses, GIF write,read, pixel set,
color map manipulation etc. If anyone knows where to get hold of this sort of
thing drop me an email timj@uk.gdscorp.com.
-- Also anyone considering creating such a project in Java should
--probably talk to me or Daryl Lonnon
I emailed Daryl about the battle computer code he said he'd get back to me but
never did as he had to consult his co author (you?). If you still have the
packages I'd like to use them we can talk via email.
-- So the point is that a lot of this stuff has already been done and
--if people are really eager to get a finished product working they
--would probably do well to build on the work of others.
I agree, I don't subscribe to the 'Not Invented Here' mindset and would be
keen to look at your code and take in on for enhancement or use it as a
component in my FT framework. I can take tar files or zip as email attachments
upto 500K but no bigger then that.
Hope to talk to you offline.
> KOCHTE @ stsci.edu writes:
> Joachim writes:
> Well...*that* was just to keep you honest. ;-)
I caught that one by changing my awk script to handle both spellings when
you switched over the first time. So switching back didn't throw it :-)
What caught me was the way in which the number of fighters in a squadron
kept moving around - the script would fail to find it, and crash
ftmap...
Oh well, it was all good fun anyway. I'll have to do some more development on
it sometime.
Hi gang,
I'm working on both a real time combat system as well as a turn based campaign
system under java, this was posted a few weeks ago (at least I thought I
posted it). I purchased a new Java Development tool today to advance the
development of the user interface side of the program. 90% of the server
module is complete and debugged. I am sill hoping to be in Beta by the end of
February. Screen shots and a java ship builder should be available before the
31st.
Keep up ideas coming,
> At 9:42 PM -0800 1/20/97, Paul Calvi wrote:
In short, this seems to be screaming for Shockwave. Pity school just started
and I won't have the time myself.... besides, Indy can't get his hands on
amodern web browser last I heard. And it wouldn't be fair to keep one of our
rare GM's from enjoying something that would eliminate his burden in running a
game.
The only system I'm working in right now that could even remotely handle
something like this is Mac only (for a few more months). And I can take time
away from a "mission critical" project to play games, but not to clamber up
yet another learning curve.
As for vector formats, I'd prefer something that produced files that I can
edit. There is a 2D variant of.dxf, but associating a bitmapped counter with a
2d.dxf object calls for serious scripting. EPS? Nahhh. Pict? You IBM and
mainframe types don't have anything that can cope.
Maybe generating a machine-readable list of ships, positions, and
vectors would be best. That has already been done for pbem maps, albeit in
Unix. But the file format exists, and I do have a copy somewhere.
> THE DIGITAL BATTLEFIELD
Shockwave??...you mean the old Ogre expansion?? I HAVE THAT! :-)
> started and I won't have the time myself.... besides, Indy can't get
News Update: the system managers here recently upgraded us and added the
netscape-for-vms...so I have netscape access now :-)
> Maybe generating a machine-readable list of ships, positions, and
Unix...I still gotta learn that someday...
Mk
> At 08:19 AM 1/28/97 -0500, you wrote:
At 5:19 AM -0800 1/28/97, "I know as a lemming I shouldn't be forming
> my own opinions, b wrote:
I have two copies of that. I actually meant Macromedia's web plugin that lets
you distribute applications created in Director over the WWW. You can make
very sophisticated interfaces and do serious programing in Lingo, Director's
scripting language. Unfortunately, I wouldn't hold my
breath for Shockwave-VMS.
You don't really *need* to learn Unix tho
> Michael Carter Llaneza wrote:
Shockwave would be ideal for an FT game, especially since the plug-in is
free, widely available, and supports more than just the PC.
> The only system I'm working in right now that could even remotely
If you plan to write a game engine to support this data, it would be advisable
to provide it with only the necessary data such as ship positions, stats, etc.
If you plan to use the DXF format, be forewarned that not all DXF viewers
support the same format. I have developed apps that use the most basic form of
2D and 3D DXF and have found a few CAD packages that croak when they try to
load the data. Also, you will need to decide whether
you are using left-hand or right-hand geometry, etc.
Someday I would like to make a Web game for FT when time permits and only
after completing my software tools I've been working on for FT. Currently, I
can only test apps for PC and Macs so these two systems would be the platforms
of choice.
[ Re-sending this, because it seems to have bouced the first time]
> >>Maybe generating a machine-readable list of ships, positions, and
albeit
> >>in Unix. But the file format exists, and I do have a copy somewhere.
> How about settleing on a format, then getting enough programers around
> First work out what the program must do, break this into subsections,
> Just an idea...
Ok, here's the format I used for ftmap (developed for Mark's most recent B5
game)
Firstly, there're some lines describing the map in this order
1) Title
2) Background gif filename or "-" to use a black background
3) course trails flag ( 1 == draw them, 0 == don't draw them)
4) min x co-ord (in game units)
5) min y co-ord (")
6) max x co-ord (")
7) max y co-ord (")
8) number of pixels per game unit
Then there are a series of sections defining the available ship classes
1) The class name 2) The file name of the gif used for the class (pointing in
direction 1) 3) Scale factor for displaying the gif 4) Legend flag ( 1==list
class in legend, 0==don't list class in legend)
This is repeated for each class, with a line containing a single * indicating
that there are no more classes.
After the * line there are a series of sections describing each ship:
1) Ship Name 2) Ship Class name (must exactly match a class name from above)
3) x co-ord
4) y co-ord
5) ship heading (1->12)
6) ship facing (1->12)
7) ship speed
8) the ammount the heading has changed by ( +12 -> -12 )
This is repeated for each ship, with a line containing a single * indicating
that there are no more ships.
Notes:
- Although I say "ships" in the above, it works just as well for
fighters.
- For normal FT, ships will have the same values of heading and
facing. Fighters can have diferent values, and the "real" thrust rules would
allow ships to also have different values.
- This format could be extended to include things like the ammount of
damage taken by each ship.
- You could use this to display Narn energy mines, as ships with speed
zero
and a .gif of an explosion - although you'ld have to rely on the
plotting program drawing things in the order specified in the file, so that
they wouldn't obsure any of the ships.
Is this the sort of thing you were thinking of?
> Alun Thomas writes:
@:) Ok, here's the format I used for ftmap (developed for Mark's most @:)
recent B5 game)
@:)
@:)
@:) Firstly, there're some lines describing the map in this order
@:)
@:) 1) Title
@:) 2) Background gif filename or "-" to use a black background
@:) 3) course trails flag ( 1 == draw them, 0 == don't draw them)
@:) 4) min x co-ord (in game units)
@:) 5) min y co-ord (")
@:) 6) max x co-ord (")
@:) 7) max y co-ord (")
@:) 8) number of pixels per game unit
@:)
@:) Then there are a series of sections defining the available ship classes
@:)
@:) 1) The class name @:) 2) The file name of the gif used for the class
(pointing in direction 1) @:) 3) Scale factor for displaying the gif @:) 4)
Legend flag ( 1==list class in legend, 0==don't list class in legend)
@:)
@:) This is repeated for each class, with a line containing a single * @:)
indicating that there are no more classes.
@:)
@:) After the * line there are a series of sections describing each ship:
@:)
@:) 1) Ship Name @:) 2) Ship Class name (must exactly match a class name from
above)
@:) 3) x co-ord
@:) 4) y co-ord
@:) 5) ship heading (1->12)
@:) 6) ship facing (1->12)
@:) 7) ship speed
@:) 8) the ammount the heading has changed by ( +12 -> -12 )
@:)
@:) This is repeated for each ship, with a line containing a single * @:)
indicating that there are no more ships.
I think this format is quite serviceable. I would think that the question of
whether ship's trails should be drawn or not should be left up to the program
and doesn't need to be in the data file. The
rest of it looks good - the separate heading and facing fields are not
required for standard FT but are a sensible precaution.
Mark Kochte's data files from the game I played in consisted of a series of
ship descriptions. The basic ship information looked something like this:
Ship Name: EAS THESEUS
Ship Class: Omega-class 'Destroyer'
Commanded by: Captain Ludo Toen, Ludo.Toen@ping.be
Location: 79.1,23.4
Velocity: 4
Heading: 4
Movement Plot: 1S-1
Mass: 90 Thrust Rating: 2 Jump Engines: Yes
Scanners: Enhanced Sensors
Damage Points: [45] 6: 0/0/0/6
As far as I'm concerned, this is a perfectly machine-readable format
that includes a lot of the information required (although thrust rating, jump
engines and scanners could all be derived from other data). I think any
computerized FT game needs all of the above information (facing would also be
nice).
Ships' systems were described like this:
Internal Configuration/Status:
HBW-3 (F) - DESTROYED
HBW-2 (A) - fired on the COEUS; 2 pts
HBW Capacitor (6): 5
C-battery, (P/F/S) -
PDAF - anti-fighter
Enhanced Sensors - DESTROYED
Fire Control
Damage Control - repairing
Jump Engines
Jump Engine Capacitor (6): 1 Thrust Engines
The information here is good but for my tastes a little inconsistent. I would
suggest a format like
SYSTEM NAME: SYSTEM INFORMATION
So a function could grab everything up to the ':' and feed the rest of the
line to a specialized function designed to handle that particular type of
system. Example:
HBW-3: (F) DESTROYED
HWB-2: (A) Hit COEUS for 2 points.
C-battery: (PFS)
Jump Engine Capacitor: 1/6 points.
And so on. Limiting each system to one line would be helpful.
The next thing in Kochte's reports was the fighter information. Although it
might be worthwhile to separate the fighters out and treat them as ships, if
that were not done, some minor tweaking would make the parsing of fighter
groups easier. In particular, an empty line or
some other indicator between fighter group/hangar bay descriptions
would help a lot - especially since a hangar bay may or may not
contain fighters, so it's hard to tell when you're done reading it (before you
start reading the next one, that is).
Hanger Bay - 6 heavy fighters - launched turn 2 - DESTROYED
Fighter Squadron A: - 3 ftrs
Location: 45.0,30.0 Velocity: 12 Heading: 4 Facing: 5 Other: engaging the
QUEENSLAND; lose 1 ftr, inflict 2 pts damage
Hanger Bay - 6 standard fighters - launched turn 1 - DESTROYED
Fighter Squadron B: - 3 ftrs
Location: 39.0,35.0 Velocity: 4 Heading: 3 Facing: 3 Other: dogfighting with
HECATE fighters; lose 0, kill 2
The last section described damage to the ship during the game, as follows:
Damage Sustained: 3 pts from COEUS on Turn 2 6 pts from HECATE on Turn 3 4 pts
from QUICKSILVER on Turn 5 Threshold Level 1 reached: Turn 5
Actually all you need is the damage for this turn - if a program
wants to, it can load multiple report files and get the multi-turn
information that way.
I think Kochte's report format could be fairly easily banged into an
effective, and even human-readable way of electronically transmitting
FT game status.
Does anyone have a digital game engine operating?