NetExaltedXP/Trait

Trait Class

The Trait Class is the second main workhorse of this proposal, the first being theNetExaltedXP/Character class. It has two modes, after a fashion. The first is inside theNetExaltedXP/NetExalted class, where it is actually relatively inert. It's there to potentially be read into aNetExaltedXP/Character class, and not much more.

Inside aNetExaltedXP/Character, it has a lot more power. Primarily, it throws around strings and/or numbers as they are requested of it, and can be quite flexible.

Data Members

• NetExaltedXP/Data Array - A special, fixed-size Array containing a few members that all Traits will posess
  • Name - The name of the Trait
  • Type - The type of the Trait
  • Group - A Trait Grouping
  • Value - The value of the Trait
  • Initialize - the first Value of the Trait
  • Multiplicity - "Single" Means that the Trait may only be 'taken' once, though its value may be modifiable. "Multiple" Means that it may be taken multiple times, its Value being set to the number of times it's taken ('owns eight Marukani swifts' or somesuch). An equation (even if it's only a number) specifies that it may be taken up to a certain number of times, and that number is stored in Value (Ox-Body and so on).
  • Editable - A specialized Value, if its Value is 0, then the Base Value cannot be directly changed by the User (it's a Derived Trait, such as Health Levels, Peripheral Essence, etc). If 1, than it can be. A 2 means that theNetExaltedXP/Character manages the score in some other fashion (for assigning XP and so on). A 3 means it is not governed by any rules (Character name, etc.)
  • Range - If specified, a comma-delimited list of acceptable values. For choosing Caste, for example.
    • Something like this will need triggers.
• NetExaltedXP/Character Parent - a pointer to the parent character. If null, we're residing in theNetExaltedXP/NetExalted class.
• NetExaltedXP/Data Array) - The remaining necessary values the Trait may have. This will vary wildly - the Name Trait, for the Character's Name, will have none of these. A Charm Trait will have several.
  • Values with names beginning with the word 'Minimum', 'Maximum', 'Limit', 'Cost', 'Equals', 'Override' and perhaps several others will need to be recognized specifically, so that Traits may govern their own limits, costs and prerequisites.
    • 'Prerequisites' will probably be an alias specifying a comma-delimited list of Traits, all of which get interpreted as 'Minimum(Trait), 1' entries.

Private Functions

• int Parse (String) - parses one of the Trait's Data.Value elements.
  • Must be able to handle addition, subtraction, multiplication, division, if-else statements, conditional and boolean operations.
  • Must be able to reference other values and parse them. For example, "Backgrounds->Breeding.Maximum" Would typically return a 5, or a 6 if the character has Legendary Breeding. The order goes (Type) -> (Trait).(Value), where the default is simply putting in (Trait) will return the Trait's basic Value.
  • "String:" - should return the following as just a plaintext string, or, getting fancy, use quotes and allow concatenation as such.
  • "None" Should return 0

Public Functions

• boolean IsPrerequisite (String) - Searches for the input word in the Prerequisites in the various 'Minimum', 'Maximum', and 'Equals' fields. Returns True if so, False otherwise.
• String Verify (String New Value) - verifies whether the new value the Trait has received can be legally set. It returns either a null string (success) or an error message explaining why the setting failed.
  • This is a public, rather than private, function because it will need to be called by the character when a value gets changed.
• boolean SetValue (String New Value) - Sets the Trait's value if it ends up being legal.
• String GetValue (ValueName) - Retrieves the parsed (if necessary) value. If no name is given, return the Trait's base Value.
• boolean Override (value, string) - Attempts to override one given value with another (typically because someone purchased a Merit or Flaw)
  • Stuff like this is going to have to be handled carefulle and perhaps reconsidered, maybe frequently.

• (Array ofNetExaltedXP/Data) GetPrequisites() - Returns a list of Traits used as prerequisites

Methodology

• The purchasing system
  • TheNetExaltedXP/Character class will have a resource manager govern the actual managings of this, but the rules are entirely Trait-governed.
  • Traits that can be purchased / upgraded will have two 'keywords' to utilize:
    • Limit - Typically, a Trait will have LimitXP, LimitBP, LimitAbilityDot, and so on. Limit is the keyword, what comes afterwards is the name of the Trait utilized. It can be an equation - it just refers to the maximum purchasable value.
    • Cost - Like Limit. It, also, can be an equation, not only for favored abilities but also for XP costs in general, of course.
    • Type and Group specifically refer to the purchase group. The Resource Manager will concern itself with things having a Cost, and act accordingly.
  • The actual resource-providing Trait itself is pretty ignorant. The Resource manager changes its values, and the Trait it purchases provides the rules for it.

Comments

Are you deliberately avoiding exception handling for some reason? Why a doubly linked list? This is the perfect case for using Hashtable? --flymolo

I'm a C++ junky, sorry, I tend to think exception handling is for unexpected errors rather than those predicted and user-caused. It's the results that are needed, though, and the trait, if it picks up the action, needs to be the one to send the appropriate message, whether through the exception handler or a return value.

A Hash table should be fine, I haven't built one in awhile. I'll need to update this to have Traits handle multiples of themselves (for now, since that only really matters for equipment, and the Hash is going to have to be pretty complex, as some Traits will have the same name, but different types, requiring a two-dimensional setup. That will be the Character class' problem to translate, although it does mean the data junkies aren't going to get away with specifying 'Sword' but almost always 'Weapon->Sword'

Shouldn't GetPrerequisites return a Value array (I ought to rename that Data array to keep from confusing).-Xeriar

Flip through the Java API if you get a chance specifically java.util , That has all the data structure classes including hashtable. Now this involves casting on the way out, because generics are java 5(1.5) only.

I was thinking the insert would look like

if (!hash.exists(swordobj.shortname)){

hash.put(swordobj.shortname,swordobj);

hash.put(swordobj.longname,swordobj);

}

else {

hash.delete(swordobj.shortname);

hash.put(swordobj.longname,swordobj);

}

But that's because I'm ok with scripts breaking if someone creates an artifact called Strength.

GetPrequisites I was thinking would return the list of Traits that the skill required, but creating all the Traits seemed too heavy so I settled for skill names. We could return String[][] so we get skill value pairs. --flymolo

We should stick with a standard method of passing around data, less headache in the long run. Anyways, I need to modify this to have one Trait govern one or more other Traits somehow - preferably elegantly. For example, if someone takes the Artifact Background, they get a number of points to purchase Artifacts with. -Xeriar

I was thinking about making a fake Traits type called points. It would have things like how many PrimaryAttributePoints. This would allow us to code the points to spend into the Traits file, and modify them with either backgrounds(Like Artifact) or merits/flaws like diminished attributes. -flymolo

I've been thinking of something similar, basically a governing Trait that could be called from by various subtraits. That itself is fine (even with favored abilities) in concept, except for that annoying Primary/Secondary/Tertiary attribute dot spread. -Xeriar