REQUESTING - Second Edition Charm Cards

As I see it and my own imperfect understanding of copyright law, your program and the structure of your database are safe to release as open source.


It really is the data that is really White Wolf's baby. I think there are a couple of approaches that you could take. You could release a non-description version of the data set (just the fields with page numbers), that seems to be fairly open since the description text is the most protected section under copyright.


You could (get someone to?) write a translator program that takes Anathema or EdExalted data and converts it to and from your own dataset. Naturally, if there was a centralized XML scheme for Exalted charms, it would be easier to write a set of programs for importing/exporting (as appropriate) to Anathema, Pattern Spider, Ed Exalted, your program, etc.


Personally, I'd like to see the program on a public SVN server or SF project and just strip out the most sensitive part of the data for now. I'd be nice if White Wolf would let you, but that would require asking their legal department questions, and you'd probably need to do it on the behalf of all Exalted character maintenance programs out there. :)


If you make it public, I'll probably write converters for my own XML schema, just because I like writing converters and I'm trying to poke holes in my schema still.
 
dmoonfire said:
It really is the data that is really White Wolf's baby.
I'm hoping that WW will allow it since they have the same data available on their own Wiki.

dmoonfire said:
You could (get someone to?) write a translator program that takes Anathema or EdExalted data and converts it to and from your own dataset. Naturally, if there was a centralized XML scheme for Exalted charms, it would be easier to write a set of programs for importing/exporting (as appropriate) to Anathema, Pattern Spider, Ed Exalted, your program, etc.
I'm all for that. If there's a good XML format I'd happily write an import/export function for it. I've even had thoughts about writing a page that doesn't rely on PHP or MySQL at all, just html, Javascript and XML, for offline use. It would be neat, but making all that Javacripting work well will be tricky.

dmoonfire said:
Personally, I'd like to see the program on a public SVN server or SF project and just strip out the most sensitive part of the data for now.
I've never developed anything for SVN or SF, but I guess it would be a good place for it when it's released.

dmoonfire said:
I'd be nice if White Wolf would let you, but that would require asking their legal department questions, and you'd probably need to do it on the behalf of all Exalted character maintenance programs out there. :)
I don't know if I should ask, as long as I don't show more than anyone else. I feel pretty secure since I'm not in the US. The feds won't kick downmy door in the night an ransack my place for RPG contraband. ;P

dmoonfire said:
If you make it public, I'll probably write converters for my own XML schema, just because I like writing converters and I'm trying to poke holes in my schema still.
All that's needed to make it public is really a good way to update it with new Charm data. Show me your XML format and I'm sure we can work something out.
 
Since I've been meaning to do it, why don't I throw up a web page on my site along with my justifications. It will only take a day or so, just have to finish something first. Plus, I'd love charms in *any* format so the detail-oriented people of us can enter everything, and then share it with their close and personal friends.


As for specifics, I think the mechanical stuff is okay, at least Anathema and Lore5/Patternspider have gone with that. Such as costs, requisites, duration, etc. Page numbers and sources are pretty safe. Since there are so many sources of that now and for so many years, I suspect it would be okay.


Give me a day or so, I'll write up my XML format and justifications.
 
http://community.livejournal.com/whitew ... 39352.html


I noticed that they have two interns working on Exalted Charm Cards. So, we might be seeing something interesting coming out of the official arena also.


Personally, I'm just hoping they accept my newest fiction again. I was so excited when I got one of my Exalted short stories in the winter quarterly a few months back. :)
 
Apparently, when I said I needed a couple of days, what I really meant was "I need a month to get my life in order." Last night, I finished up basically my draft rules on the Exalted XML format, specifically for cards (and talents, because they are special charms).


http://mfgames.com/exalted/schema


This is basically what I use to drive the XSLT for my PDF charm cards and also for my charms to Tomboy setup so I can easily referer to charms from inside Tomboy.


http://mfgames.com/exalted/releases/exa ... -0.5.1.pdf


What I'd really appreciate is just a looksie by those who write charms via XML and opinions, what I missed, comments or feedback, positive or negative. It's a PDF, because I was too lazy to figure out a ODF to XML conversion last night (again) since that library is currently in flux (again) with a library rewrite.


This is in hope that eventually, we could get a common and standard XML format for charms, heartstones, artifacts, and characters which would make it easier to import/export to and from things like lore5, anathema, the two charm card creators, etc.
 
