BTW, draft spec currently states, "When mouse lock is enabled clientX,
clientY, screenX, and screenY must hold constant values as if the mouse were
located at the center of the mouse lock target element...". I chose this to
pick something concrete, but not all zeros which may be used as magic values
in JS code, etc. I'm not strong in this opinion.
On Fri, Aug 12, 2011 at 3:20 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
> On Fri, Aug 12, 2011 at 3:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> > And if the user doesn't approve the lock you do what? Not let them
> > play your game?
>
> Maybe. It really is impossible to play a game with a control scheme
> based on WASD+mouselook if you can't get a lock.
>
> Alternately, you can switch to a different (less good) control scheme
> if you can't acquire a lock. This is not acceptable behavior for the
> default case, though. WASD+mouselook is a very entrenched and natural
> control scheme; anything else will be much harder to use.
>
> The difference isn't always quite this extreme; sometimes the
> experience is only moderately degraded, instead of majorly, if you
> can't get a lock. For example, edge scrolling in StarCraft,
> Civilization, or similar games is really useful. You could play the
> game without it, it would just be annoying. (The gamedev would have
> to implement some other way to do scrolling, either a modifier key +
> arrows, or dedicating the drag action to scrolling, or similar.)
>
> ~TJ
>