# Open Source d20 API/Engine



## nopantsyet (Mar 27, 2005)

I think this was brought up a couple of years ago and I'm assuming it never went anywhere since I can't find anything on Google. (Though I won't rule out googleblindness on my part.) 

So I'm picking up the flag from the battle field and will wave it once more to see if there's anyone to rally around it...Anyone have any interest in working on or having access to an open source data model and rules engine for d20? It just seems like some of the software out there could progress better if they weren't all duplicating the effort of developing the data model, the engine and the application.

*This effort is being launched in earnest. Please visit the RPGEngine Wiki to observe or participate. 
*


----------



## DMFTodd (Mar 28, 2005)

There's a yahoo group called D20 XML or some such thing. It hasn't made much progress.


----------



## Planesdragon (Mar 28, 2005)

nopantsyet said:
			
		

> So I'm picking up the flag from the battle field and will wave it once more to see if there's anyone to rally around it...Anyone have any interest in working on or having access to an open source data model and rules engine for d20? It just seems like some of the software out there could progress better if they weren't all duplicating the effort of developing the data model, the engine and the application.




d20-XML and the FGA (FGA-Prometheus) both would have an interested in that.

d20-XML has hit a few snags, and is more of a forum for those that do XML things than a place to collaborate a project on.

The FGA--well, I want to give everyone a chance to recover from Easter.  E-mail me off EnWorld or check www.theFGA.com in about a week or so.

The answer is "maybe us", and if that "maybe" is a "no", I'd still be interested in helping.


----------



## JimAde (Mar 28, 2005)

I'm up for it.  I'm not familiar with the efforts that have come before, but it seems like there's a definite need.


----------



## JoeyD473 (Mar 29, 2005)

I'd be willing to help out if I can


----------



## nopantsyet (Mar 30, 2005)

Thanks for the responses. I joined d20-XML and there are XML and MySQL "SRD implementations," which appear to model at least some portion of the d20 data set. I'd like to see an entity relationship diagram for that. Might be something to learn there. Also, there are a number of free and closed products that demonstrate different approaches, upon which we can hopefully improve. As I see it, there are three main tasks I'd like to accomplish. 

*1. d20 Data Model *- Define all relevant data and the states in which they exist. For example, AC: touch, flat-footed, etc. This should be as abstract as possible in order to best support rules extensions.

*2. d20 Rules Engine* - Create framework for generating, altering and persisting d20 data. Framework should be plugin-based to allow alternate or add-on rule and data sets. Implement d20 SRD rules as an extension to base environment

*3. Reference Implementation* - I think a reference implementation is important to demonstrate how this can be used as well as to get some practical benefit from this, that being the actual goal of this whole thing.

These three things are separate because of a basic design philosophy I want to follow. The data should be separate from the implementation, and the implementation should be separate from the application. On the lowest level, any application can be made to share data. On the second, any desired user interface can be built on the engine, allowing user experience to be optimized to different activities (e.g. DMing, running a PC, generating characters).

Obviously it must be OGL compliant in order to allow SRD materials to be distributed. I would like to release it under a free license, allowing it to be used in both free and commercial projects. If nobody ever uses it but us, that's fine. But should anyone else want to, the only thing I care about is that it remains compatible.

*Planesdragon* - I hadn't heard of the FGA before. I'm interpreting your statement as indicating that FGA will be making some sort of announcement soon, so I will watch the site for it then drop you an email. 

Just to see if this is viable, I'm going to wait a few days to see if I get more responses to this, then I'll open a thread to start discussing some design ideas and see if we can build any momentum. If we can, I'll put some effort into getting resources (web site, etc.) behind this.


----------



## Firzair (Mar 30, 2005)

Hi everybody,
I'm working on a piece of software that would be a universal RPG helper that you could use for D20, Rolemaster and probably anything else.
My approach (using Delphi) is just building a framework with a database behind. 
In the application you can define your object layouts, e.g. using the SRD you define a object category _skill_ with some variables like armor_penalty and use_untrained. 
Then in the application you create a panel where you can enter data for this object.

Every variable and every object has its own rules-section. 
Here's a working example:
Object: _creature_
Variable: _attribute[].current_ (defined as calculated integer)
Rules: 
:INIT
=attribute[].base

Variable: _attribute[].mod_ (defined as calculated integer)
Rules: 
:INIT
=(attribute[].current \ 2) - 5    ( \ is used for truncated division of numbers, so always rounding down)

attribute[] means there's an object type called attribute and that for every such available object an variable will be created using the correct code: attribute[strength].current will reference attribute[strength].base etc.

The :INIT-section only does initial calculations. Object- and variable-rules can add boni to calculated variables that will be evaluated after the :INIT-section.

Every variable and every object has a database field for credits and a licence reference (so you can enter all the OGLs you use in your data into your database and then you always stay OGL-compliant, as for everything on the screen you can get the relevant OGL onto the screen.

Object data ist stored as plain-text in an BLOB-field in a table. XML would be possible but I will only use this for export and import functions.

Sorry for advertising here a product that's in early alpha stadium, but my point is, an OPEN D20 API should use a similar approach: being just a framework, that gives you the possibility to enter (or import) any data and screen definitions. 

Oh and one important thing I do in my program: every object and variable has got a display name. This display name can be changed without having to change the rules. Thus you can take the english SRD-data and just change the display names to german without loosing the functions. While I'm used to english texts my players are not and they like to get german texts 

Greetings
Firzair


----------



## JimAde (Mar 30, 2005)

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.


----------



## andargor (Mar 30, 2005)

If it can help, I was working on such an engine in C++ and stopped about a year ago (RL, other group priorities, yadda, yadda).

I made a small demo that builds a 25th level barbarian from "abstract" XML objects. There's a README with it that explains the approach:

http://www.andargor.com/files/panther-demo.zip

HTH,

Andargor

PS: I'll get back to it eventually...


----------



## barsoomcore (Mar 30, 2005)

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.


----------



## JimAde (Mar 30, 2005)

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 (Mar 30, 2005)

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 (Mar 30, 2005)

barsoomcore said:
			
		

> 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 (Mar 30, 2005)

Thanks!

*reads thread*

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


----------



## nopantsyet (Mar 31, 2005)

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 (Mar 31, 2005)

barsoomcore said:
			
		

> 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:







			
				barsoomcore said:
			
		

> 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 (Mar 31, 2005)

barsoomcore said:
			
		

> 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 (Mar 31, 2005)

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 (Mar 31, 2005)

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 (Mar 31, 2005)

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


----------



## reanjr (Mar 31, 2005)

nopantsyet said:
			
		

> 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 (Mar 31, 2005)

JimAde said:
			
		

> 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" />
> ...




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 (Mar 31, 2005)

barsoomcore said:
			
		

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




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 (Mar 31, 2005)

JimAde said:
			
		

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




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


----------



## Firzair (Mar 31, 2005)

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 (Mar 31, 2005)

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 (Mar 31, 2005)

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 (Mar 31, 2005)

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 (Mar 31, 2005)

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 (Mar 31, 2005)

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>


----------



## MaxKaladin (Mar 31, 2005)

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.


----------



## JimAde (Mar 31, 2005)

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


----------



## MaxKaladin (Mar 31, 2005)

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.


----------



## JimAde (Mar 31, 2005)

I agree.  It's up to the API code to do the math.  The data model just holds all the pieces.  Cool.


----------



## Planesdragon (Apr 1, 2005)

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


----------



## Firzair (Apr 1, 2005)

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.


----------



## andargor (Apr 1, 2005)

If you need raw data (spells, powers, items, monsters, classes, etc.), you are free to use my database. It needs further breaking down, however. It's only "medium resolution".

http://www.andargor.com/

Andargor


----------



## JimAde (Apr 1, 2005)

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?


----------



## nopantsyet (Apr 2, 2005)

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.


----------



## nopantsyet (Apr 2, 2005)

I've created a thread for an initial rules discussion. You can find it here:
* 	RPG Tools - d20Engine: Core Mechanic*​ 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:.


----------



## reanjr (Apr 2, 2005)

Firzair said:
			
		

> 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 (Apr 2, 2005)

JimAde said:
			
		

> 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 (Apr 2, 2005)

MaxKaladin said:
			
		

> 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 (Apr 2, 2005)

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.




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" />
> ...




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 (Apr 2, 2005)

MaxKaladin said:
			
		

> 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 (Apr 2, 2005)

MaxKaladin said:
			
		

> 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 (Apr 2, 2005)

Planesdragon said:
			
		

> 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 (Apr 2, 2005)

nopantsyet said:
			
		

> 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 (Apr 2, 2005)

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 (Apr 2, 2005)

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


----------



## nopantsyet (Apr 3, 2005)

Regarding history, I'm inclined to make characters aggregate rather than snapshot based. You might have: 
	
	



```
<ability id="int" name="Intelligence" base="16">
  <boost value="1" reason="lvl4" uid="1293801"/>
  <boost value="1" reason="lvl8" uid="1295920"/>
</ability>
```
The uid is a unique identifier for a "change set" (e.g. all changes from advancing a level) so all related changes can be ignored to see an earlier version of the PC.







			
				reanjr said:
			
		

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



I agree that a sequential build-up should never be required. But fundamentally, I think that the character should be stored in aggregate rather than final form.


----------



## nopantsyet (Apr 3, 2005)

Planesdragon said:
			
		

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



Cool. I'll take a look.


----------



## JBowtie (Apr 3, 2005)

Currently I'm working on a Python-based character generator for my campaign, and I have a couple of observations that might be of use to you.

1) RDF/OWL is better than pure XML. RDF without OWL ends up being really, really hard to read because the XML format is horrible, but OWL lets you write stuff that looks like regular XML.
The thing about RDF is that you can define things piecemeal, extending definitions arbitrarily. For example, you could easily add new rogue abilities when you come across them, instead of having to modify the core SRD list. RDF is also *much* better for defining exceptions.

2) Complete dynamic UIs kill usability. One of the reasons I am doing my own generator is because every generator I've seen is a horror when it comes to being usable. There's no need for that.

