A new webapp for 3E Combat

[Ulthwithian]

This is awesome!

Very happy to see this, as I've been looking for it for a while. This will be a fixture in all my games.

[kawaiiwolf]

Interesting ! In it's current state you might actually just be able to scrape out the html/javascript to plug into another site as a static page: Let node.js compile it once for you then copy/paste the results to a more static webserver. I would recommend though, keep serverside interaction external to this app. I wouldn't do anything more complicated than POSTs JSON data to a URL and another that GETS JSON data, that way someone could set it up to use whatever server architecture they needed. You just need to be able to take a JSON object representing the state of a battle (Each of the involved characters, their various attributes (name/picture url/mote pool/init/boolean to represent if they've acted this round) and the current round/tick). If you pass in the json from a https://api.jquery.com/jquery.getjson/ call and set the battle to that, you've already done most of the work needed to synchronize for a "multiplayer" environment.


One thing it does need at the moment: The ability to add someone else into the mix in the middle of the battle.

[wastevens]

I would just click Add New Character, type in the group's name, and put their Size/Magnitude/Might/etc in the notes section. They won't get lost if you give them a nice portrait.

I shall bear that in mind / give it a try!

[bartkusa]

I would just click Add New Character, type in the group's name, and put their Size/Magnitude/Might/etc in the notes section. They won't get lost if you give them a nice portrait.

[wastevens]

What special functionality do Battle Groups need? Hide essence? Freeze their initiative after round 1?

Not entirely sure- I'm just anticipating that they'll easily get lost if they aren't in the tracker.
Maybe Size and Magnitude?

[bartkusa]

add a 'character' for Battle Groups?

What special functionality do Battle Groups need? Hide essence? Freeze their initiative after round 1?

[wastevens]

Holy crap this is awesome!

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?

I strongly suspect that export / import JSON of the current state would be adequete.

Also, for features to consider; add a 'character' for Battle Groups?

[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.

[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.

[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 ?

[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 ?

[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!

[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.)

[TK421]

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