<--design ^--programming--^

luad20 - a Lua Schema for d20 gaming systems - schema

As we saw back on the design page, we'll need access to the skill of a character to modify it with the feat. But what exactly are we modifying? The character already has a number of ranks in that skill (maybe 0), but that's not the number we want to modify. Instead, we want to modify a "current total". This assumes that we've got one, and that none of the values are conditional. So perhaps this isn't the best way to describe the effects of a feat?

Back in xmld20, we were going to take the approach of "registering" code for certain events, such as "call me when you're figuring out skills", or "call me when you need to know the to-hit value against a monster." This approach is preferred for various reasons, foremost to provide the most flexible environment -- while statically computing the skills might work for a character sheet, it doesn't work if the same code is used to run a d20 game, with temporary effects that need to be adjusted at any time.

So, what does this have to do with schemas? Well, we need to provide an interface for the user (that is, the data-providing user), to say what his new feat, skill, spell or ability can do, and when. In the case of our Acrobatic feat, we want to say something like:

...
	benefit=
	[[
		calcSkill=
		[[
			if skill=="Jump" then return +2 end
			if skill=="Tumble" then return +2 end
			return 0
		]]
	]]
...
I suppose this is workable. The benefit entry is a string that gets passed into loadstring(), which gives a function that sets one or more strings. These strings can then also be passed through loadstring() to produce functions, which will be called from within the real calcSkill(skill) function. Again, I'm going to fight the urge to remove Lua code and replace it with simpler notation, like
	jump:+2
	tumble:+2
and have to write a parser for this. There will be plenty of sample code for authors of new material to work from.

My above example assumes that just the name of the skill gets passed in, but I think that's too limiting. Instead, we should pass in something that represents the skill we're calculating, as well as any other calculations done so far. Why? Because of issues we discussed back in xmld20, regarding things that provide bonuses of matching types, and how they don't necessarily stack. So instead of returning +2, we need to modify an ongoing calculation.
<--design ^--programming--^

©2002-2010 Wayne Pearson