3) Have a character template that encodes all the basic assumptions, like when a character gets feats, what the basic abilities are, etc. That lets you handle variations like AU or Traveller easily by modifying the character template. It also avoids the most common hard-coding I see.

4) Model armour and weapon proficiencies explicitly, rather than generalizing them as class/race abilities or feats.  You have no idea how much it simplifies your life.

5) You can write a mini-language for evaluating expressions like (CHA/2)+2. Mine is based on MathML.

6) An awful lot of modifiers are conditional. Many generators forget this.

My code is GPL, but I'm not releasing it publicly until it's cleaned up a bit more. I figure it'll hit a 0.6 public release in about six months.


----------



## nopantsyet (Apr 3, 2005)

JBowtie said:
			
		

> 1) RDF/OWL is better than pure XML...



Thanks for the thoughts, JBowtie. I'll have to check out RDF+OWL--I'm not well acquainted with it.







			
				JBowtie said:
			
		

> 2) Complete dynamic UIs kill usability. One of the reasons I am doing my own generator is because every generator I've seen is a horror when it comes to being usable. There's no need for that.



I agree with you there. On both points. I think a solid engine would allow people to develop excellent UIs for specific purposes. A character generator has different usability considerations than a DM's table manager. My chief concern is that at the end of the day, the data and engine do not force usability or mechanical concessions in either of those potential applications.







			
				JBowtie said:
			
		

> 3) Have a character template that encodes all the basic assumptions, like when a character gets feats, what the basic abilities are, etc. That lets you handle variations like AU or Traveller easily by modifying the character template. It also avoids the most common hard-coding I see.



So you mean wrap up all of the basic non class-specific rules in that?







			
				JBowtie said:
			
		

> 4) Model armour and weapon proficiencies explicitly, rather than generalizing them as class/race abilities or feats. You have no idea how much it simplifies your life.



That makes sense.







			
				JBowtie said:
			
		

> 5) You can write a mini-language for evaluating expressions like (CHA/2)+2. Mine is based on MathML.



makes sense.







			
				JBowtie said:
			
		

> 6) An awful lot of modifiers are conditional. Many generators forget this.



Yeah, that's one part I'm still thinking a lot about. How to capture the conditions (both character and game) that trigger certain rules and rule changes.


----------



## JBowtie (Apr 3, 2005)

nopantsyet said:
			
		

> Thanks for the thoughts, JBowtie. I'll have to check out RDF+OWL--I'm not well acquainted with it.I agree with you there.



