How to represent character abilities in code

Started by
3 comments, last by Drigovas 16 years, 3 months ago
Is there some kind of standard method developers use for player abilities ? Also is there a standard way to store player data such as stats, equipment and which powers the player has ?
Advertisement
Quote:Original post by vaneger
Is there some kind of standard method developers use for player abilities ?

No.

The most common would be to have a Skill or Ability class, which all various skills and abilities derive from. Something like:

class Skill
class Crosscut : Skill
class Jump : Skill
class DemonSlash : Skill



Quote:
Also is there a standard way to store player data such as stats, equipment and which powers the player has ?

Variables. and HTML
Inheritance is not the solution (though it might be the most common). You're tying information into the type which is a no-no. Using a strategy is much better since the majority of Skill info is common, just the actual effect is the functional change.

As for storage, if you're in a DB environment, a individual table with 3 keys (the primary key, the entity, the skill definition) and perhaps some ancillary info (what provided the skill [item, level, guild, quest, etc.], uses left?, level?) sounds pretty standard.
States. A formalized state machine, you derive of base type state. The state has logic that runs when it is entered, continued, and exited. 99% of what the state is is configurable via the state creator. The enter and exit's are syncronized across the network.

EX:

<state type="base" name="jumping"> <animtion>  <track looping="false" file="jump" /> </animation> <enter>  <setphysics>   <vel y=2/>  </setphysics> </enter> <exit>  <playsound file="grunt" /> </exit></state><state type="movement" name="walking"> <animtion>  <track looping="true" file="walk" /> </animation> <enter>    <setcamera type="camera_far" /> </enter> <exit> </exit></state>


These behavior state requires no code side programming. However, this following state requires code side support to blend the two animation tracks to acheive 2 axis aiming.

<state type="aiming" name="aiming"> <animtion>  <track looping="false" file="aimX" />    <track looping="false" file="aimY" /> </animation> <enter>  <setcamera type="camera_close" /> </enter> <exit> </exit></state>
Agree with Telastyn that inheritance is not the answer here. You'll be using inheritance at some point, of course, but an individual skill can most frequently be broken down to a number of atomic behaviors pretty easily. For example, you may have your skills actually expressed as behavioral tuples [just an example] like <use condition, target predicate, effect> [which is an example from my current project, actually], each of which of these representing a base class. How you use the information is dependent on what you construct your skills out of, but in my case it operates something like this:
if(use condition) effect(result of target predicate);
The components are described in my code, but the actual skills are all stored externally in files [which means fewer bugs than re-coding the same skills over and over].

In my specific example, each of the elements in the tuple is actually a sort of base class that represents an atomic and interchangeable behavior, which I use to assemble skills like things made out of building blocks. An example of an effect would be "hurt for x damage of y type", or a target predicate could be "all entities in cone of x radians and y range toward target", or "x meters radius around user of skill", a use condition could be something simple like "alive", or "has full clip of ammunition". The use condition is analyzed to enable or disable skills as required, the target predicate would provide what sort of possible targets are acceptable, and how to submit them [target 1 location, target 2 enemy units, target self, target friendly, etc], will search over the valid entity set to derive a set of entities over which the skill will have an effect, and the effect will be applied to all things in the set.

Works very good, was quick and easy to code, and with very little redundancy. Also means I can procedurally generate skills [which I do, actually quite a bit in certain instances] since they are not hard-coded.

This topic is closed to new replies.

Advertisement