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
next prev parent 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).