> Medains wrote:
What
> restrictions have you made ?
We have made modifications to the face-to-face rules to accomodate the
play-by-e-mail games. The Fleet Book rules will also have to be
modified slightly with the fighter movement rules for their optional secondary
movement.
Rules changes:
1. Simultaneous fire
All weapons fire is conducted at the same time before any damage is allocated.
2. Conditional fire orders
Ships may designate a conditional set of orders based on the results of the
movement phase. Submunition packs usually have conditional orders to control
their use.
3. Fighter secondary movement (Fleet Book)
Fighters can use an endurance point to adjust their position in order to make
an attack. A flag could specify the option to adjust based on if the target is
in range of the fighter's position and the target's ID.
I foresee a number of issues to be addressed to accomplish this goal. The
movement format is well specified, either in cinematic or the vector movement
system. Parsing and interpreting those orders should be straight forward.
Fighter movement and salvo missile movement requires a Cartesian point
location, except for screening fighters which require a ship ID. Fighters will
need a few optional flags to specify a ship target, endurance point burn, or
fighter target.
Conditional fire orders need a language format for computer interpretation.
Keywords could be RANGE, ARC, SIZE, ESCORT, CRUISER, CAPITAL, F, FP, FS, A,
AS, AP. Point defense systems will also require conditional orders in the
cases of fighters or missile target. Area defense firecontrols will need a
targeting priority also.
Based on this first pass brainstorm, I would think that implementing a
computer moderated system for FT would be done in stages, implementing a game
initialization file and status file format, a flexible ship data structure,
and beam and pulse torpedo weapons systems, conditional fire orders, and
report and image generation. Once a reliable system is in place, fighters and
salvo missiles and limited intelligence rules and systems can be implemented.
Advancing the game even further,
a e-mail game could be initiated with a 'Judge' server and be completely
e-mail
controlled. This would be really cool!
I know that some work has gone into specifying a file format and it's
documented at the FT Computer Core.
I'd be interested in working on this and contributing to it. I think we'd also
have
> I'm currently thinking of writing something to computer moderate a
and
> intelligence rules and systems can be implemented. Advancing the game
"Way cool, you rule, dude!" Think you can have it finished by, say, this
weekend?:)
> On 21-May-99 Jon Davis wrote:
My original ideas were along the lines of the following (bearing in mind that
a, I haven't actually played much b, I only have 2nd edition and c, I've been
thinking more of ease of implementation than retaining the full flexibility of
the game):
use the FT portable format for the ships, but add 'integral systems' such as
the standard fire controls, engines etc... to the system list. number each
system
orders - give movement orders for ships, and orders such as 'pursue
X',
'intercept Y' for fighters all orders during the turn are associated with a
system
- Weapons (mostly) are linked to one of the fire control units.
- Firecontrol units can specify primary and secondary targets ( with
system level targetting if appropriate) If the primary target is in range of
any weapon linked to the firecontrol then that target is used, otherwise the
secondary target is checked in the same manner.
- Sensor systems just allocate a target to be scanned
- Reflex shields/Cloaks/ECMs/Minesweepers are set off or on.
and so on.
Things such as PDAF and ADAF etc.. become very much more complex to specify
exactly what you want them to do.
I had given some thought to conditional orders, but I think that some
assumptions will have to be made somewhere along the line.
eg.. 2 PDAF's - in a face to face game
If attacked by a single missile / one fighter group
use all PDAF's to shoot it down
If attacked by 2 or more missiles / multiple fighter groups
use both to shoot one use one on each (as far as possible) This decision is
based on the type of attackers. If attacked by a combination of missiles and
fighter groups fire at one missile and one fighter group fire both are a
missile fire both at a fighter group Again based on the types of attackers,
and whether you have screens or not.
So far this is 3 main conditions, and several sub-conditions based on
a wide variety of variables. In general this will not be too much of a problem
(every been attacked by multiple missiles and multiple fighters in the same
turn?),
but as the number of fighter defences increases. (Say an ADAF on a nearby
ship, and the possibility of using C batteries as close-in systems) The
possibilities can easily become greater than a simple order system could cope
with. My ideas with fighter defences were to allow the player to specify how
many defences to fire at each individual attacking group a prioritised list of
attacking types
eg, torp-fighter, missile, fighter, missile-needle
and whether you wish to fire on groups of larger or smaller numbers of
fighters first (potentially destroying a smaller group or saving yourself from
the possibility of greater damage)
As far as implementation goes, I think the rulebook gives a nice set of
milestones - core rules, advanced rules, optional rules from MT etc.. :)
Any more opinions?
> On Fri, 21 May 1999, Jon Davis wrote:
> I'd be interested in working on this and contributing to it.
me too.
an incremental approach is definitely the way to go - start with
some nice, simple things like data structures for ships, fleets, etc, then add
stuff to read and write various file formats (like FTPF), then some
code to track low-level orders ("fire battery a at ship x"), then some
stuff to execute orders and track results, then stuff to generate
low-level orders based on high-level orders (with conditionals and so
on),
then code to handle email, etc.
if we do it this way, we'd definitely be able to get something done, even if
it's just an FTPF parser. i seem to recall hearing there is an "ft
computer" list - would this be an appropriate place for this?
incidentally, my vote goes for java for this job. it's portable, it's strong
enough, and i know it (number one reason!).
tom
> Medains wrote:
:)
> Any more opinions?
Just make sure when you do your trig, that your rounding function works.
(8-)
The problem I found with writing a computer moderating program (which is the
goal I had in mind when I wrote the FTUtil.pm library) was how to account for
all the flexibility that people might want. I think that, either you cut the
flexibility down drastically (pick three ships that you wish to fire on), or
you're always going to need somebody
to pre-parse orders. As you can see, as soon as you start allowing
some flexibility, the possibilities grow really rapidly.
J.
> Laserlight wrote:
Let's see...
7:30 PM - 8:30 PM Conceptual design
8:30 PM - 12:00 Midnight Detailed design
12:00 - 10:00 AM Coding
10:00 - 5:00 PM Testing
5:00 - 7:00 PM On line testing
7:00 - 9:00 PM Documentation
9:00 - 9:05 PM Food and bathroom break
9:05 - 12:00 Midnight Further coding and debugging
12:00 - 3:00 AM Second online test
3:00 - 3:05 AM Quality time with wife and kids
3:05 - 3:10 AM Second bathroom break
3:10 - 7:00 AM Second debugging
7:00 AM Upload to FT Computer Core site
Finished..... :-)
> "Way cool, you rule, dude!" Think you can have it finished by, say,
> Let's see...
You know, if you're ever going to accomplish anything, you're going to have to
learn to focus on your goal and not to get distracted by
non-essentials.
: )
> Medains wrote:
such as
> the standard fire controls, engines etc... to the system list.
There are some minor and major differences between the Full Thrust and More
Thrust rules of the second edition and the rules of the Fleet Book. A flexible
implementation in software should be able to handle the weapon and arc
differences. Fighter rules are vastly different, however, as is the new rules
for point defense systems, area defense fire controls, and salvo missile
rules.
Fire control programming is a good idea and it requires some anticipation of
the enemy. I use it for my on-line game for the Estrell battleship duel
and it simplifies weapons fire.
> Laserlight wrote:
> >Let's see...
12:00-02:00 Mission formulation
02:00-02:01 Threat analysis
02:01-05:40 System Requirements Definition
05:40-07:20 System Development Plan
07:20-07:30 Hydraulic Break
> > 7:30 PM - 8:30 PM Conceptual design