This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Item Units


On Sat, 2004-08-21 at 23:39, Eric McDonald wrote:
> 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.

In many respects, these "cow patty" units could be treated like
facilities, so if someone implemented an easy way to pick up *and drop*
such units, you might have something useful.

On the other hand, the AI's understanding of facilities is a solid
"brain-dead"; I honestly think that the AI will need to be radically
re-engineered before it will ever truly understand facilities.

> 
> 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.

I experimented with control-range in a game module involving
necromancers and undead armies.  The idea was that undead units would be
helpless if they were more than 16 cells away from the necromancer,
except for vampires and liches, which can function normally up to 24
cells away and can relay orders.

It seemed to work decently, but it was around the time that the
pathfinding code was radically re-engineered (and later radically
un-re-engineered), so I ran into a bunch of problems that may have been
totally unrelated to the control code and eventually lost interest in
it.  Maybe I should take another look at it.

(This module might make a good addition to the library, but its premise
*is* rather twisted.)

> > 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.

I tried to implement armor in a game module I wrote a while ago (the
game module was never interesting enough to add to the library).  I
discovered that I could not provide more than one kind or armor without
running into the following dilemma about how the armor "occupies" the
knight:

1. If I use unit-capacity-x, I can prevent a knight from wearing two
suits of plate armor, but I can't prevent a knight from wearing a suit
of chainmail over a suit of full plate.  (If I was to allow a knight to
wear two suits of armor simultaneously, I'd want to find a way to adjust
their ACP's and hit chances accordingly.)

2. If I use generic capacity, I can ensure that a knight can wear one
and only one suit of armor, but I lose the ability to do anything
similar with other items (different kinds of shields, helmets, magic
rings...).  I would have to make various kinds of armor, shields, rings,
etc. fit in generic capacity; therefore a knight could wear one suit of
plate armor normally, and one on his finger in place of a ring of
protection (now *that's* a silly mental image).

> 
> > 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.

I guess I need to get back to work on knights.g!

---
Lincoln Peters
<sampln@sbcglobal.net>

A quarrel is quickly settled when deserted by one party; there is no battle
unless there be two.  -- Seneca


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]