Adding Advancements (Savage) - Revision history

Rob at 07:08, 23 December 2008

2008-12-23T07:08:33Z

← Older revision		Revision as of 07:08, 23 December 2008
Line 117:		Line 117:
	name="Increase Lesser Skill"		name="Increase Lesser Skill"
	compset="Advance"		compset="Advance"
	description="Increase one skill by one die type, provided that the skill is currently less than its linked attribute.~~\n\n~~{b}{text ffff00}Note!{text 010101}{/b} Select this option {b}{i}twice{/i}{/b} as a single advance, specifying a separate skill for each. This selection consumes only half an advance slot.">		description="Increase one skill by one die type, provided that the skill is currently less than its linked attribute.{br}{br}{b}{text ffff00}Note!{text 010101}{/b} Select this option {b}{i}twice{/i}{/b} as a single advance, specifying a separate skill for each. This selection consumes only half an advance slot.">
	<fieldval field="advCost" value=".5"/>		<fieldval field="advCost" value=".5"/>
	<fieldval field="advAction" value="Boost Lesser Skill"/>		<fieldval field="advAction" value="Boost Lesser Skill"/>

Rob at 10:41, 18 December 2008

2008-12-18T10:41:18Z

← Older revision		Revision as of 10:41, 18 December 2008
Line 190:		Line 190:
	]]></eval>		]]></eval>

	<evalrule ~~value~~="1"		<evalrule index="1" phase="Validate" priority="9000"
	phase="Validate" priority="9000"
	message="Multiple attributes increased within a rank" summary="Multiple attributes"><![CDATA[		message="Multiple attributes increased within a rank" summary="Multiple attributes"><![CDATA[
	~if we have no instances of multiple advances within a level, we're good		~if we have no instances of multiple advances within a level, we're good

Rob at 10:40, 18 December 2008

2008-12-18T10:40:50Z

← Older revision		Revision as of 10:40, 18 December 2008
Line 96:		Line 96:
	===Handling Skill Increases===		===Handling Skill Increases===

	As mentioned above, we need two separate mechanisms for adding skill increases. One advance is used for ~~increases~~ skills that are equal to or greater than the linked attribute, while the other is for skills that are less than the attribute. This allows us to apply a cost of one full advance for one type of increase and only a cost of a half-advance for the other type, which enables users to choose two of the latter advance for the price of any other advance. We've already instrumented each skill to possess a "Helper.LessThan" tag if it is less than the linked attribute value, so all we need to do is test against that tag. The only other details we have to make sure ~~are distinct~~ are the action text, description, and cost in ~~advance~~ slots. In the end, we have two separate advances that differ from each other in only those few ways, as shown below.		As mentioned above, we need two separate mechanisms for adding skill increases. One advance is used for increasing skills that are equal to or greater than the linked attribute, while the other is for skills that are less than the attribute. This allows us to apply a cost of one full advance for one type of increase and only a cost of a half-advance for the other type, which enables users to choose two of the latter advance for the price of any other advance. We've already instrumented each skill to possess a "Helper.LessThan" tag if it is less than the linked attribute value, so all we need to do is test against that tag. The only other details we have to make sure differ are the action text, description, and cost in terms of advancement slots. In the end, we have two separate advances that differ from each other in only those few ways, as shown below.

	<pre>		<pre>
Line 130:		Line 130:
	===Attribute Limits===		===Attribute Limits===

	All of our advances are now in place and should be working. However, we still have a special requirement regarding advances that we need to properly enforce. Attributes can only be increased once every rank. Solving this entails a rather crude, but effective, approach. We can use a "foreach" loop to iterate through all of the advances and tally the total number of attribute advances within each rank. If any rank has more than one attribute advance within it, we ~~need to~~ report an error to the user so that it can be rectified. We must process the advances in the exact order in which they were added to the character, which means we need to utilize the built-in "_CompSeq_" sort set.		All of our advances are now in place and should be working. However, we still have a special requirement regarding advances that we need to properly enforce. Attributes can only be increased once every rank. While this is probably a pretty standard rule that most gaming groups will adhere to, we can't make that assumption. So we have to allow users to break the rule, which means we need to utilize validation.

			Solving this entails a rather crude, but effective, approach. We can use a "foreach" loop to iterate through all of the advances and tally the total number of attribute advances within each rank. If any rank has more than one attribute advance within it, we can report an error to the user so that it can be rectified. We must process the advances in the exact order in which they were added to the character, which means we need to utilize the built-in "_CompSeq_" sort set.

	Unfortunately, there's an interesting wrinkle. Since there are four advances per rank through 80 XP and two advances per rank thereafter, we need to differentiate the two progressions appropriately. This means an attribute advance is allowed only once out of every block of four advances during the first 16 advances, but only once out of every two advances after that. During our loop, we need to handle this distinction properly.		Unfortunately, there's an interesting wrinkle. Since there are four advances per rank through 80 XP and two advances per rank thereafter, we need to differentiate the two progressions appropriately. This means an attribute advance is allowed only once out of every block of four advances during the first 16 advances, but only once out of every two advances after that. During our loop, we need to handle this distinction properly.
Line 136:		Line 138:
	To enforce this check, we'll create a new thing that is intended solely for validation. That means we need to add it to the file "thing_validate.dat". Since the thing is performing checks on the overall hero, it can derive from the "Simple" component set. And since the thing needs to perform its checks on all actors, we assign it the "Helper.Bootstrap" tag to ensure it gets automatically applied to all heroes.		To enforce this check, we'll create a new thing that is intended solely for validation. That means we need to add it to the file "thing_validate.dat". Since the thing is performing checks on the overall hero, it can derive from the "Simple" component set. And since the thing needs to perform its checks on all actors, we assign it the "Helper.Bootstrap" tag to ensure it gets automatically applied to all heroes.

	Most validation things possess only an EvalRule script, since they merely need to perform the validation test, and we could implement this thing the same way. However, we can make things a little simpler and more efficient by performing the validation in two stages. Each EvalRule script assumes the test is failed, so all the checks must be performed to ascertain whether test is satisfied, but it's much easier for us to simply assume success and bail out if we ever determine that the requirements aren't satisfied. Consequently, the first stage is an Eval script that determines whether all the requirements are satisfied and assigns a tag to the hero if anything is failed. The second stage is the EvalRule that merely checks for the tag and reports the validation result accordingly. All we need to do is define a new "Hero.MultiAttr" tag and write the two scripts, which yields ~~something~~ that looks like the following.		Most validation things possess only an EvalRule script, since they merely need to perform the validation test, and we could implement this thing the same way. However, we can make things a little simpler and more efficient by performing the validation in two stages. Each EvalRule script assumes the test is failed, so all the checks must be performed to ascertain whether each test is satisfied, but it's much easier for us to simply assume success and bail out if we ever determine that the requirements aren't satisfied. Consequently, the first stage is an Eval script that determines whether all the requirements are satisfied and assigns a tag to the hero if anything is failed. The second stage is the EvalRule that merely checks for the tag and reports the validation result accordingly. All we need to do is define a new "Hero.MultiAttr" tag in the file "tags.1st" and write the two scripts, which yields a new thing that looks like the following.

	<pre>		<pre>
Line 144:		Line 146:
	compset="Simple">		compset="Simple">
	<tag group="Helper" tag="Bootstrap"/>		<tag group="Helper" tag="Bootstrap"/>
	<eval ~~value~~="1" phase="Validate" priority="8000"><![CDATA[		<eval index="1" phase="Validate" priority="8000"><![CDATA[
	var index as number		var index as number
	var total as number		var total as number
Line 150:		Line 152:
	~iterate through all advances in the order they were added to the character		~iterate through all advances in the order they were added to the character
	foreach pick in hero where "component.Advance" sortas _CompSeq_		foreach pick in hero where "component.Advance" sortas _CompSeq_

	~determine whether we need to perform an actual check at this interval		~determine whether we need to perform an actual check at this interval
	is_check = 0		is_check = 0
Line 159:		Line 162:
	endif		endif
	endif		endif

	~if we're supposed to check, do so, then reset the tally count		~if we're supposed to check, do so, then reset the tally count
	~Note: If we find an error, assign a tag and there's nothing more to do.		~Note: If we find an error, assign a tag and there's nothing more to do.
Line 168:		Line 172:
	total = 0		total = 0
	endif		endif

	~if this is an attribute increase, tally it		~if this is an attribute increase, tally it
	if (~~each~~.tagis[AdvanceId.advAttrib] <> 0) then		if (eachpick.tagis[AdvanceId.advAttrib] <> 0) then
	total += 1		total += 1
	endif		endif

	~increment our index based on our cost and continue		~increment our index based on our cost and continue
	~Note: Using the cost allows us to properly identify the transitions between		~Note: Using the cost allows us to properly identify the transitions between
	~ experience point levels where we need to perform our check.		~ experience point levels where we need to perform our check.
	index += ~~each~~.field[advCost].value		index += eachpick.field[advCost].value
	nexteach		nexteach

	~perform a check on the final set of advances		~perform a check on the final set of advances
	if (total > 1) then		if (total > 1) then
Line 182:		Line 189:
	endif		endif
	]]></eval>		]]></eval>

	<evalrule value="1"		<evalrule value="1"
	phase="Validate" priority="9000"		phase="Validate" priority="9000"
Line 190:		Line 198:
	done		done
	endif		endif

	~mark associated tab as invalid		~mark associated tab as invalid
	container.panelvalid[advances] = 0		container.panelvalid[advances] = 0

Rob at 10:31, 18 December 2008

2008-12-18T10:31:42Z

← Older revision		Revision as of 10:31, 18 December 2008
Line 2:		Line 2:

	===Overview===		===Overview===

			All of the basic mechanics for advancement are now in place, so it's time to add the individual advancements for Savage Worlds.

	===Dynamic Tag Expressions===		===Dynamic Tag Expressions===

	Each advance entails the selection of something slightly different by the user, yet the advancement mechanism uses a single chooser through which the user makes ~~the~~ selections. Consequently, each advancement must properly dictate what can be selected, and this is achieved by using a dynamic tag expression within the chooser. Each advance possesses a field that contains the tag expression to be used, and it can be either hard-wired or synthesized on the fly via scripts, as necessary. This field must contain a valid tag expression that is applied against all things/picks to appropriately filter the list to the set of valid choices for the user.		Each advance entails the selection of something slightly different by the user, yet the advancement mechanism uses a single chooser through which the user makes selections. Consequently, each advancement must properly dictate what can be selected, and this is achieved by using a dynamic tag expression within the chooser. Each advance possesses a field that contains the tag expression to be used, and it can be either hard-wired or synthesized on the fly via scripts, as necessary. This field must contain a valid tag expression that is applied against all things/picks to appropriately filter the list to the set of valid choices for the user.

			For example, an advance that allows the user to add a new skill needs to specify a tag expression that identifies only the skills that have not yet been added to the character. Similarly, an advance that increases an existing skill needs a tag expression that identifies only those skills. By tailoring the tag expression properly, that same chooser can be re-configured for each advance to allow the user to select a completely distinct set of objects.

	===Handling Attribute Increases===		===Handling Attribute Increases===
Line 40:		Line 44:
	<fieldval field="advCost" value="1"/>		<fieldval field="advCost" value="1"/>
	<tag group="Advance" tag="AddNew"/>		<tag group="Advance" tag="AddNew"/>
	<eval ~~value~~="1" phase="Render" priority="1000">		<eval index="1" phase="Render" priority="1000">
	<before name="Assign Dynamic Tagexpr"/><![CDATA[		<before name="Assign Dynamic Tagexpr"/><![CDATA[
	~get the list of all edges on the hero and assemble it as a list of precluded tags		~get the list of all edges on the hero and assemble it as a list of precluded tags

Rob at 09:58, 18 December 2008

2008-12-18T09:58:10Z

Show changes

Rob: New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview===

2008-12-18T09:57:29Z

New page: {{context|Authoring Examples|Savage Worlds Walk-Through}} ===Overview===

New page

{{context|Authoring Examples|Savage Worlds Walk-Through}}

===Overview===