Reply to thread

Message

<blockquote data-quote="JBowtie" data-source="post: 70855" data-attributes="member: 1810">Re: what are using for development environment?Well, I'm using XML for the rules, XSLT for processing the rules, and HTML with Javascript for my user interface.The main drawback to a database&nbsp; as such is that a relational database doesn't work especially well with loosely structured data.&nbsp; And, given the creative ways feats and classes can affect the basic mechanics (or introduce new mechanics), the rules for d20 are only loosely structured.For example, when a new feat is defined, it may include a notation that it can be used as a fighter bonus feat.&nbsp; I'm not going to go back and edit the fighter class every time that happens, especially if the feat introduces a new mechanic.Instead, I need to be a little looser and allow the fighter list to be built from a combination of the predefined list and new feats that claim to belong to the list.This looser structure is lot harder to model in a database - that's why the Master Tools folks don't expose a way to expose your own prestige classes.&nbsp; But with XML I've added prestige classes from Dragon Magazine and Rokugan without having to change my processing or user interface.Now, I'm still in the process of defining and implementing the XML, so some prerequisites are still hard to define (mostly the ones relating to spells and casters since I don't handle spells at all yet).&nbsp; But the majority of feats and skills are handled correctly.The point is that there's enough structure to model the rules, but not enough to model them as a database.Oy, I've said too much without giving a concrete example.&nbsp; I'll post some sample markup later today.</blockquote>

[QUOTE="JBowtie, post: 70855, member: 1810"] [b]Re: what are using for development environment?[/b] Well, I'm using XML for the rules, XSLT for processing the rules, and HTML with Javascript for my user interface. The main drawback to a [I]database[/I] as such is that a relational database doesn't work especially well with loosely structured data. And, given the creative ways feats and classes can affect the basic mechanics (or introduce new mechanics), the rules for d20 are only loosely structured. For example, when a new feat is defined, it may include a notation that it can be used as a fighter bonus feat. I'm not going to go back and edit the fighter class every time that happens, especially if the feat introduces a new mechanic. Instead, I need to be a little looser and allow the fighter list to be built from a combination of the predefined list and new feats that claim to belong to the list. This looser structure is lot harder to model in a database - that's why the Master Tools folks don't expose a way to expose your own prestige classes. But with XML I've added prestige classes from Dragon Magazine and Rokugan without having to change my processing or user interface. Now, I'm still in the process of defining and implementing the XML, so some prerequisites are still hard to define (mostly the ones relating to spells and casters since I don't handle spells at all yet). But the majority of feats and skills are handled correctly. The point is that there's enough structure to model the rules, but not enough to model them as a database. Oy, I've said too much without giving a concrete example. I'll post some sample markup later today. [/QUOTE]

Verification