Meat Fighter 2 Turbo

Alan Shaw
@_alanshaw
http://tableflip.io
JavaScript Adventure Club

An experiment with meteor and websockets.

I wanted to see if I could build a game with Meteor.

SSID:
Makers Academy

Open:
http://192.168.50.105:1337

Make with socket.io

                   +---> client
                   |
client ---> server +---> client
                   |
                   +---> client

• Client emits player state (position, hit, life)
• Server broadcasts the info
• Client listens for other player state updates

I envisioned an Meteor version like this:

                   \  |  /
client            - MAGIC -       +---> client
 |                 /  |  \        |
 |                                +---> client
 +---> Players                    |
                                  +---> client

• Meteor does the magic bit really well
• What is the magic bit?
• Synchronising state between clients
• Mongo collections
• Your client interacts with a local collection
• Changes appear in other connected client's collections

SSID:
Makers Academy

Open:
http://192.168.50.105:3000

I figured:

• Still websockets
• DDP efficient transport - only communicating changes
• No more poll&diff

What I ended up doing:

• Wrote a MeteorTransport.js
  to present Players collection as a socket.io interface
• Code share FTW
• Connections collection manages who's connected
• Pinging server FML

Any ideas why websockets outperform meteor in this case?

Theories:

• Extra overhead calculating what's changed
• Writing to disk

Caveats apply:

• I'm not a game programmer
• I have no idea what I'm doing
• Crude implementation - no batches, no timestamps

Could you write a game in Meteor?

• Absolutely!
• but...maybe not a realtime game right now
• Redis support in the future might fix this

Thank you!

github.com/alanshaw/meat-fighter-2-turbo
@_alanshaw