Best place to start is the OWL guide(http://www.w3.org/TR/owl-guide/). Using OWL has opened up whole new realms of possibility for random character generation.
Skip the RDF specs, they're badly written and only confuse people (because their idea of XML syntax is absolutely hideous and makes people run screaming).



			
				nopantsyet said:
			
		

> On both points. I think a solid engine would allow people to develop excellent UIs for specific purposes. A character generator has different usability considerations than a DM's table manager.



I strictly seperated the UI from the underlying model; the engine has its own unit tests that exercise the API. Some assumptions are hardcoded into the UI (only handles 4 feats a level), but the engine actually is more flexible than that (can handle arbitrary number of feats).



			
				nopantsyet said:
			
		

> So you mean wrap up all of the basic non class-specific rules in that?



That's exactly what I mean. For example, my SRD template says a character receives a feat at first level. My AU template says a character gets two feats at first level and specifies the categories (ceremonial for one and talent or general for the other). A Blue Rose template would have a feat slot at every level. Currently the only things left hard-coded in my engine are a few formulas and rules about bonus stacking. Those will eventually migrate to the XML as well.



			
				nopantsyet said:
			
		

> Yeah, that's one part I'm still thinking a lot about. How to capture the conditions (both character and game) that trigger certain rules and rule changes.



For the general case, I have a optional condition attribute for all bonuses which contains the text of the condition; for <bonus condition="vs goblinoids">1</bonus> on the stat block/character sheet I print out "+1 vs goblinoids" (though I also specify bonus type in the actual XML).
When I'm ready to actually start evaluating actual conditions I can use OWL expressions, which will resolve automatically.


----------



## nopantsyet (Apr 5, 2005)

Well, I know you said you're not going to release your code until it's polished, but if you'd be willing, I'm really interested to see a simple example of how you're utilizing OWL. The ontological approach seems to encapsulate a number of the design principles I've had in mind. But I'm curious, does it really provide enough power and flexibility to be able to incorporate alternate rules? You mentioned AU and Blue Rose, so it sounds like it is. But what exactly does it do with a component like "vs goblinoids?"


----------



## reanjr (Apr 5, 2005)

nopantsyet said:
			
		

> Regarding history, I'm inclined to make characters aggregate rather than snapshot based.




That's a huge pain for those who just want to use the program to input their character and be done with it or those who don't care about the letter of the rules.  There's already dozens of programs out there that strictly support the rules.  I don't really see a need for another one with just a different file format.

If you have automatically stored versions of the character at each level (or any other change you want to keep updated), then this history data is self-evident without forcing the developer or user into using one particular model.

That said, I think there is room for that sort of thing, but it shouldn't be enforced.


----------



## reanjr (Apr 5, 2005)

nopantsyet said:
			
		

> I agree that a sequential build-up should never be required. But fundamentally, I think that the character should be stored in aggregate rather than final form.




But by putting it in that form, you are forcing the application to support it.  What you want to do is instead put:


```
<ability id="int" name="Intelligence" score="18">
  <boost value="1" reason="lvl4" uid="1293801"/>
  <boost value="1" reason="lvl8" uid="1295920"/>
</ability>
```

If the app supported going backwards, it could figure out the original Int was 16 and apps that didn't support this could read that the score is currently 18, regardless of how it got there.

You have to have the data in its final aggregated form or you are forcing aggregation.


----------



## reanjr (Apr 5, 2005)

JBowtie said:
			
		

> Currently I'm working on a Python-based character generator for my campaign, and I have a couple of observations that might be of use to you.
> 
> 2) Complete dynamic UIs kill usability. One of the reasons I am doing my own generator is because every generator I've seen is a horror when it comes to being usable. There's no need for that.




I agree.  I think the UI should support some dynamic elements, but overall it needs to understand what's it is trying to do.



> 5) You can write a mini-language for evaluating expressions like (CHA/2)+2. Mine is based on MathML.




I also agree with this, though I am going for something leaps more powerful (yet simpler) than MathML.  I'm going for something Lisp-like (since XML lends itself well to that structure).


----------



## nopantsyet (Apr 5, 2005)

Yeah, I see your point in that context. Just as easy to work backwards as forward. I'm fine with the idea of storing the score rather than the base, and separating the aggregate to work backwards.

I was actually thinking Python since it's appropriate for semantic processing and it's easy to embed. But if some functional XML syntax is capable of providing the same level of functionality without embedding script, I'm liking that.


----------



## reanjr (Apr 5, 2005)

nopantsyet said:
			
		

> Re: conditional modifiers
> 
> Yeah, that's one part I'm still thinking a lot about. How to capture the conditions (both character and game) that trigger certain rules and rule changes.




I've been discussing how to handle this this on the other thread (the one linked to earlier by JimAde I think).


----------



## JBowtie (Apr 5, 2005)

Here's an example of how I would model the "+1 vs goblinoids" so it can be resolved by an engine. This is off the top of my head and probably won't withstand closer analysis.
First, we'll need to define a goblinoid. Note that this could actually be an anonymous class defined as part of the bonus rather than a named class as in the example.
If something has creature subtype goblin and is a humanoid, we're calling it a goblinoid. A more accurate definition would use oneOf to enumerate the full list of subtypes IIRC.


```
<owl:Class rdf:ID="http://example.org/srd#goblinoid">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="http://example.org/srd#humanoid">
    <owl:Restriction>
      <owl:onProperty rdf:resource="http://example.org/core#creatureSubtype" />
      <owl:hasValue rdf:resource="http://example.org/srd#goblin" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>
```

Now, let's define the bonus. It's anonymous as it will typically be defined as part of some other rule, such as a racial trait.


```
<core:Bonus>
	<core:appliesTo resource="http://example.org/core#attack" />
	<core:type resource="http://example.org/srd#racial" />
	<core:Condition>
		<rdfs:label>vs goblinoids</rdfs:label>
		<core:conditionType rdf:resource="http://example.org/core#runtime" />
		<srd:goblinoid>
			<runtime:Role rdf:about="http://example.org/core#target" />
		</srd:goblinoid>
	</core:Condition>
	<core:formula>1</core:formula>
</core:Bonus>
```

So, at runtime, when a creature of subtype goblinoid is assigned the "target" role relative to the character, the formula is evaulated and applied to the attack roll subject to stacking rules for bonus types.
Here, I'm telling the processor this condition can be checked at runtime. If, at that time, there is a goblinoid with the 'target' role, apply this bonus.
Some conditions can realistically only be evaluated by a DM (see the preqs for assassins, for example). For those I would stick with a simple text description like my original example.
Now, this is a lot of work, so I'm sticking to a small, well-defined ontology to begin with (stuff in the "core" namespace, above), and building tools to extend the ontologies on top of that. So all the stuff in the SRD namespace would be the result of using my BookBuilder application. Definitions like goblinoid can be built by example rather than typed out (I haven't even thought about the book builder UI yet).


----------



## MaxKaladin (Apr 6, 2005)

I know some people have objected to the idea of the history on the basis that they don't want to worry about strict level by level compatibility or force developers to do so.  I don't think it would necessarily do so.  Different developers could do it different ways, but I can see either using a little AI to assign things to levels to come up with a legal character behind the scenes or just writing tags in the history that basically say "character built at {X} level and this value was assigned".  Other programs wouldn't be able to make sense of it for down-leveling purposes but as long as they add up the points it would still work.  

I also understand there are some wierd instances like the stat decrease example.  I would think that a program that wanted to handle this by allowing people to decrease a different stat would be able to just ask the user which stat to decrease and then apply a "decreased stat when downgraded to level {X} " tag.  It's a history, after all.  It should keep a history of all the changes made to the character and keeping track of a strict progression from 1st to 20th level is only one possible application.  

I suppose I just see a lot of these things being a function of the program and programmer manipulating the data properly.


----------



## nopantsyet (Apr 6, 2005)

