Difference between revisions of "Character Creation Logic (Savage)"

From HLKitWiki
Jump to: navigation, search
(New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview=== With all the basics now in place, it's a perfect time for us to get all of the basic character creation logic ful...)
 
Line 10: Line 10:
  
 
<pre>
 
<pre>
<eval value="1" phase="Setup" priority="5000"><![CDATA[
+
<eval index="1" phase="Setup" priority="5000"><![CDATA[
 
   ~since the base starting value for each attribute is two, we add only the extras
 
   ~since the base starting value for each attribute is two, we add only the extras
 
   hero.child[resAttrib].field[resSpent].value += field[trtUser].value - 2
 
   hero.child[resAttrib].field[resSpent].value += field[trtUser].value - 2
Line 16: Line 16:
 
</pre>
 
</pre>
  
===Skills Points===
+
===Skill Points===
  
Skills points behave much like attributes, except that we have to treat the initial purchase of the skill as one skill point and all subsequent increases as one additional skill points. We already have a resource in place to track the points, and the Skeleton files already provide a "Skill" component script that we can easily adapt to our needs. The net script that we need should look something like the following:
+
Skill points behave much like attributes, except that we have to treat the initial purchase of the skill as one skill point and all subsequent increases as one additional skill point. We already have a resource in place to track the points, and the Skeleton files already provide a "Skill" component script that we can easily adapt to our needs. The net script that we need should look something like the following:
  
 
<pre>
 
<pre>
<eval value="1" phase="Setup" priority="5000"><![CDATA[
+
<eval index="1" phase="Setup" priority="5000"><![CDATA[
 
   ~the base value for skills is two, so we need to adjust by one to get the proper cost
 
   ~the base value for skills is two, so we need to adjust by one to get the proper cost
 
   hero.child[resSkill].field[resSpent].value += field[trtUser].value - 1
 
   hero.child[resSkill].field[resSpent].value += field[trtUser].value - 1
Line 43: Line 43:
 
   compset="Simple">
 
   compset="Simple">
 
   <tag group="Helper" tag="Bootstrap"/>  
 
   <tag group="Helper" tag="Bootstrap"/>  
   <evalrule value="1" phase="Validate" priority="8000" 
+
   <evalrule index="1" phase="Validate" priority="8000" 
 
     message="Maximum of one major and two minor hindrances allowed"
 
     message="Maximum of one major and two minor hindrances allowed"
 
     summary="Limit exceeded"><![CDATA[
 
     summary="Limit exceeded"><![CDATA[
Line 56: Line 56:
 
         endif
 
         endif
 
       nexteach  
 
       nexteach  
 +
 
     ~if we have no more than one major and two minor, we're good
 
     ~if we have no more than one major and two minor, we're good
 
     if (major <= 1) then
 
     if (major <= 1) then
Line 63: Line 64:
 
         endif
 
         endif
 
       endif  
 
       endif  
 +
 
     ~mark associated tabs as invalid
 
     ~mark associated tabs as invalid
 
     container.panelvalid[edges] = 0
 
     container.panelvalid[edges] = 0
Line 69: Line 71:
 
</pre>
 
</pre>
  
After making the above changes, validation is now working as it should. However, it would be better if the title above the hindrances table appeared in red to clearly identify where to fix the problem on the tab. This can be achieved by having the above EvalRule assign a tag to the hero, which can be checked by the table portal. So we start by defining a new "Hero.BadHinders" tag within the file "tags.1st". Once that's in place, we can assign it within the above EvalRule script by adding the line below if the rule is failed.
+
After making the above changes, validation is now working as it should. However, it would be better if the title above the hindrances table appeared in red to clearly identify where to fix the problem on the tab. This can be achieved by having the above EvalRule assign a tag to the hero, which can be checked by the table portal. So we start by defining a new "Hero.BadHinders" tag within the file "tags.1st". Add the following tag to the "Hero" tag group.
 +
 
 +
<pre>
 +
<value id="BadHinders"/>  <!-- Indicates that the hindrances selected don't comply with the rules -->
 +
</pre>
 +
 
 +
Once that's in place, we can assign the tag within the above EvalRule script by adding the line below if the rule is failed.
  
 
<pre>
 
<pre>
Line 87: Line 95:
 
===Rewards===
 
===Rewards===
  
Add a variety of rewards and verify that the available number of resources is being properly adjusted. Some rewards are worth two points and some are worth one. Also verify that the effects of each reward are being applied correctly.  
+
Add a variety of rewards and verify that the available number of resources is being properly adjusted. Some rewards are worth two points and some are worth one. Also verify that the effects of each reward are being applied correctly. Everything seems to check out fine.
  
 
===Edges===
 
===Edges===
  
The final thing that we need to test on this tab is edges. Add a variety of edges and make sure that the appropriate resources are being adjusted. For edges that confer bonuses, verify that the effects are being applied properly. If an edge has user-controlled effects that can be toggled on and off, make sure the option appears properly on the "In-Play" tab and that it all behaves correctly.
+
The final thing that we need to test on this tab is edges. Add a variety of edges and make sure that the appropriate resources are being adjusted. For edges that confer bonuses, verify that the effects are being applied properly. If an edge has user-controlled effects that can be toggled on and off, make sure the option appears properly on the "In-Play" tab and that it all behaves correctly. Once that's handled, we're ready to move on with our development.

Revision as of 20:43, 17 December 2008

Context: HL KitAuthoring Examples … Savage Worlds Walk-Through 

Overview

With all the basics now in place, it's a perfect time for us to get all of the basic character creation logic fully tested and operational. This entails tracking the allocation of attribute points and skill points, as well as the selection of races, edges, hindrances, and rewards.

Attribute Points

We'll focus on attribute points first. We already have a resource in place to track those points, so we need to properly consume those points. This can be most easily handled by adding a script to the "Attribute" component that spends the resource appropriately. The Skeleton files provide such a script for us already, so all we need to do is adapt it for our needs. The d4 rating for an attribute costs no points, but each increment beyond that costs one point. So we'll employ a component script that behaves accordingly, which should look similar to the one shown below.

<eval index="1" phase="Setup" priority="5000"><![CDATA[
  ~since the base starting value for each attribute is two, we add only the extras
  hero.child[resAttrib].field[resSpent].value += field[trtUser].value - 2
  ]]></eval> 

Skill Points

Skill points behave much like attributes, except that we have to treat the initial purchase of the skill as one skill point and all subsequent increases as one additional skill point. We already have a resource in place to track the points, and the Skeleton files already provide a "Skill" component script that we can easily adapt to our needs. The net script that we need should look something like the following:

<eval index="1" phase="Setup" priority="5000"><![CDATA[
  ~the base value for skills is two, so we need to adjust by one to get the proper cost
  hero.child[resSkill].field[resSpent].value += field[trtUser].value - 1
  ]]></eval>  

Races

Try choosing all of the different races for the character and verify whether everything is behaving correctly. This includes racial bonuses to attributes, skills, and derived traits, plus other facets such as the extra edge conferred by the "Human" and "Half-Elven" races. After a quick check, everything looks correct, so races are now working.

Hindrances

Add a variety of hindrances of different severities. Also add hindrances that have a user-controlled severity and toggle that severity. While doing so, watch the total points of rewards that are available for selection on the right. The total should go up one point for each minor hindrance and two points for each major hindrance. In addition, when hindrances are added that confer negative effects, verify that the effects are being applied properly. If a hindrance has user-controlled effects that can be toggled on and off, make sure the option appears properly on the "In-Play" tab and that it all behaves correctly.

Everything is working as it should, with one exception. The rules stipulate that a character may choose a maximum of one major hindrance and two minor hindrances, but this restriction is not being validated anywhere. We need to add a new validation rule that will enforce this restriction and report when a character exceeds the limits. To do that, we need to add a new thing whose sole purpose is performing this validation. By convention, we add these "validation" things to the file "thing_validate.dat". So open up the file and we'll add a new validation thing whose sole purpose is to invoke our validation rule to verify hindrances. We derive the thing from the "Simple" component set, and we must make sure it's added to every character so that the validation is always performed. The net result looks like the following.

<thing
  id="valHinders"
  name="Hindrances"
  compset="Simple">
  <tag group="Helper" tag="Bootstrap"/> 
  <evalrule index="1" phase="Validate" priority="8000" 
    message="Maximum of one major and two minor hindrances allowed"
    summary="Limit exceeded"><![CDATA[
    ~iterate through all hindrances and tally up the number of majors and minors
    var major as number
    var minor as number
    foreach pick in hero where "component.Hindrance"
      if (each.field[hinMajor].value = 0) then
        minor += 1
      else
        major += 1
        endif
      nexteach 

    ~if we have no more than one major and two minor, we're good
    if (major <= 1) then
      if (minor <= 2) then
        @valid = 1
        done
        endif
      endif 

    ~mark associated tabs as invalid
    container.panelvalid[edges] = 0
    ]]></evalrule>
  </thing>

After making the above changes, validation is now working as it should. However, it would be better if the title above the hindrances table appeared in red to clearly identify where to fix the problem on the tab. This can be achieved by having the above EvalRule assign a tag to the hero, which can be checked by the table portal. So we start by defining a new "Hero.BadHinders" tag within the file "tags.1st". Add the following tag to the "Hero" tag group.

<value id="BadHinders"/>  <!-- Indicates that the hindrances selected don't comply with the rules -->

Once that's in place, we can assign the tag within the above EvalRule script by adding the line below if the rule is failed.

perform hero.assign[Hero.BadHinders]

The final step is to check for and properly handle the tag within the table portal. Locate the "edHinders" portal within the file "tab_edges.dat" and then find the HeaderTitle script. This script returns the title to be displayed, which currently amounts to simply "Hindrances". We can change the script to detect if the tag is present and change the color to red when it is. The new script should look similar to the one below.

@text = ""
if (hero.tagis[Hero.BadHinders] <> 0) then
  @text = "{text ff0000}"
  endif
@text &= "Hindrances"  

Rewards

Add a variety of rewards and verify that the available number of resources is being properly adjusted. Some rewards are worth two points and some are worth one. Also verify that the effects of each reward are being applied correctly. Everything seems to check out fine.

Edges

The final thing that we need to test on this tab is edges. Add a variety of edges and make sure that the appropriate resources are being adjusted. For edges that confer bonuses, verify that the effects are being applied properly. If an edge has user-controlled effects that can be toggled on and off, make sure the option appears properly on the "In-Play" tab and that it all behaves correctly. Once that's handled, we're ready to move on with our development.