Character Creation Logic (Savage) - Revision history

Rob: /* Races */

2009-02-11T07:35:27Z

Races

← Older revision		Revision as of 07:35, 11 February 2009
Line 56:		Line 56:

	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, except for one facet.		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, except for one facet.

			The issue is with the tallying of skill points. If the "Elven" race is selected, it confers a free bonus level to the "Agility" attribute. That bonus needs to be considered part of the base die type for the attribute. Otherwise, skills based on Agility will cost an extra skill point unless they are lower than the attribute.

			Taking a look at the Eval script we created a few moments ago, we can easily accommodate this fix. The bonus die level tracked within the "trtBonus" field, so all we need to do is add the bonus to the user value and we'll have the net value we need. Note that we do '''''not''''' want to use the "trtFinal" field value, since that value also includes in-play adjustments, which are temporary and must be excluded from consideration here.

			The code fragment below shows the effected lines within the Eval script and what they should now look like.

			<pre>
			~get the level of our linked attribute and factor in bonuses due to races and such
			var attrib as number
			attrib = linkage[attribute].field[trtUser].value
			attrib += linkage[attribute].field[trtBonus].value

			~add an extra point for every level we exceed our linked attribute
			if (field[trtUser].value > attrib) then
			points += field[trtUser].value - attrib
			endif
			</pre>

	===Hindrances===		===Hindrances===

Rob: /* Attribute Points */

2009-02-11T07:18:10Z

Attribute Points

← Older revision		Revision as of 07:18, 11 February 2009
Line 10:		Line 10:

	<pre>		<pre>
	<eval index="1" phase="~~Setup~~" priority="~~5000~~"><![CDATA[		<eval index="2" phase="Traits" priority="10000">
			<before name="Calc resLeft"/>
			<after name="Bound trtUser"/><![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
	perform #resspent[resAttrib,+,field[trtUser].value - 2,field[name].text]		perform #resspent[resAttrib,+,field[trtUser].value - 2,field[name].text]

Rob: /* Skill Points */

2009-02-11T07:17:23Z

Skill Points

← Older revision		Revision as of 07:17, 11 February 2009
Line 27:		Line 27:

	<pre>		<pre>
	<eval index="1" phase="~~Setup~~" priority="~~5000~~"><![CDATA[		<eval index="2" phase="Traits" priority="10000">
			<before name="Calc resLeft"/>
			<after name="Bound trtUser"/><![CDATA[
			~if this skill is not added directly to the hero (i.e. an advance), skip it entirely
			if (origin.ishero = 0) then
			done
			endif

	~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
	var points as number		var points as number

Rob: /* Races */

2009-02-11T07:13:33Z

Races

← Older revision		Revision as of 07:13, 11 February 2009
Line 46:		Line 46:
	===Races===		===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~~.		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, except for one facet.

	===Hindrances===		===Hindrances===

Rob: /* Skill Points */

2009-02-11T07:06:20Z

Skill Points

← Older revision		Revision as of 07:06, 11 February 2009
Line 18:		Line 18:
	===Skill Points===		===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:		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 either one or two 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 interesting logic here has to do with determining whether each die type for a skill costs one or two points. We can start by assuming that each notch counts at least one point. So we'll first calculate the total number of notches. We must also subtract one from our total, since the base values for skills is two, which costs the first point.

			The extra skill point cost is incurred for each level that a skill exceeds its linked attribute. We can access the linked attribute and get its value via the "linkage" transition. Once we have that value, we can compare the two and add an extra skill point for each level of difference between them.

			The net script that we need should look something like the following:

	<pre>		<pre>
	<eval index="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		var points as number
			points = field[trtUser].value - 1

			~add an extra point for every level we exceed our linked attribute
			var attrib as number
			attrib = linkage[attribute].field[trtUser].value
			if (field[trtUser].value > attrib) then
			points += field[trtUser].value - attrib
			endif

			~accrue the total points spent on this skill
			hero.child[resSkill].field[resSpent].value += points
	]]></eval>		]]></eval>
	</pre>		</pre>

Rob: /* Attribute Points */

2009-02-11T06:49:17Z

Attribute Points

← Older revision		Revision as of 06:49, 11 February 2009
Line 12:		Line 12:
	<eval index="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~~		perform #resspent[resAttrib,+,field[trtUser].value - 2,field[name].text]
	]]></eval>		]]></eval>
	</pre>		</pre>

Rob: Character Creation Logic (Skeleton) moved to Character Creation Logic (Savage)

2008-12-18T04:10:45Z

Character Creation Logic (Skeleton) moved to Character Creation Logic (Savage)

← Older revision	Revision as of 04:10, 18 December 2008
(No difference)

Rob at 03:43, 18 December 2008

2008-12-18T03:43:28Z

← Older revision		Revision as of 03:43, 18 December 2008
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.

Rob: 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...

2008-12-17T07:09:05Z

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...

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 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.

<pre>
<eval value="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>
</pre>

===Skills 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:

<pre>
<eval value="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>
</pre>

===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.

<pre>
<thing
id="valHinders"
name="Hindrances"
compset="Simple">
<tag group="Helper" tag="Bootstrap"/>
<evalrule value="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>
</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.

<pre>
perform hero.assign[Hero.BadHinders]
</pre>

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.

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

===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.

===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.