adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Adonthell-devel] equipping items


From: Mike Avery
Subject: RE: [Adonthell-devel] equipping items
Date: Fri, 16 May 2003 11:55:32 -0700


> > OK.  I was wondering about an enum for this.
> 
> >From a coding point of view, the enum would be easier (and more
> performant too). But it would somewhat limit the engine to 
> our model of
> a character. 

Ah, OK, I hadn't thought of this.  We'd better read categories from a file
too then!  We wouldn't want to assume that all characters have "LEGS". ;)



> My thought was that you'd match an item against a named slot and get
> either a "fits" or "doesn't fit". Equipping isn't involved directly.
> I was rather thinking about some GUI features that would need such
> method:
> 
> * either when hitting the 'equip' button you'd get a list of possible
>   slots, in case the item fits into more slots. (like rings which find
>   into left or right finger, or weapons that can be double wielded)

Like if a player selects an item in the inventory, slots which are not
capable of equiping the item (for whatever reason) could be disabled and
shadowed, or something like that.  I follow.

This begs the question...  Do (or will) the interface widgets have event
support?  Much of this could be relayed to the player through visual queues
like turning a slot red or something like that on mouse button press, etc.

I digress.  Categories it is.


> Of course, if there is a better way to accomplish that, which is as
> flexible, I'd chose that rather than the category / slot-name mapping.
> I just can't think of anything right now.

Not really, me neither.  
 

> > I would think that this method should do ONLY the placing of an item
> > into a slot, and that's it.  Return a bool for success/failure.  The
> > existing methods on the character would be good for this and are
> > already in place. I think the handling of swapping items 
> etc might be
> > better handled at a higher level.
> 
> Okay, that seems sensible. I always end up with writing 
> methods that are
> a bit too convenient, and therefore lack flexibility.

So we will move the equip.add() equip.remove() and equip.slot.accepts()
methods to the item class? 


> > Here's a rough idea:
> 
> [...]
> 
> Yeah, I'll stick to that, then. When an item is equipped, the 
> previously
> equipped item (or NULL if none was equipped) is returned. On 
> failure it
> returns the item given.
 
Right!
 

> > > Remains the question whether we still need the (optional) 
> equip and
> > > unequip method of items.
> 
> > Doesnt hurt.  personally, I think the methods for
> > equip/remove/slot_empty could be just about anywhere.  We should
> > decide which spot makes most sense though. Character, Manager,
> > Inventory, Item.  Which makes the most sense to you?
> 
> Equip/unequip could be with the item, in order to trigger 
> events when an
> item is actually equipped or removed. They'd be optional though, and
> only called if they exist.

Sounds good to me!


OK Kai, if you want to look at the item manipulation, I can get started on
writing up some methods for character and item stat checks etc.  We can roll
these into the manager when we have something to combine.

We want the manager performing the character and item checks yes?

Mike




reply via email to

[Prev in Thread] Current Thread [Next in Thread]