[whatwg] Proposal: requestBackgroundProcessing()

[Glenn Maynard]

On Thu, Feb 20, 2014 at 4:32 PM, Ashley Gullen <ashley at scirra.com> wrote:

> Since it's a peer-to-peer engine, the user acting as the server is also a
> participant in the game. This means the server is also running the full
> game experience with rendering and audio.
>

The user is a client, and also a server for all clients (including
itself).  There should be no need for the client to run in the same
environment as the server.  The user's client is just another client to the
server (that happens to be running in a worker in the same browser).

The game logic is tied to rAF, since we intend to step the world once per
> screen draw, including for the player acting as a server.
>

That doesn't make sense.  requestAnimationFrame is bound to the refresh
rate of the user's monitor, and each user can have a monitor with a
different refresh rate.  (You can even have different monitors on the same
system with different refresh rates, though I don't know if that happens in
practice today.)  Even if everyone's monitor happens to have the same
refresh rate, the monitors won't all be refreshing in sync.  You also
wouldn't want gameplay behavior to change in subtle ways depending on
whether some user's display was at 50Hz or 60Hz or 120Hz.


> It looks like the server is caught between running in the UI thread and
> hanging when in the background, or running in the worker and not having a
> straightforward way to provide the rendering and audio game experience for
> the host player.
>

The host player just connects to the server, like any other client does.
(The actual connection layer is likely to be different, of course, since
you can just post messages across and not establish any network connection.)


> One solution is to make web workers able to access many of the same APIs
> the UI thread can, especially with WebGL, Web Audio, WebRTC and rAF. Then
> it might be practical to move a full game engine in to a worker. If that is
> planned, I guess there is no need for a new feature.
>

Not a "full game engine", just the server logic where gameplay state,
physics and so on are handled and communicated to clients.

-- 
Glenn Maynard