Re: Item Units

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Elijah Meeks wrote:

> It seems like the
> framework's in place for items, just add a fifth entry
> to the ferry-on-entry/departure tables that's "Full"
> (Or something similar).  I'd thought, when I first
> worked with items as occupants, that "over-all"
> would've worked, but it didn't.  "Full" would mean
> that the transport paid all necessary ACP costs for
> the occupant to move into the hex and load onto the
> unit.

I think one problem with cow patties is that ideally one would like them 
to be actionless, and hence they could not be selected as active units. 
So, having a transport offer to pay for everything would not do much 
good for items that cannot even be selected as actors.

A dedicated pickup/get command like most good dungeon games have would 
be nice.

Another possibility would be to get Xconq's control range stuff working 
(if it's not already; I haven't experimented with it, but there does 
appear to be some support for it in the code). Then set the control 
range of regular units to be something like 1 or 2 cells for item units. 
Thus the item units would only be able to act (i.e., move) in the 
presence of a regular unit.

> The AI, of course, would likely not get that these
> units were useful, and would probably pick them up and
> drop them at random. 

One thing that I have tried before, but with only partial success, was 
to set the 'ai-peace-garrison' of mobile transports, such as carriers, 
close to their occupancy max, and then set the 'ai-war-garrison' to 0.

In the case of item units, I would guess that both garrisons should be 
at the occupancy max to encourage the AI to retain the items at all times.

> I'd like to introduce three item types in Opal: 
> Weapon, Armor and Gear.  

I'm looking at Weapons and Armor for Wreckreation. Armor could already 
be done since the 'protection' (should really be called 'vulnerability') 
table already exists.

> So far, so good (Heck, only six new
> units, I'll never reach 1000 like this).  

Yeah, no kidding. And I thought it was 10000 in order to win the magic 
donut.

> But we've
> all seen how a unit looks with three occupants,
> especially when it occupies a cell with another unit
> or two.  Without an occupant dialog box, it'd just be
> too cluttered.

IIRC, you suggested this when we were disucssing options for Cast Iron 
Life last year. I think it is a good idea. I have been quite tempted to 
try implementing it in the Tcl/Tk interface. I think I would improve 
formation selection first, before attempting that, since the improved 
formation selection stuff is likely easier.

> Building each magic sword by hand is also a pain.  So
> I'd love to see initial-occupant and
> occupant-when-created tables that call for, 

Yeah, the 'initial-occupant' idea has been at the back of my mind as 
well, and out of the same needs that you mention. It seems that you 
thought about it more than me though, since I didn't think of the 
randomness aspect.

Hans just recently implemented part of another idea I had: units under 
construction being tougher than 1 HP. Had I implemented it, I would have 
redirected damage to CP instead of HP, and set up a HP-to-CP conversion 
ratio table. However, since he implemented it with a static HP value; I 
may still have the opportunity to do something more dynamic (scalable) 
like I had originally intended. The two solutions can probably exist 
side by side (though mutuall exclusive), if done right.

> Tablewise, occupant-adds-hit-chance/fire-hit-chance,
> occupant-adds-acp, occupant-adds-damage and
> occupant-adds-hp would be a great start.

You've already got 'occupant-adds-acp' and 'occupant-multiplies-acp'. I 
added those a while back ago. I think there is a fairly good chance that 
I will want to add 'occupant-adds-hit-chance', 
'occupant-adds-fire-hit-chance', and 'occupant-adds-damage', and their 
multiplicative counterparts. I hadn't thought of the HP one.

> And neural nets, and 3D units, and a fully 3D globe,
> and XBox support, and and and...

That "and and..." is becoming a trademark of yours. :-)

Thanks for the thoughts. I hope to address at least some of them in the 
next month or so, but knowing how I always get sidetracked, I should 
stop quoting timelines.

Eric