Adding Edges (Savage)

Context: HL Kit … Authoring Examples … Savage Worlds Walk-Through 

Overview

With the mechanics for edges in place, we now need to get them implemented. We'll keep them all together as a group by creating a new "thing_edges.dat" file where they will be added. All of the reminders outlined for hindrances also apply to edges, and the following sections discuss a few key edges to highlight important facets of their implementation.

Something Simple

We'll start with the simple "Combat Reflexes" edge. This edge is of type "Combat" and has a minimum rank of "Seasoned" (or one), so we assign the tag and set the field value accordingly. The result is shown below.

<thing
  id="edgComRefs"
  name="Combat Reflexes"
  compset="Edge"
  isunique="yes"
  description="Description goes here">
  <fieldval field="edgMinRank" value="1"/>
  <tag group="EdgeType" tag="Combat"/>
  </thing> 

User Activation

Next up is the "Berserk" edge, which demonstrates the handling of user-activated behaviors. The fact that there is a user-activated behavior is controlled by assigning the "User.Activation" tag. We use an Eval script to assign the behaviors, wrapping them within a test of the activated ability state. This edge also demonstrates the need to carefully distinguish between using the "#traitbonus" and "#traitroll" macros. The net result is the definition below.

<thing
  id="edgBerserk"
  name="Berserk"
  compset="Edge"
  isunique="yes"
  description="Description goes here">
  <fieldval field="edgMinRank" value="0"/>
  <tag group="EdgeType" tag="Background"/>
  <tag group="User" tag="Activation"/>
  <eval value="1" phase="PreTraits" priority="5000">
    <before name="Calc trtFinal"/><![CDATA[
    if (field[abilActive].value = 0) then
      #traitbonus[trParry] -= 2
      #traitbonus[trTough] += 2
      #traitroll[skFighting] += 2
      endif
    ]]></eval>
  </thing> 

Arcane Backgrounds

Each arcane background is granted via an edge. That means that each arcane background thing must automatically add all of the proper logic for managing that arcane background. One thing can automatically add any number of chained things by use of the "bootstrap" mechanism within Hero Lab, so our edge will bootstrap the logic for the arcane background. The "Magic" background below demonstrates this.

<thing
  id="edgArcMag"
  name="Arcane Background: Magic"
  compset="Edge"
  isunique="yes"
  description="Description goes here">
  <fieldval field="edgMinRank" value="0"/>
  <tag group="EdgeType" tag="Background"/>
  <bootstrap thing="arcMagic"/>
  </thing> 

Trait Pre-Requisites

Numerous edges possess pre-requisites on different traits, such as requiring a Strength attribute of d8 or higher, or needing a Fighting skill of d10 or higher. Each edge needs to implement these pre-requisites individually, but the structure and behavior is always the same. We use the "Sweep" edge as an example to show how this works below.

<thing
  id="edgSweep"
  name="Sweep"
  compset="Edge"
  isunique="yes"
  description="Description goes here">
  <fieldval field="edgMinRank" value="0"/>
  <tag group="EdgeType" tag="Combat"/>
  <prereq iserror="yes" message="Strength d8 required.">
    <valid><![CDATA[
      if (#trait[attrStr] >= 4) then
        @valid = 1
        done
        endif
      altthing.linkvalid = 0
      ]]></valid>
    </prereq>
  <prereq iserror="yes" message="Fighting d8 required.">
    <valid><![CDATA[
      if (#traitfound[skFighting] >= 4) then
        @valid = 1
        done
        endif
      altthing.linkvalid = 0
      ]]></valid>
    </prereq>
  </thing>

Note that each separate requirement is implemented as a distinct pre-requisite instead of merging them into a single test. While this is not required, it is a highly recommended approach. The advantage of doing this is that Hero Lab can readily report each individual requirement that is not satisfied, providing greater detail to the user about what is wrong and needs to be fixed.

Pre-Requisites on Other Edges

There are quite a few edges that are boosted versions of other edges. They can only be taken when the lesser version of the edge has already been taken. For example, the "Improved Arcane Resistance" edge can only be taken if the "Arcane Resistance" edge has already been taken. So we need to setup appropriate pre-requisites on the presence of other edges. Since every edge has an identity tag and those identity tags are being automatically forwarded to the hero by a component script, we can check the hero for the existence of the identity tag corresponding to the edge that is depended upon. The implementation of "Improved Arcane Resistance" shown below demonstrates how this is done.

<thing
  id="edgArcRes2"
  name="Improved Arcane Resistance"
  compset="Edge"
  isunique="yes"
  description="Description goes here">
  <fieldval field="edgMinRank" value="0"/>
  <tag group="EdgeType" tag="Background"/>
  <prereq iserror="yes" message="Arcane Resistance required.">
    <valid><![CDATA[
      if (hero.tagis[Edge.edgArcRes] <> 0) then
        @valid = 1
        done
        endif
      altthing.linkvalid = 0
      ]]></valid>
    </prereq>
  </thing> 

Deferring Complex Special Cases

There will be times when you run into special cases that you want to implement correctly but that will require a non-trivial amount of extra work. In those cases, the best strategy is to figure out a suitable interim solution and plan to implement a "proper" solution once everything else is in place. There are two shining examples of this among the edges of Savage Worlds.

The first is the "Scholar" edge, which requires the user to select two "Knowledge" skills at d8 or higher and confers a "+2" bonus to each of the selected skills. Allowing the user to make the selections requires that edges support two separate menus from which the user can select one skill each. The presented list of skills must be filtered to only show the existing "Knowledge" skills, and it should ideally only include skills with a d8 rating or higher. This represents a fair amount of work to implement, so we're going to defer adding this until later. For the time being, we'll setup the "Scholar" edge to simply require that at least two "Knowledge" exist at d8 or higher. We'll also leave it up to the user to add two suitable permanent adjustments to apply the appropriate bonuses to the desired skills. While this solution is a bit clunky, it allows the user to achieve the desired result without requiring lots of extra development work - a perfect interim solution when you're trying to get your initial set of files operational.

The second example of complexity that is best deferred is the "Professional" edge, along with its siblings "Expert" and "Master". Each of these requires that the user select a trait that is at a d12 rating, with that trait being granted a "+1" bonus. Just like the "Scholar" edge, a menu is needed that properly filters the list of traits shown to those that qualify and from which the user can make the selection. As an interim solution, these three edges can simply verify that at least one trait is at a d12 rating and the user can add a permanent adjustment to apply the bonus to the trait.

Acknowledging Our Limitations

There is one edge that we simply can't implement with 100% completeness, unless we want to inconvenience the user. The "Gadgeteer" edge requires that the character have at least two "Knowledge" skills at a d6 or higher, and those skills must be scientific in nature. The problem is that the user is free to type in whatever he wants for the domain of the skill, so we have no way to determine whether a particular skill is scientific or not. In situations like this, we are forced to either add some contrived mechanism to get the information we need or defer the details to the user. Deferring to the user is almost always the best path to choose. With "Gadgeteer", we can verify that there are at least two "Knowledge" skills at a d6 or higher, but we must leave it up to the user to verify that both of them are truly scientific in focus.