Network play

[Alex Wilson]

I'm not sure whether the multiplayer API should be built on top of WebRTC or direct connections between node processes. WebRTC Data Channel isn't available yet, and i'm not sure when it will become available. The node processes, however, have the bottleneck of socket.io connected to the browser (which brings up the point that it might be in our interest to make a lighter version of socket.io using ArrayBuffers and raw WebSocket to send the data between browser and process).

We can always use the node process idea until, if ever, WebRTC Data Channel becomes available for us. What are some opinions?

[Jeremy Kahn]

It's generally not a good idea to build on top of incomplete technology, so I'd advise against WebRTC.  Since we are only supporting one browser, it seems to me that the best option is to go with raw WebSockets.  I haven't done any work with socket.io or WebSockets, so I'm not sure how much more difficult that would be to implement.  If building a custom WebSocket layer is something you find interesting, it sounds like this project would benefit from that.

Ideally we should abstract the data connection into a layer that we can swap out later.  I think the first step is to spec out an interface that makes sense for both WebRTC and WebSockets.

On Mon, Sep 24, 2012 at 4:36 PM, Alex Wilson <arex...@gmail.com> wrote:

I'm not sure whether the multiplayer API should be built on top of WebRTC or direct connections between node processes. WebRTC Data Channel isn't available yet, and i'm not sure when it will become available. The node processes, however, have the bottleneck of socket.io connected to the browser (which brings up the point that it might be in our interest to make a lighter version of socket.io using ArrayBuffers and raw WebSocket to send the data between browser and process).

We can always use the node process idea until, if ever, WebRTC Data Channel becomes available for us. What are some opinions?

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/RyJOc6AvmDMJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jeremy Kahn

jerem...@gmail.com

https://github.com/jeremyckahn

@jeremyckahn

[Alex Wilson]

Agreed. I'll look at raw WebSockets and work more on the multiplayer API.

[Alex Wilson]

I have raw binary WebSockets running in Chrome using node-ws (a WebSocket implementation socket.io is based on), and I've started work on a utility for wrapping binary sockets as event emitters. I'll be running some tests soon to make sure the speed increase from using binary sockets is anything more than marginal (it definitely should be).

[Jeremy Kahn]

Awesome, great work Alex! Let us know when you're ready to show it off. :)

[Alex Wilson]

It looks like what I'm working on is a little bit faster than socket.io right now. Between that and the fact that it can be relayed through the node app to the webpage without having to parse and re-stringify. My next steps will be to speed up the parser, expand coverage to all objects covered by JSON and put a nicer API on top of the whole thing.

[Jeremy Kahn]

Awesome! I'd love to see a demo when you have something ready to show. When this is ready, where should the code live, the main Pine repo, or your API repo? Would you be interested in making this a standalone library?

[Alex Wilson]

So far I have it in it's own repo, and I think it's a useful project, so I'll work on packaging it as a standalone.