Open Source d20 API/Engine

[JimAde]

Exactly. So you need a model that is tolerant of stuff like that. You have to include "miscellaneous" elements everywhere so applications programmers and users can throw in things ad hoc.

You can't, for example, create a data model for weapons that only includes bonuses to hit and damage. What about when the GM wants to have a weapon that give you a bonus to AC? Or your Diplomacy skill? So you add a "skill modifier" element, but then the GM wants a different weapon that does some other weird thing.

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.

 

[andargor]

You do need some basic "object dictionary", based on the game system. A bonus, a stat, creature (which can be a collection of a minimum number of other defined "objects"), armor class, spell resistance, etc.

The WotC Glossary is a good starting point for the minimum naming/resolution "standard".

Andargor

 

[WingOver]

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.

It's here:

http://www.enworld.org/showthread.php?t=87751

 

[barsoomcore]

Thanks!

*reads thread*

Boy, when I get ranty I really get ranty, don't I? Yikes.

 

[nopantsyet]

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.

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.

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)? "

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?

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.

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.

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

 

[nopantsyet]

Thanks!

*reads thread*

Boy, when I get ranty I really get ranty, don't I? Yikes.

I read one of your responses on the other thread, and I wanted to quote it here:

I DON'T need a "rulebook in a box" -- PC Gen goes WAY overboard in this regard. Just give me a way to specify character stats (preferably via point buy at a level I can set), and track the consequences of the classes I take insofar as BAB, saves, skill points, spells, feats and so on increase per level. Then let me assign my skill points (tracking class skills per class, sure), and keep calculating my modifiers as I choose feats. That's it.

You're hitting on the same think that I don't like. If I want to add a level of a class, I want to be able to do so easily. And if I want to give a PC a feat that is not granted by their class, I want to be able to do so easily. I want to compute the results of the rules without restricting you to just that.

 

[WingOver]

Thanks!

*reads thread*

Boy, when I get ranty I really get ranty, don't I? Yikes.

I liked the "sheerest nonsense" quote in the last post. That was money. haha

yeah.. you were pretty opinionated in that one. Come to think of it, there were a lot of strong opinions in that thread.

Good luck to those pursuing the open source engine. It's interesting to follow.

 

[Firzair]

I don't think it makes sense to get into a data modell for D20 at this point in an OPEN D20 API project as you have to be aware that every such project has to be universally usable to accomodate all the different add-ons. Your super data model for D20 might be good for D&D Core, but what if I want to use grim and gritty or star wars or or or.

What you have to look at first is what different functions will be needed and what level of manipulation to an object do we want. Shall every rpg object come with it's own functions? I believe not, cause you would have to code every new object class. So what basic function are needed?

The base class needed would be a data class (with possible specialization for the different data types).
Every data object can have its own rules, so you need to store them.
For these you need functions to calculate values (that's the integral part of most data). This calculation can be in the form of just doing arithmetic calculus or in the application of boni and penalties. So they have to store boni with some data.
Obviously the different data objects need to know each other and which other data objects they must inform about value changes.
The data objects also need to know which controls (gui components) to inform about changes.
Some script engine is needed to interpret the rules.

Then you would want some container class (mine is called RPGobject). This consists of a list of data objects and some basic functions (GetValue(dataname), SetValue(ataname,value) etc.).

For the rules you would want a rules object, that stores the rules for shared easy access and perhaps in tokenized form.

Perhaps you want some container for the RPGObjects (an RPGController). This would be the master of all. In addtition it should have all general rules objects in it.

That would be the core engine I think. I don't know if java will be the right language for this, as it tends to be somewhat slow and unwieldy for gui creation, but its platform independant (the only thing I don't like about Delphi).

Greetings
Firzair

 

[Firzair]

Ok, here's some more meat from my current application...
Here's what I thought would be needed:
- available data types (integer, float, string, dice, memo, cost (that's an abstract fantasy money value), object, reference, item, itemslot, logical (yes/no) and SetOf (reference to one or more objects)
- some basic definition for a bonus
I've got a table just for you to enter available bonus (and penalty) names and whether they stack or not. Bonus handling is done by the dataobject
- tables for storage of the data
Current tables (using access at the moment):
Object types (e.g. creature, skill, feat etc.)
Variables by object type (e.g. age, hit_points_max, skill[] for creature)
Objects (all object types are stored in the same table, the object data goes into a BLOB)
Bonus types (as described above)
Rules (for storing rules that don't directly belong to a variable or an object; not sure if needed)
Masks (my name for panels to show the data)
Generators (here the rules for different generation methods for the various object types are stored; a generator can be with or without graphical interface)
GeneratorTables (I've created an engine like an early version of TableSmith; here the tables will be stored)
Tables (here you can store tables like experience by CR etc.)

The object table has the following fields:
ObjectType
ObjectName
Creator (this is part of the primary key, so you can import data with the same name from a friend and the select, which version to use)
Data (the BLOB with the actual data
Prereq (expressions that can be checked; if the prerequisites are not satisfied the object won't appear in selection boxes; can be overridden)
Description (a free text)
Rules (rules for the specific object)
Active (a true/false field, where you can just turn off the availability of the object)
DisplayName (as described above)
Licence (reference to the OGL for that object)

Perhaps that's a not so abstract base for conversation and discussion.

Greetings
Firzair

 

[reanjr]

I'm currently working on some things along those lines for the .NET framework. I wasn't planning on opening the source, but I might be compelled to if there are enough people who want to help.

Currently, I'm doing a lot of data scrubbing, running Regular Expressions over HTML representations of the rules to form XML representations. There's a lot of scripting and manual work involved as well.

Since I am only working on it alone, I was creating XML as I went along, not codifying as a schems or anything.

The goal is to have a framework for representing characters in a management utility for DMs and Players.

So far, my primary work has been on spells because I really need a spell manager. As an example, acid fog would be:

<spell name="acid-fog" school="conjuration" subschool="creation" descriptor="acid">
	<level sor="6" wiz="6" water="7" />
	<components verbal="true" somatic="true">
		<material type="arcane">A pinch of dried, powdered peas combined with powdered animal hoof.</material>
		<focus type="divine" />
	</components>
	<casting-time length="1" unit="standard" />
	<range length="medium" />
	<effect type="spread" shape="cylinder" radius="20" radius-unit="feet" height="20" height-unit="feet" />
	<duration length="1" unit="round" perlevel="true" />
	<body>
		<p>Acid fog creates a billowing mass of misty vapors similar to that produced by a <link ref="spell://srd/solid-fog" /> spell. In addition to slowing creatures down and obscuring sight, this spell’s vapors are highly acidic. Each round on your turn, starting when you cast the spell, the fog deals <dice number="2" type="6" /> points of acid damage to each creature and object within it.</p>
		<damage type="acid" number="2" type="6" />
	</body>
</spell>

Anyway, all that data would be recognized by the application in the context of the character casting it. So it would calculate out the duration, you could click on the 2d6 in the spell description to get a random result, etc. The effect would be automated on a grid system. Before commiting to anything, you could remove or add targets that the application might not be able to figure out (for instance, if there is a wall in the way the program doesn't know about, you could select the area, then remove the targets behind the wall, then have it commit and calculate 2d6 points of acid damage to everything in the spread.).