public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* A more sophisticated demonstration of change-type
@ 2004-05-28 17:44 Lincoln Peters
  2004-05-29  2:28 ` Eric McDonald
  0 siblings, 1 reply; 16+ messages in thread
From: Lincoln Peters @ 2004-05-28 17:44 UTC (permalink / raw)
  To: Xconq list

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

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).

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.

---
Lincoln Peters
<sampln@sbcglobal.net>

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

[-- Attachment #2: knights.g --]
[-- Type: text/plain, Size: 22969 bytes --]

(game-module "knights"
  (title "Knights")
  (blurb "Adventuring knights gain experience, grow more powerful, and conquer the world")
  (instructions "Gain the skills you need, then take over the world!")
  (notes "This game is an effort to bring d20-style combat to Xconq.  Like d20-based role-playing games, this includes combat units of 20 levels, and it is possible for them to advance in levels through combat experience.  There are also cities of various sizes, and larger cities can train units to higher levels before releasing them.  Eventually, I hope to add various kinds of magical flourishes, such as acid fog, walls of iron, and so on.")
  (version 0.1)
  (variants
    (world-seen)
    (see-all)
    (sequential true)
    (world-size (240 120 1440))	; Should it be bigger, considering the scale?
    ("Lots of starters" many-starters
     "Start with an entire army at your command"
     (true
	(add metropolis start-with 1)
	(add large-city start-with 2)
	(add small-city start-with 3)
	(add large-town start-with 4)
	(add small-town start-with 5)
	(add hamlet start-with 6)
	(add thorp start-with 7)
	
	(add knight-20 start-with 1)
	(add knight-19 start-with 2)
	(add knight-18 start-with 3)
	(add knight-17 start-with 4)
	(add knight-16 start-with 5)
	(add knight-15 start-with 6)
	(add knight-14 start-with 7)
	(add knight-13 start-with 8)
	(add knight-12 start-with 9)
	(add knight-11 start-with 10)
	(add knight-10 start-with 11)
	(add knight-9 start-with 12)
	(add knight-8 start-with 13)
	(add knight-7 start-with 14)
	(add knight-6 start-with 15)
	(add knight-5 start-with 16)
	(add knight-4 start-with 17)
	(add knight-3 start-with 18)
	(add knight-2 start-with 19)
	(add knight-1 start-with 20)
    ))
    ("Minimal starters" min-starters
     "Start with a band of settlers only"
     (true
       ; Redefine the starting units.
       (add u* start-with 0)
       (add settler start-with 1)
    ))

  )
)

;;; INITIALIZATION

(scorekeeper (do last-side-wins))

(include "advterr")
(include "ng-weird")

(define water (sea lake))
(define land (swamp salt-marsh desert semi-desert steppe plain forest mountain))

;                               		sea 	lak	swa 	sal 	des 	sed	ste	pla 	for 	mou 	ice
; ---------------------------------------------------------------------

(add cell-t* alt-percentile-min 	(  	0  	89 	0  	20	21  	21  	21	21	21  	90  	99	))
(add cell-t* alt-percentile-max 	( 	20  	90  	0  	23	90  	90  	90	90	89  	99 	100	))
(add cell-t* wet-percentile-min 	(  	0   	0  	20   	20	0  	10	20  	30	70   	0   	0	))
(add cell-t* wet-percentile-max 	(	100 	100 	100	100	10  	20	30 	70	100 	100 	100	))

;; Places

(unit-type thorp (image-name "ancient-tribe")
  (hp-max 100) (hp-recovery 1.00) (reach 1))

(unit-type hamlet (image-name "ancient-village1")
  (hp-max 200) (hp-recovery 2.00) (reach 2))

(unit-type village (image-name "ancient-village2")
  (hp-max 400) (hp-recovery 3.00) (reach 3))

(unit-type small-town (image-name "ancient-green-city")
  (hp-max 800) (hp-recovery 4.00) (reach 4))

(unit-type large-town (image-name "ancient-city")
  (hp-max 1600) (hp-recovery 5.00) (reach 5))

(unit-type small-city (image-name "ancient-small-city")
  (hp-max 3200) (hp-recovery 6.00) (reach 6))

(unit-type large-city (image-name "ancient-blue-city")
  (hp-max 6400) (hp-recovery 7.00) (reach 7))

(unit-type metropolis (image-name "ancient-white-castle")
  (hp-max 12800) (hp-recovery 8.00) (reach 8))

;; Facilities

(unit-type granary (image-name "granary") (cp 25)
  (hp-max 30) (help "Improves food production"))
  
(unit-type mine (image-name "iron-mine") (cp 25)
  (hp-max 30) (help "Improves productivity"))
  
;; Colonizers

(unit-type settler (image-name "ancient-colonizer")
  (hp-max 4) (acp-per-turn 4) (acp-min -3) (cp 10)
  (help "Builds new settlements"))

;; Military units
; These knights are loosely based on fighters from any fantasy RPG.
; (need more distinctive images!)

(unit-type knight-1 (image-name "ancient-spearman")
  (hp-max 10) (cp 10)
  (help "Level 1 knight"))

(unit-type knight-2 (image-name "heroes-yellow-shiledman")	;; "shiledman" is a typo is fantasy.imf
  (hp-max 20) (cp 12)
  (help "Level 2 knight"))

(unit-type knight-3 (image-name "ancient-swordman")
  (hp-max 30) (cp 14)
  (help "Level 3 knight"))

(unit-type knight-4 (image-name "heroes-dwarf2")
  (hp-max 40) (cp 16)
  (help "Level 4 knight"))

(unit-type knight-5 (image-name "heroes-prince1")
  (hp-max 50) (cp 18)
  (help "Level 5 knight"))

(unit-type knight-6 (image-name "heroes-swordman1")
  (hp-max 60) (cp 20)
  (help "Level 6 knight"))

(unit-type knight-7 (image-name "heroes-swordman2")
  (hp-max 70) (cp 22)
  (help "Level 7 knight"))

(unit-type knight-8 (image-name "heroes-swordman3")
  (hp-max 80) (cp 24)
  (help "Level 8 knight"))

(unit-type knight-9 (image-name "heroes-hobbit2")
  (hp-max 90) (cp 26)
  (help "Level 9 knight"))

(unit-type knight-10 (image-name "heroes-swordman4")
  (hp-max 100) (cp 28)
  (help "Level 10 knight"))

(unit-type knight-11 (image-name "heroes-man4")
  (hp-max 110) (cp 30)
  (help "Level 11 knight"))

(unit-type knight-12 (image-name "heroes-prince2")
  (hp-max 120) (cp 32)
  (help "Level 12 knight"))

(unit-type knight-13 (image-name "heroes-clubman")
  (hp-max 130) (cp 34)
  (help "Level 13 knight"))

(unit-type knight-14 (image-name "heroes-wildman")
  (hp-max 140) (cp 36)
  (help "Level 14 knight"))

(unit-type knight-15 (image-name "heroes-viking")
  (hp-max 150) (cp 38)
  (help "Level 15 knight"))

(unit-type knight-16 (image-name "heroes-yellow-man")
  (hp-max 160) (cp 40)
  (help "Level 16 knight"))

(unit-type knight-17 (image-name "heroes-prince3")
  (hp-max 170) (cp 42)
  (help "Level 17 knight"))

(unit-type knight-18 (image-name "heroes-blue-shieldman")
  (hp-max 180) (cp 44)
  (help "Level 18 knight"))

(unit-type knight-19 (image-name "monsters-yellow-man")
  (hp-max 190) (cp 46)
  (help "Level 19 knight"))

(unit-type knight-20 (image-name "heroes-bluecape")
  (hp-max 200) (cp 48)
  (help "Level 20 knight"))

;; Sword fodder

(unit-type goblin (image-name "monsters-orc1")
  (hp-max 6) (cp 10)
  (help "Small menace in large packs"))

;; Materials

(material-type food (image-name "green") (resource-icon 1)
  (help "Feeds cities"))
(material-type ores (image-name "blue") (resource-icon 2)
  (help "Used to build anything"))

;;; DEFINITIONS

; define groups of units, first by type, then by level.

(define cities (thorp hamlet village small-town large-town small-city large-city metropolis))
(define facilities (granary mine))
(define fighters (knight-1 knight-2 knight-3 knight-4 knight-5 knight-6 knight-7 knight-8 knight-9 knight-10 knight-11 knight-12 knight-13 knight-14 knight-15 knight-16 knight-17 knight-18 knight-19 knight-20))
(define monsters (goblin))

(define l1 (knight-1 goblin))
(define l2 (knight-2))
(define l3 (knight-3))
(define l4 (knight-4))
(define l5 (knight-5))
(define l6 (knight-6))
(define l7 (knight-7))
(define l8 (knight-8))
(define l9 (knight-9))
(define l10 (knight-10))
(define l11 (knight-11))
(define l12 (knight-12))
(define l13 (knight-13))
(define l14 (knight-14))
(define l15 (knight-15))
(define l16 (knight-16))
(define l17 (knight-17))
(define l18 (knight-18))
(define l19 (knight-19))
(define l20 (knight-20))

; Some units expend fewer ACP when they attack.
(define atk1 (l1 l2 l3 l4 l5 l6))
(define atk2 (l7 l8 l9 l10 l11 l12))
(define atk3 (l13 l14 l15 l16 l17 l18 l19 l20))

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

(add fighters acp-per-turn 4)
(add monsters acp-per-turn 4)

(add fighters acp-min -3)
(add monsters acp-min -3)

(add cities speed 0)
(add cities advanced true)
(add cities acp-independent true)

(add settler possible-sides '(not "independent"))

;;; INITIAL SETUP

(set country-radius-min 20)

(add u* start-with 0)
(add thorp start-with 3)
(add knight-1 start-with 5)

(table favored-terrain
  (u* t* 0)		; Do NOT just lay them out at random!
  (u* plain 100)	; Plains are preferred above all else!
)

(table independent-density
  (thorp (plain steppe forest semi-desert) (100 75 75 50))
)

(add t* capacity 32)

(table unit-size-in-terrain
  (u* t* 1)
  (cities t* 29)
)

(add cities capacity 32)

(table unit-size-as-occupant
  (u* cities 1)
  (cities cities 99)
)

(table occupant-multiply-production
  (granary food 150)
  (mine ores 150)
)

;;; MOTION

(table mp-to-enter-terrain
  (u* land 1)
  (u* water 99)
  (cities t* 99)
)

;;; MATERIALS

(table unit-storage-x
  (cities m* 9999)
)

(table terrain-production
	(t* m* 0)
	((desert semi-desert) ores 1)
	((steppe plain) ores 2)
	((forest mountain) ores 3)
	((sea lake semi-desert) food 1)
	((steppe forest) food 2)
	((plain) food 3)
)

(table unit-consumption-per-size
	(cities food 1)
)

(table unit-consumption-to-grow
	(cities food 25)	;; Is this too high?
)

(table material-to-build
	(u* ores 1)
	(cities ores 0)
)

(table unit-consumption-per-cp
	(u* ores 1)
	(cities ores 0)
)

;;; CONSTRUCTION

(table acp-to-create
  (u* u* 0)
  (cities settler 1)
  (cities facilities 1)
  (settler thorp 4)

  (cities knight-1 1)
  ((hamlet village small-town large-town small-city large-city metropolis) knight-2 1)
  ((village small-town large-town small-city large-city metropolis) knight-3 1)
  ((small-town large-town small-city large-city metropolis) knight-4 1)
  ((large-town small-city large-city metropolis) knight-5 1)
  ((small-city large-city metropolis) knight-6 1)
  ((large-city metropolis) knight-7 1)
  (metropolis knight-8 1)
)

(table acp-to-build
  (u* u* 0)
  (cities settler 1)
  (cities facilities 1)
  (settler thorp 4)

  (cities knight-1 1)
  ((hamlet village small-town large-town small-city large-city metropolis) knight-2 1)
  ((village small-town large-town small-city large-city metropolis) knight-3 1)
  ((small-town large-town small-city large-city metropolis) knight-4 1)
  ((large-town small-city large-city metropolis) knight-5 1)
  ((small-city large-city metropolis) knight-6 1)
  ((large-city metropolis) knight-7 1)
  (metropolis knight-8 1)
)

(table hp-to-garrison
  ; The settler disappears after building a thorp.
  (settler thorp 4)
)

;;; COMBAT

(table acp-to-attack
  #| This doesn't seem to work!
  (fighters u* 4)
  (monsters u* 4)

  (atk1 u* 4)
  (atk2 u* 2)
  (atk3 u* 1)
  |#

  (u* u* 4)
)

(table acp-to-defend
  (u* u* 3)	;; It's possible, but difficult, to make a fighting retreat.
)

(table hit-chance
  ; The general idea is that you have a 50% chance to hit an opponent of your
  ; level.  For every level you are higher, your chance increases by 5%.  For
  ; every level you are lower, your chance decreases by 5%.  However, there is
  ; always a 1% chance to hit any opponent and a 1% chance to miss any opponent.
  ; This could be represented FAR more easily with equations!
  #| This doesn't seem to work!

	;                   1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20
	;                 --------------------------------------------------------------
	(knight-1  levels (50 45 40 35 30 25 20 15 10  9 8  7   6  5  4  3  2  1  1  1))
	(knight-2  levels (55 50 45 40 35 30 25 20 15 10 9  8   7  6  5  4  3  2  1  1))
	(knight-3  levels (60 55 50 45 40 35 30 25 20 15 10 9   8  7  6  5  4  3  2  1))
	(knight-4  levels (65 60 55 50 45 40 35 30 25 20 15 10  9  8  7  6  5  4  3  2))
	(knight-5  levels (70 65 60 55 50 45 40 35 30 25 20 15 10  9  8  7  6  5  4  3))
	(knight-6  levels (75 70 65 60 55 50 45 40 35 30 25 20 15 10  9  8  7  6  5  4))
	(knight-7  levels (80 75 70 65 60 55 50 45 40 35 30 25 20 15 10  9  8  7  6  5))
	(knight-8  levels (85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10  9  8  7  6))
	(knight-9  levels (90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10  9  8  7))
	(knight-10 levels (91 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10  9  8))
	(knight-11 levels (92 91 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10  9))
	(knight-12 levels (93 92 91 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15 10))
	(knight-13 levels (94 93 92 91 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 15))
	(knight-14 levels (95 94 93 92 91 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20))
	(knight-15 levels (96 95 94 93 92 91 90 85 80 75 70 65 60 55 50 45 40 35 30 25))
	(knight-16 levels (97 96 95 94 93 92 91 90 85 80 75 70 65 60 55 50 45 40 35 30))
	(knight-17 levels (98 97 96 95 94 93 92 91 90 85 80 75 70 65 60 55 50 45 40 35))
	(knight-18 levels (99 98 97 96 95 94 93 92 91 90 85 80 75 70 65 60 55 50 45 40))
	(knight-19 levels (99 99 98 97 96 95 94 93 92 91 90 85 80 75 70 65 60 55 50 45))
	(knight-20 levels (99 99 99 98 97 96 95 94 93 92 91 90 85 80 75 70 65 60 55 50))
  |#

  (u* u* 50)

  (l1  l1  50)
  (l1  l2  45)
  (l1  l3  40)
  (l1  l4  35)
  (l1  l5  30)
  (l1  l6  25)
  (l1  l7  20)
  (l1  l8  15)
  (l1  l9  10)
  (l1  l10  9)
  (l1  l11  8)
  (l1  l12  7)
  (l1  l13  6)
  (l1  l14  5)
  (l1  l15  4)
  (l1  l16  3)
  (l1  l17  2)
  (l1  l18  1)
  (l1  l19  1)
  (l1  l20  1)

  (l2  l1  55)
  (l2  l2  50)
  (l2  l3  45)
  (l2  l4  40)
  (l2  l5  35)
  (l2  l6  30)
  (l2  l7  25)
  (l2  l8  20)
  (l2  l9  15)
  (l2  l10 10)
  (l2  l11  9)
  (l2  l12  8)
  (l2  l13  7)
  (l2  l14  6)
  (l2  l15  5)
  (l2  l16  4)
  (l2  l17  3)
  (l2  l18  2)
  (l2  l19  1)
  (l2  l20  1)

  (l3  l1  60)
  (l3  l2  55)
  (l3  l3  50)
  (l3  l4  45)
  (l3  l5  40)
  (l3  l6  35)
  (l3  l7  30)
  (l3  l8  25)
  (l3  l9  20)
  (l3  l10 15)
  (l3  l11 10)
  (l3  l12  9)
  (l3  l13  8)
  (l3  l14  7)
  (l3  l15  6)
  (l3  l16  5)
  (l3  l17  4)
  (l3  l18  3)
  (l3  l19  2)
  (l3  l20  1)

  (l4  l1  65)
  (l4  l2  60)
  (l4  l3  55)
  (l4  l4  50)
  (l4  l5  45)
  (l4  l6  40)
  (l4  l7  35)
  (l4  l8  30)
  (l4  l9  25)
  (l4  l10 20)
  (l4  l11 15)
  (l4  l12 10)
  (l4  l13  9)
  (l4  l14  8)
  (l4  l15  7)
  (l4  l16  6)
  (l4  l17  5)
  (l4  l18  4)
  (l4  l19  3)
  (l4  l20  2)

  (l5  l1  70)
  (l5  l2  65)
  (l5  l3  60)
  (l5  l4  55)
  (l5  l5  50)
  (l5  l6  45)
  (l5  l7  40)
  (l5  l8  35)
  (l5  l9  30)
  (l5  l10 25)
  (l5  l11 20)
  (l5  l12 15)
  (l5  l13 10)
  (l5  l14  9)
  (l5  l15  8)
  (l5  l16  7)
  (l5  l17  6)
  (l5  l18  5)
  (l5  l19  4)
  (l5  l20  3)

  (l6  l1  75)
  (l6  l2  70)
  (l6  l3  65)
  (l6  l4  60)
  (l6  l5  55)
  (l6  l6  50)
  (l6  l7  45)
  (l6  l8  40)
  (l6  l9  35)
  (l6  l10 30)
  (l6  l11 25)
  (l6  l12 20)
  (l6  l13 15)
  (l6  l14 10)
  (l6  l15  9)
  (l6  l16  8)
  (l6  l17  7)
  (l6  l18  6)
  (l6  l19  5)
  (l6  l20  4)

  (l7  l1  80)
  (l7  l2  75)
  (l7  l3  70)
  (l7  l4  65)
  (l7  l5  60)
  (l7  l6  55)
  (l7  l7  50)
  (l7  l8  45)
  (l7  l9  40)
  (l7  l10 35)
  (l7  l11 30)
  (l7  l12 25)
  (l7  l13 20)
  (l7  l14 15)
  (l7  l15 10)
  (l7  l16  9)
  (l7  l17  8)
  (l7  l18  7)
  (l7  l19  6)
  (l7  l20  5)

  (l8  l1  85)
  (l8  l2  80)
  (l8  l3  75)
  (l8  l4  70)
  (l8  l5  65)
  (l8  l6  60)
  (l8  l7  55)
  (l8  l8  50)
  (l8  l9  45)
  (l8  l10 40)
  (l8  l11 35)
  (l8  l12 30)
  (l8  l13 25)
  (l8  l14 20)
  (l8  l15 15)
  (l8  l16 10)
  (l8  l17  9)
  (l8  l18  8)
  (l8  l19  7)
  (l8  l20  6)

  (l9  l1  90)
  (l9  l2  85)
  (l9  l3  80)
  (l9  l4  75)
  (l9  l5  70)
  (l9  l6  65)
  (l9  l7  60)
  (l9  l8  55)
  (l9  l9  50)
  (l9  l10 45)
  (l9  l11 40)
  (l9  l12 35)
  (l9  l13 30)
  (l9  l14 25)
  (l9  l15 20)
  (l9  l16 15)
  (l9  l17 10)
  (l9  l18  9)
  (l9  l19  8)
  (l9  l20  7)

  (l10 l1  91)
  (l10 l2  90)
  (l10 l3  85)
  (l10 l4  80)
  (l10 l5  75)
  (l10 l6  70)
  (l10 l7  65)
  (l10 l8  60)
  (l10 l9  55)
  (l10 l10 50)
  (l10 l11 45)
  (l10 l12 40)
  (l10 l13 35)
  (l10 l14 30)
  (l10 l15 25)
  (l10 l16 20)
  (l10 l17 15)
  (l10 l18 10)
  (l10 l19  9)
  (l10 l20  8)

  (l11 l1  92)
  (l11 l2  91)
  (l11 l3  90)
  (l11 l4  85)
  (l11 l5  80)
  (l11 l6  75)
  (l11 l7  70)
  (l11 l8  65)
  (l11 l9  60)
  (l11 l10 55)
  (l11 l11 50)
  (l11 l12 45)
  (l11 l13 40)
  (l11 l14 35)
  (l11 l15 30)
  (l11 l16 25)
  (l11 l17 20)
  (l11 l18 15)
  (l11 l19 10)
  (l11 l20  9)

  (l12 l1  93)
  (l12 l2  92)
  (l12 l3  91)
  (l12 l4  90)
  (l12 l5  85)
  (l12 l6  80)
  (l12 l7  75)
  (l12 l8  70)
  (l12 l9  65)
  (l12 l10 60)
  (l12 l11 55)
  (l12 l12 50)
  (l12 l13 45)
  (l12 l14 40)
  (l12 l15 35)
  (l12 l16 30)
  (l12 l17 25)
  (l12 l18 20)
  (l12 l19 15)
  (l12 l20 10)

  (l13 l1  94)
  (l13 l2  93)
  (l13 l3  92)
  (l13 l4  91)
  (l13 l5  90)
  (l13 l6  85)
  (l13 l7  80)
  (l13 l8  75)
  (l13 l9  70)
  (l13 l10 65)
  (l13 l11 60)
  (l13 l12 55)
  (l13 l13 50)
  (l13 l14 45)
  (l13 l15 40)
  (l13 l16 35)
  (l13 l17 30)
  (l13 l18 25)
  (l13 l19 20)
  (l13 l20 15)

  (l14 l1  95)
  (l14 l2  94)
  (l14 l3  93)
  (l14 l4  92)
  (l14 l5  91)
  (l14 l6  90)
  (l14 l7  85)
  (l14 l8  80)
  (l14 l9  75)
  (l14 l10 70)
  (l14 l11 65)
  (l14 l12 60)
  (l14 l13 55)
  (l14 l14 50)
  (l14 l15 45)
  (l14 l16 40)
  (l14 l17 35)
  (l14 l18 30)
  (l14 l19 25)
  (l14 l20 20)

  (l15 l1  96)
  (l15 l2  95)
  (l15 l3  94)
  (l15 l4  93)
  (l15 l5  92)
  (l15 l6  91)
  (l15 l7  90)
  (l15 l8  85)
  (l15 l9  80)
  (l15 l10 75)
  (l15 l11 70)
  (l15 l12 65)
  (l15 l13 60)
  (l15 l14 55)
  (l15 l15 50)
  (l15 l16 45)
  (l15 l17 40)
  (l15 l18 35)
  (l15 l19 30)
  (l15 l20 25)

  (l16 l1  97)
  (l16 l2  96)
  (l16 l3  95)
  (l16 l4  94)
  (l16 l5  93)
  (l16 l6  92)
  (l16 l7  91)
  (l16 l8  90)
  (l16 l9  85)
  (l16 l10 80)
  (l16 l11 75)
  (l16 l12 70)
  (l16 l13 65)
  (l16 l14 60)
  (l16 l15 55)
  (l16 l16 50)
  (l16 l17 45)
  (l16 l18 40)
  (l16 l19 35)
  (l16 l20 30)

  (l17 l1  98)
  (l17 l2  97)
  (l17 l3  96)
  (l17 l4  95)
  (l17 l5  94)
  (l17 l6  93)
  (l17 l7  92)
  (l17 l8  91)
  (l17 l9  90)
  (l17 l10 85)
  (l17 l11 80)
  (l17 l12 75)
  (l17 l13 70)
  (l17 l14 65)
  (l17 l15 60)
  (l17 l16 55)
  (l17 l17 50)
  (l17 l18 45)
  (l17 l19 40)
  (l17 l20 35)

  (l18 l1  99)
  (l18 l2  98)
  (l18 l3  97)
  (l18 l4  96)
  (l18 l5  95)
  (l18 l6  94)
  (l18 l7  93)
  (l18 l8  92)
  (l18 l9  91)
  (l18 l10 90)
  (l18 l11 85)
  (l18 l12 80)
  (l18 l13 75)
  (l18 l14 70)
  (l18 l15 65)
  (l18 l16 60)
  (l18 l17 55)
  (l18 l18 50)
  (l18 l19 45)
  (l18 l20 40)

  (l19 l1  99)
  (l19 l2  99)
  (l19 l3  98)
  (l19 l4  97)
  (l19 l5  96)
  (l19 l6  95)
  (l19 l7  94)
  (l19 l8  93)
  (l19 l9  92)
  (l19 l10 91)
  (l19 l11 90)
  (l19 l12 85)
  (l19 l13 80)
  (l19 l14 75)
  (l19 l15 70)
  (l19 l16 65)
  (l19 l17 60)
  (l19 l18 55)
  (l19 l19 50)
  (l19 l20 45)

  (l20 l1  99)
  (l20 l2  99)
  (l20 l3  99)
  (l20 l4  98)
  (l20 l5  97)
  (l20 l6  96)
  (l20 l7  95)
  (l20 l8  94)
  (l20 l9  93)
  (l20 l10 92)
  (l20 l11 91)
  (l20 l12 90)
  (l20 l13 85)
  (l20 l14 80)
  (l20 l15 75)
  (l20 l16 70)
  (l20 l17 65)
  (l20 l18 60)
  (l20 l19 55)
  (l20 l20 50)

  ;; Stationary targets are automatically hit, since they cannot dodge.
  (u* cities 100)

)

(table damage
  ; The general idea is that a guy with a sword deals 2d4 damage, +1 per level.
  ; There could certainly be exceptions with monsters.

  (u* u* 1d6)	; This is a default more than anything else.

  (l1  u* 2d4+1)
  (l2  u* 2d4+2)
  (l3  u* 2d4+3)
  (l4  u* 2d4+4)
  (l5  u* 2d4+5)
  (l6  u* 2d4+6)
  (l7  u* 2d4+7)
  (l8  u* 2d4+8)
  (l9  u* 2d4+9)
  (l10 u* 2d4+10)
  (l11 u* 2d4+11)
  (l12 u* 2d4+12)
  (l13 u* 2d4+13)
  (l14 u* 2d4+14)
  (l15 u* 2d4+15)
  (l16 u* 2d4+16)
  (l17 u* 2d4+17)
  (l18 u* 2d4+18)
  (l19 u* 2d4+19)
  (l20 u* 2d4+20)
)

(table capture-chance
  ; Generally, higher-level units have a better chance of capturing a place, but
  ; bigger places are harder to capture.

  ;            thorp  hamlet  village  small-town  large-town  small-city  large-city  metropolis
  ; (l1  cities (   10       9        8           7           6           5           4           3))

  (fighters cities 100)		; If the city has no defenders, it falls quickly!
)

(table protection
  ; A city cannot be captured while it has armed defenders.
  ; Furthermore, the city allows the defenders to fortify themselves!

  (fighters cities 0.00)
  (cities fighters 0.60)
)

;;; REPAIR

(table auto-repair
  (thorp u* 1.00)
  (hamlet u* 2.00)
  (village u* 3.00)
  (small-town u* 4.00)
  (large-town u* 5.00)
  (small-city u* 6.00)
  (large-city u* 7.00)
  (metropolis u* 8.00)
)

;;; COMBAT EXPERIENCE

; This game is unusual in that when units meet certain requirements, they are
; automatically transformed into units of the next higher level.  At the time
; it was initially written, no other Xconq game supported this.
; (Note that, although bolodd3.g was the first in the game library to use
; change-type, this game was written first.)

(add thorp auto-upgrade-to hamlet)
(add hamlet auto-upgrade-to village)
(add village auto-upgrade-to small-town)
(add small-town auto-upgrade-to large-town)
(add large-town auto-upgrade-to small-city)
(add small-city auto-upgrade-to large-city)
(add large-city auto-upgrade-to metropolis)

(add knight-1 auto-upgrade-to knight-2)
(add knight-2 auto-upgrade-to knight-3)
(add knight-3 auto-upgrade-to knight-4)
(add knight-4 auto-upgrade-to knight-5)
(add knight-5 auto-upgrade-to knight-6)
(add knight-6 auto-upgrade-to knight-7)
(add knight-7 auto-upgrade-to knight-8)
(add knight-8 auto-upgrade-to knight-9)
(add knight-9 auto-upgrade-to knight-10)
(add knight-10 auto-upgrade-to knight-11)
(add knight-11 auto-upgrade-to knight-12)
(add knight-12 auto-upgrade-to knight-13)
(add knight-13 auto-upgrade-to knight-14)
(add knight-14 auto-upgrade-to knight-15)
(add knight-15 auto-upgrade-to knight-16)
(add knight-16 auto-upgrade-to knight-17)
(add knight-17 auto-upgrade-to knight-18)
(add knight-18 auto-upgrade-to knight-19)
(add knight-19 auto-upgrade-to knight-20)

; Knights gain levels by earning CXP.
; Places gain levels by growth.

(table size-to-change-type
  ; This provides more tangible benefits for larger cities!
  (thorp hamlet 4)
  (hamlet village 8)
  (village small-town 16)
  (small-town large-town 32)
  (large-town small-city 64)
  (small-city large-city 128)
  (large-city metropolis 256)
)

(add fighters cxp-max 30000)

(table cxp-per-combat
  ; This may need a lot of playtesting, to see what value promotes the proper
  ; rate of experience gain.
  (fighters u* 10)
)

(table cxp-to-change-type
  (knight-1  knight-2    100)
  (knight-2  knight-3    300)
  (knight-3  knight-4    600)
  (knight-4  knight-5   1000)
  (knight-5  knight-6   1500)
  (knight-6  knight-7   2100)
  (knight-7  knight-8   2800)
  (knight-8  knight-9   3600)
  (knight-9  knight-10  4500)
  (knight-10 knight-11  5500)
  (knight-11 knight-12  6600)
  (knight-12 knight-13  7800)
  (knight-13 knight-14  9100)
  (knight-14 knight-15 10500)
  (knight-15 knight-16 12000)
  (knight-16 knight-17 13600)
  (knight-17 knight-18 15300)
  (knight-18 knight-19 17100)
  (knight-19 knight-20 19000)
)

;;; VISION

(add u* vision-range 4)
(add cities vision-range 8)
(add u* vision-bend 0)


(add u* initial-seen-radius 12)

(add cities see-always true)

;;; MISCELLANEOUS

(add u* namer "generic-names")

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-28 17:44 A more sophisticated demonstration of change-type Lincoln Peters
@ 2004-05-29  2:28 ` Eric McDonald
  2004-05-29  6:02   ` Lincoln Peters
  0 siblings, 1 reply; 16+ messages in thread
From: Eric McDonald @ 2004-05-29  2:28 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29  2:28 ` Eric McDonald
@ 2004-05-29  6:02   ` Lincoln Peters
  2004-05-29 15:41     ` Eric McDonald
  2004-05-29 17:17     ` Eric McDonald
  0 siblings, 2 replies; 16+ messages in thread
From: Lincoln Peters @ 2004-05-29  6:02 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Fri, 2004-05-28 at 19:25, Eric McDonald 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 think I get it.

> 
> > 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'.

Yes, that is what I meant (although I don't think that any other games
use change-type correctly; space-civ.g might work but I haven't tested
it since change-type was made to work at all).

> 
> > 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.

It's just a fortune, as per the popular UNIX application.
It might seem a little spooky that it related to the message at all, at
least until you look at the fortune attached to the bottom of *this*
message.

---
Lincoln Peters
<sampln@sbcglobal.net>

Humor in the Court:
Q: Are you qualified to give a urine sample?
A: Yes, I have been since early childhood.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29  6:02   ` Lincoln Peters
@ 2004-05-29 15:41     ` Eric McDonald
  2004-05-29 17:17     ` Eric McDonald
  1 sibling, 0 replies; 16+ messages in thread
