search

deathcap / voxel-fuel

a loader client/server engines (for voxel.js)
2 stars 2 forks source link

Support local/offline gameplay (non-RTC, client=server) #4

Open deathcap opened 10 years ago

deathcap commented 10 years ago

Even non-switchboard RTC might be ok. rtc.io can take a while to load, but this simple example doesn't use it:

http://simpl.info/rtcdatachannel/ https://github.com/samdutton/simpl/blob/master/rtcdatachannel/js/main.js

deathcap commented 10 years ago

http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ https://github.com/cjb/serverless-webrtc/

deathcap commented 10 years ago

Maybe it is possible to setup the local client/server RTC connection without a signaler (to avoid hard dependency on rtc.io or another external switchboard server, even if I host it myself), then contact the signaler asynchronously afterwards to locate additional clients?

deathcap commented 10 years ago

https://github.com/rtc-io/rtc-signaller supports:

  • local, in memory message passing
  • via WebSockets and higher level abstractions (such as primus)
  • also over WebRTC data-channels (very meta, and admittedly a little complicated).
deathcap commented 10 years ago

New module https://github.com/deathcap/rtc-signaller-sw uses shared webworkers as the RTC messenger (signalling) for fast local play, no remote server dependency. Uses the same WebRTC infrastructure otherwise, minimizing separate codepaths (still uses data channels, etc).

However, this means client/server only works locally now (same browser instance, possibly separate tab/window). Would like to connect the SharedWorker-based signaler to a remote rtc-switchboard server, on demand and asynchronously (to avoid lag and not regress local usage).