dmoonfire said:
This is in hope that eventually, we could get a common and standard XML format for charms, heartstones, artifacts, and characters which would make it easier to import/export to and from things like lore5, anathema, the two charm card creators, etc.
I'd recommend against building tight type tags (e.g. <charm>, <hearthstone>, etc.) into your schema. It sounds like a good idea at first. I did this for 1E and it caused a number of problems because the divisions break down. As an example: is an automaton an <artifact> or a <creature> or a <character>? Are demon-embracing robes <armor> or <weapon>?


When building my own schema for 2E, I started by relaxing my 1E types, but soon abandoned them altogether. The result is a schema that is generic for all game data, not just for Exalted, but for any game at all. It also uses inheritance. I keep threatening to write it up, but have not yet done so.
 
My original plan was to basically keep charms and talents as the same thing with just a different type.


I was planning on having <item> to handle heartstones, artifacts, armor, weapons, etc. Basically just a weapon block inside that to say it has weapon stats, an armor block for armor stats, etc. But, equipment is equipment, the distinction isn't important. That way, I can do things that grant bonus dice, armor, and also have multiple weapon lines.


The other categories were going to be spells (which are fairly distinct) but also combined with the machine protocols (alchemicals) and characters, which will cover all character types, spirits, etc.


Some blocks are going to be in most things (<costs/> comes to mind since it applies to artifacts, spells, and charms).


For automons, I've pretty much universally called them characters. Always have, so I never saw a reason to consider it anything else. Except maybe it has an artifact rating.


Seem reasonable?
 
dmoonfire said:
Seem reasonable?
Yes. In thinking about my 2E schema, I thought about something similar. But then I thought: if it is OK to call hearthstones, artifacts, armor, weapons, etc. "items", what is the fundamental difference of "spells", "charms" and "characters"? Why not just call them "items" as well? Ultimately they are all just collections of values. I couldn't think of a reason not to, so I use one basic tag (<rpgobject>) for everything.


Well, not entirely true. My schema ultimately intends to encode rules as well as more standard data, so there is a second tag for rules. These can occur on their own or attached to rpgobjects.
 
Yeah, in the game system I wrote (Balance), everything was a character. :) Drove some of my playtester nuts since I designed the entire game that way. One person on rpg-create suggested that object-oriented gaming wasn't really ready for prime time yet. :) I thought it was the greatest idea and it was a lot of fun to do. If Exalted was designed that way, I would have done that in an heartbeat, because there is nothing like playing an intelligence artifact sword being wielding by a lunar while you are throwing charms left and right.