From: Eric McDonald @ 2004-05-29 15:41 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sat, 2004-05-29 at 00:03, Lincoln Peters wrote:

> > 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 think I get it.

You could probably still use the compact table format, but you would
need to restructure your definitions slightly and you would end up with
4 such tables instead of 1. Fortunately, you could just copy-n-paste,
and then edit a single column in each one.

(define l1k knight-1)
(define l1m goblin)
...
(define knight-levels (l1k ... l20k))
(define monster-levels (l1m ... l20m))
(table hit-chance
  ; Knight vs. Knight
  (knight-1 knight-levels (50 ...))
  (knight-2 knight-levels (55 50 ...))
  ...
  ; Knight vs. Monster
  (knight-1 monster-levels (50 ...))
  ...
  ; Monster vs. Knight
  (monster-1 knight-levels (50 ...))
  ...
  ; Monster vs. Monster
  (monster-1 monster-levels (50 ...))
)

This would also give you more flexibility if a monster had a special
attack (firing, exploding, etc...) rather than a conventional attack,
because then you could 0 out its row without worrying about other units
at its level which still might want to perform conventional attacks.

> > > 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.
> 
> It's just a fortune, as per the popular UNIX application.
> It might seem a little spooky that it related to the message at all, at
> least until you look at the fortune attached to the bottom of *this*
> message.

