Dynamic Character Sheets

Micah
Micah
edited April 2010 in Feature Requests
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.
«13456789

Comments

  • giftedmunchkin
    Posts: 11
    If there's support for checkboxes, then getting a boolean out of the trained/untrained skills area should be easy. jQuery and plain old Javascript both have something for checking this. For example, here's the jQuery documentation for the :checkbox selector.

    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?
  • Micah
    Micah
    Posts: 894
    The editing is very dynamic. We're using "jeditable":http://www.appelsiini.net/projects/jeditable to allow in-place editing. This saves us from having to define some kind of form for every sheet. Instead, just edit in-place.

    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.
  • dylanryan
    dylanryan
    Posts: 3
    I've been working on a very similar system and am nearly complete. A few things to consider:

    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!
  • Micah
    Micah
    Posts: 894 edited April 2010
    Dylan,

    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.
    Post edited by Micah on
  • gnunn
    gnunn
    Posts: 423 edited April 2010
    My skill with HTML is fairly limited, but I do have some experience in design, specifically for formats that require quick processing of information (esp. e-learning & museum exhibits) and as someone who started a group of newbie players using "3rd party electronic character sheets":http://www.ssa-x2.com/images/3/31/Screenshot-CharSheet_v30-Page1.gif , I have learned about some features that can be very helpful/unhelpful from a visual presentation standpoint.

    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.
    Post edited by gnunn on
  • dylanryan
    dylanryan
    Posts: 3 edited April 2010
    I totally understand that, and that is how i felt too. Until I started programming it (I should state that I play mostly play-by-email games so these are our primary character sheets: We have no paper versions). But the point is, my pages are not specifically pathfinder or 3.5 or anything, just that that is what I have am using. I coded it to be completely ignorant of any specific game system, and then added "utility functions" that are system-specific. It can read an arbitrary dice expression ("d6+2D8+3"), figure out what it means, and handle it. And it is written so that a 1-line "assume D100s" could change +4 from meaning d20+4 to d100+4. With a little work (writing one JavaScript function and making a one-line "use this" change), it could even mean "draw a card from a standard playing card deck and add 4, counting facecards as 10" or "roll a d6, and roll another if it's a 6 and keep going, then add 4 at the end". Or any arbitrary JavaScript function that returns a number, so anything can be covered. I plan on shortly making Inquisitor (d100 based) pages, and there is no reason it can't adapt (and I mean easily adapt) to any system under the sun. Dice, cards, coin flipping(that's just a d2 of course), anything that a compeer can emulate. It works precisely because it doesn't know what system it is for. It just sees equations ("this thing called 'attack roll' is the sum of this thing called 'dex mod' and this other thing 'bab'. If any one of them changes, this should change to reflect that. The page is telling me this is a d20 roll, so let's make it a link too"). Anyone can make a template that has all the standard equations for the system built in that anyone can use (I essentialy have this for 3.5 and pathfinder but that is purely a function of current games I'm in), and if you wanted to use it for a game system you were just writing (ie that no one else could possibly know), you just write a few equations and lay them out where you want and it'll calculate them and spit out a fully playable sheet. And once there is a template for a game, the next character is just a simple "here are the stats, use that template, go" affair.

    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.
    Post edited by dylanryan on
  • dylanryan
    dylanryan
    Posts: 3
    And I agree 100% with gnunn: Showing how numbers were achieved is vital (where copyright permits, of course). Seeing that your AC is 15 doesn't tell you anywhere near as much as that you have a dex mod of -1, a amulet of nat. armor +2, and some suit of armor that gives you +4, or what have you.
  • JimTriche
    JimTriche
    Posts: 483 edited April 2010
    That assumes they want a specific character sheet.

    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.
    Post edited by JimTriche on
  • giftedmunchkin
    Posts: 11 edited April 2010
    I think I like the idea of the DSTs better than a generic form the GMs make. It would allow the opportunity for nice looking character sheets for nearly any system, as opposed to the somewhat utilitarian sheet you're suggesting. And from what I've seen of the code (not a whole lot, just what's on the wiki), they're easy to make, so anyone can make one for their favorite system. Particularly with the rewards system in place, I don't think there not being a template for your system of choice won't be a problem for long.

    EDIT: You edited your post before I could post mine, sorry about that.
    Post edited by giftedmunchkin on
  • giftedmunchkin
    Posts: 11
    Sorry for the double post, but another thought - what about print stylesheets? Probably not necessary, since it's unlikely there will be over-elaborate sheets that won't by default print well, but being able to print off a nice, clean copy of your character sheet hosted at Obsidian Portal would be pretty cool.
  • Micah
    Micah
    Posts: 894
    A print stylesheet would definitely be a nice-to-have. It wouldn't be too hard to work into the current system.
  • kwdav
    kwdav
    Posts: 1
    This is a great tool! And I have 2 opinion:

    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.
  • MALfunction84
    MALfunction84
    Posts: 15
    This all looks *very* promising. I definitely agree that the character sheets should not try to enforce the rules but rather just assist in filling out the fields, much like a PDF form. I'm definitely going to have to learn more about jeditable.

    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.
  • Micah
    Micah
    Posts: 894
    Malfunction seems to have a pretty good handle on what we're trying to say here. It's not the be-all-end-all online game sheet, but instead just a nice looking, pre-formatted sheet.

    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.
  • gnunn
    gnunn
    Posts: 423
    I agree printable sheets would be ideal, I know my players would not use them unless they could be printed. 4 of my 7 use printed versions of their electronic sheets at the table. I recently discovered an online character sheet that utilized the official D&D sheet layout, but decided not to tell my players about it, specifically because it couldn't be printed.
  • Micah
    Micah
    Posts: 894
    I'll add printable CSS to the list, but remember *we're depending on YOU* to make the actual DSTs. I hope that's clear here. We're making the underlying platform, but we need community members to step forward and create the HTML and CSS. Creating a full-featured character sheet for each and every system isn't something we can really do, so we're asking for help.
  • MALfunction84
    MALfunction84
    Posts: 15
    At the risk of derailing to a discussion of the meta-system, how community-centric will this process be? How will you prevent someone from submitting a sheet that's functionally identical to another sheet so they can some free Ascendancy? Will all contributions go through an approval process? Will templates be associated with individual user accounts, like campaigns are now with the DM(s)? It sounds like developers will be able to download others' templates and build off of them. Will OP provide an avenue for cooperative development, like a public SCM repository?

    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.
  • giftedmunchkin
    Posts: 11
    I have downloaded the dev kit and am hoping to make shiny things with it as soon as I have the time.
  • Micah
    Micah
    Posts: 894
    I don't have answers to a lot of these questions, as I'm just running ahead as fast as I can. I'm hoping some of it will shake out and be apparent in time.

    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.)
  • ChainsawXIV
    ChainsawXIV
    Posts: 524 edited May 2010
    This is looking like a very cool feature, and I look forward to working with it. I'm certain I can cook up some good contributions to the list given time. As I like a challenge, I think I'll start by trying to convert in a rather "graphics intensive":http://www.obsidianportal.com/campaigns/sotfa/characters/kadon sheet I made for Exalted, but it may be a while before I finish it... If only you'd dropped this a couple of months ago, before I had my new job...

    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.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894
    Well maybe someday you'll be semi-unemployed like me. Can't pay my bills, but I can work on Obsidian Portal, which is more important than electricity and water, right?

    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.
  • ChainsawXIV
    ChainsawXIV
    Posts: 524 edited May 2010
    As a quick note, you should probably include OP's standard Doctype in the dev kit's HTML file, as it has a very significant impact on how some CSS is rendered. Doing so will save a lot of us going, "Hey! That's not what it looked like on my machine!" down the road.

    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.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894
    These are all good suggestions. I'll add the doctype and re-upload a newer version.

    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.
  • Micah
    Micah
    Posts: 894
    I just updated "the tutorial":http://help.obsidianportal.com/faqs/advanced/creating-a-dynamic-character-sheet-template-dst with a list of required fields. There will be certain standard fields across all sheets, like character name, the campaign, the player name, etc. These will be handled somewhat separately on the backend, but it should be invisible when making a DST.

    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?
  • giftedmunchkin
    Posts: 11 edited May 2010
    Toying around with the dev kit, now, and I have a few questions.

    * 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.
    Post edited by giftedmunchkin on
  • ChainsawXIV
    ChainsawXIV
    Posts: 524
    Ok, so making sure I understand fully, there will ultimately be a "Save" button, which writes the contents of dynamic_sheet_attrs up to the server, so a script that needs to record a value can simply add it to dynamic_sheet_attrs, and it should be good to go? Assuming I understand correctly, that will be nice and easy. Cool.

    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?
  • Micah
    Micah
    Posts: 894
    We could do character images, I suppose. We can settle on a given size and then you could leave a space in the DST for the image. The actual image tag (or even just the src, I guess) could be inserted with javascript. Definitely possible, and not really all that hard.

    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.
  • Micah
    Micah
    Posts: 894
    Chainsaw:

    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.
  • giftedmunchkin
    Posts: 11
    The point of changing the title in my mind is that instead of showing "DST Dev Kit", for example, instead it will show "DST Dev Kit - Tordek" (or "Tordek - DST Dev Kit"). It's really a personal preference, but I think it would be nice if the title of the page showed the character's name, or even the campaign's name. If it's not something that you think should be implemented system-wide, then it shouldn't be difficult for the individual developer to implement something like this.
  • Micah
    Micah
    Posts: 894 edited May 2010
    Ah, ok now I see. The devkit title is pretty much meaningless.

    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.
    Post edited by Micah on
Sign In or Register to comment.