Suite Interoperability

[Davin]

Having a central repository to ensure there are no GUID collisions. It would need to be relatively real-time in order to not slow down anyone's development (i.e. it can't be a periodically published list). Also, it needs to be OS independent (I know Windows has a facility for generating "random and unique" GUIDs, but it won't apply to Macs or Linux)

Actually, you probably don't have to worry about that. Have you stopped to see what the odds were that a purely random GUID would be accidentally duplicated? They're astronomical -- well beyond the "fuggetaboudit" stage.

 

[smetzger]

I don't think the data exchange format should include GUIDs.

The amount of effort to design and implement these is not payed back in benefits.

When a program imports data, if it needs a unique id for that feat, spell, class, character or whatever the program can generate it on the fly just as if someone had added the information by hand into the program.

There are very few instances where there are duplicate feat names, spell names, class names, monster names etc. If a program has two feats named Toughness that do different things thats a bad thing anyway even if they have different GUIDs. What are you going to do display the GUIDs and have the user choose between the feats? No, you should rename one of the feats.

There are relatively few name clashes and when there are name clashes it behouves the programmer to fix the name clash instead of assigning a unique ID to the item.

 

[Hollywood]

I don't think the data exchange format should include GUIDs.
The amount of effort to design and implement these is not payed back in benefits.

Actually, its very very small. Most modern OS' have an implementation of a GUID thats easy to get at. But yes, it may not be best to have it in the root character data, but it definetly should be in the per application data.

There are very few instances where there are duplicate feat names, spell names, class names, monster names etc. If a program has two feats named Toughness that do different things thats a bad thing anyway even if they have different GUIDs. What are you going to do display the GUIDs and have the user choose between the feats? No, you should rename one of the feats.

Think about house rules. Think about different d20 systems. Plenty of reasons that there can be the same feat name, but with different rules associated with it for that setting, etc. Names are NOT guarenteed to be unique, period! End of story.

There are relatively few name clashes and when there are name clashes it behouves the programmer to fix the name clash instead of assigning a unique ID to the item.

Absolutely not. The name of an object should be of no concern to the programmer. In fact, the programmer should not care one iota about the data except that it is of the correct data type. Thats the extent of it. The end-user is responsible for the data.

 

[Hollywood]

I have no problem with custom info from different tools being stored in the export, and that is safely ignored by other tools. Maybe I didn't understand your example correctly, but if changes are made in another tool, then a common way of indicating that those changes have been made to other tools would have to be implemented. I still maintain that "recorded" user choices is probably the most tool independent way to do this.

Unless everyone is going to agree to a common "audit" format, which is going to be a bit tougher than just getting people to use one common "character data" format, there is not going to be a way for different applications to know what another application changed and how. Not to mention, I think its really beyond the scope of things. Are there common elements of 3rd Ed. that can be tracked as character data? Sure, stuff like noting what the base ability score is, what level a feat or a skill rank was assigned at, what level a class was taken at and its hp, etc.

Ah. The unique ID issue. There are two ways of doing it:

Um, no. A uniquie ID is unique because the chances of it ever being in existance at the same time is astronomically small as Davin noted. The Windows OS provides a Globally Unique ID (GUID) that is easily available programmatically. The GUID is significantly big, and the algorithm that produces rigorous enough that you won't see the same GUID twice. Tons of stuff on the Windows platform rely on this. Java has a UID, which isn't quite as globally unique, but would be unique enough. And Mac OSX/Linux/Unix has something similiar but I forget its nomeclature.

- Having a central repository to ensure there are no GUID collisions. It would need to be relatively real-time in order to not slow down anyone's development (i.e. it can't be a periodically published list). Also, it needs to be OS independent (I know Windows has a facility for generating "random and unique" GUIDs, but it won't apply to Macs or Linux)

This would in general be a bad idea. Now you're tying all programs to the internet. Even assigning blocks of GUIDs can cause issues and collisions. So this is the baby out with the bathwater.

- Using game system elements to establish uniqueness. I submit that a name, a type, a version, and a source reference (perhaps with the game system name) would be sufficient. For example, I have not seen duplicate D&D feats named X from the same source, except errata (and the version tag fixes that).

Yes, this *might* work too. Its definetly far better than just a feat or skill or whatever name. But you'd have to come up with a nomeclature that all parties would be agreeable too.

The common XML format is just that (the DIB ).

Well, um, to some extent. DIB is very basic, but it doesn't really have enough information such as layers, alpha channels, etc., etc. The XML data format would need to know about the "DIB", i.e. the exploded character data plus some layering to be able to track level stuff, i.e. what level a feat was added at, as its the basic. On top of that would be program specific information. And basic information for any custom data plus program specific information for that custom data.

If my XSL-fu was as good as my code-fu, I'd probably draft up something fairly quickly for DMGenie, RPM and Campaign Suite, and the common format is really irrelevant.

Sure it is... without a common format somewhere, it means every RPG software app out there for d20 has to code up transformations for every other data format too. Essentially reinventing the wheel every time.

What I was getting at is that you *can* have a common format, without too much trouble thats able to be used between applications. Further still, but allowing proprietary information to be embedded in the format you could move away from needing transformations.

Nonetheless, back to the root.. what I believe you proposed, what I've tossed out there because I've been using it for some time now and its been through several revisions, and what CSX proposed in beta and DMGenie is going to support for importing, are fairly similiar with some minor differences. If we could get a common import/export format at the very least that contains enough basic character information then individual programs only now need to do transformations from ONE common format to their own format. For CSX, it already has guy's like Jay Cline willing to do such work.

 

[andargor]

I agree that we can't debate ad infinitum on this. After all, over-debating the format is what probably killed d20-XML. If Jay is willing to propose working examples, then we can work from there.

Note that I am also interested in extending this to sourcebook datasets eventually, but I realize character sheets is probably a good starting point.

There are a lot of people, especially the PCGen volunteers, who could be swayed to code in data in a format usable by many tools. I realize PCGen is probably not the best example, as they blur the line between code and data, but in light of certain recent events within their organization this could be something they would be interested in.

Andargor

 

[Hollywood]

I agree that we can't debate ad infinitum on this. After all, over-debating the format is what probably killed d20-XML. If Jay is willing to propose working examples, then we can work from there.

Well, we'd need to start with a common template. Maybe a combination of CSX and mine to start with as a proposed middle ground? Remember too, CSX is pretty tied to 3rd Ed. right now [at least it seems so], but I also need it to be capable and flexible enough to hold at least two different d20 brews [M&M for one, and a homebrew I may someday publish].

DMGenie, I believe thats the correct program, author would then want to go against the common import/export format rather than CSX itself [although he could do both... ]. And the closer CSX is to the common template, less work Jay would need to do to write a filter to transform to and from the template.

Note that I am also interested in extending this to sourcebook datasets eventually, but I realize character sheets is probably a good starting point.

Not as much interested in this myself, but its definetly a seperate issue.

There are a lot of people, especially the PCGen volunteers, who could be swayed to code in data in a format usable by many tools. I realize PCGen is probably not the best example, as they blur the line between code and data, but in light of certain recent events within their organization this could be something they would be interested in.

Well, um... I think it'd be better to get a transformer from the PCGen character data to a common template. Thats all we're talking about at this time. It'd probably need to be built into PCGen itself instead of a standalone, so that the PCGen app didn't export any non-SRD/OGL material.

 

[soulcatcher]

Well, we'd need to start with a common template. Maybe a combination of CSX and mine to start with as a proposed middle ground? Remember too, CSX is pretty tied to 3rd Ed. right now [at least it seems so], but I also need it to be capable and flexible enough to hold at least two different d20 brews [M&M for one, and a homebrew I may someday publish].

DMGenie, I believe thats the correct program, author would then want to go against the common import/export format rather than CSX itself [although he could do both... ]. And the closer CSX is to the common template, less work Jay would need to do to write a filter to transform to and from the template.

Not as much interested in this myself, but its definetly a seperate issue.

Well, um... I think it'd be better to get a transformer from the PCGen character data to a common template. Thats all we're talking about at this time. It'd probably need to be built into PCGen itself instead of a standalone, so that the PCGen app didn't export any non-SRD/OGL material.

Sorry for my long absense, but I have had some bing RL issues...

I would like a seat at this table as well - I have created a format (posted on this forum) that I would like to see parts of it considered. I don't so much care about the format as I care about all of the data that is in the format being included.

I do think the easiest thing to do in the short term is create a format that reflects the state of a character, and not all of the rules to get them where they are....

Soulcatcher (Devon Jones)
GMGen Silverback
PCGen BoD

 

[Hollywood]

I would like a seat at this table as well - I have created a format (posted on this forum) that I would like to see parts of it considered.

Well, take a gander at the format I posted and see whats not there... took a look at your listing and I *think* everything is there, although I did note that the turn stuff wouldn't be.

I do think the easiest thing to do in the short term is create a format that reflects the state of a character, and not all of the rules to get them where they are....

Yes, I concur... and really that's the core of what a common format should be, the rest is optional.

Now if we could just get Chris at TwinRose and DMFTodd of DMFamiliar [not all references go DMGenie should be replaced by DMFamiliar as I was thinking of the later and refering to the former] to come look at this thread again.

 

[Davin]

There are very few instances where there are duplicate feat names, spell names, class names, monster names etc.

I'm sorry to disagree, but while this sounds perfect in theory, it fails miserably when you start actually having to do things with it in real life. Please put this notion on the scrap heap and look for a synthetic identifier (like a GUID/UUID).

Even the big composite structure with name, source, release, version, etc. combined together still suffers from many of the same problems and isn't as perfect as it seems at first. I'd try to avoid that too, if I were you.

 

[pezagent]

Let's not let this thread die...

I've actually seen some movement in the d20-XML group! (Incredible, I know) I think we are on the verge of something, seeing the transform that Hollywood posted.

If I may make one comment: my belief is that the content of interoperable character sheets only need to have user inputs. Why is it necessary to have all the calculations? Don't the engines know the rules?

All that should be in there is "the user chose Str 18, Dex 13, etc.", "the user put 2 skillpoints at level 2 into Craft (Alchemy)","the user rolled 8 for hitpoints at level 5", etc.

Custom feats are probably more troublesome, and spell/item descriptions would still need to be relatively standard, but that is "data" as opposed to "user input".

Am I making any sense?

Andargor

Hey Andagor,

Looks like I made it. Thanks for the invite. And for anyone seriously interested in data exchange I've started a new group at Yahoo! because I grew tired of dealing with the other group. It's a personal thing--I've got work to do. (see d20-xml-dataExchange).

Andargor, I looked over your pattern and it's not bad. I think you might want to look at MVC patterns and they might help you come up with a more streamlined version of what you're looking for. I believe all of the data sources should be together like mySQL and XML files. I'm not sure why you have two data abstraction layers. One is all you need. It contains the DAO which will handle all the inserting and selecting. It gets tricky if you are using XSL to extract data and pass it to your script, because the function call comes from the script but it's using a stylesheet to do all the dirty work. So I've got two DAO classes, one for SQL and the other for XML.

Good stuff, keep up the great work,

/johnny