Sure, sure. I understand that. You have been appending them to your
messages for a while now. I didn't really think it was related to the
message in any way; I was just having a little fun with it. That's all.

Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29  6:02   ` Lincoln Peters
  2004-05-29 15:41     ` Eric McDonald
@ 2004-05-29 17:17     ` Eric McDonald
  2004-05-29 18:38       ` Lincoln Peters
  2004-06-07  2:26       ` Lincoln Peters
  1 sibling, 2 replies; 16+ messages in thread
From: Eric McDonald @ 2004-05-29 17:17 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sat, 2004-05-29 at 00:03, Lincoln Peters wrote:
> > (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 think I get it.

It turns out that the 'acp-to-attack' problem you were seeing is related
to this. The 'atk1', 'atk2', etc. are also lists of lists; i.e., 'atk1'
expands to:
  ((knight-1) (knight-2) ... (knight-6))
instead of:
  (knight-1 knight-2 ... knight-6)
Placing an 'append' in the definition solves the problem:
  (define atk1 (append l1 l2 l3 l4 l5 l6))

Other notes:
  I played the game for a while last night. I think it has a lot of
potential, and I already found it to be rather enjoyable, in spite of
its early stage of development. It seems that 'knight-1' units are
becoming 'knight-2' units at about the right rate. However, I am not
sure that 'knight-2' units are becoming 'knight-3' units fast enough. Of
course, I didn't actually encounter the enemy, so I didn't have a chance
to engage other 'knight-2' units, but laying siege to independent
'thorps' with gangs of knights was (a) fun, and (b) not rewarding enough
in terms of advancement to ranks higher than 'knight-2'. Maybe the
transition from 'thorp' to 'hamlet' could be accelerated so that the
independent 'hamlets' would appear and produce opposing 'knight-2' units
sooner. I think this would also make the game a little more entertaining
in its early stages; people might feel more compelled to play if the
earlier advances happen more rapidly before they become distracted by
more fulfilling aspects of game play such as slaughter, carnage, and
wrecking mayhem on an active opponent.

Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29 17:17     ` Eric McDonald
@ 2004-05-29 18:38       ` Lincoln Peters
  2004-05-29 18:58         ` Eric McDonald
  2004-05-29 22:01         ` Eric McDonald
  2004-06-07  2:26       ` Lincoln Peters
  1 sibling, 2 replies; 16+ messages in thread
