Reply to thread

Message

<blockquote data-quote="reanjr" data-source="post: 2132201" data-attributes="member: 20740">This is why I am doing mine in a very datacentric-way.&nbsp; Once all of the rules have been represented as data, you can design an app as a plugin system to do what you want with the data.&nbsp; You need not be constrained by anything.&nbsp; If you have altered your teleport spell in your game to be level 9, you simply define a house-rules namespace and add the additional rule to an XML file.&nbsp; You set the app to use or not use specific namespaces or plugins.&nbsp; Voila, an architecture that supports any OGL system.I reiterate last point.Again, a plugin architecture allows for any type of add-on you would need.&nbsp; It's interesting that my basic design would allow for a plugin to handle any of the things you mention here, even though I hadn't thought of any of them.The way I am going about it is to take the entire ruleset and represent it as data.&nbsp; This allows for logic and rules changes by editing a simple text file that is near-plain english.&nbsp; I18n is something that can be done at the data level, though I do not plan on placing any real support in it.&nbsp; From what I understand, most rule books are never published outside of the English language anyway.&nbsp; I may be wrong on this.&nbsp; Anyway, you could take the spells.xml file and alter just the spell description and you would be supporting i18n.&nbsp; XML already supports this.My goal is also to facilitate tabletop play, though I do have an explicit goal of making it network enabled so that if you have a group of players around a table with PDAs/Laptops/whatever they could all share data.&nbsp; This would, of course, work over the internet, too, but that's more of a side effect than anything else.I disagree.&nbsp; Again, if all the rules are represented as data that is easily altered, it doesn't matter.&nbsp; Plugin writers can add or alter functionality as they see fit, as long as they have the rules.That's what end users are for, silly.</blockquote>

[QUOTE="reanjr, post: 2132201, member: 20740"] This is why I am doing mine in a very datacentric-way. Once all of the rules have been represented as data, you can design an app as a plugin system to do what you want with the data. You need not be constrained by anything. If you have altered your teleport spell in your game to be level 9, you simply define a house-rules namespace and add the additional rule to an XML file. You set the app to use or not use specific namespaces or plugins. Voila, an architecture that supports any OGL system. I reiterate last point. Again, a plugin architecture allows for any type of add-on you would need. It's interesting that my basic design would allow for a plugin to handle any of the things you mention here, even though I hadn't thought of any of them. The way I am going about it is to take the entire ruleset and represent it as data. This allows for logic and rules changes by editing a simple text file that is near-plain english. I18n is something that can be done at the data level, though I do not plan on placing any real support in it. From what I understand, most rule books are never published outside of the English language anyway. I may be wrong on this. Anyway, you could take the spells.xml file and alter just the spell description and you would be supporting i18n. XML already supports this. My goal is also to facilitate tabletop play, though I do have an explicit goal of making it network enabled so that if you have a group of players around a table with PDAs/Laptops/whatever they could all share data. This would, of course, work over the internet, too, but that's more of a side effect than anything else. I disagree. Again, if all the rules are represented as data that is easily altered, it doesn't matter. Plugin writers can add or alter functionality as they see fit, as long as they have the rules. That's what end users are for, silly. [/QUOTE]

Verification