RE: [Adonthell-devel] Hello Hello

[Mike Avery]

Been reading the docs, and just read the rules documentation. Are the rules
in this document the decided approach to melee hit determiation and damage
calculation?

Mike

> -----Original Message-----
> From: Mike Avery [mailto:address@hidden
> Sent: Thursday, May 01, 2003 10:18 AM
> To: 'Programmers playground'
> Subject: RE: [Adonthell-devel] Hello Hello
> 
> 
> > > 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
> 
> 
> _______________________________________________
> Adonthell-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/adonthell-devel
>