public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: "Jakob Ilves" <illvilja@yahoo.com>
Cc: xconq7 <xconq7@sources.redhat.com>
Subject: Re: Concept: Compound (hierarcical) units
Date: Wed, 19 Nov 2003 22:08:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0311191626290.31399-100000@leon.phy.cmich.edu> (raw)
In-Reply-To: <20031119211837.31588.qmail@web40904.mail.yahoo.com>

Hi Jakob,

On Wed, 19 Nov 2003, Jakob Ilves wrote:

> (You're too fast for me guys!  I write 1 mail and during that time 7 new mails pop up in the
> mbox...)

But your mails are 7 times as long.... ;-)

> I recall a game written at the Chalmers University (it never 
>got published, unfortunately :-/)
> when I studied there.

Do you have the source code to it? It sounds like a fun game to 
try.

> Once in combat, some units inside could be lost, others damaged.  After combat (if surviving ;-),
> one could go to a factory and repair damaged units and using existing brigade units to equip the
> batallion with the lost units.

Interesting.

> That could be useful in Xconq as well, both to handle the movement of bunches of units but also to
> handle situations where you have one unit with subsystem units inside, for example an ironclad

I think that this concept could be reasonably simulated in Xconq 
by slightly extending/modifying the existing occupant-transport 
model. Lincoln has already made one such proposal that could be 
used to support this.

Even the unit production aspects that you mention can probably be 
accomodated by adding a 'unit-creation-requires-unit' table and 
the corresponding logic.

Custom definitions of aggregate units are the only thing that 
might require significant work to add, AFAICT. There really is no 
support for dynamically adding unit types once a game is underway 
(except by possibly merging with another module).

> A corp HQ were not in the same hex as it's various divisions 
>(stacking limitations) but were among
> them, being a powerful supply unit, sending stuff to all the 
>division HQs it supported and being
> able to use rather distant cities for getting supplies.

You can simulate this in Xconq by setting the 'in-length' and 
'out-length' of logistical units higher than other units.

> Needless to say, it was a wonderful tactic to cut off another unit's supply lines by occupying the
> hexes between it and it's own town, making it run out of ammo and fuel.  I usually experienced it

Actually, there is supply line interdiction support buried in 
Xconq.

> Too bad the game never became published.  It was approx 10 
>years ago I saw/played it.

Yes, this is too bad. It sounds like a very fun game.

  Best regards,
    Eric

  reply	other threads:[~2003-11-19 21:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-19 21:48 Jakob Ilves
2003-11-19 22:08 ` Eric McDonald [this message]
2003-11-19 22:22 Elijah Meeks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0311191626290.31399-100000@leon.phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=illvilja@yahoo.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).