Open Source d20 API/Engine

[reanjr]

JimAde is definitely thinking along the same lines I am here. I agree--as barsoomcore pointed out--this is a complicated and difficult thing. Does explain PCGen, but PCGen also carries baggage from the fact that it was the first thing out there. That's not to say it's a poor application; there is a lot to like about it. But it is exactly the excpeptions that cause the biggest problems. PCGen is somewhat constraining in that area. On the other hand, DM Genie allows you to override nearly everything, but you risk losing track of how anything got the way it is.

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 want to really consider how it is that people play the game at the table in order to really account for that. What's the first and easiest "outside the rules" character tweak? "Can I exchange X class skill for Y?" Let me make that change easily, without having to modify or recreate the original class.

I reiterate last point.

And I think accounting for rule exceptions is probably the easy part. Accounting for other aspects of table-top play lead to questions like, should the data model account for history and progression? Snapshots, deltas, dates and times, etc. What about the ability to annotate changes? ("DM said I could do this because PC was raised by flumphs.") What about automatic annotations like, "+6 Int (Circlet of Intellect)? "

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.

And yes, at some point you have to ask the question, "Does X belong in the data model, the API , the persistence engine or the application?" At what level should internationalization be implemented, for example?

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 primary objective is to facilitate tabletop play, whether at game-time or in preparation. (Or both.) It might not explicitly support it, but it should probably not eliminate the possibility of network interaction. It should probably not eliminate the possibility of storing as XML or as a database. It should probably not eliminate the possibility of being used in an online application like 3EProfiler.

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 think it's a pretty tall order, but I think it can be done. I think it means taking stats and rules individually and really understanding how the function in the game and how they are used at the table. It sounds like a lot of work, but I think it's worth it.

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.

But what I really want to know is...Who's going to write the rules regression test?

That's what end users are for, silly.

 

[reanjr]

I'm thinking of an element that is allowed to modify other elements by name, somehow. That may be getting into implementation too much, but it's something to think about. So, for example, I want to create a +1 weapon that gives a +2 deflection bonus to AC. So the weapon includes elements like:

<modifier modifiedElementName="tohit.enhancement" modifier="1" />
<modifier modifiedElementName="damage.enhancement" modifier="1" />
<modifier modifiedElementName="wielder.ac.deflection" modifier="2" />

It would be the application's responsibility to know that the deflection bonus doesn't stack with other deflection bonuses.

Just thinking out loud, I guess.

That's the gist of my design. I also plan on creating event hooks. A character might have an OnHit event that fires whenever they are attacked by a weapon. Passed to the event are the weapon's stats and the damage result (which can be altered by the event before releasing control). Now, to account for damage reduction, you need not have the application explicitly understand it. All you have to is attach an event handler for the OnHit event and whenever it's fired, subtract 5 (or whatever) from the damage. One might ask what happens when you have two types of damage reduction.

Maybe you have DR 5/- and DR 7/magic. Both of these are attached to the event. When the DR 5/- event fires, it subtracts 5 from damage and passes on a little bit of metadata to the passed damage indicating what it did. When the DR 7/magic event fires, it checks for this metadata and realizes that it only needs to subtract 2 more damage.

If you created a weapon that ignores damage reduction, it could have an OnDamage event fired just before damage is applied. In the event handler, it checks for the metadata that the DR event handlers added and can re-add in the damage before the final damage is applied.

The main trick I foresee is creating an extensible event model. Though, I suppose this could just be something hardcoded into a plugin.

 

[reanjr]

I'm very interested in such development work and would be happy to help out, at the least by contributing snarky comments and obscure movie references.



It's a big project, I think is why it hasn't happened yet. Somewhere there's a discussion of things that make it hard, one of those being the difference in data requirements for pen & paper versus software -- for pen & paper, every other instance can be an exception to the rule and that's no problem. Whereas when you're trying to develop an object model, those exceptions drive you crazy because you end up with a bazillion very similar but somewhat different objects. In pen and paper world that's fine, because they're all individual objects anyway, but in software it keeps adding complexity to your model.

Which explains PCGen, in a lot of ways.

You are correct; it is a huge project. I had a lot of work done on it (before I lost all my code ) and had only scratched the surface. I'm still trying, though.

 

[reanjr]

Firzair, your app sounds interesting, but I think we're talking about a lower-level standard here. Unless I'm mistaken, nopantsyet wants to define an object model. For example: exactly what data makes up a character? Some of the elements will be simple values (like name) while others will be complex structure of their own (like feats, which would be a sequence of complex elements). What you're talking about is a specific implementation of that model. So we need several layers:

1) Object model: As described above. This could be described as XML schema (I assume that's where nopants is going with this). This has to be finished (or at least well-started) first.

2) API: These would be actual code objects (I would vote for Java classes) that allow programmers to manipulate the data structures.

3) Persistence: Some method of saving the objects. This could be a database that looks like the objects, or it could just read and write the XML files directly (which would be my vote) or a database that stores BLOBS containing the XML. Whatever.

4) Reference Implementation: One or more actual applications that use all the above to do useful work. This could be a character generator, a combat assistant or even a full-blown computer RPG (a little ambitious, I think... ). This could also include things like XSL style sheets that can read a data file and present it nicely.

So, anyway, it's way too early to start talking specifics like resource files for display names, and what programming language to use. On the other hand, it sounds like you are much farther along than we are.

As may be garnered from my last couple of posts, I think this is entirely the way to NOT go about it.

 

[Firzair]

My take will ever be to have the data of the objects entered in a gui. I'd hate to code every object in XML by hand.
You'd need to create a frontend that takes the XML-data-structure (has to be defined in some fashion) and creates a nice gui.
You only get a decent community of developers that add content for your application if is easy. One big problem of PCGen in my eyes is the absence of a decent gui for entering rules (last version I used was 5.6 or something).
Also the structure of the objects should be edited with the gui.

 

[reanjr]

I agree on data entry, but I don't think the application that utilizes the data needs be the application to create the data. I think it would work well as a separate utility.

As for the second I'm not sure exactly what you mean. What data would be formed into a UI? If you simply mean character sheets and the such, that can easily be done using XSLT.

Also, since new content is being created all the time (OGL publishers), you're not really looking for a community of content creators so much as content-converters. Those are usually pretty easy to find.

There's really little point in allowing the average user to alter schema. A schema change would almost certainly require a logic change in code to take advantage of it. Since the average user can not take advantage of this, then there is no point in allowing them to change schema. That should be left to scripters/plugin developers.

 

[Firzair]

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.

 

[JimAde]

It's possible to make a GUI that dynamically builds itself based on a provided data structure. So in your example, the user would have to somehow tell the system that this new field exists. Either by hand-editing the "feat schema" or through some kind of meta-tool. Once he did that, the actual feat editor could be smart enough to display the new field for entry.

But I think we're getting way ahead of ourselves. I understand that Firzair and Reanjr have both done a lot of work on their own tools, but they are a perfect example of why this project is needed. They are using different data models (and everything else). If we had a pre-defined set of data models, they could make their apps any way they want, and still be able to share data.

Would this not be spiffy?

The various pieces can be used (or not) by different projects. So say we have a good data model, but some hack does most of the API coding and it's buggy. You could still use the data model, but write your own code. Or maybe the data model and the API are good, but you decide you really want your data to live in a database instead of XML files, you can do that.

A unified data model has to come first, though.

 

[MaxKaladin]

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.

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.

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

 

[JimAde]

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.

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). So in your example, the "house rules" could include a bit of markup that says the spell called "acid fog" should have its level set to 8 for wizards and sorcerers. 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>