Open Source d20 API/Engine

[reanjr]

I meant that if someone wants to add a new field to lets say the feat object (e.g. minimum level as an silly example) he sure wants to fill this field for all existing feats so he'd need a gui component for this field.
So he'd have to open the RPGDeveloper(tm) to add the field, then add it in the gui. Close the RPGDeveloper and open RPGDataApplication(tm) to enter the data?
I think in RPM (RolePlayingMaster) there's something like a maintainance mode for such things. I checked RPM a long time ago...
You shouldn't have to use different tools for this.

The way I look at it is that if the data is stored as XML, there are already hundreds of tools out there to do exactly this, only way better than anything the RPGDataApplication developers would come up with.

I do see your argument, though. Just not something I find to be important.

 

[reanjr]

A unified data model has to come first, though.

I agree. That's part of the reason I posted my example spell to see if anyone had any alternate ways of going about it.

I think XML is pretty much a given (?) I also think my implied schema for spells works pretty well (including some tidbits on linking, etc.) Does anyone think there is anything wrong with it? I'd post a DTD, but formalizing schemas isn't my thing, designing them is. I would require someone else for that sort of work.

I am diligently working on spells and a GUI design (including some preliminary code, though I keep flip-flopping on the Document interface for Character Sheet plugins and the like to implement).

The way I see it, the entire text of the SRD should be able to be extrapolated from the XML files (maybe not word for word, but all the rules should be there). One could, of course, start by determining which types of XML files are needed. Suggestions? (Obviously Skills, Feats, Spells, Classes, Monsters (I think this should cover Races)).

 

[reanjr]

Just a couple of comments from the peanut gallery.

1. I think history should be a part of any such data model. You should be able to look at the data and see exactly how the character progressed to the level they're at. I think this is important for a couple of reasons. One is if people use this at the game table and you have temporary level loss affect the character. This would make it easy to just click a button to apply that loss and the application can know exactly how to 'downgrade' the character. Another is for DMs making NPCs. One thing I sometimes do when making NPCs with programs like PCGen is decide I want to take a few levels off either to add them to a different class or just for balance. I generally find this to be a pain to do since you then end up having to go through and manually subtract skill points, feats and stat bonuses (which may then affect skill points) and so on. A history would make this much easier.

Level downgrade is fairly undefined by the SRD, though (as far as I can recall). A player can (and may want to) downgrade their level in a tailored fashion. Following the rules a character may increase their Str from 10 to 11, then lose a point of Dex because that's their highest score. This can be advantageous in certain, limited situations.

I think this should be up to the application, keeping old copies of files at any point. The application can do this automatically or at certain points (level up, for instance). The application can use intelligent merging to simulate Undo of certain things. Keeping an actual data history for rollback would likely result in a design that made it easy to Undo the last change, but difficult to, for instance, go down a level, without losing equipment, etc.

2. I think the data model should include tags that allow modifications for specific rulesets. For instance, you could specify that acid fog is level 8 in a specific set of house rules and when a program is switched to a set of house rules, it could go through the list and apply all of the modifications to the various elements in the data. You would probably need to specify what the specific set of rules is, what to modify and what to change it to. If you're really ambitious, you could also allow for new variables that aren't in the standard rules like spell points for house rules that use them.

I did already cover that type of thing in my namespaces idea. I should point out that they are not XML namespaces, but custom ones designed for the application to use. I imagine it as a dialog with optional check boxes for each of the namespaces. You check the ones that you want to apply. The namespaces themselves would have a parent namespace to indicate which changes have priority.

For instance, namespace MaxKaladinHouse would be a child of namespace SRD. In it, it would define <spells><spell name="acid-fog"><level sor="8" wiz="8"> ...end all tags...

Since MaxKaladinHouse is defined as a child of SRD, it obviously is designed to override the data in the SRD, so it would take precedence. Now if you had two namespaces ReanjrHouse and MaxKaladinHouse that both descended from the SRD and both redefined the Acid Fog spell, the dialog could detect this and ask the end user which has precedence.

Also, since it is XML, one could easily add a <SpellPoint> value for every spell, giving you that capability in a particular set of house rule, though better would be creating a metatag that calculated the SpellPoint cost based on Level. That way, you could apply the ReanjrHouse (acid fog level 6) and MaxKaladinHouse (acid fog level 8 and SpellPoints) and have it use ReanjrHouse for the level (6) and MaxKaladinHouse for SpellPoint rules, which calculate based on level 6 from ReanjrHouse.

Just throwing this stuff out so that people can get a better idea of where my thoughts are. Obviously nothing of this sort is implemented. That would be real work.

Yeah, I know its too early to define the data but I just wanted to throw those ideas out there.

 

[reanjr]

And fine ideas they are. I really like the history point. I wonder if it's really part of the data, though. I would think it would be the application's responsibility to keep track of previous versions of the data. Just as the spec for a Word document doesn't (I assume) include revisions, but the MS Word document keeps previous versions or information about actions taken for undo.

I agree with you, but I do actually think .doc files keep change history of some kind. It's at least an option.

Your second suggestion gets at something ...snip... This might have a syntax something like

<modifier modifiedElementName="global.spell.acid fog.level.wizard">
<modificationType="replace" modifiedValue="8" />
</modifier>
<modifier modifiedElementName="global.spell.acid fog.level.sorcerer">
<modificationType="replace" modifiedValue="8" />
</modifier>

Too complicated. See my previous post for how I see it being done. My method keeps the data author in the same mindset whether they are writing new rules or modifying old ones, which I think is important.

 

[reanjr]

