adonthell-devel
[Top][All Lists]
Advanced

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

Re: [Adonthell-devel] Adjustments to items.h ?


From: Kai Sterker
Subject: Re: [Adonthell-devel] Adjustments to items.h ?
Date: Thu, 14 Feb 2002 17:58:56 +0100 (CET)

On Thu, 14 Feb 2002 11:04:38 -0500 Mike Avery wrote

> Well, you guys are the bosses, so I'll go with whatever approach you want to 
> take, but I personally think that decentralizing game mechanics is a mistake. 
> Unless I've missed something, it looks like you want to have a series of 
> python scripts handle game mechanics functions that will be required both in 
> and out of combat.

I'll answer to that one first, as it is shorter ;).

I would really like to unify the mechanics into a set of functions (or
scripts) that take some items and/or characters as input, no matter what
items that are.

That's why I am against having a class for each item type.

However, I don't think we can limit everything to the pure number
crunching. There are not only weapons and armour, and foci, reagents and
potions, but other items too. Books and lightsources, keys and yeti
figurines, all that stuff that needs to be handled in a completely
different way.

So an item had a number of uses. "Equip", "Unequip", "Attack", "Defend",
"Use", "Combine". Don't know if we would need more. Possibly not.

Actually, I think we might reach a compromise here. In my other mail I've
been talking about the scripts that handle on certain use for a number of
items (the more the better), and special fx scripts that provide
functionality for an item that is not handled by the generic scripts.

Now I think we might be able to have the generic uses (those that only
involve calculations on attributes) handled by the game engine. I.e. C++
side.

However, a python script could be attached to any of the use to handle
everything that is not done by the generic code. Especially, the python
scripts should be able to 'override' the normal code, to accomplish
special behaviours. For example, a cursed foci might make flowers grow at
the spot it is directed at, instead of roasting the opponent.

That could be done by checking the return code of the python script. If it
is not 0, we continue with the normal mechanics, otherwise, we return
immediately.

That way we had the most generic functionality centralized, but could
handle any special occasions or items as well.


Kai





reply via email to

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