A new webapp for 3E Combat

[bartkusa]

New feature: Track characters' personal and peripheral essence! (as of 3/26/16)

I'm working on a webapp for tracking initiative, essence, onslaught, and all the other fiddly numbers that change a lot in combat.



The "useful links" thread already has a tracker in Google Spreadsheets tracker, but it requires lots of clicking and typing, and I think I can (eventually) make something that's slicker and more touch-friendly (eg, for iPads).

So far, all you can do is track who has gone each round, and what each person's initiative is. I'm trying to figure out what I should add next, that'd make this helpful to more people. Let me know what you think!

[Ellis]

Essence and anima, maybe? Keeping in mind some Charms expend anima.
Also, Tepet Zherkoff should be an npc in everyone's game.

[Fata-Ku]

Nice!
Suggestion A: something should noticeably notify you once the round is over (like maybe the "next round" button gets focus and flashes or something), because once that last go button disappears, the user is focusing on the bottom of the screen and it's easy to miss that button.

Suggestion B: put a second next round button under the character list, so that as the "go" button progresses downward and disappears, "next round" is clearly the next expected interaction. It would reduce cognitive load in having to memorise the interface and eliminate the need to scroll back up.

Suggestion C: both

Edit: I'm definitely planning on using this because it's awesome, but it's gonna be on my phone. Could you make the note fields responsive? Like, have them go below the character when the display is under a certain screen width, and potentially be collapsible? (just, like, a css @rule)

(Also if your project is on GitHub I could contribute some of these features :P )

[Magnum Opus]

Awesome webapp, I was planning a big fight soon and I'll be using this for sure.

[Deamonlight]

Edit: Nevermind. This is really useful.

[bartkusa]

Nice!
Suggestion B: put a second next round button under the character list.

...

Edit: I'm definitely planning on using this because it's awesome, but it's gonna be on my phone. Could you make the note fields responsive?

Thanks for the great feedback! I can easily add another Next Round button in the right place. Consider it on my short-list.

The code is hosted at https://github.com/bartkusa/Ex3eTracker. The two files you'd want to tweak are Combatant.jsx and Combatant.less.

I'm happy to review pull-requests, or you can just send me a sample of HTML + responsive CSS. That might be easier, if you don't already know React + Webpack (but maybe you do).

[bartkusa]

Made some tweaks.

• Next Round button also appears under the last active combatant.
• You can now remove characters from a battle entirely during Round 0.
  • This is helpful if you have a big library of stock NPCs.
• On phones/tablets, there's a special iPod-style UI for changing initiative, but only if you visit http://bartkusa.com/ex/?#spin.
  • I'm pretty sure it's buggy as hell on iOS.

Next up: fix iPod-thing on iOS, fix layouts on phones, and add Essence and/or Onslaught. Might be a while.

[TK421]

Looks good! Suggestion: a "Reset to Base Initiative" button that puts a combatant back to 3.

[bartkusa]

Made some tweaks for phones. Next up: essence, then defense/onslaught, then maybe a reset button.

(I'm struggling to add more stuff because I'm not a good designer, and I'm running out of space to add buttons.)

[bartkusa]

You can now track characters' personal and peripheral essence!



When you click the [Go] button, that character will gain 5 motes automagically (assuming they're not full up).

I'm also gradually making this less awful on phones, but it isn't easy.



Feedback is welcome!

[kawaiiwolf]

Looks pretty good ! Glancing at the github js code I'm not even sure where I'd start to convert this, but I'm thinking I might need to develop something similar with a php/mysql backend. How difficult would this be to transition to a shared web tool, where say any change made would be pushed out to the other players, so you could keep multiple player's screens up to date concurrently ?

[Magnum Opus]

So I used it in my last Exalted combat and it went really well. Like, a lot more fluid than when we were using tokens and questions

[kawaiiwolf]

Looks pretty good ! Glancing at the github js code I'm not even sure where I'd start to convert this, but I'm thinking I might need to develop something similar with a php/mysql backend. How difficult would this be to transition to a shared web tool, where say any change made would be pushed out to the other players, so you could keep multiple player's screens up to date concurrently ?

A few more related thoughts for concurrency and stored sessions:
- assume players can be trusted to edit and access fairly. If your players are willing to actively cheat to gain an unfair advantage, you have worse issues than an application can/should handle
- don't worry about authentication and user permissions. Leave that to a web server or application framework to manage. Alternatively, use randomly generated shared session keys (pass around the link) to obscure/protect sessions and allow multiple concurrent sessions. Data is fairly minimal, easily purged and keeping orphaned sessions past their use only takes significant space in the case of deliberate flooding on the site.
- race conditions can be mitigated with a little logic - allow the server to replay changes as it sees it. This is also useful for refreshing a player who connects Midway into a session
- user notification can easily be handled via jquery fade-in effect, letting users know unobtrusively where live changes were made.

Most importantly: having one master function that accepts a json response from a php page that can set/replay a session state can let you hook in a server concurrency module without breaking much of the currently working functionality. From there you just loop a call with a to a php application every few seconds or use a long poll for said json object, sending updates to a separate php page as necessary.

-------------------

On an unrelated note, this could use an undo button to backup one step in case you goof and hit [go] on the wrong player


Edit: Derp, after a bit more code digging I realize this is a node.js application, which kills the portability of it and negates some of above statements. I have to ask, why utilize something with so many server-side callbacks for what is ultimately client rendering ? Were you already planning on database integration ?

[Gayo]

I'd be all over this if it had a way to store state, but I can totally see how you would not want to get into the business of storing people's state. I do agree that you probably don't need to worry about "security" concerns, at least. I wonder if there's a way to hook it to third-party state storage, e.g. as a google app.

[bartkusa]

I'd be all over this if it had a way to store state, but I can totally see how you would not want to get into the business of storing people's state. I do agree that you probably don't need to worry about "security" concerns, at least. I wonder if there's a way to hook it to third-party state storage, e.g. as a google app.

What do you mean by "store state", precisely?

- You can store your character roster in your browser's localstorage with the Save button.
- You can store a battle-in-progress by... not closing the browser tab. :P

I'd love to let users have access to their data from multiple clients, but I have a limited amount of time to work on this, so I've just ignored the server entirely.

The easiest thing I could do to enable data-sharing w/o a server would be:

- button to export raw roster data as JSON
- button to import raw roster data from copy-pasted JSON
- button to import raw roster data from JSON stored at a URL

That'd be a LOT faster to code than provisioning and connecting to a server; would it help scratch your itch?

...

On an unrelated note, this could use an undo button to backup one step in case you goof and hit [go] on the wrong player

...

Edit: Derp, after a bit more code digging I realize this is a node.js application, which kills the portability of it and negates some of above statements. I have to ask, why utilize something with so many server-side callbacks for what is ultimately client rendering ? Were you already planning on database integration ?

Node is necessary to build the app, but there is no Node server at run time. bartkusa.com is just a file server. Everything is happening in the browser.

I'd love to build "multiplayer" for this, and "undo" is on my mental to-do list as well. Both of those things would be easier if I switched from Reflux to Redux for app-state.