I found that writing a computer program to treat everything is a generic object kind of increases the work at a certain point. Mainly because the players view them as separate and distinct objects (charms, spells, characters), so the program has to do more work to format it. Same thing applies with a bunch of other stuff I work with (computer performance tracking, system stats, etc). I could do it as a generic object, but it starts to get cludgy faster and I found it more work than it really gave me. Also, I prefer strongly-typed languages (C, C#, Java) instead of those that don't require strong types (VB.NET, Perl, PHP).


I like at least a bit of semantic data. Makes stylesheets easier to write, at least for me. I'm willing to consolidate as much as what I think is reasonable, but I could probably write it to handle a "generic" object also, but I wanted something that was easier to convert to and from stuff that obviously has a distinction between them. In a way, it easier to convert from a semantic file to a generic internal structure than the other way around.


It is also overlap. I don't know of any spell that acts like a charm or a character. Spells create weapons, but then I just add a weapon block to the spell. Automons are characters, an NPC to effectively an Alchemical, so I called them characters, but they aren't really a spell or a charm. There is a bit of overlap in those three distinct areas (well, 4 but I'm not including "location" in this, my game actually let you play locations too) but I don't know if there is much.


I could add a generic object that basically allowed for sub-blocks such as:


 <exalted>


   <object>


     <charm><!-- stuff that looks like a charm --></charm>


   </object>


 </exalted>


Now, I think it would be pretty easy to create a translator between th two. :) I guess I'll see what the others think (if they respond) since my goal is to get a common file format for everyone to work with. Don't care if it is mine or someone elses, I just want everyone to play together. :D
 
You are correct on several points. My schema is definately more work to use, particularly with XSLT (though this is largely because of the use of inheritance).  The intent with a generic schema though, is that you only really need to do this work once. For example, how many character tracking applications do you need? I'd prefer this answer to be "one, for all games combined". I'm sick of each game having to roll its own application to do the exact same thing that the apps for every other game do. Better to write one generic one and "skin" it with rules for a specific game. In my head, this seems very possible, even to the point of radically different UI for each game. Obviously, this isn't the goal you are shooting for, instead looking to unify exalted data.


My love for strongly-typed languages is slowly eroding and my 1E xml attempts are one reason. Another is using Python and Perl a bit more than I used to.


You are very correct in that it is easier to convert from specific to generic than the other way around, though. Any Exalted-specific schema should be convertible to mine without much effort, and would be easier to work with. Oddly, the use of XML actually means that one lone data standard isn't as important as it used to be. Assuming two schema encapsulate the same data, translating from one to the other is fairly routine.


In any case, it will probably be a while before my schema is in postable shape, so don't let me stop you.
 
dmoonfire said:
I could add a generic object that basically allowed for sub-blocks such as:


 <exalted>


   <object>


     <charm><!-- stuff that looks like a charm --></charm>


   </object>


 </exalted>
This is why God gave us namespaces.
 
wordman said:
In any case, it will probably be a while before my schema is in postable shape, so don't let me stop you.
Maybe I missed it, but do you have an XSD you can send me?
 
memesis said:
wordman said:
In any case, it will probably be a while before my schema is in postable shape, so don't let me stop you.
Maybe I missed it, but do you have an XSD you can send me?
Sunday? I forgot to check in what I have into my SVN and I'm about to get drowned in family politics because my wife is walking the stage for her college graduation tomorrow, which means drama and food for 48 hours. :)
 
Looks good to me.


The exalted-type tag is a bit misleading as it would be used to distinguish spirit charms, arcanoi, etc. But it's just a tag name I guess.


The information in the special tags used for marking how many times a charm can be picked should be described in the text description as well, right?


As for the cost tag, does it cover a charm that has a cost of Xm per Y *and* Z? Like "1m per ally and die"?


So... When do we get access to xml files with all the Exalted data? :P
 
HertzaHaeon said:
The exalted-type tag is a bit misleading as it would be used to distinguish spirit charms, arcanoi, etc. But it's just a tag name I guess.
I couldn't think of a good name to describe functional area for the charm.

The information in the special tags used for marking how many times a charm can be picked should be described in the text description as well, right?
Ideally, but I wanted a programmic way of doing it. That way, if they were so inclined, they could add some meta information to the user without the description having it. I think I got it to handle the basic "no more than Trait times" which seems to cover most of them, but I just realized I missed Glorious Solar Saber which is unbounded.

As for the cost tag, does it cover a charm that has a cost of Xm per Y *and* Z? Like "1m per ally and die"?
Hrm, didn't put that can in. Is there a charm that actually does that? Right now, I'd say put per="Dice and Ally" but I don't have it in the enumeration yet.

So... When do we get access to xml files with all the Exalted data?
Hrm, I'd say as soon as I think it is stable and someone gives me a good source of the data entered into another program. :) I'll write an XSLT/program to convert it into this format. As for stable, I'll call it 1.0 probably in a week or so, if no one finds any critical problems with it.


I'm just finishing up the XSD, I found a couple whoopsies. The first is that I need a key instead of using the name, Ox-Body just doesn't work when there are a gazillion of them. So, I'm going to put in an arbitrary key field with guidelines for the WW charms for consistency. I'll post a 0.6 link in a few hours.
 
dmoonfire said:
Ideally, but I wanted a programmic way of doing it. That way, if they were so inclined, they could add some meta information to the user without the description having it. I think I got it to handle the basic "no more than Trait times" which seems to cover most of them, but I just realized I missed Glorious Solar Saber which is unbounded.
I understand the need for expressing it in a way that programs can use, but maybe it could be noted that you don't expect it to be translated to human readable description and that it should be included in the description as well. I don't know, maybe it's obvious.

dmoonfire said:
Hrm, didn't put that can in. Is there a charm that actually does that? Right now, I'd say put per="Dice and Ally" but I don't have it in the enumeration yet.
Hmm, I can't think of an existing Charm like that, but it's a possibility. Your solution should work just fine though.

dmoonfire said:
Hrm, I'd say as soon as I think it is stable and someone gives me a good source of the data entered into another program. :) I'll write an XSLT/program to convert it into this format. As for stable, I'll call it 1.0 probably in a week or so, if no one finds any critical problems with it.
I've scraped together most Solar Charms that I can send you, but those are probably the easiest to find.
 
Good idea. I moved the <exalted-type/> into the attribute of the charm, that way it is a "charm type" which is a bit more accurate.


I also added your suggestions in the PDF documentation and also uploaded the XSD file that validates through my stuff (well, my test cases so far).


Getting just a bit closer:


Home: http://mfgames.com/exalted/schema


PDF: http://mfgames.com/exalted/releases/exa ... -0.6.0.pdf


XSD: http://mfgames.com/exalted/releases/exa ... -0.6.0.xsd


If you want, feel free to send me what you do have in the way of charms to d dot moonfire at mfgames dot com (with extra-leet ofuscation!) and I'll see about creating a library of the charms so everyone can see how it looks.


Feedback is always appreciated.
 
Oh right, two more things.


What about martial art styles? How do you group Charms into styles?


For custom Charms, what would you use to mark the author? Maybe a creation date or version could be useful as well.
 
Doh! I knew I forgot something. :) I forgot to add "Terrestrial MA", "Celestial MA", and "Sidereal MA" to the CharmAttributeEnum. I'll put that in for 0.7.0. :)


