Collaborative gameboy emulation powered 100% by JavaScript
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.gitignore
Readme.md
index.js
package.json
redis.js

Readme.md

weplay

How to install

Install with

$ npm install

Then run it with the following ENV vars:

  • WEPLAY_PORT - pointing to the port you want to listen on (3001)
  • WEPLAY_REDIS - redis uri (localhost:6379)
  • WEPLAY_SERVER_UID - unique persistent identifier for this server's instance. Used for keeping track of # of clients in redis (defaults to WEPLAY_PORT)
  • WEPLAY_IP_THROTTLE - the least amount of time in ms that need to pass between moves from the same IP address (100)
$ node index

This will set up the IO server for weplay. It's necessary that you also launch the other services:

  • weplay-web serves the HTML pages and static assets to run the game. It also serves initial state from Redis with the page for optimal performance.
  • weplay-emulator runs an emulator and broadcasts the image data from it with socket.io-emitter to the IO instance(s) that users are connected to.
  • weplay-presence notifies all the IO instance(s) of the aggregate number of online users.

FAQ

How does this all work?

The weplay-emulator service runs a JavaScript-based gameboy color emulator that gets painted to an instance of node-canvas.

Upon each draw an event is emitted and the PNG buffer is piped through Redis to all the IO instances of weplay (this project).

With Socket.IO 1.0 binary support, we can seamlessly transfer the image data contained in the Buffer to all the connected clients, in addition to all the JSON datastructures to make chat and commands work.

This makes weplay a 100% JavaScript project!

What are the error handling scenarios?

  • In the event of a crash of a weplay IO node, clients can be rerouted to another instance and reconnect automatically thanks to socket.io-client.
    • Events that are broadcasted to other users (such as chat messages and "x moved y" events) get persisted upon broadcast into a Redis capped list, which means that upon reconnection users will get the latest events despite having been routed to a new server.
    • The connection count will be eventually consistent and correct thanks to the work of the weplay-presence service that aggregates the connection counts of all servers.
  • In the event of a crash of weplay-emulator, the next time it boots up it restores the virtual machine state that gets persisted by default every 60 seconds (for performance reasons).

Support

If you have ideas or contributions, join #weplay on Freenode.

License

MIT