Difference between revisions of "Countering Hindrances (Savage)"

From HLKitWiki
Jump to: navigation, search
(Adding the Rewards)
Line 81: Line 81:
 
   <fieldval field="rewPoints" value="1"/>
 
   <fieldval field="rewPoints" value="1"/>
 
   <eval index="1" phase="Setup" priority="5000"><![CDATA[
 
   <eval index="1" phase="Setup" priority="5000"><![CDATA[
     herofield[acCashMult].value *= 2
+
     herofield[acCashMult].value += 1
 
     ]]></eval>
 
     ]]></eval>
 
   </thing>  
 
   </thing>  
 
</pre>
 
</pre>

Revision as of 19:56, 8 February 2009

Context: HL KitAuthoring Examples … Savage Worlds Walk-Through 

Overview

When a user selects hindrances for a character, that character gains benefits to offset those hindrances. The hindrance points are accrued, and the user must now redeem those hindrance points.

Component and Component Set

Within the Savage Worlds game system, there are four choices for how to spend the accrued hindrance points, so we need a way to mange this. This entails adding a new component and component set, and we'll refer to each of these options as a "Reward". Each reward is extremely simple, with a field specifying how many hindrance points are redeemed for the reward and all other details being managed through an Eval script.

An appropriate implementation of the component and component set are presented below. Note that the same reward can be selected multiple times, so it's important that rewards not be designated as unique.

<component
  id="Reward"
  name="Reward for Hindrances"
  autocompset="no"
  panellink="abilities">
  <field
    id="rewPoints"
    name="Hindrance Points"
    type="static">
    </field>
  <eval index="1" phase="Setup" priority="5000"><![CDATA[
    #resspent[resHinder] += field[rewPoints].value
    ]]></eval>
  </component>

<compset
  id="Reward"
  forceunique="no">
  <compref component="Reward"/>
  </compset> 

Adding the Rewards

We'll add all of our rewards into a new file named "thing_rewards.dat", thereby keeping them all together in a convenient location. Three of the rewards entail merely adjusting the maximum value for a resource to confer the benefit. For example, the reward that grants an extra attribute point is shown below. Remember that the same reward can be selected multiple times, so rewards must not be unique.

<thing
  id="rewAttrib"
  name="+1 Attribute Point"
  compset="Reward"
  description="Description goes here">
  <fieldval field="rewPoints" value="2"/>
  <eval index="1" phase="Setup" priority="5000"><![CDATA[
    #resmax[resAttrib] += 1
    ]]></eval>
  </thing>

The fourth reward doubles the character's starting cash, which is easy in concept but currently cannot be handled by the data files. There is a field on the "Actor" component for tracking the character's starting cash, but this is a user-controlled field. As such, if we double this value in a script, we'll physically change the value that the user can specify. In addition, we'll keep doubling the value again every time that HL needs to re-evaluate everything. So we need to keep the effects of this reward decoupled from the user-controlled starting cash field.

One simple solution would be to revise the Eval script within the "Actor" component that calculates the total cash possessed by the character. We could check for the existence of the "double cash" reward and multiply the starting cash by two if it's found. This could entail defining a tag that the reward could assign to the hero, or the Eval script could explicitly look for the specific reward. While this would work, it would be exclusively tied to this one reward. Given that this is a role-playing game, it's quite likely that some GMs (or potentially some official supplements) will introduce other cases that can influence the character's starting cash. So we should come up with a more generalized solution.

A solid, generalized solution would take the form of adding a new field to the "Actor" component. This new field would track a starting cash multiplier that would default to one. For the reward that doubles the starting cash, the value could be multiplied by two. For another effect that decreases starting cash by 10%, the value could be multiplied by 0.9. The final value of this field could then be integrated into the Eval script that calculates the net cash possessed by the character. Putting it together, the new field and revised Eval script would look like those presented below.

<field
  id="acCashMult"
  name="Starting Cash Multiplier"
  type="derived"
  defvalue="1">
  </field>

<eval index="3" phase="Effects" priority="5000"><![CDATA[
  ~our net cash is our configured starting cash plus our accrued cash
  field[acCashNet].value = field[acCashCfg].value * field[acCashMult].value + hero.usagepool[TotalCash].value
  ]]></eval>

Once the above mechanics are in place, we can add the fourth reward, and it should look similar to the example shown below.

<thing
  id="rewCash"
  name="Double Starting Cash"
  compset="Reward"
  description="Description goes here">
  <fieldval field="rewPoints" value="1"/>
  <eval index="1" phase="Setup" priority="5000"><![CDATA[
    herofield[acCashMult].value += 1
    ]]></eval>
  </thing>