Dynamic Character Sheets

1246789

Comments

  • Micah
    Micah
    Posts: 894
    I haven't added support for the avatar images yet. I'll see if I can do that today.

    Leave a spot for them in your sheets and they should automagically appear in the next day or so.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Can you share the class names (for the span, and the image tag itself) you're planning on using? I've got the spot framed in on my sheet, and just need to set the classes to match the standard.
  • FailRogue
    FailRogue
    Posts: 2
    I haven't had the chance to read through the entire thread yet, but I'm very excited about this feature, and I'd love to contribute some designs and CSS. Please let me know if I can help with anything. I'll try and catch-up on the discussion when I'm not busy at work :D
  • Micah
    Micah
    Posts: 894
    Sheet looks great Patrick!

    I'm just about to push the updates with the character image. Just add a span like so:



    it will insert an img tag with a class of _avatar_image_
  • Micah
    Micah
    Posts: 894
    Things are looking pretty good. If there are any bug reports, let me know as soon as you find them.

    Let's spend a couple days making sure things look good, then we'll pull the trigger!
  • templeorder
    templeorder
    Posts: 18
    I'm going to go ahead and take a try at this for my own system. Micah - is the SDK link early on the latest and greatest?
  • pelwer
    pelwer
    Posts: 18
    Micah,

    Looking good. I made a few more tweaks and got the image in there.
    Here's an example: http://www.obsidianportal.com/campaigns/shadora/characters/arghmon

    Great work!
    Pat.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    Excellent! With the portrait key in place, and the last few issues on my own list fixed, I think mine is all set as well. I've just submitted it through the system.

    Here's an "example character":http://www.obsidianportal.com/campaigns/chainsawxiv-test-campaign/characters/kadon with the finished template.

    Micah, for what it's worth, I also finished converting out the controls scripts so they function in a way that should be totally sheet independent. Whenever you're ready to think about a common scripts setup, let me know and I'll write up the (minimal) documentation needed. In the end, I did four custom inputs - lists, pips, check boxes, and text areas - all of which I think folks might find useful. Alternately of course, people could just copy and paste them into their own script files, if you'd rather just handle it that way.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894
    Both Pat's and Chainsaw's sheets look totally sweet. This has turned out so awesome so far.

    templeorder - The devkit is mostly up to date, as is the tutorial. My best advice is to get a basic version working with the devkit, then bring it over to the main site and try it there. The only place it needs to work is on the main site, so that's where you should do most of your real development.

    Also, ask Pat (Pelwer) and Chainsaw about their experiences. They know more than I do at this point about how to do this effectively.
  • Micah
    Micah
    Posts: 894
    Any bugs found? Problems with the sheets? Things I've forgotten?
  • Huyderman
    Huyderman
    Posts: 3
    I'd thought I'd pitch my thoughts on arrays. In the data, use JSON arrays, e.g.:
    {"feats":[{"feat":"Dodge"},{"feat","Combat Reflexes"}]}

    Then in the html you could have something like:





    For each item in the array, the .dsf_template element is repeated, applying values as appropriate.

    And I was hearing something about a beta-list?
  • Micah
    Micah
    Posts: 894
    Huyderman,

    Interesting idea about the arrays. Like you say, it's definitely supported in the JSON, and I can store it on the backend pretty easily. We might not even need the dsf_array class, either. Perhaps it could just find all duplicate dsf_XXX classes and group those into an array automatically.

    I hadn't considered this because in the first version we were using IDs, but thanks to Chainsaw's advice we switched to classes. That opens up a lot more possibilities. Cool!

    I've added you to the beta list. Check out the "existing DSTs":http://www.obsidianportal.com/dynamic_sheet_templates and create one of your own if you're interested.
  • ChainsawXIV
    ChainsawXIV
    Posts: 530 edited May 2010
    I support this as a generalized, under the hood solution to storing lists. This should be simple enough if you're dealing with single fields, where each list item is a single value, and only somewhat more complex if you want to have more than one - like the Backgrounds list in my Exalted sheet, for example, which stores a background name and background value for each row. Not too hard to deal with really, just another aspect to handle (and much simpler if you use a parent container).

    While my own list control doesn't store its data this way (it just uses enumerated field names, which are the simplest alternative in the current system), it would be fairly simple to adapt I think, as it's otherwise very like the one suggested above. At the very least, it does provide a point of reference for features an official list control might include. Namely, the ability to control the ordering of the list, and the ability to split the list across multiple columns.
    Post edited by ChainsawXIV on
  • Micah
    Micah
    Posts: 894 edited May 2010
    My current thought about the above example is that I'm not sure if it's supposed to represent saving complex object values. For example, here's what I would expect to support with an array:

    {"feats" : ["Dodge", "Combat Reflexes"]}

    Huyderman's example scares me a little in that it is an array of objects. I don't even want to think about supporting anything above the most basic array of atomic values.

    But, the idea of a repeatable template is a good one. It should make it much easier to lay out and style the list.

    I may tackle checkboxes before the arrays, as it's probably much easier. But, I like the ideas for arrays, and if anyone else wants to weigh in, I'm listening.
    Post edited by Micah on
  • ChainsawXIV
    ChainsawXIV
    Posts: 530
    Check boxes should be cake, really. I set up an image based equivalent (the favored ability pips next to the abilities in my sheet), and it was totally painless.
    Complex object storage would be ideal for multi-field rows, in my opinion. In particular, arrays can readily contain multi-part data in an explicit order:

    {"backgrounds" : [["Resources","3"],["Artifact","3"],["Manse","5"]]}
  • Micah
    Micah
    Posts: 894
    Checkboxes are pretty easy, but I'm trying to add a solution that makes them dead-simple to do, even without javascript. My hope is to make it fairly easy to do a decent DST without knowing any javascript.

    I've been playing for a bit, and I think I can get a decent checkbox solution in today.

    All you need to do is add a class of _checkbox_ to a _dsf_ element. It will autoload a checkbox and check/uncheck it automatically. It will also be disabled except in edit mode.
  • Micah
    Micah
    Posts: 894
    Checkbox support is in. I've also updated the tutorial and devkit to give an example.
  • Huyderman
    Huyderman
    Posts: 3
    Uploaded my first stab at a character sheet. :) I went for Maid since it's a relativly simple system to start with. Of course some stuff broke when uploaded, and I haven't done any cross-browser testing yet (only Chrome and Opera)...
  • Micah
    Micah
    Posts: 894
    I'll take a look. Thanks!
  • Micah
    Micah
    Posts: 894
    Ha, it looks awesome!

    I think things may have broken due to unterminated divs and/or spans. Running the devkit version through the "w3c validator":http://validator.w3.org/ would be a good final step before pasting into the live site.

    I'll pull that background image to our server. I'm not sure what to do about the font files. Maybe put them along side the background image and serve them as well.

    Unless you protest, I'll go ahead and set it to live so other beta testers can play. Most likely we'll go live with the full DST system on Sunday evening.
  • Micah
    Micah
    Posts: 894
    Maid has been approved, and I've made the approval system a little easier on myself, so I can get DSTs live much quicker.
  • Theoremancer
    Theoremancer
    Posts: 15
    Micah, can you add me to the beta? I assumed I was already, but none of these sheets people have been submitting are visible to me. Thanks!
  • Micah
    Micah
    Posts: 894
    Now you're set.
  • OPAdmin
    OPAdmin
    Posts: 53
    You should now be able to use DSTs on new characters, instead of having to save then re-edit.

    Let me know if there are any bugs.
  • Micah
    Micah
    Posts: 894
    You should now be able to use DSTs on new characters, instead of having to save then re-edit.

    Let me know if there are any bugs.
  • Theoremancer
    Theoremancer
    Posts: 15 edited May 2010
    Thanks! Ok, I've got a few questions/suggestions.

    # Since the DSTs are going to be under version control, does the version number still need to be part of the path?
    # Rather than editing index.html, I think the HTML for each DST should be in its own directory (dynamic_sheets/slug/sheet.html?), alongside its JS, CSS, and other resources.
    ** Better file organization.
    ** Allows the sheet to stand on its own and declare its own dependencies.
    ** Opens up index.html for another purpose...
    # index.html could be styled to match OP itself. It could contain an iframe, sized to match that of the OP character page, which points to the DST's HTML.
    ** Easier local development of multiple DSTs -- just change the src of the iframe in index.html.
    ** Designers know how much space they have to work with.
    ** Designers can see how their sheets compare to OP's style.
    # It might not be a bad idea for each DST to be distributed with an example_data.js to pre-populate a sample, or even a blank_data.js which initializes the sheet for new characters.
    Post edited by Theoremancer on
  • Micah
    Micah
    Posts: 894
    We're not doing any kind of version control anymore, plus the HTML, JS, CSS "files" are actually stored in the database. The main impetus for this was so that DST authors could edit everything as they needed, as opposed to having to send things to me to put on the server.

    I suppose I should get rid of any reference to versioning in the devkit. The devkit still has some of the original pathing structure that's no longer needed. Pathing is handled automatically, except for images, which we're still trying to figure out.

    The best course of action is to get the basics working with the DST, then move over to the live site and put on the finishing touches there.

    Example data would be a little tricky, because the user would then need to remove all of it for their sheet. I think most people would rather start with a blank slate. It's assumed that they're using a system they know, so they'll know what values to put in and where.
  • pelwer
    pelwer
    Posts: 18
    Hi Micah,

    Looking at the "to do" list at the bottom of the dev kit page I noticed this

    "Textareas? Is there a way to mark a field as a textarea instead of a simple text input?"

    I'm concerned that if we add this (or other features) after the DST's go public we might be in a position to lose data.

    Here's the scenario:
    1. we don't have versioning on the DST
    2. we have a section in the sheet called "Gear"
    3. the Gear section has 5 dst variables, gear1-5, for each line of text in the Gear section
    4. Textareas become available to the sheet developers
    5. The DST developer changes the Gear section to use Textareas and not only needs 1 variable so they delete gear2-5 variables
    6. next time the user pulls up their sheet, they have lost any data stored in gear2-5

    I'm wondering if you have a solution for this?

    1. Should I be using an array instead of separate variables to store gear?
    - this solution implies that there is some sort of DST code review prior to release to enforce proper DST coding practices
    2. Should we implement the textarea before going public?
    - this solution also implies that there is some sort of DST code review prior to release to enforce proper coding practices
    3. Should we allow/encourage DST developers to version in the names of their DST's?
    - puts the onus on the DST developer to not lose data, still human glue
    4. User can view old versions of their character sheet
    - OP would have to store history for the PC pages and provide a mechanism to diff or view the old versions(read only) so that
    users could copy their data forward via cut/paste
    5. Other thoughts?

    I don't like to pose a problem without giving you a solution, but I'm not sure how we would protect the user's data against DST updates.

    Pat.
  • Micah
    Micah
    Posts: 894
    Pat,

    At this point, I'm not too worried. You bring up a good problem, and we'll have to solve it eventually, but some of this stuff will just need to be figured out as we go along. Even once we launch, I'm still going to consider the DSTs a beta product for at least a little while. We'll add new features, change things around, and mess things up a couple times.

    In essence, we can't let a fear of future features paralyze us and prevent us from launching. I'm very pleased with how things are now, and I want to get it in front of people to see how it works. My gut tells me that we'll have much bigger problems than the textarea issue.
  • Theoremancer
    Theoremancer
    Posts: 15
    Micah,

    I was mainly referring to the organization of the devkit, not the files as they'll exist in OP itself. Since developers submit HTML, CSS, and JS, I thought it made sense for the devkit to be organized in such a way that those three files would be found in the same place. As it is, one must edit index.html in the base directory but JS and CSS in the DST directory, and that just seemed weird to me.

    As for changing index.html in the devkit, I was mainly interested in having the size of the final OP content pane reflected there. I tend to do layout first and then fill it in with content, so knowing the size is especially important for me. Locally, I'm using the iframe method I described and thought others might benefit from a similar arrangement. Could I email you an example?

    The sample data idea was for developers, not users. Users would start with a blank sheet, but developers could load sample data to get a feel of what a filled-out sheet would look like. If the DSTs aren't going in a repository though, there's really not much use for this.

    Even though the final product is going to be stored in the OP DB, I still think a (mostly) public repository would be a great idea for development. It'd be simple enough to create a project on Google Code with a pre-selected source license (MIT) and content license (CC). Then you could open it up to anyone, and all contributions would be automatically covered by the same license. It would also allow others to see works-in-progress, provide feedback, and participate in cooperative development. Google Code would also have a wiki and issue tracker. I'd be willing to set it up if you like the idea. If nothing else, I may just set one up for myself.
Sign In or Register to comment.

March 2024
Wrath of the Highborn

Read the feature post on the blog
Return to Obsidian Portal

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Discussions