Fright (Savage): Difference between revisions

From HLKitWiki
Jump to navigationJump to search
New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview=== Fright is a Savage Worlds mechanic that works very similarly to injuries. If a character suffers a severe enough ...
 
(No difference)

Revision as of 07:52, 18 December 2008

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

Overview

Fright is a Savage Worlds mechanic that works very similarly to injuries. If a character suffers a severe enough scare, they can become subject to a particular fright behavior on a permanent basis. Some frights confer a hindrance in the same way that injuries do, and we need to handle that properly.

Frights as Advancement

When a character has a severe scare and incurs a fright, that becomes a permanent effect on the character. Since frights do not apply adjustments to attributes, there is no requirement for frights to be handled as advancements. However, the basic logic for treating them as advancements is already in place, and it should also make sense to users. So we'd be well-served by setting up frights as a new type of advancement.

Before we launch into doing that, though, we should first consider the bigger picture. Frights either confer temporary penalties or a hindrance of some sort. It's also possible through the course of play that a character will become subject to a new hindrance that has no association with a fright. Consequently, it's probably a better approach for us to make it possible to assign a new hindrance to a character as a advancement. Any hindrance conferred due to fright represents a special case, while adding hindrances in general solves the general case.

Hindrances as Advancement

We can add hindrances via their own new advancement very easily. The only special detail that we have to make sure of is that we must ensure the cost of a hindrance advance is zero, just like we did for injuries. Beyond that, adding hindrances via advancement works just like adding a new skill or edge. The corresponding advancement thing should look a lot like the example provided below.

<thing
  id="advHinder"
  name="New Hindrance"
  compset="Advance"
  description="Select this advance to ascribe a new hindrance to the character during play. When acquired as an advancement, no offsetting rewards are gained for the hindrance.">
  <fieldval field="advAction" value="New Hindrance"/>
  <fieldval field="advDynamic" value="component.Hindrance"/>
  <fieldval field="advCost" value="0"/>
  <tag group="Advance" tag="AddNew"/>
  <child entity="Advance">
    <tag group="Advance" tag="MustChoose"/>
    </child>
  </thing> 

Add Frights

There is one fright that confers an effect which is not a standard hindrance - the "Mark of Fear". Consequently, we need to define that effect as its own new hindrance so that it can be selected by the user if it comes up during play. For simplicity, we'll add the new hindrance along with all the other hindrances in the file "thing_hindrances.dat". Our new hindrance should look similar to the one shown below.

<thing
  id="hinMkFear"
  name="Mark of Fear"
  compset="Hindrance"
  isunique="yes"
  description="Description goes here">
  <fieldval field="hinMajor" value="0"/>
  <eval value="1" phase="PreTraits" priority="5000">
    <before name="Calc trtFinal"/><![CDATA[
    #traitbonus[trCharisma] -= 1
    ]]></eval>
  </thing> 

Hindrance Advances Don't Confer Rewards

We have one last detail that needs to be sorted out. Hindrances that are added via advances need to not confer reward points to the character. Looking at the current Eval script for the "Hindrance" component, rewards are accrued for any hindrance that is user-added. Unfortunately, any hindrance added as an advancement is user-added, so it will confer reward points. So we need to revise the script in some way to preclude advancements from being accrued. One detail that we can always rely upon is that every advance always possesses an "Advance.?" tag. This means that we can simply check for an advancement tag and ignore the accrual if we find such a tag. A revised version of the Eval script that incorporates this change is presented below. 

<eval value="3" phase="Setup" priority="5000"><![CDATA[
  ~if this hindrance was not add by the user, skip it entirely
  if (isuser = 0) then
    done
    endif
  ~if this hindrace was added as an advance, skip it entirely
  if (tagis[Advance.?] <> 0) then
    done
    endif
  ~consume another hindrance slot or two, depending on the severity
  #resmax[resHinder] += field[hinMajor].value + 1
  ]]></eval>