[Top][All Lists]

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

Re: [Adonthell-devel] Iems

From: Mike Avery
Subject: Re: [Adonthell-devel] Iems
Date: Mon, 18 Feb 2002 12:12:18 -0500

OK, I'm going to leave this.  You have a far better understanding of how you 
want to integrate this, so I'll leave that to you or Alex.

I'll revisit the combat essentials, and try to work out generic calculations 
that can handle melee, magic and alchemy.


> On Mon, 18 Feb 2002 10:17:41 -0500 Mike Avery wrote
> > I have a few questions..
> >
> > Here is what I believe is true as of now:
> >
> > We will create 'action' classes for items:
> >
> > Equip
> > Combine
> > Use
> > Enchant
> > --[others]
> I think we wanted to have one 'action' class that contains a method for
> all possible actions. If an item would need more specific actions than
> provided by the base action class, it would extend that class and override
> whatever actions it wants.
> That however means that an individual item must know what capabilities it
> has, as it would inlude all possible actions.
> As for the implementation, I think there would be a base item class done
> in C++, which would extend the storage class and define a few attributes,
> like item type and name. All further attributes would be kept in the map
> the storage class provides.
> Further, this item class would contain the action script, and the
> functionality to launch a certain action. The py_object class is possibly
> a good starting point for that.
> There would be a python wrapper for that item class, of course.
> The advantage is that you would not need a special class for each item, as
> the item class can store any (integer-)attributes an item might have. The
> main difference between various items is achieved through the attached
> action script. So a book, a potion, a candle or a sword might all be
> represented by the base item class, but through different action scripts
> their behaviour will be completely different.
> As items are somehow placed on the map one day, it's also of advantage to
> have C++ objects we can use.
> Of course, some items would need special variables (for example
> containers), so they would extend the base item class. Possibly also on
> C++ side.
> > Question:  Do we want to put the items in individual Python modules, or
> > many per module?
> So far we have one python module for all wrapper classes. (
> After my interpretation, items wouldn't be handled any different, so thay
> should go in there as well.
> However, I think it might be better to split this file into different
> modules. Because it contains wrappers for the complete Adonthell API, you
> need to link to the complete Adonthell source code if you want to use one
> of the wrappers. That's a general issue, not at all item-related.
> As far as the actions go, I guess they could be kept in seperate modules,
> as their dependencies might be quite different.
> > Question:  We're going to need access to a character calss.  When we work
> > in encumberance, item Equipping requirements, enchanting skills etc,
> > we're going to need to check and/or adjust character stats based on item
> > use and manipulation.  Is the character class going to be in Python?
> Not exactly. The character class is done in C++ and has a python wrapper.
> That means, a character is always a C++ object, but can be passed to
> python scripts, or created in python scripts and passed to C++ methods.
> That's more flexible than coding it directly in Python.
> > I'd like to work on this.  I would rather sort this out right now, since
> > combat/magic is going to rely heavily on the item interface and general
> > mechanics.  I'd rather get this into place than rewrite the combat stuff
> > now, just to rewrite it again once this stuff is done.  Objections? 
> > Thoughts?
> Well, there is the lot at the beginning. You shouldn't consider that as
> the ultimate wisdom. When you start thinking it through it might turn out
> to be not very good. If I would code the item system, I would take that as
> a starting point and improve upon it.
> However, you might have different ideas and different solutions to the
> various problems that are equally good or better. Feel free to do it your
> way then.
> Kai
> _______________________________________________
> Adonthell-devel mailing list
> address@hidden

reply via email to

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