As for splitting out styles, my test files didn't have it, but I forgot to add a optional <group/> right above the <name/> tags. It was suppose to let me split apart the Lunar/Alchemical charm trees (since they were broken somewhat arbitrarily) and it would work for MA styles.


As for creator information, hrm. Not sure about that. I could add a meta block or just a author/date/version but I'm worried that it would be redundant with the non-visible key. It *should* be in there, at both the <exalted/> tag level and the individual element level.


Probably?


<meta>


 <creator></creator>


 <version></version>


 <date>Official XML Date</date>


 <source page="23">Exalted</source>


</meta>


Sound reasonable?


I'll upload 0.7.0 later today with it, unless someone has a better idea. :)
 
It all sounds good. But what if you make a general source tag, both for official charms, their books and pages, and custom charms with author, date and perhaps an url? And maybe a specific way to mark official data from WW?
 
dmoonfire said:
Code:
<meta>
 <creator></creator>
 <version></version>
 <date>Official XML Date</date>
 <source page="23">Exalted</source>
</meta>

Sound reasonable?
Does creator mean "the one who created the information" or "the one who created the file"? In the schema I built, I called the former "author" and the latter "scribe". Also, I highly recommend my reference standard for page numbers.
 
How about?


 <meta>


   <company>White Wolf</company> <!-- optional, of course -->


   <author>Bob</author> <!-- This would missing for White Wolf canon -->


   <scribe>Gary</scribe> <!-- "scribe" seems to mostyl work -->


   <copyright year="2007">Name of Copyright owner</copyright>


   <license></license> <!-- let people describe their limits? -->


   <version>0.1.2b</version>


   <date>2007-07-01</date> <!-- or whatever the default XSD format is -->


   <canon/> <!-- obviously, only if it is canon -->


   <source page="22" url="">Exalted</source>


 </meta>


Naturally, everything would be optional in here. I put in copyright because it seemed like sense. License, not sure about it, but I know that most of what I do is "Creative Common by-sa".


Hrm, I think I could use a consistent source/ref line, both here in the meta tag and also in the descriptions. The problem with using the ERS is that White Wolf doesn't use it. And using ERS directly would require people to parse it, which is rather hard in XSLT. Plus, I'd rather have it in XML format since that is the point of XML at least. Now, it does point out that I could use some combination to let you pick and choose as appropriate.


 <source column="" paragraph="" url="" page="" to-page="">Name of Book</source>


This would be used in the meta data and in the descriptions, and maybe a variant in the prerequisites(?). Would that work for both method? I.e. you could convert to ERS or the White Wolf method without too much trouble.


I could see it either being <canon/> or actually have one of:


 <canon same attribute as source/>


 <source same attribute as source/>


With just the tag telling you if it is canon or otherwise. I lean toward having a <canon/> indicator with a consistent source field. Of course, just having a "canon" indicator might be a problem since there might be typos and it really isn't "canon".
 
I'd replace the "canon" tag with an "unofficial" tag. That is, assume canon by default unless told otherwise.
 
If we're going to have reliable people putting together xml data of the official charms, isn't it easier to get them to include a canon tag than to get all fans to include an unofficial tag? But I guess someone could think they're being canon for following WW:s Charm creation guidelines...
 

Users who are viewing this thread

Back
Top