Micah
This is a place to discuss the dynamic character sheets (ie. DSTs) that we're working on.
"READ THIS FIRST":http://help.obsidianportal.com/faqs/advanced/creating-a-dynamic-character-sheet-template-dst
If that makes no sense to you and you have no idea what HTML/CSS is, then this thread probably isn't for you. This is a very technical discussion, but it will hopefully result in something that is easy to use and requires no technical background at all. Once everything is in place, we'll make an announcement about how to use the dynamic character sheets.
But, if you've read the DST FAQ and have any questions or suggestions, then by all means please post. My hope is that all of us together are smarter than me by myself.
*Update*: I've added the "developer kit":http://d26snb5x2x7cfb.cloudfront.net/dst_devkit/dst_devkit-0.1.zip This should allow you to see what I'm working on and how it all works. Suggestions welcome.
*Update 2*: As per suggestions, I have moved the dev kit to public code hosting "on github":http://github.com/obsidianportal/dynamic_sheet_templates This will be where all sheets are stored as well. Hopefully this will make it easier to collaborate.
Comments
http://api.jquery.com/checkbox-selector/
If it's a text box, I don't positively know of a way off the top of my head to do it, but it'd probably be something about extracting the output and testing it against True or False. Anyone more skilled than I have better ideas?
I think there is a way to set an item to use a checkbox, or even a select, using jeditable. I'll have to dig in. This will probably end up being another class that you tack on to the span in order to force it to a checkbox.
1) it is often nice to have TEMPORARY modifications: a Druid with wild shape, some casting cats grace, etc. Nice to be able to change this in-game and see updated values for things like attacks, saves, ac, etc, but not commit the change to the page permanantly.
2) it saves time to hve a common page that lists things like party Xp, hp, consumable items, that everyone in the party "imports". That way after an encounter, you (ie the gm) can go and edit 1 page and every character in the party updates. Saves a ton of time.
3) it is very nice to have things that are dice rolls linked and clickable. For example, ether than say your attack is +4, make the +4 a link that uses JavaScript to roll a d20 and add 4.
4) it needs to support house rules! What if someone uses pathfinder's rules as a base, but add a seventh ability score to the mix to measure, I don't know, sanity say. So, users/gms need to be able to add fields to pre-existing templates
I have a framework that sounds very similar to what you have, that accomplishes all these things, already written and working (though I wrote it assuming only I'd ever deal with the code so it is very much not friendly to anyone but me to work on). It runs in firefox, safari (including iPhone), chrome, and opera at the least (other browsers not tested but anything based on WebKit should work, and there is no theoretical reason it would fail in IE, but I have had no reason to test it there yet). I'd be happy to donate code and ideas and experience on this front. I'm using this in 3 campaigns (pathfinder and 3.5 so far but my framework can theoretically support anything that uses math) and constantly refining it in what amounts to live playtest. I could easily make template pages for every core class in pathfinder/3.5 (and any other game if I went out and bought the rules, and I could refine my language so anyone can make pages for rules I don't have quickly) so people just plug stats in. I sent a link to an example in the email saying I'd be willing to beta test (my server can't quite handle many many hits so I do not want to post an example link publically yet)
Ps sorry for any horrendous spelling. Editing this on an iPhone is not easy. I'll fix any errors when I get home. Please make things more iPhone friendly! I'd also be glad to help on that front!
We're looking to be a lot less than what you're describing. I don't want to program a whole gaming engine, and it's not meant to be interactively used. The goal is to simply provide a "pretty" character sheet, something that you could use at the table if you forgot your paper sheet. Or, another group member could use it to run your character if you miss a session.
Temporary bonuses, dice rolls, and all that kind of stuff is out of scope at this point.
Why? Well, we don't want to be too locked down to any one system. Pathfinder and D&D are nice, but the whole galaxy of systems is much more varied. By starting modest, we can work our way up.
I'd be happy to look at what you've got, though. I'll take a look when I have a chance.
P.S. I may take you up on your offer to be more iPhone friendly. We've got some ideas in that direction.
Specifically, I learned that including a visual representation of the formula used to generate certain numbers (e.g. Final AC or to-hit numbers w/ specific weapons) can be very helpful in game, especially if players print out their sheets. WOTC does a very good job of this with the "official D&D character sheets.":http://jetfuel.metalbat.com/blah/D&D%20Character%20Sheet.png
For example, the official sheet lists AC as a sort of equation
|=. ==__== |=. = 10 + |=. ==__== |=. + |=. ==__== |=. + |=. ==__== |=. + |=. ==__== |=. + |=. ==__== |=. + |=. ==__== |=. + |=. ==__== |
|=. AC |=. == == |=. armor | == == |=. shield | == == |=. dex mod | == == |=. size mod | == == |=. nat. armor | == == |=. deflection | == == |=. misc. mod |
Seeing the actual formula spelled out this way does wonders for a sheet's usefulness by helping players calculate any changes to their stats that might occur mid-game. I learned this the hard way, because since my players started with a sheet that did not include such visual breakdowns, it took them a lot longer to learn what numbers actually made up Total AC etc. Those who eventually switched to the official sheets consistently do better with in-game adjustments to their stats.
Just food for thought, and likely something people will worry about AFTER they actually have their html set up.
From what I can tell, once a template with all apropriate equations was written, it would be just as easy to make characters as your system: plug in a page that says where things go, a list of stats, and go. The only difference is that each template page is game-aware and tells the underlying system that a modifier uses a d20 or a d100 or whatever. And it falls back gracefully to a non-interactive version in the case of a quick template that provides no equations dictating what is used for what.
Anyway, just saying, I've done a lot of work on a similar, ultimately compatible version that takes it one step further. All the code is free, and I could easily adapt it to work with this framework.
I think something with a spot for stats, with an editable form, would be the ideal solution. Something the GM would have to do, then all the characters in a specific campaign would use the same sheet.
If you use a system that doesn't use Armor Class, why have the stat there on the sheets? Same for Hit Points or whatever else. They should be as generic as possible to ensure maximum potential for use.
A customizable stats block area, skill area, equipment area, experience (or some synonym to express the analog) and background info and notes should be all the sheets have.
Not to poke my nose in since I know nothing about markup, but for versatility, the more generic the better.
I can also shut up since I just read the FAQ and now realize there will be multiple sheets...
SORRY.
EDIT: You edited your post before I could post mine, sorry about that.
1. There should be 4 styles for the DST for player to choose: Middle Age (D&D), Classic (COC), Modern & Future (Star War)
2. Additional pop-up page for DM viewing the basic status of the characters during gaming. Before showing the status, the DM should choose which status will be shown. And this will be prefect, if there is a simple initiative counting.
I do think the CSS classes should have a namespace. The print stylesheet is a brilliant idea.
From what I can tell, checkboxes wouldn't necessarily have to go through jeditable. I would recommend using [input type="checkbox"] with events to sync its state to the underlying JS Object. jQuery could easily find all checkboxes and bind these sync events.
I'm looking forward to seeing how we're supposed to implement the more dynamic behaviors, like having a list of arbitrary length (think D&D feats or multiclassing).
Maybe there could be some standard mechanism to highlight dependent fields either while editing or when an edit is submitted. For instance, if I edit my Strength score, it could quickly show me that my Strength modifier, melee attack bonus, and Strength-based skills are affected.
Dynamic behaviors like arbitrary lists could be handled with javascript, like adding new fields on the fly like feat_1, feat_2, feat_3, and just adding new feat fields every time the user clicks a "Add new feat" link or something. The downside is that it wouldn't really be a true array, just a bunch of unrelated fields. I'd like to support arrays and maps and such, but we've got to start small. We're also hoping to get some ideas on this front.
We also don't have any standard mechanisms right now for things like highlighting, but we can start to build some javascript/jQuery utilities. Plus, we have all the jQuery magic at our disposal, so things like animations and effects are possible.
I like the SCM repository idea. If a community runs the show, it's less for you to keep track of. Plus, it would do versioning for us and make branching easy.
For now, there will be a manual approval process where you email me a DST, I look it over, play with it in dev mode, and then put it live in the system. I'd rather start manual and build an automated system once you guys overwhelm me with submissions.
I can definitely see a public repository being a good idea. I hadn't planned for that, but it wouldn't be hard to do. I think there would be some good co-op opportunities, like if someone is really good with CSS/photoshop, but needs someone else to write the javascript.
Templates will be associated with user accounts so that the original author gets full credit for it, something like a "Designed by so-and-so" at the bottom of each page using the template. I'm not sure how to handle multiple authors. Maybe everybody flips a coin to see who gets the credit.
As for free Ascendant time, if you rip-off an existing one and it has no meaningful changes, you dont get squat. That's why I said that step 1 is to email me and tell why the existing DSTs for a given system don't cut it. If your reason is "I wish it were a different shade of blue" then I'm probably going to turn you down. However, if you want to make a separate character sheet for wizards vs rogues or something like that, then I'm definitely interested.
These are all good questions. Keep them coming.
(Also, I'll be out of town next week, so my responses may be a little slower. I apologize for ducking out at such an exciting time.)
Also, let me just say, hooray for style sheets, even if they are only for these sheets. Inline CSS is great and all, but doing fancy things like character sheets was getting a little bit beyond the sane man's patience.
We're working on making things more accessible and controllable. To be perfectly honest: You guys are better at this stuff than me. I'm basically blind when it comes to making things look good. I can work magic when it comes to databases and HTTP requests, but the end result always looks...well you all have seen the site.
I'm really happy that we're finding ways to let all of you bring your design skills to the forefront. Obsidian Portal looks good thanks to all your hard work adding such great stuff.
On another note, any chance you could point me at the function I'll need to call to store a field value, or save the values from dynamic_sheet_attrs (I'm not sure if you're storing values individually, or re-saving the whole lot each time)? I'll find it eventually, assuming it's actually hooked up in the dev-kit code, but I'm not familiar with jquery, so it's a bit of a slog.
Edit More: Just to add, the save function mentioned above will also be very relevant when employing javaScript that dynamically creates fields on the character sheet, as mentioned above.
Edit: An additional thought. If you could change the value of the submit string in characters.js to something like _✓_ (A button with a check-mark in it, with the necessary trappings to position the button and its contents using CSS), that would allow us to apply styles to the submission button, so it can be pretty too.
There should be no need to call anything to save the values. Everything will be re-saved every time when the user clicks on save. The values from each field will be written to hidden inputs and then the entire form is submitted. There shouldn't be a need to mess with any of that, but I could be wrong.
If you're looking to do things like update field Y when field X is changed, then you'll need to bind to an event (using jQuery). In the sheet.js file you'll see at the bottom where I'm binding to the "valchange" event. That's a pseudo-event that I created just for this, it's not a real javascript event. Whenever a field is changed, the valchange event is fired for that field and the new value is passed. That's how the example sheet is recalculating the ability modifier scores and whatnot.
I'll see about the submit button. I'm still not sure how to integrate things like _bio_, which can have wiki links and textile formatting. Using the jeditable in-line editing to show and edit that text will be difficult. Plus, I'm not sure how nicely it will play with the MarkItUp editor toolbar we use. We're getting into some strange areas here. The point of all this is that I may (at least in the beginning) leave in some textareas and other basic text fields (like name) on the edit form. They can be cleanly integrated into the display view of the sheet, but will have to be handled separately in the edit view.
I'm also considering adding some (well, at least 1) special HTML class: gm_only, or something like that. We'll need a way to display gm_only notes on each sheet, but we don't want to display it for non-GMs. Don't worry, I'm not talking about writing it into the DOM and then hiding it with CSS (since that's not much of a secret...) Instead, I'm saying that let's assume you create a section for GM-only notes, and it has a header that says "GM Only". I'm sure you'd rather that header not display at all if it's not the GM viewing the sheet. We could accomplish this by setting aside a special class (like gm_only). Anything with that class is hidden if it's not the GM viewing the page. Does that make sense?
* This might be asking for a bit too much, but have you given any thought to Character images?
* How are we supposed to deal with something like feats, where there needs to be a theoretically infinite list of possible values? What HTML should be put in there?
* The title of the page - is there anyway that you could have the server change it to "[Name of Sheet] - [Name of Character]"? Or should I rig up a Javascript function to do it for me?
Thanks in advance.
Also, with regards to the click to save - right now, it feels clunky and unintuitive. I think people are used to, at this point, having the web save their changes with little effort on their end. It'll take time to adjust, and I'm not sure if they'll want to wait that long.
Talking scripts, it looks like you use jquery almost exclusively in your own scripts. Personally, I don't like to use it (and haven't ever really learned it) because I find it cryptic, and I prefer rolling my own versions of most of its features anyway. Do you have any objections to our using scripts which aren't written using jquery?
For feats and other "array-like" values, for now I'm thinking we just go with "ds_feat_1", "ds_feat_2", "ds_feat_3", etc. With javascript, it's not too hard to create a "add new feat" link that just inserts a new span with the number incremented.
Hmm, another approach would be to name each value as "ds_feat[]" That would allow for real arrays. We'd need a way to create unique IDs, but allow for duplicate field names so as to have valid HTML. Let me double check on this, but I think it should be possible.
What's the goal of changing the title? I assume you're talking about the title tag. I'm not sure I see the goal here.
As to saving, we could make it so all changes are saved instantly, but I'd like to skip that for now. I'm personally not a fan of those kind of interfaces, plus it'd be harder to do. We can explore that later. We're trying to take small steps.
The editing and saving should be 99% transparent to DST authors. That's where jeditable comes in. It will allow for us to automatically insert _input_ tags in place of _span_ elements when someone clicks to edit something. That's how the devkit works. Basically, all the DST author has to worry about is making sure that the spans have the correct IDs, and we do the rest. If I get a chance, I'll try to update the devkit to make this a little clearer.
Yes, I've become a 100% jQuery convert. I could gush for hours on how awesome I think it is. That being said, I have nothing against people using bare javascript if they so choose. However, I'm not sure how the event binding can be accomplished without jQuery. Basically, I need a way to be able to notify your javascript or call a function when the user changes a value. I know how to do this with jQuery (ie. event binding), but I'm clueless as to how it's done otherwise.
The title for a character will be the same as it is on the site currently. For example, "this character":http://www.obsidianportal.com/campaigns/kensing/characters/alron-tarris has this title "Alron Tarris | D&D 3.5 | Obsidian Portal"
I suppose I should change that to include the campaign. The current title is a bit of a holdover from when characters weren't fully integrated with campaigns.
Anyways, don't worry about that. The DST sheet will be part of the current character display, and so the title will stay the same.