Reply to thread

Message

<blockquote data-quote="reanjr" data-source="post: 2137113" data-attributes="member: 20740">Note: I use the term mechanics separate from data for clarity, but the mechanics should be defined as data...Going through the mechanics in the order of the book is a good way of going about it since the authors intentionally tried to avoid forward references of rules.&nbsp; Though I would like to point out that it might be advantageous to start with how you want to represent data (for define all the spells before you define the spell system, so you know everything you are looking at).&nbsp; Keeping the data simple to design is more important than keeping the mechanics simple for the end user.I think AOP is a better design paradigm for this than OOP.I think embedded script is the best way to go about this sort of thing.&nbsp; The only downfall to embedded script is language choice.&nbsp; I feel .NET as the platform of choice is a good idea because it allows each developer to use their own language.&nbsp; (I just want to point out that .NET IS cross-platform before people start complaining that it isn't; I have created several applications in that run on both Linux and Windows in .NET/Mono).I think the trick is to design a way to use XML to create and attach events to different pieces of data.&nbsp; The event handlers can then be in the XML with embedded script to handle it.&nbsp; I've only experimented with this idea so far, nothing concrete.&nbsp; But it seems to be a good direction.I assume you meant to put rolls instead of faces in the D20.Any way, I think you should first start with a random number generator.&nbsp; As we are designing this for game use, it is safe to assume that random numbers would be integral to almost any game conceivable, so I have no problem relegating that to the App.&nbsp; The app can always ignore it if it wants (for a program made to simply print character sheets there would be no need).&nbsp; So as part of the contract, an application that intends to support logic (rather than just static representations of data) has to support a number of core functions.&nbsp; Some of these follow:&lt;random min-result=&quot;...&quot; max-result=&quot;...&quot; /&gt;&lt;add&gt;...&lt;/add&gt;&lt;subtract&gt;...&lt;/subtract&gt;&lt;multiply&gt;...&lt;/multiply&gt;&lt;divide options=&quot;round-down|round-up|round|float&quot;&gt;...&lt;/divide&gt;&lt;repeat num-times=&quot;...&quot;&gt;...&lt;/repeat&gt;&lt;set name=&quot;...&quot;&gt;...&lt;/set&gt;&lt;return&gt;...&lt;/return&gt;The ... represents passed arguments in the form &lt;a&gt;reference&lt;/a&gt; or internal commands to run, depending on context.So to define a roll function we might do the following:[CODE]&lt;function name=&quot;roll&quot; face=&quot;6&quot; num=&quot;1&quot; mod=&quot;0&quot;&gt;&nbsp; &nbsp; &lt;repeat num-times=&quot;num&quot;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;set name=&quot;result&quot;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;add&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;result&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;&lt;random min-result=&quot;1&quot; max-result=&quot;face&quot; /&gt;&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/add&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;/set&gt;&nbsp; &nbsp; &lt;/repeat&gt;&nbsp; &nbsp; &lt;add&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;result&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;mod&lt;/a&gt;&nbsp; &nbsp; &lt;/add&gt;&lt;/function&gt;[/CODE]Note: return is not necessary; it is implied that the function returns the last result calculated (from the add function).&nbsp; Also note that the values set in the function tag are the default values.&nbsp; You can now call &lt;roll face=&quot;20&quot; /&gt; to get a d20 roll.You could then further define a d20 function for simplicity:[CODE]&lt;function name=&quot;d20&quot;&gt;&nbsp; &nbsp; &lt;roll face=&quot;20&quot; /&gt;&lt;/function&gt;[/CODE]and now use &lt;d20 /&gt; for a result.Pretend we've now defined all the dice.&nbsp; We now need a check function to make a check of some kind.&nbsp; In this case, it uses context.&nbsp; Whenever the code encounter .whatever it is a reference to the whatever property of the calling context.&nbsp; If it encounters .[whatever] it resolves the whatever value and references that property of the calling context.&nbsp; When a passed paramete is given the &quot;!&quot; default value, then it must be supplied.[CODE]&lt;function name=&quot;check&quot; type=&quot;!&quot; dc=&quot;!&quot;&gt;&nbsp; &nbsp; &lt;gte&gt; &lt;!-- greater than or equal to --&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;add&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;&lt;d20 /&gt;&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;.[type]-mod&lt;/a&gt;&lt;/add&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;/add&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;dc&lt;/a&gt;&nbsp; &nbsp; &lt;/gte&gt;&lt;/function&gt;[/CODE]In the character, of course, we need to define how strength-mod, etc. is determined:[CODE]&lt;character&gt;&nbsp; &nbsp; &lt;strength-mod&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;divide options=&quot;round-down&quot;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;subtract&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a default=&quot;10&quot;&gt;.strength&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;10&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;/subtract&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;a&gt;2&lt;/a&gt;&nbsp; &nbsp; &nbsp; &nbsp; &lt;/divide&gt;&nbsp; &nbsp; &lt;/strength-mod&gt;&lt;/character&gt;[/CODE]The default attribute of a specifies that if the calling context does not have a .strength property set, then it should use 10 (to get no modifier).you can now call &lt;check type=&quot;strength&quot; dc=&quot;15&quot; /&gt; to make a DC 15 strength check.Anyway, some thoughts to bounce around.&nbsp; I know there are some holes in there that need to be plugged (for instace, setting the context - is this done by the application or by further XML script).</blockquote>

[QUOTE="reanjr, post: 2137113, member: 20740"] Note: I use the term mechanics separate from data for clarity, but the mechanics should be defined as data... Going through the mechanics in the order of the book is a good way of going about it since the authors intentionally tried to avoid forward references of rules. Though I would like to point out that it might be advantageous to start with how you want to represent data (for define all the spells before you define the spell system, so you know everything you are looking at). Keeping the data simple to design is more important than keeping the mechanics simple for the end user. I think AOP is a better design paradigm for this than OOP. I think embedded script is the best way to go about this sort of thing. The only downfall to embedded script is language choice. I feel .NET as the platform of choice is a good idea because it allows each developer to use their own language. (I just want to point out that .NET IS cross-platform before people start complaining that it isn't; I have created several applications in that run on both Linux and Windows in .NET/Mono). I think the trick is to design a way to use XML to create and attach events to different pieces of data. The event handlers can then be in the XML with embedded script to handle it. I've only experimented with this idea so far, nothing concrete. But it seems to be a good direction. I assume you meant to put rolls instead of faces in the D20. Any way, I think you should first start with a random number generator. As we are designing this for game use, it is safe to assume that random numbers would be integral to almost any game conceivable, so I have no problem relegating that to the App. The app can always ignore it if it wants (for a program made to simply print character sheets there would be no need). So as part of the contract, an application that intends to support logic (rather than just static representations of data) has to support a number of core functions. Some of these follow: <random min-result="..." max-result="..." /> <add>...</add> <subtract>...</subtract> <multiply>...</multiply> <divide options="round-down|round-up|round|float">...</divide> <repeat num-times="...">...</repeat> <set name="...">...</set> <return>...</return> The ... represents passed arguments in the form <a>reference</a> or internal commands to run, depending on context. So to define a roll function we might do the following: [CODE] <function name="roll" face="6" num="1" mod="0"> <repeat num-times="num"> <set name="result"> <add> <a>result</a> <a><random min-result="1" max-result="face" /></a> </add> </set> </repeat> <add> <a>result</a> <a>mod</a> </add> </function> [/CODE] Note: return is not necessary; it is implied that the function returns the last result calculated (from the add function). Also note that the values set in the function tag are the default values. You can now call <roll face="20" /> to get a d20 roll. You could then further define a d20 function for simplicity: [CODE] <function name="d20"> <roll face="20" /> </function> [/CODE] and now use <d20 /> for a result. Pretend we've now defined all the dice. We now need a check function to make a check of some kind. In this case, it uses context. Whenever the code encounter .whatever it is a reference to the whatever property of the calling context. If it encounters .[whatever] it resolves the whatever value and references that property of the calling context. When a passed paramete is given the "!" default value, then it must be supplied. [CODE] <function name="check" type="!" dc="!"> <gte>  <add> <a><d20 /></a> <a>.[type]-mod</a></add> </add> <a>dc</a> </gte> </function> [/CODE] In the character, of course, we need to define how strength-mod, etc. is determined: [CODE] <character> <strength-mod> <divide options="round-down"> <subtract> <a default="10">.strength</a> <a>10</a> </subtract> <a>2</a> </divide> </strength-mod> </character> [/CODE] The default attribute of a specifies that if the calling context does not have a .strength property set, then it should use 10 (to get no modifier). you can now call <check type="strength" dc="15" /> to make a DC 15 strength check. Anyway, some thoughts to bounce around. I know there are some holes in there that need to be plugged (for instace, setting the context - is this done by the application or by further XML script). [/QUOTE]

Verification