From: Lincoln Peters @ 2004-05-29 18:38 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Sat, 2004-05-29 at 10:14, Eric McDonald wrote:
> It turns out that the 'acp-to-attack' problem you were seeing is related
> to this. The 'atk1', 'atk2', etc. are also lists of lists; i.e., 'atk1'
> expands to:
>   ((knight-1) (knight-2) ... (knight-6))
> instead of:
>   (knight-1 knight-2 ... knight-6)
> Placing an 'append' in the definition solves the problem:
>   (define atk1 (append l1 l2 l3 l4 l5 l6))

Thanks, I'll do that.

> 
> Other notes:
>   I played the game for a while last night. I think it has a lot of
> potential, and I already found it to be rather enjoyable, in spite of
> its early stage of development. It seems that 'knight-1' units are
> becoming 'knight-2' units at about the right rate. However, I am not
> sure that 'knight-2' units are becoming 'knight-3' units fast enough. Of
> course, I didn't actually encounter the enemy, so I didn't have a chance
> to engage other 'knight-2' units, but laying siege to independent
> 'thorps' with gangs of knights was (a) fun, and (b) not rewarding enough
> in terms of advancement to ranks higher than 'knight-2'. Maybe the
> transition from 'thorp' to 'hamlet' could be accelerated so that the
> independent 'hamlets' would appear and produce opposing 'knight-2' units
> sooner. I think this would also make the game a little more entertaining
> in its early stages; people might feel more compelled to play if the
> earlier advances happen more rapidly before they become distracted by
> more fulfilling aspects of game play such as slaughter, carnage, and
> wrecking mayhem on an active opponent.

