adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] equipping items


From: Kai Sterker
Subject: Re: [Adonthell-devel] equipping items
Date: Fri, 16 May 2003 20:35:23 +0200

On Fri, 16 May 2003 08:59:16 -0700 Mike Avery wrote:

> I've been thinking about this stuff too Kai, but I didn't want to just
> go and start ripping your code apart!

Well, if you'd need any changes or additions for your code to work, just
say so.


> We need to come up with a plan so we can divide and conquer without
> breaking each-other's stuff.

True. I wasn't exactly sure what you were up to, so I thought I get the
discussion going with this basic things below.


> > So, first of all we'll need a method like can_equip that gets a
> > character and returns true or false. If an item does not implement
> > the method, we would assume false.
> 
> This would need to check requirements for equipping, like STR, DEX,
> race etc obviously, but you know this already :)

Exactly.
  

> > That mapping shouldn't be hard-coded, but read from a
> > data file, so that it remains flexible.
> 
> 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. If someone wanted to make a game with an eight-legged and
two-headed monstrosity as main character, they had to change the engine.
That shouldn't become neccessary. (I assume that the manager would be
written in C++, not Python. Otherwise matters would be different, of
course.)

With the category/slot-name check they would just need to update or
rewrite some scripts, but they could use the same engine.

[...]

> Some Pseudo (C) for equipping a helment on the head:
> 
> if ( char.inv.item.equipable_slots &HEAD ) {
>       char.equip (character, char. helmet, slot);
>       ...
> }

Where would that code go?


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)

* when hitting the 'equip' button over a certain slot, you'd get a 
  list of all items that fit into that slot.

Equipping would happen afterwards.


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.
 

> What are your thoughts on this?  Seems easier than parsing categories
> and keeps things easy for people to edit and understand.

The categories would be required anyway, I think. And setting up a
mapping of item categories and slots should be fairly straightforward
too. But as said above, any easier solution that is flexible enough to
add or change slots without modifying the engine will do.


> > * bool equip (item_base*, slot*)
>
> 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.


> Here is how I have been envisioning the logic.  Let me know if you
> think I'm out of whack.  Some of the pseudocode below doesn't reflect
> the current methods, but I think you'll understand where I'm coming
> from.
> 
> 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.


> See above.  A failure would be result in the return of the items
> passed.  If we do have a failure equipping for some reason, we won't
> lose items. Also it would lend itself to good default behaviour, for
> screen updates (items in hand, drag/drop items in the iventory etc). 
> The correct item would be shown if a faulire ocurred, and the GUI
> would be correct.  This could also be used for situations where the
> character doesn't meet requirements for equipping an item.  Just
> return the item passed, and it doesn't appear on the character, gets
> back to where it came from, etc.

Right. Point taken :).



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

The actual equipping/removing would be handled by the manager. So
neither character nor inventory should be in need of these.



> Yep!  Just need to make the manager really!
> 
> I'd like to know your thoughts on the stuff above.  Are we on the same
> page more or less?

Mostly, I think. The only difference would be the way to determine
whether an item fits into an equipment slot.

Kai




reply via email to

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