Re: A more sophisticated demonstration of change-type

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Hi Lincoln,

On Fri, 2004-05-28 at 11:44, Lincoln Peters wrote:
> Here is a game module that uses the new change-type mechanism to
> implement d20-style combat.  It contains 7 types of cities and 20 types
> of knights.  The cities gain levels by growing them to a threshold size,
> and the knights gain levels by gaining CXP.  In the case of cities,
> higher-level cities can build higher-level knights, and higher-level
> knights are more effective combatants than lower-level knights (+5%
> chance to hit, -5% chance to be hit, +1 damage per level).  A city can
> be automatically captured by a knight (100% chance) if the city has no
> armed defenders (0% chance to capture unless the defenders are
> destroyed).

I read your game file while I was eating supper. Looks nifty; I will try
it shortly.

I did notice your comments regarding 'acp-to-attack' and 'hit-chance'. I
believe the problem is in the fact that you are dealing with a list of
lists rather than a list of atoms in the case of 'hit-chance'. Your
'levels' definition:

(define levels (l1 l2 l3 l4 l5 l6 l7 l8 l9 l10 l11 l12 l13 l14 l15 l16
l17 l18 l19 l20))

expands to this:

((knight-1 goblin) (knight-2) ... (knight-20))

and thus an atom is being iterated against a list of lists, but needs to
be iterated against other atoms (such as a list of atoms) in order to
locate distinct positions in the table to fill in.

I will experiment with the 'hit-chance' table that you have in compact
form (commented out), and see if I can think through the correct GDL
syntax that will preserve what you are trying to do.

> In its current form, this module effectively demonstrates (at least to a
> point) how the new change-type code can be used, but I plan to do a lot
> more work on it before I would consider adding it to the library as
> anything other than a test module.

In your comments you say that 'bolodd3.g' was the first game in the
library to use 'change-type', but I think you must mean
'auto-upgrade-to'.

> If the future isn't what it used to be, does that mean that the past
> is subject to change in times to come?

The future isn't what it could be, because the past was subject to
change in times past (and present).

But maybe that is just a revisionist take on the question.

Eric