By the end of this month (August), we will be running a Kickstarter, and voting is one area we plan to enhance with funds we raise – including speedier vote resolution. We’ll have more details when the Kickstarter begins.
even worse example: on "Quest: Dead Sail, Chapter 1: Approach", 2/3 options are ineligible for our party! (1 runecaster and 2 truebows lack both Persuasion and Tactics) but yet we have to wait for us to "vote" on the only option open to us. should just bypass the voting with narrative.
It’s very likely we will make a change along these lines. There are some complications to work out, most importantly how to make sure parties don’t get auto-advanced through many rounds while players are asleep (without forcing them to constantly remember to change their time limit before bedtime). We have some ideas here, but also encourage you to post your own solutions.
making the timeout changeable by the party leader is definitely easy and should be done first. one member of our party is currently awol, so we're only making 1 move per day. that their character isn't contributing any damage output hasn't impacted us yet, but default actions should be fairly simple to code: move forward until the closest target is in range and attack with the class' "basic" attack (to borrow a d&d 4e term, which is basically auto-attack "white damage" in WoW).
sounds like recover should fix bleeding as a major for any class.
runcasters should keep woundbinding as a minor.
Conflicts during action-taking no longer require an extra click to acknowledge the conflict, which should make them less annoying. Action-taking still requires a click to begin so that you can see the details of what just happened, but we’re considering whether we should streamline this further.
Re: Han's "this would allow you to attack, then move away, which wouldn't be so good for game play"... why? the foe can step to follow you and attack. d20 actions have been like this for years, and it works perfectly, but d20 also allows more movement more than just 1. offhand, the only place where this would be broken is the beacon's push attack.
fwiw, i gave up on playing a beacon early on for exactly this reason: could never reach anything before ranged players killed it, and could no do anything until you get there.
We’re taking a look at how we handle notifications during asynchronous play to make them as timely as possible without becoming annoying,
pls make the emails use gmail's heuristics for threading, i.e. all use the same subject.