I've noticed the same things during testing.  I might re-do the level
advancement so that less CXP's are needed to advance (or more CXP's are
gained after each combat round), or (less likely) I might make it so
that the CXP's earned depend on what you're fighting (the more powerful
the opponent, the more CXP's earned).  I may also change the growth
threshold for city types from 25 to 10.

One thing that I suspect could make it more playable is semi-automatic
AI control; some kind of mechanism by which I could easily give a task
to a group of units, for example "Capture the independent thorp at
x,y".  Especially when you consider the number of units you could be
dealing with before the end.  On the other hand, I doubt that any such
mechanism will be implemented when so many bugs are left to squash.

I also noticed that the knight-8 through knight-20 units don't show up
in the list, even though I could conceivably acquire them by making a
knight earn enough CXP's.  On the other hand, all of the city types
appear on the list.

---
Lincoln Peters
<sampln@sbcglobal.net>

Make sure your code does nothing gracefully.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29 18:38       ` Lincoln Peters
@ 2004-05-29 18:58         ` Eric McDonald
  2004-05-29 22:01         ` Eric McDonald
  1 sibling, 0 replies; 16+ messages in thread
From: Eric McDonald @ 2004-05-29 18:58 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sat, 2004-05-29 at 12:39, Lincoln Peters wrote:

> One thing that I suspect could make it more playable is semi-automatic
> AI control; some kind of mechanism by which I could easily give a task
> to a group of units, for example "Capture the independent thorp at
> x,y".  Especially when you consider the number of units you could be
> dealing with before the end.

Yes, that would be nice. I was using the "Set Formation" command last
night, so that I could lead different gangs of knights around to the
various targets just by moving one piece. That helped quite a bit.

I noticed that the "Set Formation" command didn't have its key binding
('F') listed in the Tcl/Tk interface, and so I added that this morning.
Then, I decided to play around with using prefix arguments to set
relative distance to the leader, and that is presently what I am working
on. Both relative position and relative distance must be maintained as
much as possible, shrinking the relative position when it is beyond the
relative distance.

The way things have worked up until now is that the relative distance
was set to 1 no matter what.

> I also noticed that the knight-8 through knight-20 units don't show up
> in the list, even though I could conceivably acquire them by making a
> knight earn enough CXP's.  On the other hand, all of the city types
> appear on the list.

Oh right. I noticed that too. I will look into it. I suspect that
'can-change-type-to' is being checked to see if the 'auto-upgrade-to' is
valid, and it shouldn't be checking that.

Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29 18:38       ` Lincoln Peters
  2004-05-29 18:58         ` Eric McDonald
@ 2004-05-29 22:01         ` Eric McDonald
  1 sibling, 0 replies; 16+ messages in thread
From: Eric McDonald @ 2004-05-29 22:01 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sat, 2004-05-29 at 12:39, Lincoln Peters wrote:

> I also noticed that the knight-8 through knight-20 units don't show up
> in the list,

They do now.

Eric


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-05-29 17:17     ` Eric McDonald
  2004-05-29 18:38       ` Lincoln Peters
@ 2004-06-07  2:26       ` Lincoln Peters
  2004-06-07  2:40         ` Eric McDonald
  1 sibling, 1 reply; 16+ messages in thread
From: Lincoln Peters @ 2004-06-07  2:26 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Sat, 2004-05-29 at 10:14, Eric McDonald wrote:
> It turns out that the 'acp-to-attack' problem you were seeing is related
> to this. The 'atk1', 'atk2', etc. are also lists of lists; i.e., 'atk1'
> expands to:
>   ((knight-1) (knight-2) ... (knight-6))
> instead of:
>   (knight-1 knight-2 ... knight-6)
> Placing an 'append' in the definition solves the problem:
>   (define atk1 (append l1 l2 l3 l4 l5 l6))

That did seem to work initially, but I've been elaborating on the game,
and seem to have run into an even more complex problem.  Consider the
following (admittedly *really* long) snippet of code from the new
version:

(unit-type blue-wyrmling
  (hp-max 30) (cp 14))
  
(unit-type very-young-blue-dragon
  (hp-max 40) (cp 16))
  
(unit-type young-blue-dragon
  (hp-max 60) (cp 20))
  
(unit-type juvenile-blue-dragon
  (hp-max 80) (cp 24))
  
(unit-type young-adult-blue-dragon
  (hp-max 110) (cp 30))
  
(unit-type adult-blue-dragon
  (hp-max 140) (cp 36))
  
(unit-type mature-adult-blue-dragon
  (hp-max 160) (cp 40))
  
(unit-type old-blue-dragon
  (hp-max 180) (cp 44))
  
(unit-type very-old-blue-dragon
  (hp-max 190) (cp 46))
  
(unit-type ancient-blue-dragon
  (hp-max 210) (cp 50))
  
(unit-type blue-wyrm
  (hp-max 230) (cp 54))
  
(unit-type great-blue-wyrm
  (hp-max 250) (cp 58))
  
(define blue-dragons (append blue-wyrmling very-young-blue-dragon young-blue-dragon juvenile-blue-dragon young-adult-blue-dragon adult-blue-dragon mature-adult-blue-dragon old-blue-dragon very-old-blue-dragon ancient-blue-dragon blue-wyrm great-blue-wyrm))

(add blue-dragons image-name "monsters-blue-dragon")
(add blue-dragons help "Vain, territorial dragon")

(unit-type copper-wyrmling
  (hp-max 30) (cp 14))
  
(unit-type very-young-copper-dragon
  (hp-max 50) (cp 18))
  
(unit-type young-copper-dragon
  (hp-max 70) (cp 22))
  
(unit-type juvenile-copper-dragon
  (hp-max 90) (cp 26))
  
(unit-type young-adult-copper-dragon
  (hp-max 110) (cp 30))
  
(unit-type adult-copper-dragon
  (hp-max 140) (cp 36))
  
(unit-type mature-adult-copper-dragon
  (hp-max 160) (cp 40))
  
(unit-type old-copper-dragon
  (hp-max 190) (cp 46))
  
(unit-type very-old-copper-dragon
  (hp-max 200) (cp 48))
  
(unit-type ancient-copper-dragon
  (hp-max 220) (cp 52))
  
(unit-type copper-wyrm
  (hp-max 230) (cp 54))
  
(unit-type great-copper-wyrm
  (hp-max 250) (cp 58))
  
(define copper-dragons (append copper-wyrmling very-young-copper-dragon young-copper-dragon juvenile-copper-dragon young-adult-copper-dragon adult-copper-dragon mature-adult-copper-dragon old-copper-dragon very-old-copper-dragon ancient-copper-dragon copper-wyrm great-copper-wyrm))

(add copper-dragons image-name "monsters-green-dragon")
(add copper-dragons help "Witty, prankster dragon")

(unit-type gold-wyrmling
  (hp-max 50) (cp 18))
  
(unit-type very-young-gold-dragon
  (hp-max 70) (cp 22))
  
(unit-type young-gold-dragon
  (hp-max 90) (cp 26))
  
(unit-type juvenile-gold-dragon
  (hp-max 110) (cp 30))
  
(unit-type young-adult-gold-dragon
  (hp-max 140) (cp 36))
  
(unit-type adult-gold-dragon
  (hp-max 160) (cp 40))
  
(unit-type mature-adult-gold-dragon
  (hp-max 190) (cp 46))
  
(unit-type old-gold-dragon
  (hp-max 210) (cp 50))
  
(unit-type very-old-gold-dragon
  (hp-max 220) (cp 52))
  
(unit-type ancient-gold-dragon
  (hp-max 240) (cp 56))
  
(unit-type gold-wyrm
  (hp-max 250) (cp 58))
  
(unit-type great-gold-wyrm
  (hp-max 270) (cp 62))
  
(define gold-dragons (append gold-wyrmling very-young-gold-dragon young-gold-dragon juvenile-gold-dragon young-adult-gold-dragon adult-gold-dragon mature-adult-gold-dragon old-gold-dragon very-old-gold-dragon ancient-gold-dragon gold-wyrm great-gold-wyrm))

(add gold-dragons image-name "monsters-pterodactyl")
(add gold-dragons help "Graceful, wise dragon")

(unit-type red-wyrmling
  (hp-max 40) (cp 16))
  
(unit-type very-young-red-dragon
  (hp-max 50) (cp 18))
  
(unit-type young-red-dragon
  (hp-max 70) (cp 22))
  
(unit-type juvenile-red-dragon
  (hp-max 100) (cp 28))
  
(unit-type young-adult-red-dragon
  (hp-max 130) (cp 34))
  
(unit-type adult-red-dragon
  (hp-max 150) (cp 38))
  
(unit-type mature-adult-red-dragon
  (hp-max 180) (cp 44))
  
(unit-type old-red-dragon
  (hp-max 200) (cp 48))
  
(unit-type very-old-red-dragon
  (hp-max 210) (cp 50))
  
(unit-type ancient-red-dragon
  (hp-max 230) (cp 54))
  
(unit-type red-wyrm
  (hp-max 240) (cp 56))
  
(unit-type great-red-wyrm
  (hp-max 260) (cp 60))
  
(define red-dragons (append red-wyrmling very-young-red-dragon young-red-dragon juvenile-red-dragon young-adult-red-dragon adult-red-dragon mature-adult-red-dragon old-red-dragon very-old-red-dragon ancient-red-dragon red-wyrm great-red-wyrm))

(add red-dragons image-name "red-dragon")
(add red-dragons notes "Covetous, greedy dragon")

; Dragon-kin

(unit-type dragon-turtle (image-name "beetle")
  (hp-max 90) (cp 26)
  (help "Aquatic dragon"))

(unit-type wyvern (image-name "monsters-small-dragon")
  (hp-max 60) (cp 20)
  (help "More primitive dragon-kin"))
  
(define true-dragons (append blue-dragons))
(define true-dragons (append copper-dragons))
(define true-dragons (append gold-dragons))
(define true-dragons (append red-dragons))

(define wyrmlings (blue-wyrmling copper-wyrmling gold-wyrmling red-wyrmling))
(define very-young-dragons (very-young-blue-dragon very-young-copper-dragon very-young-gold-dragon very-young-red-dragon))
(define young-dragons (young-blue-dragon young-copper-dragon young-gold-dragon young-red-dragon))
(define juvenile-dragons (juvenile-blue-dragon juvenile-copper-dragon juvenile-gold-dragon juvenile-red-dragon))
(define young-adult-dragons (young-adult-blue-dragon young-adult-copper-dragon young-adult-gold-dragon young-adult-red-dragon))
(define adult-dragons (adult-blue-dragon adult-copper-dragon adult-gold-dragon adult-red-dragon))
(define mature-adult-dragons (mature-adult-blue-dragon mature-adult-copper-dragon mature-adult-gold-dragon mature-adult-red-dragon))
(define old-dragons (old-blue-dragon old-copper-dragon old-gold-dragon old-red-dragon))
(define very-old-dragons (very-old-blue-dragon very-old-copper-dragon very-old-gold-dragon very-old-red-dragon))
(define ancient-dragons (ancient-blue-dragon ancient-copper-dragon ancient-gold-dragon ancient-red-dragon))
(define wyrms (blue-wyrm copper-wyrm gold-wyrm red-wyrm))
(define great-wyrms (great-blue-wyrm great-copper-wyrm great-gold-wyrm great-red-wyrm))

(define dragons (append true-dragons))
(define dragons (append dragon-turtle wyvern))


What I want to happen is that true-dragons becomes a list of all units
found in the lists blue-dragons, copper-dragosn, gold-dragons, and
red-dragons (i.e. all dragons except for the dragon-turtle and wyvern);
rather than a list containing the lists blue-dragons, copper-dragons,
gold-dragons, and red-dragons.  However, I get the following error when
Xconq parses those lines:

Warning: knights:482-523:
Symbol `true-dragons' has been bound already, overwriting

The error becomes compounded when I try to define "dragons" as including
"true-dragons", then I try to define "monsters" as including "dragons". 
The end result is that all dragon units are totally useless.

So what the heck am I doing wrong here?  I re-examined the "Language
Syntax" section of the manual, but I still don't quite see how this is
supposed to work.

> 
> Other notes:
>   I played the game for a while last night. I think it has a lot of
> potential, and I already found it to be rather enjoyable, in spite of
> its early stage of development. It seems that 'knight-1' units are
> becoming 'knight-2' units at about the right rate. However, I am not
> sure that 'knight-2' units are becoming 'knight-3' units fast enough. Of
> course, I didn't actually encounter the enemy, so I didn't have a chance
> to engage other 'knight-2' units, but laying siege to independent
> 'thorps' with gangs of knights was (a) fun, and (b) not rewarding enough
> in terms of advancement to ranks higher than 'knight-2'. Maybe the
> transition from 'thorp' to 'hamlet' could be accelerated so that the
> independent 'hamlets' would appear and produce opposing 'knight-2' units
> sooner. I think this would also make the game a little more entertaining
> in its early stages; people might feel more compelled to play if the
> earlier advances happen more rapidly before they become distracted by
> more fulfilling aspects of game play such as slaughter, carnage, and
> wrecking mayhem on an active opponent.

Wait until you see the rest of this new version!

---
Lincoln Peters
<sampln@sbcglobal.net>

Some scholars are like donkeys, they merely carry a lot of books.
		-- Folk saying

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  2:26       ` Lincoln Peters
@ 2004-06-07  2:40         ` Eric McDonald
  2004-06-07  5:05           ` Lincoln Peters
  0 siblings, 1 reply; 16+ messages in thread
From: Eric McDonald @ 2004-06-07  2:40 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list

On Sun, 2004-06-06 at 20:26, Lincoln Peters wrote:
> On Sat, 2004-05-29 at 10:14, Eric McDonald wrote:
> > It turns out that the 'acp-to-attack' problem you were seeing is related
> > to this. The 'atk1', 'atk2', etc. are also lists of lists; i.e., 'atk1'
> > expands to:
> >   ((knight-1) (knight-2) ... (knight-6))
> > instead of:
> >   (knight-1 knight-2 ... knight-6)
> > Placing an 'append' in the definition solves the problem:
> >   (define atk1 (append l1 l2 l3 l4 l5 l6))
> 
> That did seem to work initially, but I've been elaborating on the game,
> and seem to have run into an even more complex problem.  Consider the
> following (admittedly *really* long) snippet of code from the new
> version:

[ snipped ]

> (define blue-dragons (append blue-wyrmling very-young-blue-dragon young-blue-dragon juvenile-blue-dragon young-adult-blue-dragon adult-blue-dragon mature-adult-blue-dragon old-blue-dragon very-old-blue-dragon ancient-blue-dragon blue-wyrm great-blue-wyrm))

The use of 'append' is not necessary here. You can simply define
'blue-dragons' as a list of atoms. 'append' is used to flatten a list of
lists (and possibly atoms as well) into a single list of atoms.

Likewise for the other wyrmish hues.

[ snipped ]

> (define true-dragons (append blue-dragons))
> (define true-dragons (append copper-dragons))
> (define true-dragons (append gold-dragons))
> (define true-dragons (append red-dragons))

You are trying to override your definition of 'true-dragons' 3 times.
Try this instead:
(define true-dragons (append blue-dragons copper-dragons gold-dragons
red-dragons))
That should give you the desired effect.

> (define dragons (append true-dragons))
> (define dragons (append dragon-turtle wyvern))

(define dragons (append true-dragons dragon-turtle wyvern))

should be sufficient.

> So what the heck am I doing wrong here?  

Try my suggestions above; I think they should do what you want.

> Wait until you see the rest of this new version!

Very much looking forward to it. Looks like it exceeds Bellum II in
numbers of units now. Lots of monsters to slaughter, it seems; can't
wait for the carnage to begin. Let me know when I can have a "developer
release". :-)

Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  2:40         ` Eric McDonald
@ 2004-06-07  5:05           ` Lincoln Peters
  2004-06-07  5:18             ` Elijah Meeks
  0 siblings, 1 reply; 16+ messages in thread
From: Lincoln Peters @ 2004-06-07  5:05 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Sun, 2004-06-06 at 19:37, Eric McDonald wrote:
> > (define true-dragons (append blue-dragons))
> > (define true-dragons (append copper-dragons))
> > (define true-dragons (append gold-dragons))
> > (define true-dragons (append red-dragons))
> 
> You are trying to override your definition of 'true-dragons' 3 times.
> Try this instead:
> (define true-dragons (append blue-dragons copper-dragons gold-dragons
> red-dragons))
> That should give you the desired effect.

Thanks; it works now.

> > Wait until you see the rest of this new version!
> 
> Very much looking forward to it. Looks like it exceeds Bellum II in
> numbers of units now. Lots of monsters to slaughter, it seems; can't
> wait for the carnage to begin. Let me know when I can have a "developer
> release". :-)

Current total is 116 (and rising!).  And I expect to add more once I
make sure that there is a reasonable game balance (a great gold wyrm can
pretty much end the game if the other side commands a bunch of orcs and
little else).


---
Lincoln Peters
<sampln@sbcglobal.net>

There is an old time toast which is golden for its beauty.
"When you ascend the hill of prosperity may you not meet a friend."
		-- Mark Twain

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  5:05           ` Lincoln Peters
@ 2004-06-07  5:18             ` Elijah Meeks
  2004-06-07  5:44               ` Eric McDonald
  2004-06-07  5:55               ` Lincoln Peters
  0 siblings, 2 replies; 16+ messages in thread
From: Elijah Meeks @ 2004-06-07  5:18 UTC (permalink / raw)
  To: Lincoln Peters, Eric McDonald; +Cc: Xconq list

> Current total is 116 (and rising!).  

Oh good, so I don't have to feel guilty with 800?

I mean, it's important to differentiate between a
veteran understrength 3rd generation armor group and a
crack understrength 3rd generation armor group and a
crack reinforced 3rd generation armor group and an
elite reinforced 3rd generation armor group and, and,
and...

It looks pretty good in SDL, so I assume it'll look
fine on the Mac, too, but after about a hundred units,
I have my doubts any sane player will put up with the
TCL interface.

And now that Eric's introduced tabled wreck-types,
that'll allow for an exponential increase in units... 
First to 10,000 wins a donut.


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  5:18             ` Elijah Meeks
@ 2004-06-07  5:44               ` Eric McDonald
  2004-06-07  6:11                 ` Lincoln Peters
  2004-06-07  5:55               ` Lincoln Peters
  1 sibling, 1 reply; 16+ messages in thread
From: Eric McDonald @ 2004-06-07  5:44 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: Lincoln Peters, Xconq list

On Sun, 2004-06-06 at 23:18, Elijah Meeks wrote:
> > Current total is 116 (and rising!).  
> 
> Oh good, so I don't have to feel guilty with 800?
> 
> I mean, it's important to differentiate between a
> veteran understrength 3rd generation armor group and a
> crack understrength 3rd generation armor group and a
> crack reinforced 3rd generation armor group and an
> elite reinforced 3rd generation armor group and, and,
> and...

You're not joking, are you?

> And now that Eric's introduced tabled wreck-types,
> that'll allow for an exponential increase in units... 
> First to 10,000 wins a donut.

You guys can fight over the donut. ;-)

I take pride in the fact that each of Bellum II's 62 unique unit types
is lovingly handcrafted, with attention paid to literally scores of
tables and properties on a per unit type basis. The result: 5142 lines
(and growing) of GDL (no maps or predefined units) across 4 files. I
still have about another 7 unit types to add to make it to the release
version. Then, after release, I'll maybe add advance types, and a tech
tree, which will probably push the envelope past the 200 unique unit
types mark.... Right now, I just have the "classic" generation of units,
but I have ideas for the "modern", "post-modern", "future", and
"far-future" generations. Of course, maybe I'll get burnt out before
reaching the last generations. We'll see.

  Regards,
    Eric

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  5:18             ` Elijah Meeks
  2004-06-07  5:44               ` Eric McDonald
@ 2004-06-07  5:55               ` Lincoln Peters
  2004-06-07  6:35                 ` Elijah Meeks
  1 sibling, 1 reply; 16+ messages in thread
From: Lincoln Peters @ 2004-06-07  5:55 UTC (permalink / raw)
  To: Elijah Meeks; +Cc: Xconq list

On Sun, 2004-06-06 at 22:18, Elijah Meeks wrote:
> > Current total is 116 (and rising!).  
> 
> Oh good, so I don't have to feel guilty with 800?

I guess I can see how a game could include 800+ units, but it would have
to be a *really* complicated game!

> 
> I mean, it's important to differentiate between a
> veteran understrength 3rd generation armor group and a
> crack understrength 3rd generation armor group and a
> crack reinforced 3rd generation armor group and an
> elite reinforced 3rd generation armor group and, and,
> and...

Sounds just like the thing with my knights, although if I was to go into
as much meticulous detail as you seem to be going into, I could set up
20 levels of archers, allow lots of humanoid races (dwarves, elves,
orcs, goblins, hobgoblins, bugbears, gnolls, troglodytes, et al.) to
gain levels...

Add to that that not all knights use swords and shields (some use
two-handed swords and no shield, some use warhammers instead of swords,
some use polearms), and that number at least quadruples.

Given the current capabilities of Xconq, I can see at least 1,280
distinct units required to do all of that (and I haven't even counted to
the 48 dragon units!).  At that point, I'd want to start writing some
Perl scripts to generate this stuff.  Although some day Xconq might be
able to provide all of this flexibility *without* using 320+ distinct
units.

> 
> It looks pretty good in SDL, so I assume it'll look
> fine on the Mac, too, but after about a hundred units,
> I have my doubts any sane player will put up with the
> TCL interface.

With 116 units, I've already noticed that it's a little painful with the
TclTk interface.  Especially when, for example, you're looking at all 12
varieties of red dragons and all of them have the same icon (I'd make my
own images, but I don't consider myself much of an artist).

The last time I used the SDL interface, it seemed to be missing a lot of
functionality that I find essential to this kind of game, such as a Help
screen (so that I can verify that my code is actually going to do what I
think it will!).

> 
> And now that Eric's introduced tabled wreck-types,
> that'll allow for an exponential increase in units... 
> First to 10,000 wins a donut.

I haven't even considered how I'll incorporate the new wrecking code
into this game, although it would certainly open up possibilities (this
game also has vampires).  I could conceivably try to create variants of
the aforementioned humanoids, such as half-celestials, half-fiends,
half-dragons, liches, vampires...

On the other hand, I don't want to define any more units than I have to
in order to get the desired results; most players would go crazy trying
to figure out a game with 10,000 units.

---
Lincoln Peters
<sampln@sbcglobal.net>

Authors (and perhaps columnists) eventually rise to the top of whatever
depths they were once able to plumb.
		-- Stanley Kaufman

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  5:44               ` Eric McDonald
@ 2004-06-07  6:11                 ` Lincoln Peters
  0 siblings, 0 replies; 16+ messages in thread
From: Lincoln Peters @ 2004-06-07  6:11 UTC (permalink / raw)
  To: Eric McDonald; +Cc: Xconq list

On Sun, 2004-06-06 at 22:41, Eric McDonald wrote:
> > And now that Eric's introduced tabled wreck-types,
> > that'll allow for an exponential increase in units... 
> > First to 10,000 wins a donut.
> 
> You guys can fight over the donut. ;-)

I don't intend to write a game that involves 10,000 units unless I can
justify having 10,000 units.  The example below demonstrates that this
game could easily handle hundreds (if not thousands) of fairly
distinctive units, but 10,000 units seems ridiculous.

> 
> I take pride in the fact that each of Bellum II's 62 unique unit types
> is lovingly handcrafted, with attention paid to literally scores of
> tables and properties on a per unit type basis. The result: 5142 lines
> (and growing) of GDL (no maps or predefined units) across 4 files. I
> still have about another 7 unit types to add to make it to the release
> version. Then, after release, I'll maybe add advance types, and a tech
> tree, which will probably push the envelope past the 200 unique unit
> types mark.... Right now, I just have the "classic" generation of units,
> but I have ideas for the "modern", "post-modern", "future", and
> "far-future" generations. Of course, maybe I'll get burnt out before
> reaching the last generations. We'll see.

What I'm trying to do is work my new game so that its properties depend
partially on unit-specific properties (hp-max, cp), but mostly it
depends on what lists it is found on.  Take the dragon turtle for
example:

* It is a monster, so it can fight other units and capture cities,
citadels, and lairs (as can fighters).

* It is a level-9 unit, so it has a 50% chance to hit other level-9
units, and its chance to hit other units changes by 5% for each level it
is different from its opponent, and it does 2d4+9 damage when it hits.

* It is a dragon, so you need a special type of place (a draconomicon)
in order to build it.

* It is aquatic, so it can move through water with ease but cannot
survive on land (for most units, it's the other way around).

* It is a ranged combatant, so it can fire at enemies up to 6 cells
away.  Firing is resolved exactly the same way as melee attacks.


This makes it a lot easier to define lots of units and make them work
with little difficulty.*  Although the really weird things (lightning
bolts, walls of stone, etc.) still need a lot of code that is specific
to them.


* Assuming an adequate understanding of how lists work in GDL!

---
Lincoln Peters
<sampln@sbcglobal.net>

You will be misunderstood by everyone.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: A more sophisticated demonstration of change-type
  2004-06-07  5:55               ` Lincoln Peters
@ 2004-06-07  6:35                 ` Elijah Meeks
  0 siblings, 0 replies; 16+ messages in thread
From: Elijah Meeks @ 2004-06-07  6:35 UTC (permalink / raw)
  To: Lincoln Peters; +Cc: Xconq list


> > > Current total is 116 (and rising!).  
> > 
> > Oh good, so I don't have to feel guilty with 800?
> 
> I guess I can see how a game could include 800+
> units, but it would have
> to be a *really* complicated game!

Yeah, it'd be easier with attributes.  For now, it
just means that each unit has a marginally improved
attack and hit points.  The more wrecked and less
experienced units have a higher chance of retreating
when attacked, that kind of thing.  It works out
pretty easily in GDL, so far (I'm not actually up to
800 units, though...)

> On the other hand, I don't want to define any more
> units than I have to
> in order to get the desired results; most players
> would go crazy trying
> to figure out a game with 10,000 units.

Not really, at least not if it was going on in the
background.  Even at 800+ units for my little Xconq
WWIII, as long as the player doesn't have to cycle
manually through the whole list, they see a very small
and manageable list of units.  All the experience
levels are handled internally by auto-upgrade, all the
wrecked-types are also handled internally, the various
tech levels include obsoleting, so that a player never
has to cycle through more than a dozen units, at any
point in the game.

And, yeah, I love SDL, but it's a long way from
perfect.  Still, it gives you some idea of how
manageable such a large unit list is when you only see
what a unit can build.



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2004-06-07  6:35 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-28 17:44 A more sophisticated demonstration of change-type Lincoln Peters
2004-05-29  2:28 ` Eric McDonald
2004-05-29  6:02   ` Lincoln Peters
2004-05-29 15:41     ` Eric McDonald
2004-05-29 17:17     ` Eric McDonald
2004-05-29 18:38       ` Lincoln Peters
2004-05-29 18:58         ` Eric McDonald
2004-05-29 22:01         ` Eric McDonald
2004-06-07  2:26       ` Lincoln Peters
2004-06-07  2:40         ` Eric McDonald
2004-06-07  5:05           ` Lincoln Peters
2004-06-07  5:18             ` Elijah Meeks
2004-06-07  5:44               ` Eric McDonald
2004-06-07  6:11                 ` Lincoln Peters
2004-06-07  5:55               ` Lincoln Peters
2004-06-07  6:35                 ` Elijah Meeks

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).