Re: Three thoughts

[Elijah Meeks <elijahmeeks at yahoo dot com>]

> If the solution isn't a fancy "occupants navigator",
> then perhaps the
> solution is just change the game designs to reduce
> the problem.  For
> example, one reason that the standard game only
> allows 16 units in one
> cell is to make them easy to draw and see.  The
> standard game is
> lacking any such mitigation for the "infantry in a
> bomber in a carrier
> in a town" problem, however.  I wonder what it would
> do to playability
> if a town/city could only hold 8 units?

I generally agree with this, and it's why I've fallen
into using a four unit limit per cell with my designs.
 Still, even a game like civilization uses a seperate
status window for cities, which near the end of the
game would have dozens of what XConq considers units. 
So, if a designer wants to create a civ-like game
that's visually appealing, we need some way to hide
the ancillary units, which in general aren't combat
units but rather units that somehow affect a 'mother'
unit (Improvements in Civ/MOO/MOM, items in the case
of fantasy/RPG-style games).

Speaking of items, I'd like to add random piles of
gold to Opal.  I can do this in a way by making
advanced 'Random Pile of Gold' units with an initial
supply of 'gold' material that gives to the treasury,
so that when a player captures the unit, the gold is
tossed into their treasury (The independant side
defaults to not using the treasury, so the gold isn't
looted by greedy iplayers).  This is, however, a
cumbersome procedure, and I was wondering as to the
feasibility of an capture-gives-material table.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail