REQUESTING - Second Edition Charm Cards

Hrm, you do have a point. Actually, I think we should probably pull the idea of canon or unofficial entirely. I think between publisher, author, scribe (or contributor which I think is a better tag name), and source, do we have enough to identify a "mostly canon" charm?


Also, White Wolf has charm creation guidelines? Where?
 
dmoonfire said:
Hrm, you do have a point. Actually, I think we should probably pull the idea of canon or unofficial entirely. I think between publisher, author, scribe (or contributor which I think is a better tag name), and source, do we have enough to identify a "mostly canon" charm?
Click to expand...
Hmm. I can't help to think it's a bit much, even if all the tags could be useful. I guess if most of them are optional it'll be fine. My original idea was a tag that simply marks if a charms comes from one of WW's Exalted books. A simple yes or no, not something you'd have to derive from a bunch of information.

Jeppe said:
dmoonfire said:
Also, White Wolf has charm creation guidelines? Where?
Click to expand...
Core book, p. 182.
Click to expand...
Don't forget the Sidereal book. The charm creation guidelines there is basically "don't".   :P
 
Well, everything in the <meta> tag (including the <meta> tag itself) is going to be optional. Having a simple tag to identify official WW is a good idea, but why not this:


 <meta>


   <company>White Wolf</company>


 </meta>


... as the simple indicator if it is canon? If someone wants to put more information (page number, source, etc), that's great, but just say the minimum is the <company/> tag for canon?
 
Sounds good. I guess it's not much to fuzz about. As long as it's clear to both humans and machines what data comes from White Wolf and what comes from fans, all is good. If I can check if the <company/> tag is set to "White Wolf", it should work fine.


Just to clarify - the keywords and costs blocks aren't optional, right? Even if they're empty they should be there?


I also found a typo (mismatching tags) in your PDF doc:


<key>Flashing Vengenance Draw</name>


Another idea - there could be a distinction between a full description and a brief description maybe? You know, for limited spaces or mouse-overs or such?


Some Charms that could be trouble as for costs are Rain of Feathered Death  and Charge of One Hundred Generals (DB p181). Both have cost alternatives, like "5m or 8m".
 
I just thought of another thing. Maybew there should be a <group /> tag too. For most Exalted Charms it would have the same value as the Ability it's based on, but Lunar Charms could have the Attribute or the classification in the book (like Interaction). Spirit Charms would have the Virtue and MA Charms could have the Style name.


The reason I'm bringing this up is because I'm trying to write a Charm Card app that only uses Javascript and XML. There's no data that clearly groups Charms together in logical groups, other than the main Charm type.
 
Thanks for reminding me, I was about to upload my current version and remembered I forgot that. Originally, I was planning on doing just a group tag inside the charm, but it might make sense to allow a group tag right inside the <exalted/> tag that lets you define entire charm trees, blocks, etc.


I'm not sure what is best:


 <exalted>


   <charms>


     <charm>


       <group>Laughing Wounds</group>


or


 <exalted>


   <group>


     <name>Laughing Wounds</name>


      <charms>


        ..


or both? What do you think?


Oh, for every 0.7.0:


Project Page


XSD


PDF


These are the changes:


  - Corrected a typo on <key/> example.


   - Added the <meta/> tag.


   - Expanded the <ref/> and <source/> tags.


   - Gave rules for "or" charm costs.


   - Added <costs/> tag to <charm-option/>


   - Clarified that <costs/> and <keywords/> are both optional.


   - Added the one-line <summary/> tag to charms.
 
Hrm, that is actually a hard one in some ways. The <group/> tag inside a charm (item, etc) is fairly easy. But, with XSLT it is a bit harder to group on that. Having an optional group tag inside the <exalted/> tag is easier for XSLT to group things.

Code: 
 <exalted>
   <charms/>
   <group>
     <name>Group 1</name>
     <!-- more --><charms/>
   </group>
   <group>
     <name>Group 2</name>
     <!-- even more --><charms/>
   </group>
 </exalted>

With everything being optional. Though, I'm hesitant to add both since it means that someone has to look in both places. Not really sure which one is better.
 
Can someone refresh my memory as to what all of this is going to accomplish? Charm cards?
 
Well, at least two of us are doing charm cards of various types. That is the one basic reason for it, to have a common format that we could do our processing off of while still using the same XML format. Then, naturally, getting various producers (lore5, anathema, edexalted) to export that format would be the next step. That way, the charm card creators could use data created by other people. And then, maybe, allowing imports of that format so if someone wanted to create a charm, character, item (based on future stuff) editor, and then import it into the program of their choice. Or export from one program to another. Or creating XSLT to create pretty web-based character sheets.


So, my goal for this is to create a common XML format that all these Exalted program writers could at least "mostly" agree on and see if we if we can at least share some of this creative energy or at least allow one person's effort be shard among others. I mean, how many times has the Solar book charms been entered? If it was in a common format, then it would just be a matter of writing an import and not having yet another 30-50 hours of typing go to waste. :)
 
You must log in or register to reply here.

Users who are viewing this thread

Total: 7 (members: 0, guests: 7)

Similar threads

Sora No Kami
A vicious dance with death (RP 1x1 based on the song "My R") TW: Self-loathing, Suicune
Replies
1
Views
97
Sora No Kami
Sora No Kami
Back
Top