Slides for Meat Fighter 2 Turbo talk - Meteor London December 2014

mf2t.md

Alan Shaw
@_alanshaw
tableflip.io

---

An experiment with meteor and websockets.

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

---

Demo

SSID: xxx
Open: http://10.0.0.11:1337

---

Make with socket.io

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

• Your browser emits player state (position, hit, life)
• Your browser listens for other player state updates
• Server relays the info

---

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 collcetions

---

Demo SSID: xxx
Open: http://10.0.0.11: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