I think I'm swayed to making history optional. I've been trying to formulate a good argument against it because I felt pretty strongly it should be mandatory, but nothing has held up to my own scrutiny and I'm out of arguments.

*JBowtie - *I like the direction you're going with this. Have you read the other thread, about implementing the core mechanic? I'm curious what your thoughts are on Ardargor's approach of deconstructing his existing d20 schema into an ontology using Protégé.


----------



## reanjr (Apr 6, 2005)

nopantsyet said:
			
		

> Yeah, I see your point in that context. Just as easy to work backwards as forward. I'm fine with the idea of storing the score rather than the base, and separating the aggregate to work backwards.
> 
> I was actually thinking Python since it's appropriate for semantic processing and it's easy to embed. But if some functional XML syntax is capable of providing the same level of functionality without embedding script, I'm liking that.




I decided on a XML for a couple of reasons:

 - It's extremely simple and intuitive for the common user to read and fiddle with.
 - No dependency issues (other than XML libraries which can hardly be called dependencies nowadays)
 - Doesn't foster argument over language issues ("This architecture would be great if they had used Java/Perl/Python/whatever")
 - It creates only a single learning curve.  Once you get into editing data files (such as a character), it's a natural progression to edit rules files.  Also simplifies the architecture a little (though this isn't that big a deal with the libraries available).
 - Licensing free.  I didn't want to get into the muddled mess of using GPL/CNRI (Python is CNRI, most language libraries are GPL) code.  I just find it easier to deal with freely available closed libraries, which, in my experience, are better at maintaining backwards compatibility and packaging support.  I usually try to work with the BSD license, which is how I planned on licensing mine.
 - Language agnostic.  While one could write a Perl application that uses Python script (for example), one would find that by using Python script, you would attract a lot of Python developers and few others.
 - Extensible language.  No language (other than Lisp) is extensible like XML.  In fact, it can be said with more than a grain of truth, that any language that is as extensible as Lisp is itself a dialect of Lisp.  With that in mind, I chose to design the XML language using Lisp principles (they parse in a similar fashion, so it's quite intuitive).

That said, I primarily develop in PHP and .NET.  Using .NET for the application-level I think is the way to go so that people have language choices (C#, VB, C++, Perl, Python, PHP, Fortran, COBOL and many others all have .NET versions).  Also, of the 3 major platforms (Wintel, Linux on Intel, and Mac), only Java Bytecode has better cross-platform support and user penetration than MSIL/Mono,but it sticks you with a single language.


----------



## reanjr (Apr 6, 2005)

JBowtie said:
			
		

> Here's an example of how I would model the "+1 vs goblinoids" so it can be resolved by an engine. This is off the top of my head and probably won't withstand closer analysis.
> First, we'll need to define a goblinoid. Note that this could actually be an anonymous class defined as part of the bonus rather than a named class as in the example.
> If something has creature subtype goblin and is a humanoid, we're calling it a goblinoid. A more accurate definition would use oneOf to enumerate the full list of subtypes IIRC.




For comparison, my methodology follows:


```
<!--
	target and mod are variables passed by the attack event
	e is equals function
	I should also point out that the parser doesn't need to understand and, e, and if
	as they can be described with the simpler assert function in a library
-->
<creature-attack-bonus attach="attack" when="before" type="@" subtype="@" bonus="0">
	<assert>
		<and>
			<is-set>type</is-set>
			<e><a>type</a><a>target.type</a></e>
		</and>
		<if>
			<is-set>subtype</is-set>
			<assert>
				<e><a>target.subtype</a><a>subtype</a></e>
				<set name="mod"><add><a>mod</a><a>bonus</a></add></set>
			</assert>
			<set name="mod"><add><a>mod</a><a>bonus</a></add></set>
		</if>
	</assert>
</creature-attack-bonus>
```

In the dwarf creature all you have to do is:

```
<monster name="dwarf">
	<creature-attack-bonus type="humanoid" subtype="goblinoid" bonus="1" />
	<creature-attack-bonus type="humanoid" subtype="orc" bonus="1" />
</monster>
<monster name="gnome">
	<creature-attack-bonus type="humanoid" subtype="kobold" bonus="1" />
	<creature-attack-bonus type="humanois" subtype="goblinoid" bonus="1" />
</monster>
```

You can use the same function for Ranger favored enemy bonuses as they are chosen.


----------



## reanjr (Apr 6, 2005)

MaxKaladin said:
			
		

> I know some people have objected to the idea of the history on the basis that they don't want to worry about strict level by level compatibility or force developers to do so.  I don't think it would necessarily do so.  Different developers could do it different ways, but I can see either using a little AI to assign things to levels to come up with a legal character behind the scenes or just writing tags in the history that basically say "character built at {X} level and this value was assigned".  Other programs wouldn't be able to make sense of it for down-leveling purposes but as long as they add up the points it would still work.




I disagree with it on the basis that it kills interoperability.  The main framework for defining a character should be as simple as possible so more clients can be created to use it.  Forcing history to be kept (as you do if you aggregate the final value) raises the bar for creating compatible application dramatically.

The way I currently have it worked out is


```
<!--half-orc example-->
<character>
	<strength>12
		<modifier mod="2" source="race" />
	</strength>
	<dexterity>10</dexterity>
	<constitution>10</constitution>
	<intelligence>8
		<modifier mod="-2" source="race" />
	</intelligence>
	<wisdom>10</wisdom>
	<charisma>8
		<modifier mod="2" source="race" />
	</charisma>
```

Another app would simply read the first text element (I'm using the wrong term here) found in the strength element and would be fine.



> I also understand there are some wierd instances like the stat decrease example.  I would think that a program that wanted to handle this by allowing people to decrease a different stat would be able to just ask the user which stat to decrease and then apply a "decreased stat when downgraded to level {X} " tag.  It's a history, after all.  It should keep a history of all the changes made to the character and keeping track of a strict progression from 1st to 20th level is only one possible application.




My example allows that, but doesn't force it.



> I suppose I just see a lot of these things being a function of the program and programmer manipulating the data properly.




Shouldn't force the programmer (or the program for that matter) to know the rules.  It makes things difficult to change and update.


----------



## reanjr (Apr 6, 2005)

Just ran into a legal snag.  Ability score generation is not open content.  Unless I'm missing something.  The Elite Array is in there, so you could use that.  Or you could distribute 63 points evenly (giving the average) or some other method.  But 4d6, drop lowest, arrange is nowhere to be found.

In the meantime, I'm going to put in ability score generation as a library function that can be removed later easily and isn't part of the core document.


----------



## reanjr (Apr 6, 2005)

Well, this is what I've accomplished since this discussion began (though a lot of it has been stewing in my head for quite some time).

Just wanted to post this up in case anyone wanted to take a look.  This is the beginning documentation for what I call RPGML (RPG Markup Language).  It includes most of the core functions that an interpreter must understand (it's missing the ones related to adding and deleting XML tags from a dataset).  It should give you a more formal idea of what I've been blathering about in random spurts of XML.  I've already coded a library of a dozen or so helper functions in this language to facilitate easier use, but I haven't had the time to document them.

Some of the helper functions include (C/Java equivilents with my function names in parentheses):

>= operator (gte)
<= operator (lte)
?: operator (if)
&& operator (and)
|| operator (or)
A simple switch statement (supports different branches on <, =, >) (compare)
A function that takes a number and normalizes it to a certain range (range)

In addition, I have the following rules coded up in RPGML:

The core mechanic.
Ability score modifiers.
Bonus spells based for high abilties.
A generic roll function that will take any-sided die with any modifier.
A function for each die (d6 function, d8 function, etc.).
Racial ability score modifiers.
Human bonus feat and skills.
Most Dwarven racial abilties (Stability was a pain, but I think I have the issue resolved now).

As you might imagine, I'm steadily moving my way directly through the SRD.

I currently left off on the racial rules to work on the core create-character function so that the engine knows what steps need to be taken (for instance apply race stuff AFTER ability scores) and I can work out how the language tells the app it needs input from an end user.


----------



## MaxKaladin (Apr 6, 2005)

reanjr said:
			
		

> The way I currently have it worked out is
> 
> 
> ```
> ...



The thing is that history could easily be included in this.  I said that I didn't think it should include calculated number or, at least, only calculated numbers.  If we include both, the way it would work out is something like this:


```
<!--half-orc example-->
<character>
	<strength>13
		<modifier mod="2" source="race" />
		<modifier mod="1" source="level" level="4" />
	</strength>
	<dexterity>10</dexterity>
	<constitution>10</constitution>
	<intelligence>8
		<modifier mod="-2" source="race" />
		<modifier mod="1" source="level" level="8" />
	</intelligence>
	<wisdom>10
             	<modifier mod="-1" source="leveldecrease" level="8" />
             </wisdom>
	<charisma>8
		<modifier mod="2" source="race" />
	</charisma>
```

If someone wants to use the history, they can just look at the elements.  If not, they can just look at the base tags for each ability to get the final number.  Perhaps we can even enclose history in <history> tags so they can be further ignored if desired.  

I suppose I'd see less need for something like this if I hadn't had such a hard time trying to fiddle with my NPCs in PCGen.  Trying to take someone down a level in that program is one of the easiest ways to screw it up.


----------



## reanjr (Apr 6, 2005)

MaxKaladin said:
			
		

> The thing is that history could easily be included in this.  I said that I didn't think it should include calculated number or, at least, only calculated numbers.  If we include both, the way it would work out is something like this:
> 
> 
> ```
> ...




OK, in that case, we're on the same page.  I have no problem supporting a history in the design spec.  I just wanted to make sure it was built from current -> back rather than from starting -> forward so "dumb" clients could still use the character.  I'm sold on that idea.

Good idea about the history tag.  That would actually work well for one of the design issues I was trying to come up with a solution for - how to separate temporary modifiers from permanent ones (by temporary, I mean ones that are not saved to the character but are added from, for instance, a temporary spell effect or something like that).  My initial thought was to go through the various "source" attributes checking to see if the source attribute was a permanent one or not, but it seemed clunky, which, of course, it was.

So you could have something like:


```
<strength>17
	<history mod="2" source="race" />
	<history mod="1" source="level" meta="4" />
	<modifier mod="4" source="spell" meta="1" />
</strength>
```

Notes:
 - There's a good reason I used meta instead of level that I needn't go into now.
 - The meta for spell is sort of an id for the spell that an event can be attached to so that, when the spell runs out, it can be removed.

Then when saving the character, any application that supported temporary modifiers could remove all modifier tags (and reduce the value accordingly) before saving.  Unless you wanted to have an option to save exact state (if you leave off gaming in the middle of a battle or you are playing a PbP type game).

I think that would work pretty well.

[edit] Maybe even a third tag for non-permanent, but long term modifiers (such as a continuous magic item).  I'll think more on that idea after I get the first two or three chapters of the PHB translated to markup.


----------



## MaxKaladin (Apr 6, 2005)

reanjr said:
			
		

> OK, in that case, we're on the same page.  I have no problem supporting a history in the design spec.  I just wanted to make sure it was built from current -> back rather than from starting -> forward so "dumb" clients could still use the character.  I'm sold on that idea.
> 
> Good idea about the history tag.  That would actually work well for one of the design issues I was trying to come up with a solution for - how to separate temporary modifiers from permanent ones (by temporary, I mean ones that are not saved to the character but are added from, for instance, a temporary spell effect or something like that).  My initial thought was to go through the various "source" attributes checking to see if the source attribute was a permanent one or not, but it seemed clunky, which, of course, it was.
> 
> ...



How about we develop it a bit further to have a <base> tag.  That way you have the starting point and all the modifiers both historical and current used to arrive at the final number.  Thus:


```
<strength>17
	<base value="10" />
	<history mod="2" source="race" />
	<history mod="1" source="level" meta="4" />
	<modifier mod="4" source="spell" meta="1" />
</strength>
```

A program can ignore all that and just use the given strength number or it can derive its own number by reading the base tag and then applying the history and modifier tags to arrive at the proper number.  



			
				reanjr said:
			
		

> [edit] Maybe even a third tag for non-permanent, but long term modifiers (such as a continuous magic item).  I'll think more on that idea after I get the first two or three chapters of the PHB translated to markup.



That's not a bad idea, but it might also be applied using the existing modifier tags.  Just set the source to "item" and use the meta tag to identify which one somehow.


----------



## nopantsyet (Apr 6, 2005)

Hi--Good thoughts everyone. I've set up a Wiki at my web site http://rpgengine.newtongamers.com/ if you'd like to start some work there. It's going to start out informal while we determine how the project will be governed. I would like this to be lightweight and straightforward, but all final works should have consistency with the design goals. I'll post some more thoughts on this tonight.


----------



## Planesdragon (Apr 7, 2005)

reanjr said:
			
		

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




MS's Word .DOC format has an *option* of etiher tracking changes or saving a previous version.  Both of these are not turned on by default, and can baloon a document's size to unwiedly proportions.

Just a Wednesday night FYI.


----------



## Firzair (Apr 7, 2005)

reanjr said:
			
		

> Well, this is what I've accomplished since this discussion began (though a lot of it has been stewing in my head for quite some time).
> 
> Just wanted to post this up in case anyone wanted to take a look.  This is the beginning documentation for what I call RPGML (RPG Markup Language).  It includes most of the core functions that an interpreter must understand (it's missing the ones related to adding and deleting XML tags from a dataset).  It should give you a more formal idea of what I've been blathering about in random spurts of XML.  I've already coded a library of a dozen or so helper functions in this language to facilitate easier use, but I haven't had the time to document them.
> 
> ...




Hi reanjr,
this document's something I really like. One more thing to define would be the _modifier_ because there's a distinct mechanic behind the modifier handling (stacking of different bonustypes). But if this could easily be done with the current ruleset (RPGL) I'd like to see how it comes out.

Greetings
Firzair

PS: I think I'll rewrite my script engine to use RPGL


----------



## reanjr (Apr 7, 2005)

MaxKaladin said:
			
		

> How about we develop it a bit further to have a <base> tag.  That way you have the starting point and all the modifiers both historical and current used to arrive at the final number.




I suppose you could for clarity, but I'm not sure what use it would have except to introduce data integrity issues (if someone hand-edited and forgot to change one of the mods, but they changed the final).  You can always backtrack it.  There might also be a problem if you create a character in an editor that fully supports history then modify it in one that doesn't.  It's something to think about, though.


----------



## Firzair (Apr 7, 2005)

A bit OT, but I've got a question about XML: how would XML represent a char who has the feat _toughness_ twice? Do you need a counter for this?

Greetings 
Firzair


----------



## reanjr (Apr 7, 2005)

Nope...


```
<character>
	<feat name="toughness" />
	<feat name="toughness" />
</character>
```

...or some such thing would work fine.


----------



## Firzair (Apr 7, 2005)

Hi reanjr,
I think there is some more functionality needed from the RPGL:

Some kind of SELECT for getting a collection of something used with a kind of FOREACH clause (e.g. Select from Feats where Feats.Type like "Fighter"). 
I think there has to be a scope for each function (e.g. something that says this function belongs to the object _creature_)

Could this already be done or do you have to implement some more tags?

Greetings
Firzair


----------



## reanjr (Apr 7, 2005)

Firzair said:
			
		

> Hi reanjr,
> this document's something I really like. One more thing to define would be the _modifier_ because there's a distinct mechanic behind the modifier handling (stacking of different bonustypes). But if this could easily be done with the current ruleset (RPGL) I'd like to see how it comes out.
> 
> Greetings
> ...




I thought I had responded to this... maybe not.

Anyway, yes it can be done in RPGML.  I just need to decide how I want it to work.  Since I haven't gotten to that part of the rules yet, I don't want to make a decision until I see how more of the data pans out.  As an initial guess, It would probably be something along the lines of passing in a stat name and having the function iterate over all the modifiers that stat has and store them in a temporary context (you can think of a context as an XML element with any number of attributes and child elements), checking whether there is already a modifier in the temporary context with the same bonus type.  Once it's done building the temporary context full of unique modifier, it would just go through and add them up.

In the long run, all you would do is call <get-mod name="search-skill" /> or something like that.


----------



## reanjr (Apr 7, 2005)

Firzair said:
			
		

> Hi reanjr,
> I think there is some more functionality needed from the RPGL:
> 
> Some kind of SELECT for getting a collection of something used with a kind of FOREACH clause (e.g. Select from Feats where Feats.Type like "Fighter").
> ...




As to the first point, there is a way to do it (and I suppose it could be mashed into a function, too; but I hadn't gotten to anything like that yet).  Basically, the <a> function can resolve simple XPath like statements and return arrays of data.  For instance:

<a>feats.feat:type='Fighter'</a>

Would return an array of all feat elements that are children of the feats element and half a type attribute set to Fighter.  Once you have this array, you can use another special resolution mechanism ::

Say that you store the array in a variable called fighter-feats.  Then:

<a>fighter-feats::count</a>
Would return the number of elements in the array

<a>fighter-feats::1</a>
Would return the first of them.

So you could fairly easily write a foreach function (and I'm pretty sure I will).

I haven't finalized anything on the way those variable resolutions work yet, but tentatively, the following apply:


```
.
Current context

.child
The child of the current context (and so forth like .child.grandchild etc.)  This can be a child element or a property of the context.

:property
A property.  If this is left without any qualification, it just checks if the property exists or not.  You can also append ='value' to evaluate to a property that is set to a particular value.  I use single quotes here for ease of parsing.  Unlike using the .child syntax to select a property, using the :property syntax doesn't evaluate to the property but is used as a means of identifying elements.  (I hope I explained that clearly, I can't tell).

::count
The number of elements in the reference.  Usually 1.

::1, ::2, etc.
A particular element if there are multiple.  Defaults to the first element if unspecified.

[ ]
Anything found in brackets is evaluated as a variable reference then plugged in to its surroundings (<a>fighter-feats::[counter]</a> for instance).
```


----------



## Firzair (Apr 7, 2005)

reanjr said:
			
		

> Nope...
> 
> 
> ```
> ...




How could you tell that he has it twice? There has to be some way for this...
And how would I refer to the second one?


----------



## reanjr (Apr 7, 2005)

Firzair said:
			
		

> Hi reanjr,
> I think there is some more functionality needed from the RPGL:
> 
> Some kind of SELECT for getting a collection of something used with a kind of FOREACH clause (e.g. Select from Feats where Feats.Type like "Fighter").
> ...




As to the second point what you do is define functions inside different root elements.  For example, stonecunning (the dwarf ability) is defined like so:


```
<monsters>
	<function name="stonecunning">
		<text-representation>
			<a>"Stonecunning: automatically search secret doors...blah blah"</a>
		</text-representation>
		<add-conditional-skill-mod skill="search" mod="2" type="racial" reason="stonecunning" />
	</function>
</monsters>
```

Now in the dwarf data, we write


```
<monsters>
	<monster name="dwarf">
		<stonecunning />
	</monster>
</monsters>
```

When you apply a race to a character (in this case dwarf), all of the stuff in the dwarf element is basically merged into the character element and executed.  So you create a character, add dwarf stuff, which triggers stonecunning to execute, which in turn adds a conditional skill modifier to search checks.

So, basically, because the stonecunning function is found inside <monsters>, that is its scope.  But once monster data is merged with character data, it allows the character context to use the function.

So, nope.  No additional tags needed.

I haven't seen a need for a new tag outside the data tags (create-context, add-data, add-property, delete-data, delete-property, and import-data) in several days, so it seems like a decent set of functions.  I will probably have to think of string functionality of some kind, but I might just treat that like an array of chars.  "level"::count would be 5 for instance and "level"::3 would be "v".

I think that actually pretty much covers it except for events, which I'll explain here just so that I have talked about it.  I'll use the dwarven ability to move at full speed while encumbered as an example, because it's pretty straight forward.

An event is declared in a similar fashion to a function, but it never takes arguments (I don't think, don't hold me to that).  It generally handles a simple operation that could easily be done without a function.


```
<event name="speed-change" amount="0" reason="">
	<set name=".speed">
		<add>
			<a>.speed</a>
			<a>amount</a>
		</add>
	</set>
</event>
```

Basically, you can declare a function as normal but set two reserved properties on it: attach and when.

attach indicates an event to attach the function to.  when indicates when to run the function in relation to the event: "before" or "after".

So, in the monsters stuff you have

```
<monsters>
	<function name="encumbered-movement" attach="speed-change" when="before">
		<assert>
			<e>
				<a>reason</a>
				<a>"encumbrance"</a>
			</e>
			<set name="amount">
				<a>0</a>
			</set>
		</assert>
	</function>
</monsters>
```

When a character becomes encumbered, you call
<speed-change amount="-10" reason="encumbrance" />

This triggers the encumbered-movement function because it was told to attach to the speed-change event.  It was also told to run before the event itself.  It checks the reason, which is "encumbrance", and so sets the amount to 0.  Then it lets the event run, but since amount has been changed to 0, it doesn't do anything.


----------



## reanjr (Apr 7, 2005)

Firzair said:
			
		

> How could you tell that he has it twice? There has to be some way for this...
> And how would I refer to the second one?




In this case you could use the following to tell you he had it twice:
<a>.feat:name='toughness'::count</a>

And you could use this to refer to the second one:
<a>.feat:name='toughness'::2</a>

The first one could be referred to with either of these:
<a>.feat:name='toughness'</a>
<a>.feat:name='toughness'::1</a>


----------



## reanjr (Apr 7, 2005)

I don't think I talked about conversions.  If you have to explicitly treat one type as another, you can do that with the <a> function using its convert property.  Convert can be one of the following values:

text: converts number or boolean to text
boolean: converts number or text to boolean
number: converts string or boolean to number
integer: converts to number and then truncates fractional part
lower: lowercase text
upper: uppercase text
is-set: returns boolean indicating whether value is Nothing (I just thought of this so I can get rid of the is-set function.


----------



## andargor (Apr 7, 2005)

I'm sort of... intrigued by the purpose of RPGML. Out of curiosity, where does it fit compared to the ontology? Is it something that would be generated from it to accomodate specific implementations? (what I term an "intermediate format")

Also, to search, just use XPath or XQuery. I assume you want to do this to load the XML into some form of internal binary representation? From experience, using the XML directly hasn't proved very efficient.

Andargor


----------



## reanjr (Apr 8, 2005)

andargor said:
			
		

> I'm sort of... intrigued by the purpose of RPGML. Out of curiosity, where does it fit compared to the ontology? Is it something that would be generated from it to accomodate specific implementations? (what I term an "intermediate format")




It's an alternative to the ontology that I support using instead of RDF-OWL.  It's much simpler to use RPGML to do the stuff that we'd use RDF-OWL for.  The benefit of RDF-OWL (I feel obligated to point out), is that it is a major standard with library support and documentation all over the internet.

RDF-OWL is fairly straight-forward for those familiar with XML and the way XML works.  RPG ML is designed to be simple for your average, computer-savvy role-player who, years ago, fiddled with a programming and/or scripting language.  In my opinion, RPG ML will lead to a much larger development community than RPG ML.  I think RDF-OWL will be intimidating, and keep non-programmers away.

I also point out on the Wiki that it is fairly straightforward to use RPG ML to create a normal scripting language that is translated into RPG ML.  That way, Java programmers can have a version of RPG ML that looks very much like Java, rather than using XML to code.

[edit] I also point on the Wiki that is fariyl... man I rarely have that many typos/word ommissions in such a small space...



> Also, to search, just use XPath or XQuery. I assume you want to do this to load the XML into some form of internal binary representation? From experience, using the XML directly hasn't proved very efficient.
> 
> Andargor




I was going to use XPath, but I decided against it for the reason stated above.  A person just picking up on RPG ML can easily understand child/parent realtionships and remember how to use the, but once you get into ancestors, siblings and the more esoteric selectors available in XPath, it can become confusing for someone who doesn't sit down and decide to learn XPath on its own.  I have to look up stuff all the time for XPath even though I do understand it.  That's not the type of environment I want people to be working in.

Though only initial thoughts, my idea for the engine architecture is to load the main RPG ML file(s) into memory and create a set of (for instance) a collection of functions that contained the text of the RPG ML.  I thought of actually compiling the functions on the fly, but RPG ML actually contains language features that a standard programming language can't really handle very well.  But by keeping the lists, pointers, variables, etc. stored in the engine and just keeping the RPG ML for function references that can be parsed when called, I hope to gain the best of both worlds (the app doesn't need to parse through a gigantic XML tree to find the function "roll", but it still has to read the 10-20 XML tags contained in "roll" to figure out what it does).

As for data (such as characters, etc.) I do plan on those being kept in XML format.  They should be very simple and small snippets, so I don't see performance being an issue.  They're just being used as a data store.

I picture the engine having a stack, as to be expected, contexts that the engine is currently running in.  A particular context can contain its own unique set of functions and variables.  I haven't really looked into it, but I believe a context can only have access to its own local functions and variables and those that are global, so there would be no long walk up the stack to find where something is declared (important as every other RPG ML function call has some sort of variable reference).

I also might experiment with some sort of caching mechanism if it seems to need it.


----------



## solomonk (Apr 22, 2005)

greate idea! i start my own development of such d20 engine in C#
can I join your group?


----------



## Firzair (Apr 29, 2005)

Sure Solomonk,
just head over to the RPGEngine-Wiki. At the moment it's a bit deserted, but I hope that's just due to RL constraints of reanjr and Andargor (I think I saw him posting about some absence du to business).
I myself await eagerly their return as the RPGML functions need some more description.

Greetings
Firzair


----------



## DickieBear (Nov 14, 2006)

Did anything ever come of this work?


----------



## Firzair (Nov 16, 2006)

Its still in the works. 
Currently my RPG XML Rules Engine is in beta stage, I have done some major overhaul of the gui and I'm not finished yet.
As the base program can already handle most things I'm currently in the process of creating the xml code for the different editors etc.
At the moment I can create and edit features (for classes/races), languages, races, skills.
I have to put all these functions in the main menu (which is also done in xml-code).

After some thinking I stopped this for now, putting my effort into a PCGen-lst-converter, that produces xml-data. I think, that would bring about a much larger data base than waiting for users to code the srd-data.
Currently the converter can be used for languages, equipment and races with some exceptions. I need to build a conversion for all the different bonus tags and the somewhat complex expressions in these tags so that all fits together.

I think with some work a user could already create a full character editor with the program (RPGXML Rules Engine), but he would need to enter lots of data by hand. By converting PCGen data I will have data which can then be used to just create the functionality to use the data.

Perhaps I will publish my current verion of the program even though the gui isn't finished. Old versions had some major bugs and the audience was screwed and left, so I'm somewhat reluctant... also this is a free time project and there's not really much free time between job, wife and two kids 

Greetings
Firzair


----------



## karianna (Nov 16, 2006)

Firzair said:
			
		

> Its still in the works.
> Currently my RPG XML Rules Engine is in beta stage, I have done some major overhaul of the gui and I'm not finished yet.
> As the base program can already handle most things I'm currently in the process of creating the xml code for the different editors etc.
> At the moment I can create and edit features (for classes/races), languages, races, skills.
> ...




You'll need to get hold of us if you intend to convert PCGen datasets, there are some IP issues etc with some of our datasets, please contact Paul King (kingpaul) for further information


----------



## Firzair (Nov 16, 2006)

karianna said:
			
		

> You'll need to get hold of us if you intend to convert PCGen datasets, there are some IP issues etc with some of our datasets, please contact Paul King (kingpaul) for further information



Trying to build the converter I just remembered, why I didn't use the PCGen-Files initially. They are just to PCGen specific... so I will go on creating my code from scratch and dump the converter.
Anyway thanks for the info. I wouldn't want to indulge on anyones copyrights.

My program will probably only come with some generic data and some data from the srd so there should be no IP in it. I'm not sure yet how I will implement the license issues for the srd, most probably the different licenses will just be objects that are referenced by other objects.

Greetings
Firzair


----------



## karianna (Nov 16, 2006)

Firzair said:
			
		

> Trying to build the converter I just remembered, why I didn't use the PCGen-Files initially. They are just to PCGen specific... so I will go on creating my code from scratch and dump the converter.
> Anyway thanks for the info. I wouldn't want to indulge on anyones copyrights.
> 
> My program will probably only come with some generic data and some data from the srd so there should be no IP in it. I'm not sure yet how I will implement the license issues for the srd, most probably the different licenses will just be objects that are referenced by other objects.
> ...




OK that's cool, we were just starting to do a round up of all of the 3rd party software products that were intending on using the PCGen datasets and I noticed this thread.

Our OGL/PI gurus realised that there would be problems for people wanting to convert our data in the fact that the agreements we made with publishers aren't automatically transferable, so we wouldn't be able to give permission unless the publisher gave permission as well.  As always these things are a bigger minefield than expected .  Good luck with your project!


----------



## DickieBear (Nov 16, 2006)

I'm glad to know someone is working on an API.  With the recent release of XNA, I decided to try to make a game.  I started on a side-scrolling shooter, but decided I want to make  a DnD game. I started working on the API and quickly realized how complicated it's gonna be. Are you gonna release the XML files at some point? I'd like to see how you are structuring your classes.


----------



## Firzair (Nov 16, 2006)

DickieBear said:
			
		

> I'm glad to know someone is working on an API.  With the recent release of XNA, I decided to try to make a game.  I started on a side-scrolling shooter, but decided I want to make  a DnD game. I started working on the API and quickly realized how complicated it's gonna be. Are you gonna release the XML files at some point? I'd like to see how you are structuring your classes.



Oh, sorry for some misinterpretation. I'm working on a program that will use xml-files to create data and functions not exactly an API.
I've just uploaded the actual version of my tool to my homepage so can get a picture of it. It's still in beta and I have quite a lot of ideas for extending it (list component and a map component should be the mostly needed)...

Greetings
Firzair


----------



## DickieBear (Nov 16, 2006)

Oh, yeah.  Sorry for my confusion.  I just got excited.  I will take a look at your files though.  It might give me some good ideas on how to model 3.5 D&D.  I'm at work now, so it'll have to wait until I get home.


----------



## azhrei_fje (Nov 17, 2006)

karianna said:
			
		

> Our OGL/PI gurus realised that there would be problems for people wanting to convert our data in the fact that the agreements we made with publishers aren't automatically transferable, so we wouldn't be able to give permission unless the publisher gave permission as well.  As always these things are a bigger minefield than expected .  Good luck with your project!



I did a quick search at CMP.com and couldn't find the license agreement for the use of the data sets.  Would you be so kind as to post it here?  Or maybe have it posted in the FAQ section of the site?

Thanks.


----------



## acon360 (Nov 18, 2006)

*DM Genie*

Has anyone looked at how the creator/s of DM Genie approached or solved this problem?? I think it has a rules file that the engine interprets from. And then several types of objects to represent actual data. Perhaps one could look at DMG's rules file and try to interpolate how the engine functions.


----------



## karianna (Nov 20, 2006)

azhrei_fje said:
			
		

> I did a quick search at CMP.com and couldn't find the license agreement for the use of the data sets.  Would you be so kind as to post it here?  Or maybe have it posted in the FAQ section of the site?
> Thanks.



Just to clarify, PCGen is _not_ CMP.  PCGen (the Open Source project) has built a ton of datasets, some of which are OGL, some of which are closed content.

* All of these datasets are provided with PCGen for free (just as PCGen itself is free).
* We have permissions from each of the publishers that we provide data sets for.

We're aware of this new interest in converting our datasets and we're currently debating on how to proceed with this.  We'll posting our views/position on this shortly.

I'm not sure what you'd have to do in order to get permission to convert CMP's data sets (these are the ones that CMP produce and sell), I'd suggest contacting Lone Jedi on their website.

Hope that helps


----------



## Firzair (Nov 20, 2006)

So, PCGen comes with OGL datasets and others... could someone convert these OGL datasets without infringing your rights? I went away from the conversion stuff but I just wanted to know if these copyright problems stand for all the datasets coming with PCGen.

Greetings
Firzair


----------



## kingpaul (Nov 20, 2006)

Firzair said:
			
		

> So, PCGen comes with OGL datasets and others... could someone convert these OGL datasets without infringing your rights? I went away from the conversion stuff but I just wanted to know if these copyright problems stand for all the datasets coming with PCGen.



*takes off PCGen Bod hat*

Alright, the name "PCGen" is owned by Bryan McRoberts, PCGen's Benevolent Dictator. If you want to use that name, you'll have to talk, at the least, with Bryan.

Secondly, per the OGL, the title of any source is PI. So, if you want to state that you have Fantastic Fred's Feats, you need to get Fred's permission to state that.

Thirdly, many of PCGen's sets have either PI or outright closed content material in them that PCGen has requested publisher permission for. That permission doesn't transfer to someone else.


Does that help?


----------



## azhrei_fje (Nov 21, 2006)

*Conversion tool, .LST -> DMGenie?*



			
				kingpaul said:
			
		

> *takes off PCGen Bod hat*



Heh-heh, understood. 



> Does that help?



Somewhat.

First, a statement of fact:  it is not illegal to build copy machines, but it IS illegal to use them to reproduce copyrighted materials.

Now on to my assertion:  it is not illegal to write conversion software, but it IS illegal to use the conversion software on copyrighted datasets and then distribute those datasets.

My question: what does the existing license say for the CMP data sets (not PCGen(TM), but Code Monkey Publishing).  Since I couldn't find it on the CMP web site, perhaps someone who has purchased licensed the data sets could reply and include the general gist of the agreement?

Thanks.


----------

