Hindrance Support (Savage): Difference between revisions
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... |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 18: | Line 18: | ||
<compset | <compset | ||
id="Hindrance | id="Hindrance"> | ||
<compref component="Hindrance"/> | |||
<compref component="Hindrance | |||
<compref component="Ability"/> | <compref component="Ability"/> | ||
<compref component="SpecialTab"/> | <compref component="SpecialTab"/> | ||
Line 28: | Line 27: | ||
===Inclusion on "Special" Tab=== | ===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. | 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. This is solved by adding 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. | ||
<pre> | |||
<value id="Hindrance" order="30"/> | |||
</pre> | |||
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: | 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: | ||
Line 51: | Line 54: | ||
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. | 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. | ||
<pre> | |||
<value id="UserSelect"/> <!-- Whether a hindrance is user-selectable for major/minor (vs. fixed) --> | |||
</pre> | |||
===User-Specified Domain=== | ===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. | 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. This is achieved by adding a new "compref" element to the component set that includes the "Domain" component. | ||
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. | 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. | 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. By default, the "Domain" component already integrates the domain into the name, so we can simply use that default behavior. If we wanted to do something different, would could define an Eval script that sets the "spcName" field to whatever is appropriate. | ||
===Hindrance Points=== | ===Hindrance Points=== | ||
Line 82: | Line 72: | ||
<pre> | <pre> | ||
<eval | <eval index="2" phase="Setup" priority="5000"><![CDATA[ | ||
#resmax[resHinder] += field[hinMajor].value + 1 | #resmax[resHinder] += field[hinMajor].value + 1 | ||
]]></eval> | ]]></eval> | ||
Line 91: | Line 81: | ||
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. | 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: | We saw earlier that designating an identity tag group on a component requires a single line to be added to the component. This automatically defines the tag group and assigns the proper 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: | ||
<pre> | <pre> | ||
<identity group="Hindrance"/> | <identity group="Hindrance"/> | ||
<eval | <eval index="1" phase="Setup" priority="5000"><![CDATA[ | ||
perform forward[Hindrance.?] | perform forward[Hindrance.?] | ||
]]></eval> | ]]></eval> | ||
</pre> | </pre> |
Latest revision as of 20:33, 11 February 2009
Context: HL Kit … 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 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"> <compref component="Hindrance"/> <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. This is solved by adding 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.
<value id="Hindrance" order="30"/>
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.
<value id="UserSelect"/> <!-- Whether a hindrance is user-selectable for major/minor (vs. fixed) -->
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. This is achieved by adding a new "compref" element to the component set that includes the "Domain" component.
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. By default, the "Domain" component already integrates the domain into the name, so we can simply use that default behavior. If we wanted to do something different, would could define an Eval script that sets the "spcName" field to whatever is appropriate.
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 index="2" 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 automatically defines the tag group and assigns the proper 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 index="1" phase="Setup" priority="5000"><![CDATA[ perform forward[Hindrance.?] ]]></eval>