RE: [Adonthell-devel] Hello Hello

[Mike Avery]

> > Is Adonthell at the point now where combat is a real goal?
> 
> Yeah, absolutely. I'd like to have all the lowlevel stuff 
> ready in time
> for the new mapengine. Then we'd just need to connect the two, write
> some GUIs and we'd have combat and items working.
> 
> Your help would therefore be greatly appreciated :). Not only 
> am I quite
> busy with other stuff these days, but I also lack motivation, 
> as there's
> hardly any progress these days. So if you'd jump aboard and get
> something done, that'll probably wake my interest again.
 
Great!  Count me in!


>    http://adonthell.linuxgames.com/development/doc_cvs.shtml
> 
> The scripting guide contains information about how to write item
> templates. And the architecture doc has a chapter about items and
> inventories in general. Then there's of course the item/inventory
> related code: item_base.cc/.h slot.cc/.h inventory.cc/.h. 
> However, a lot
> of the stuff is written in Python, and that code isn't in CVS yet.
> Unfortunately, it's not on that box here either. So you'll 
> have to wait
> 'til the weekend before I can send it over. (Although some bits and
> pieces are available through the mailing list archive, as you 
> might have
> seen.)


Great, I'll start reading.



> And another thing is having characters actually equip these items. My
> thoughts about that are that characters have two inventories: one that
> represents the backpack, and one for the items they are wearing. In
> latter, slots are given names, so that the items inside can be easily
> accessed. However, I am not quite sure how item properties are applied
> to characters when they equip items. I guess they should be 
> added to the
> character's stats when equipping them, and removed upon unequipping.

Yes, there is an important decision to make here.

I'll continue my verbose history here. I see you've become verbose when
discussing design issues too Kai :)
I'm going to take a week or more to take a good look at the code and
interfaces so I have a good understanding of direction etc, but here's a few
design considerations that may or may not have been addressed yet?  Like I
said, I'll spend a week looking over things.

If you consider a character wearing several pieces of armor and/or clothing.
They have a magical enhancement to stats going (say, "Flight of the Gazelle"
(read speed)), as well as attribute enhancing runes or enchantments on props
(weapons, walking sticks or magic shoes or something).

If combat is to occur "on the map" with the same view as exploration
(without a separation of engines), the principal engine needs access to
these modifiers regardless of whether the character is in combat, or just
walking around.  So we have three or four different sources of
stat/skill/status modifiers:

1. Magical enchantment (through several possible means I would imagine)
2. Prop (item) attributes
3. Potions and items
4. Feats?

This calls in questions of inventory / equipped items, etc as well.  We need
a standard way to comb over a character and determine their current status,
and we need to determine the best "way and place" to turn this bundle of
information into something which is usable within combat routines.
Important IMO.  

There are I believe a few ways to do this (and probably more that I haven't
thought of):

I use the term "modules" below.  What I mean by this is a distinct block of
code responsible for a specific purpose, such as combat, exploration etc.
Engines within the engine if you get my meaning.

"Actuals" is used symbolically as the actual calculated totals for
stats/modifiers.


1. Store this information "on the character", and standardize change
methods.  The code that equips an item on the character changes the
attribute by the desired amount, as you have suggested Kai.

Pros: -Does not require specific "character management" code
        -Character "numbers" are always actual
        -Least overhead (no need to determine actuals through calculation)

Cons: -Bugs in this area amounts to bugged characters
        -Equip code would need a scheduler to avert races or clobbering
         (I assume that characters can have stats modified by outside
parties
        -Modifier heuristics are global, less flexibility (this could be
good or bad depending on your view)



2. Determine this information through calculation within a module when it is
needed.

Pros:   -Best isolates bugs to modules, rather than globally
        -Flexibility (game engine modules can use unique heuristics)
        -Character's stats are never really modified (other than permanent
changes), rather, actuals are    determined through reads and calculation,
not writes to the character data (safe)
        
Cons:   -Overhead (duplicated work in the modules)
        -Complexity added to modules


3. Develop Central Character Management Interface.  This module would be
responsible for equipping, stat changing, determining actuals for use by the
modules.


Pros: -Centralized management and complexity
        -Enforced, standardized interface
        -Overhead.  This would be efficient

Cons: -Would need to interface or integrate with inventory code (this may be
good after all)
        -Modifier heuristics are global, less flexibility (this could be
good or bad depending on your view)


I have a favourite, but I'd like your thoughts or suggestions.

There are probably pieces to this pie that I will only discover once I get
to reading the code and docs.  Please add to this, or let me know if I'm off
base with current design goals.


Off to read the docs!

Mike