public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* Concept: Compound (hierarcical) units
@ 2003-11-19 21:48 Jakob Ilves
  2003-11-19 22:08 ` Eric McDonald
  0 siblings, 1 reply; 3+ messages in thread
From: Jakob Ilves @ 2003-11-19 21:48 UTC (permalink / raw)
  To: xconq7

Hello again!

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

Just a concept to think about and, who knows, maybe implement in Xconq.

I recall a game written at the Chalmers University (it never got published, unfortunately :-/)
when I studied there.  It was very inspired by Xconq but still a completely different animal.  In
that game, you could build things like armor, infantry, artilliry units (I think they were brigade
size) but the player could also define "units" of their own.  For instance, you could define a
unit which you called "offensive armor batallion" consisting of a batallion HQ, 1 self propelled
artillery brigade, 3 medium tank brigades and 2 tank-killer brigades.  Once that you got this
definition in place you could tell a factory to build it.  So, your factory started to build all
the HQ as well as all the 6 included brigades.  Once complete, an armor batallion unit appeared on
the map and by moving that single icon around, all the 7 included units moved along.

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.

There were divisional head quarters, being used when turning batallions (and possible some
brigades) into divisions.  Those also moved as just one unit but contained, well, quite some
units.

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
with two turret units or in a tactical tank combat game a tank with a radar unit onboard.  If a
hard hit strikes the transport, one passenger subsystem might get destroyed, crippling but not
killing the bigger unit (the ironclad looses firepower, the tank looses radar visibility).

One can optionally make that "compound unit" rigid in the sense that one cannot add/remove units
from it and that the specific compound unit is defined in the scenario.  For instance, the
ironclad have two turret units when initially built and those turret units can never leave the
ironclad (unless the are destroyed).  That would make it easier for the AI to figure out how to
use them properly.  So, in this context, the turrets are "equipment" units.  If one permits such
"equipment" units to actually leave one unit and be moved into other units or one allows a unit to
mix and match "equipment" one can assist the AI by giving the "equipment" hint about those units. 
So, you could choose, if that cybertank is supposed to contain an cannon turret and a missile
turret as well as an ECM array unit or if you want to go for all cannon turrets...

Actually, by elaborating this a bit, you can create games with rather few actual units on the map
but where each unit have fairly intricate interiors.  Especially when one considers how various
equipment units and transport units should handle materials.  One unit can be a material depot,
providing a lot of ammo and fuel.  Run out of ammo or fuel and you need someone to assist you...


The implementation of supplies in that game I initially mentioned was quite intriguing:

A HQ supplied it's units below in the hierarchy with ammo and fuel.  An HQ can also transfer
supplies from cities (especially large HQs).

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.

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
the other way aroun though :-).

So, you had to ensure that your supply net were working.  Also, you had to buffer upp with heavy
ammo in a few headquarters near your forces if you intended to use much heavy artillery because
they could easily get out of ammo, even with working supply lines.

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

Best regards

/IllvilJa

(Who's still short of time, and still dare to have opinions :-)


=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html

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

* Re: Concept: Compound (hierarcical) units
  2003-11-19 21:48 Concept: Compound (hierarcical) units Jakob Ilves
@ 2003-11-19 22:08 ` Eric McDonald
  0 siblings, 0 replies; 3+ messages in thread
From: Eric McDonald @ 2003-11-19 22:08 UTC (permalink / raw)
  To: Jakob Ilves; +Cc: xconq7

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

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

* Re: Concept: Compound (hierarcical) units
@ 2003-11-19 22:22 Elijah Meeks
  0 siblings, 0 replies; 3+ messages in thread
From: Elijah Meeks @ 2003-11-19 22:22 UTC (permalink / raw)
  To: mcdonald; +Cc: xconq7

"There really is no support for dynamically adding
unit types once a game is underway (except by possibly
merging with another module)."

In a way, if we could change around the occupant
combat model (And get the AI to recognize it), you
don't need to create dynamic units.  You can just have
a single, "Army" or "Division" unit that holds each of
these brigades, and instead of the "Army" or
"Division" unit attacking, it's the individual
occupants that attack and defend.  That's the way Cast
Iron Life works.  The two major problems it runs into
are 1) The AI sure don't like it, and has a hard time
dealing and 2) Every successful attack against an Army
results in an attack on each of it's occupants, which
multiplies your attacking brigade's power by the
number of enemy occupants.  There's a workaround, by
making all units use the Fire command instead of
Attack, but it's even more screwy for the AI to figure
out and it allows for no counterattacking.  It kinda
bothers me, though, because Jakob says this idea's 10
years old, I thought I came up with it...

What's cool about this system is that you suddenly
have smaller units to work with so that if anyone was
ever ambitious enough to integrate a Master of Magic
style tactical combat engine into Xconq, you'd have
the necessary pieces to pass into it.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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

end of thread, other threads:[~2003-11-19 22:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-19 21:48 Concept: Compound (hierarcical) units Jakob Ilves
2003-11-19 22:08 ` Eric McDonald
2003-11-19 22:22 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).