Skills (Savage)

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

Overview

Once attributes are working, we need to focus on the next most fundamental facet of the game system, working our way progressively so that we always build on top of the mechanisms we've implemented thus far. For Savage Worlds, the next facet is skills.

How to Handle Skills?

As we did for attributes, the first thing we need to do for skills is figure out what mechanics we haven't handled yet. After close examination, there are a number of aspects of skills in general that require special handling distinct from attributes. We also need to assess any differences between how skills are handled within the Skeleton files versus the Savage Worlds game system. Lastly, we need to review each individual skill to see if any of them will introduce complexities, handling them as appropriate.

Auto-Add of Skills

The most obvious difference between skills in Savage Worlds and the Skeleton data files is that all skills are auto-added by the Skeleton files. We can stop auto-adding skills easily enough, but then we'll need to modify the tab panel to let the user add skills. That entails a bit more work that we aren't ready to do yet, so we'll defer fixing this issue for a little while.

Calculated Attack Values

Within the Skeleton files, attack values for weapons are calculated by adding a value for the weapon to the underlying skill and its linked attribute. Weapons work nothing like this for Savage Worlds. As such, the calculations of weapon attack values that are provided by default need to be changed. In addition, these calculations reference the "Melee" and "Shooting" skills that are pre-defined - and that are about to be replaced. We could try to figure out how this should work now, but it's premature to do so. The simplest solution is to just comment out the script code that calculates the attack values for now and replace it with something appropriate when it's time to look at adding weapons.

Open the file "equipment.str". If you search for references to the "wpNetAtk" field, you'll find its definition and two separate Eval scripts that calculate its value. One script is within the "WeapMelee" component and the other is in the "WeapRange" component. Comment out these scripts, but don't delete them - we'll replace them with proper logic later on. To comment them out, you can either place a "~" at the start of each line of script code, or you can put the entire XML "eval" element within an XML comment wrapper. Both methods will work equally well, and both are shown below.

<!--
<eval index="1" phase="Final" priority="7000" name="Calc wpNetAtk"><![CDATA[
  field[wpNetAtk].value = #trait[skShooting] + field[wpBonus].value + field[wpPenalty].value
  ]]></eval>
-->

OR

<eval index="1" phase="Final" priority="7000" name="Calc wpNetAtk"><![CDATA[
  ~field[wpNetAtk].value = #trait[skShooting] + field[wpBonus].value + field[wpPenalty].value
  ]]></eval>

Knowledge Skill

After reviewing all of the skills, only one of them has any interesting implications - the "Knowledge" skill. Within Savage Worlds, skills are typically unique, existing only once. However, the Knowledge skill must have an appropriate "domain" specified for it, and it can be taken multiple times with separate domains for each. In order to support this, a few changes need to be made to how skills work in general.

First of all, the "Skill" component set currently forces all skills to be designated as "unique". The "Knowledge" skill must not be a unique skill so that it can be purchased multiple times, while all other skills should remain unique. Therefore, the "forceunique" attribute within the "Skill" component set definition (near the bottom of the file "traits.str") needs to be eliminated. It's important that you not change the attribute to have a "no" value, since that will force all skills to be non-unique. Instead, we want the default behavior, which allows some skills to be designated as unique and others as non-unique.

The remaining facet of the "Knowledge" skill that needs to be handled is allowing the user to specify the appropriate "domain". This requires that we add a new text-based field to store the domain, as well as a way to generically identify skills that require the user to specify a domain. Since this is a mechanic that many game systems require, the Skeleton files include built-in mechanisms to handle it. The "Domain" component is provided such that you can simply integrate it into a component set to provide domain tracking, so add a new "compref" element to the "Skill" component set, as shown below.

<compset
  id="Skill">
  <compref component="Skill"/>
  <compref component="Trait"/>
  <compref component="Domain"/>
  <compref component="CanAdvance"/>
  </compset>

Similarly, the "User.NeedDomain" tag is defined as a convenient means to designate a thing that requires a domain, so we can assign this tag to the "Knowledge" skill. It is defined as a "User" tag because the tag will be able to be specified by users who create their own custom skills through the Editor.

Add Skills for Game System

All of the necessary mechanics should now be in place for skills, so it's time to define them. Open up the file "thing_skills.dat" and you can begin adding all the Savage Worlds skills to the file. [Note: For the moment, do not delete the sample skill.]

As we discovered for attributes, all of the mechanics for skills are managed by the underlying components, so each skill is quite simple. You can copy the sample skill provided and adapt it appropriately for each skill of the game system. The "Investigation" skill is shown as an example below.

<thing
  id="skInvest"
  name="Investigation"
  compset="Skill"
  isunique="yes"
  description="Description goes here">
  <fieldval field="trtAbbrev" value="Invst"/>
  <tag group="DashTacCon" tag="NonCombat"/>
  <link linkage="attribute" thing="attrSma"/>
  </thing> 

When defining skills, you'll need to specify the linked attribute for each. This is accomplished via the "link" XML attribute, as shown above. Every skill requires a linkage, and the compiler should report an error if you omit the linkage for a particular skill.

Any skill that should be shown within the non-combat list of skills on the Tactical Console needs to be flagged as such. You can do this by assigning the "DashTacCon.NonCombat" tag to the skill. When assigned, the skill will be included. We'll review this in more detail later on.

The one skill that will be slightly different from the others is the "Knowledge" skill. As mentioned previously, this skill must be non-unique and must have the "User.NeedDomain" tag assigned. The "Knowledge" skill is shown below as an example.

<thing
  id="skKnow"
  name="Knowledge"
  compset="Skill"
  description="Description goes here">
  <fieldval field="trtAbbrev" value="Know"/>
  <tag group="User" tag="NeedDomain"/>
  <tag group="DashTacCon" tag="NonCombat"/>
  <link linkage="attribute" thing="attrSma"/>
  </thing> 

Once you've added all the new skills, reload the data files and verify that they all show up properly.

Delete Sample Skill

Once the skills all show up and work properly, it's safe to delete the sample skill. Unlike with attributes, the sample skill is not referred to by anything else and can be freely deleted.