Re: [whatwg] Proposal: requestBackgroundProcessing()

On Thu, 20 Feb 2014, Ashley Gullen wrote:
>
> We're building a browser-based P2P multiplayer engine on top of WebRTC 
> DataChannels. You can try out our work-in-progress here: 
> http://www.scirra.com/labs/multiplayer/test1/
> 
> The first player in to a room is assigned the host, and all other 
> subsequently joining peers connect to the host with WebRTC DataChannels 
> and start exchanging game data. Like all responsible HTML5 games, it 
> runs based on a requestAnimationFrame loop.

requestAnimationFrame() is for animations, not for logic. For logic, your 
better bet is to use a worker or, at worst, setInterval().


> To prevent multiplayer games commonly hanging, perhaps there could be a 
> new API to request that a page can keep running at full capacity even in 
> the background, such as window.requestBackgroundProcessing().

Workers are the mechanism for running code in the background.

I would strongly recommend not using a peer server architecture, though. 
Doing this requires trusting the client, which is highly dubious. A 
hostile player could just inject arbitrary code into your logic, and 
subtly cheat without being detected. It also means that handling the host 
crashing or closing their laptop or going into a tunnel is different than 
the same for another player, which is a sucky experience for everyone.


On Thu, 20 Feb 2014, Glenn Maynard wrote:
> On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier wrote:
> >
> > Is WebRTC available in a worker?
> 
> I don't know, but if not, fixing that is probably closer to the right 
> direction than letting people run fast timers in minimized UI threads.

Yeah. If WebRTC isn't being exposed to workers, I recommend bringing that 
up with the editor of the WebRTC spec.


On Thu, 20 Feb 2014, Ashley Gullen wrote:
>
> There's a lot of worker features that aren't widely supported yet, like 
> rendering to canvas with WebGL and 2D, Web Audio support, inputs, 
> various APIs like speech and fullscreen, so I don't think that's 
> practical right now.

Presumably your server logic doesn't need to be fullscreen...


On Thu, 20 Feb 2014, Ashley Gullen 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.

That part of the logic should be in the tab. Then the tab just acts as a 
client to the server in the worker, in the same way that the other clients 
for the other players do.


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

Different players are going to have different frame rates, so it doesn't 
make sense to make one player's frame rate more important than another's.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 11 April 2014 23:10:33 UTC