I'm not just talking about an undo function. I'm talking about making it part of the data to keep track of how each score developed over levels. For example, if you have a character with a skill, the character data would keep track of the fact that you added two ranks at 1st level, one at 2nd, two at third and one at fourth. If you're looking at the data, you can see exactly how the ranks were distributed to arrive at a given score. As part of the data, this would persist across sessions so that if you came back after a game and needed to drop your character in level for some reason (say you talked to your DM and he didn't approve a prestige class you took or something), you can just go back and remove the level of that prestige class and the program will know from the data exactly how to modify all the level dependant things to return the character to its previous state.

The benefits/pitfalls of this idea is probably mostly defined by how often you want real people looking at the code, and how many different supporting applications you want. Keeping it simple allows people to hand edit their files and allows developers of new software to support the data to have an easier time implementing it. Of course, compatability might be accomplished through a XSLT tranform. I am personally of the feeling that keeping the schema simple is important for both content translators (I use the term translator to indicate someone going through an OGL book and transferring info to our imagined data format) and developers.

On top of that, I know most DMs I've seen do not care to enforce level-by-level progression of new high-level characters. Mostly, I'm sure this is because of the difficulty, but to make the program sync with what actually goes on in a game, I think keeping this sort of data would be a struggle that paid off very little. You can always keep snapshots of the character creation process level-by-level if you want to have this kind of info.

A plugin developer could also create a validator plugin to make sure it is possible to come up with a theoretical high level character by doing it level-by-level. I don't think that's something the data store should provide.

 

[reanjr]

Basically, I don't think the data should contain any calculated numbers, or at least not only calculated numbers. The data should contain all of the information necessary to calculate any numbers involved.

I just want to point out another reason this is important. If the rules can be changed, you can't use precalculated numbers. If someone house rules that Ability Scores of 14 or less have no modifier, then the character with a Strength of 8 shouldn't have the StrMod of -1 precalculated since it no longer applies with this house rule.

 

[reanjr]

Oh, and reanjr -- there's plenty of work already done on spells, items, and monsters as XML in the d20-XML files section. You should probably check them out to see if they could help you with your project. (I have a fat file of XML-spells on my hard drive, but they're all custom, tagged using VB for Word, and in need of another pass through.)

I will check that out. I've always been leary of Yahoo groups for some reason, but I'll check them out. Even if it doesn't have something I feel I need, it would probably be a lot easier to do a transform than go from HTML.

 

[reanjr]

This is where I come to the "unified data model." Because there are statistical and mechanical aspects to nearly every entity in the game. You cannot fully divide them without making important sacrifices to usability.

I see things as highly contextual. If a spell has a components tag, great. If it doesn't then the application handling the spells should be able to deal with that (automatically making it verbal, for example).

History is a prime example. I think it's very important in order to create a usable application. And keeping with the principle of portability, that should be part of the data of the character. Which places it firmly in the data model.

I think the only good way to do history is to keep several snapshots of your data with maybe an attribute indicating which set is current and which set is the previous one. For example:

<character snap-id="reanjr" snap-current="true" old-snap="reanjr12" name="Reanjr" />
<character snap-id="reanjr12" old-snap="reanjr11" name="reanjr" />
<character snap-id="reanjr11" old-snap="reanjr10" name="Reanjr" />

etc. (note I changed the name attribute from Reanjr to reanjr to Reanjr.)

If a developer wants to ignore history altogether, they can simply ignore anything with a snap-id whose snap-current is not set to true. This allows for complete interop between apps that do support rollback and those that don't. I don't think it is appropriate to force an application to start at the beginning and build up through the changes (and it's probably quite inefficient, too). It's much better to start at the latest and work back through changes. I'll leave the implemention details of how you delete data as you go back to someone else. Perhaps snap-delete="true" deletes the entire tag, while snap-delete-attributes="name id" could be used to, for instance, delete the name and id attributes of the tag. Anything specified (name="reanjr") is changed and anything unspecified is left identical.

 

[schporto]

A few things:
1. I'm willing to help out, but most of my experience is with direct database work, so XML is outside of my expereience and you folks have lost me some on your discussions about some of those details. But, I can help in other ways.
2. Different types of XML files, we probably need to include an items file, and maybe an events file. The events file would be to capture things such as a Dungeon Delver must make it through a dungeon on his own to qualify. Items will get complicated depending on the flexibility desired.
3. The history point, I think history should be implemented. But leave it as optional. So you can use history or not determined at the document creation time. So (and I'm not even gonna try to put this in XML):
With history:

STR = 15
STR 3rd level bump = 1
STR item enhancement bonus = 2
STR spell enhancement bonus = 4
​

So the application would determine that the final strength is 20 (enhancement bonuses do not stack).
Or without history:

STR = 16
STR item enhancement bonus = 2
STR spell enhancement bonus = 4
​

Again strength = 20.
Having both possibilities there will allow for more flexibility. This can let DMs quickly work up a mook who will die in 10 minutes and a player make a PC who will be subject to death, level drain, level increase etc.

Just my ideas, hope I can help.
-cpd

 

[Planesdragon]

FGA gets the XML bug

As you know by know if you're on the d20-XML or FGA-Prometheus Yahoogroups (or if you've just checked www.theFGA.com), the FGA is going ahead with our XML plan.

I'll attach our first draft of an XML standard. It details a few of the basics, and as a sample file and sample XSLT included.

One thing that I feel is a good idea that's only possible in XML is the <rule> object: a selection of text that describes one rule, with a few subrules. Ordinarilly this is shown as headings and text, but if we add a specific markup to it an author or user or programmer can have software seperate rules and not-rules (such as setting information and whatnot.)

(Beyond the <rule> and a subest of xhtml, included are formats for races, classes, skills, feats, and spells.)