• NOW LIVE! Into the Woods--new character species, eerie monsters, and haunting villains to populate the woodlands of your D&D games.

Open Source d20 API/Engine

JimAde said:
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. So when you level your character, the application would archive the previous level in a known location and if you want to revert it can. Of course it would have to be smart enough to revert only things that are level-dependent and not, for example, equipment. :)
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.

An undo function would just be something in the application that would maintain a record of changes so it can reverse them if the user says to. This history I'm talking about would record the path, so to speak, of how the character got where he was so you can backtrack down it at a later date if you so desire, even across sessions.

Your second suggestion gets at something I was trying to say earlier. I would love it if we could define some kind of meta-data for modifying existing data. It's a major feature of d20 (and RPGs in general) that a lot of things can affect a lot of other things (pretty generic statement I know).
Yeah, PCGen has a good idea in the ability to make a "campaign file" you can spread around so others can make their copies of the program compatible with your game. I just think it needs to go further.
 

log in or register to remove this ad

I understand the goal of being able to revert to a previous level, but I'm not sure it belongs in the data model. I'm not saying it doesn't, just that I'm not entirely convinced yet.

What you describe almost sounds like we would have the original state of the character, then track all changes as "actions". When you want to see the current state of the character, you just apply all the actions. When you want to see a previous level version, you only apply the changes up to that level. This sounds cool (and is actually very similar to something I worked on for my actual job, strangely enough).
 

JimAde said:
I understand the goal of being able to revert to a previous level, but I'm not sure it belongs in the data model. I'm not saying it doesn't, just that I'm not entirely convinced yet.

What you describe almost sounds like we would have the original state of the character, then track all changes as "actions". When you want to see the current state of the character, you just apply all the actions. When you want to see a previous level version, you only apply the changes up to that level. This sounds cool (and is actually very similar to something I worked on for my actual job, strangely enough).
That's more or less it, though I'd be more inclined to call them "components" and expand them a bit. The way I envision it you'd have a skill, for instance, and it would have a list of components that tally up to the final score. Among the components would be a listing of points spent at each level. Other components would be things like bonuses gained from feats (Alertness, anyone) or items. Ideally, you could not only backtrack a character this way but you could also write your character program in such a way that you could instantly see what all went into coming up with a final number for something. As it works now, you see a number you aren't sure about, you start rooting around until you figure out how the number was derived. Here, you could see instantly what components you hadn't thought of are included so you could understand what is going on. This expands to stuff like a component saying you got a +2 to the skill because you're such-and-such race or because your DM gave it to you because of your background. The system will arrive at its final number by adding up all the components. Most systems now just seem to store the final number and leave you to figure out how it was calculated on your own if you need to change it or think it isn't correct.

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.
 


News Saturday

Just an FYI:

The FGA will either pass or accept my thought on Saturday. (Essentially, we don't want to announce something new on April Fool's Day.)

My view is that we should work to have a "common language" that data can be shared with, rather than a decreed format (which d20-XML tried and passed on) or a standard document (which the FGA tried before, and failed.)

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.)
 

OK, so what type of data model we are talking of? Do you want a data model for the D20 objects? I think that's in parts done by the already mentioned D20 XML group.
If you're talking about a data model for the basic meta data for the API we should start this here.

Oh and I also like the idea of a history, I already thought about how to do this for my app, as dropping a char in level is one of the worst mechanics in D&D to program. My house rules discarded the mechanic ;) but for a core game this mechanic should be available.
To do this the idea of just accounting the changes done by level (or by experience) seems right. But also the possibility to just keep a backup of the data by level could be done. Some metadata for the object that just says something like "backup if the level goes up" could be used for this.
 


That's great Andargor. Once we settle on some formats, it'll be great to have all that electronic data to import. I've said it before and I'll say it again: Andargor rocks the house. :)

BTW, how does everybody like the new post counts? :)
 

JimAde said:
BTW, how does everybody like the new post counts? :)
That's just mind-boggling!

Anyway, I had quite a bit of catching up to do. All good stuff.

Your comments illustrate what I see as the first fundamental design decision. What is the line between the data model and the functional API? As reanjr pointed out, you can build a lot of functionality into XML files, including embedding script code. And does the application have functional significance or is it just a user interface?

I initially thought I would like every d20 rules engine to have the ability to share data simply by adding a new "Save As" function. But the more I think about it, the more I realize that there are good reasons to include rule information in the data. Namely, usable overrides.

Ever try using PCGen with custom data in a group of non-technical people? I felt like tech support. Entities such as characters must be portable. And that includes the overrides and special rules. You cannot expect everybody to load the same versions of the same data just to view a character. Plus, you want to have the flexibility to simultaneously use conflicting overrides. (e.g. two fighters tweaked in different ways)

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.

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 history being implemented something like this. All changes are stored as atomic entities which are both descriptive (view character at an earlier time or view differences between change points) and functional (roll back a level). I think rollback will be more useful for DMs, who may make numerous revisions to an NPC before putting it into play. All changes should be attributed to a rule (e.g. "Ranger level 4") or an explanation provided at the time of change (e.g. "magical fountain granted permanent +1 bonus to Will save").

So where I end up is that there is a data model that contains descriptions/statistics as well as mechanics. In many or all cases, those mechanics will be implicit to the data model:

JimAde said:
<modifier modifiedElementName="tohit.enhancement" modifier="1" />
<modifier modifiedElementName="damage.enhancement" modifier="1" />
<modifier modifiedElementName="wielder.ac.deflection" modifier="2" />
But are there any cases where that might require code to implement something more complex? Are there any spells or class abilities that couldn't be implemented simply by defining modifiers and conditions?

Planesdragon - I'm interested to see your proposal. Let us know what happens.
 

I've created a thread for an initial rules discussion. You can find it here:
The purpose of this new thread is to have a dialog to see how viable a collaboration on this might be. I have tried to raise some of the design questions that I'm thinking about within the context of the rules themselves, starting with the core mechanic. Please join and share your thoughts.

.:npy:.
 

Into the Woods

Remove ads

Top