Hindrance Support (Savage)

From HLKitWiki
Revision as of 20:27, 16 December 2008 by Rob (Talk | contribs) (New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview=== Now that we've got all the pieces in place that are depended upon, we can add support for hindrances, which are d...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Context: HL KitAuthoring Examples … Savage Worlds Walk-Through 

Overview

Now that we've got all the pieces in place that are depended upon, we can add support for hindrances, which are disadvantages that can be optionally selected for a character.

Component and Component Set

While hindrances have a lot of behaviors in common with the existing "Ability" component set, they also introduce a variety of new behaviors that must be properly managed. As such, we need to define a new "Hindrance" component and a corresponding component set. We'll flesh out the new component in the following sections, so we'll start by defining a simple component that does nothing as an initial framework. Then we can define our component set appropriately, building upon the "Ability" and "SpecialTab" components as well. The net result is the following:

<component
  id="Hindrance"
  name="Hindrance"
  autocompset="no"
  panellink="abilities">
  </component> 

<compset
  id="Hindrance"
  forceunique="yes">
  <compref component="Hindrance" primary="yes"/>
  <compref component="Ability"/>
  <compref component="SpecialTab"/>
  </compset> 

Inclusion on "Special" Tab

Since hindrances will come up during play, we want to make sure they appear on the "Special" tab. The basic appearance is handled by inclusion of the "SpecialTab" component in the component set, but we need to customize the behavior appropriately. First of all, we need to define a new classification tag for ordering the display of hindrances on the "Special" tab. Add a "Hindrance" tag to the "SpecialTab" tag group within the "tags.1st" file, being sure to specify a suitable order value to sequence everything appropriately.

Once the tag is defined, we then need to make sure that all hindrances are assigned the tag. We can do that within the component by simply adding the line below to the component:

<tag group="SpecialTab" tag="Hindrance"/> 

Major Versus Minor

Hindrances can be classified as either major or minor in nature. Some hindrances are always major, others are always minor, and there are some where the user can decide whether the severity is major or minor. So we need to define a field for hindrances to track the severity of the hindrance. Since the severity is a simple two-state condition, we use a value of zero to indicate a minor hindrance and a value of one to indicate something major. The result is shown below.

<field
  id="hinMajor"
  name="Is Major?"
  type="user"
  minvalue="0"
  maxvalue="1">
  </field> 

We also need to handle the distinction between a hindrance with a fixed severity and one that is user-selectable. We can use either a field or tag for this, but a tag is easier because we can always detect a tag within a tag expression, so we'll use a tag this time. We only need one tag, since the tag indicates one behavior and the lack of the tag indicates the other. So we define a new tag in the "User" tag group to indicate a hindrance is user-selectable and give it the "UserSelect" unique id. Any hindrance that is user-selectable must be assigned this tag as part of its definition.

User-Specified Domain

Certain hindrances are similar to the "Knowledge" skill in that they require the user to specify a "domain" in which the hindrance applies. For example, the "Phobia" and "Habit" hindrances each need to identify the subject of the phobia or the type of habit. Just like we did for skills, we need to integrate the "Domain" component into the component set so that the user-specified domain can be tracked for appropriate hindrances. 

We also need to identify which hindrances require the user to provide a domain. Fortunately, we can easily re-use the same "User.NeedDomain" tag that we leveraged for skills. If a hindrance has the "User.NeedDomain" tag assigned, then the user is expected to specify a domain.

If a hindrance has a domain specified, then it would be valuable for that domain to be shown as part of the hindrance on the "Special" tab. Consequently, we should generate a suitable, customized name for displaying the hindrance on the "Special" tab. This can be achieved by adding a script to the component that incorporates the domain into the display name, as appropriate, with the new script looking similar to the one below.

<eval value="2" phase="Render" priority="5000"><![CDATA[
  ~if there is no domain given, just use the default name
  if (tagis[User.NeedDomain] = 0) then
    done
    endif
  ~synthesize an appropriate name for display that incorporates the domain
  var domain as string
  if (field[domDomain].isempty = 0) then
    domain = field[domDomain].text
  else
    domain = "No Domain Given"
    endif
  field[spcName].text = field[name].text & " (" & domain & ")"
  ]]></eval> 

Hindrance Points

Whenever a hindrance is selected for a character, hindrance points are accrued that can be traded in for offsetting benefits to the character. Each hindrance must therefore add the appropriate number of hindrance points to the resource we created earlier. Since the rule for hindrance points is one point for a minor hindrance and two points for a major hindrance, we can perform this automatically for each hindrance via a script on the component. The script would look something like the one shown below.

<eval value="3" phase="Setup" priority="5000"><![CDATA[
  #resmax[resHinder] += field[hinMajor].value + 1
  ]]></eval> 

Identification for Pre-Requisites

There are a few situations where a particular hindrance conflicts with something else. For example, it's not possible to combine the "Luck" edge with the "Bad Luck" hindrance. We also have to identify when the user tries to take the "All Thumbs" hindrance with the "Elves" race. In order to do this, we need to track which hindrances have been added to the character in a centralized way. This is most easily accomplished by designating an "identity" tag group for hindrances and then forwarding the identity tag of each selected hindrance to the hero. The net result is that the hero will always possess tags for each hindrance chosen for the character.

We saw earlier that designating an identity tag group on a component requires a single line to be added to the component. This defines and assigns the tag to each thing. Then a one-line script can be defined for the component that forwards the identity tag up to the hero. The two pieces should look like the following for hindrances:

<identity group="Hindrance"/>

<eval value="1" phase="Setup" priority="5000"><![CDATA[
  perform forward[Hindrance.?]
  ]]></eval>