This is the mail archive of the xconq7@sourceware.cygnus.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GDL (was Re: Mailing List Split)


Andrae Muys wrote:

> Regarding GDL.  I keep trying to fix the Napoleonic rule set, but keep
> running into problems.  I do have some questions regarding the design of
> GDL.
> 
> 1) Who thought of making GDL declarative?  Kudos, an excelent choice -- I
> love the syntax.  It makes it easy to code new rules.

Aw shucks, I guess that PhD in programming languages was useful after all. :-)

Actually, it was evolutionary; the original 1987 version just had a bunch
of structs.  There were three, for what are now standard, greek, and napoleon,
and you had to choose which to compile in.  Then the first generation of
readable game descriptions used postfix, which although executable, the
purpose was still to fill in data structure.  The present-day GDL got started
when the data structures needed to be more complex than vectors and arrays.
Lisp seems like more of an oddball choice than it did 10 years ago, but it
has the advantage of being a simple syntax.

> 2) Why are HP, AP, and Materials treated differently?  Conceptually aren't
> HP and AP just specialised Materials?

In theory yes.  The real original reason for the difference is that hp and acp
came first, and materials later.  But there are some semantic differences; for
instance, when units take damage, there is a two-stage system so that cascade
effects (such as detonations) can be properly calculated before the units get
their final hp values.  Of course, you could declare a material type to be
the "hp material" and do the two-stage on whatever was said to be the hp.

If somebody worked out all the necessary changes to make hp and acp into materials
and sent in a mondo patch, I'd most likely take it.  It would be a long time
before I got around to doing it myself though, plenty of other issues seem more
pressing.

> 3) The lack of unit orientation makes tactical and operational level game
> development prior to 20th century infantry battles very difficult.

Yup.  Facing is on the doc/PROJECTS list.  Basic facing doesn't seem too hard
to add, but I've been undecided about whether it should be a direction or a
bitmask of directions.  The latter case would be interesting for a fortification
type unit, which might be strong in 4 directions and weak elsewhere.  The bitmask
could also represent squares vs line formations.  On the downside, it's more
complicated to handle internally, and to display.  It's turned out to be a really
bad idea to add features without displays, so that really needs to be solved
before we try adding facing.

> 4) Is it possible to elaberate on ZOC sizes, and effects?

ZOC radius > 1 is not implemented.  Within the ZOC, movement can be made more
expensive, any combo of entry, departure, or traversal (movement within ZOC).
ZOC has no other effects at the moment.  Lots of room for GDL extensions here...

> 5) How good is the computer at automating PLAYER actions?  (ie, can supply
> be automated for the player?)

The standard generic supply (that which is controlled by in-length/out-length)
is automatic.  The supply line algorithm is also automatic.  In fact, the
only manual supply algorithm would involve units carrying supply as cargo.

> Ok, my concept for a Napoleonic period ruleset (so you can understand the
> reasons for my questions) is:
> 
> Most of the battles fought in this period had very few casualties
> inflicted on either side during the battle itself.  Even the losing side
> rarely suffered more then 10-20% losses, if the loses were higher they
> were invariably the result of a determined pursuit post-battle, or
> phyisical terrain acted to intensify the fighting/result (rivers, bridges
> collapsing, sieges, etc).  The decision was made not by killing the enemy
> but by dispersing the enemy formations and (at a higher level) disrupting
> command/control.
> 
> To represent this I wanted a focus on `cohesion' rather then numerical
> strength.  Combat, Manuvere, Formation Changes, and the presense of enemy
> units nearby (especially cavary/guards) ie. ZOC's, would all attrit
> `cohesion'.  Time, Leaders, and the presense of friendly units nearby
> (especially cavarly/guards) would all increase the `cohesion'.

I can see two different ways to look at this.  One is to treat cohesion is a
type of material, and work out tables for it.  Another is to say that hit points
represent cohesion directly - a unit with 0 hp represents a combination of
dead, prisoners, and foot-powered early retirement :-).  You can, for instance,
make a unit with low hp recover it by resting.  Similarly, you can have stack
protection effects, and you can cripple a damaged unit.  So you can probably
get most of the right behavior with hp alone, while doing it with a cohesion
material will probably require some additions to the engine (which may be
worthwhile anyway).

In any case, it would be really cool to have a Napoleonic battle game.  Even
though the Gettysburg scenario isn't particularly accurate (real battle lines
never develop as they should), it's always been enjoyable to play.  I recently
bought one of Talonsoft's PC games (Prelude to Waterloo), just to see how
they do things in the Napoleonic battle genre, and what can be carried over
into Xconq.

Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]