SlideShare a Scribd company logo
Hi, I’m Rob Hawkes and I’m here today to give an inside look at the development of Rawkets,
my HTML5 and JavaScript multiplayer space shooter.
If you don’t already know, I work at Mozilla.

My official job title is Technical Evangelist, but I prefer Rawket Scientist, which is what it says
on my business card.

Part of my job is to engage with developers like you and me about cool new technologies on
the Web.
Throughout this talk I plan to take a quick journey through some of the issues that plagued
early development of the game, and cover the subsequent solutions that helped resolve
them.
ion
                                                       t
                                                     ta lab
                                                 e n
                                            erim from m    y

                                         Exp       ate
                                                adu
                                                     a gr
                                               is
                                          kets
                                       Raw


Rawkets is a project that originally came out of this experimentation, from a desire to learn
more about WebSockets in regards to multiplayer gaming.

Now, the game is much more mature and I’d consider it as a separate entity aside from the
experiments. It’s something that I plan to develop and support way beyond the original scope
of learning WebSockets.
ts ?
                                                       ke
                                                     aw ckets
                                                 is R      Ro
                                      at             ts,
                                                         d
                                                         an
                                    Wh           ocke
                                               bS
                                          s, We
                                        ke
                                     Raw



Rawkets stands for Rawkes (a merging of my names), as well as WebSockets, and Rockets.
Rawkets is a multiplayer space game that allows you to shoot your friends in the face with
HTML5 technologies.

It’s still not really at a beta release level yet, hence the bugs you might notice in this video.

http://rawkets.com
By now you’ve probably realised that the graphics at the beginning of this talk and on the
posters aren’t the real game graphics.

They are actually an awesome “artists impression” illustration that I commissioned a guy
called Reid Southen to create.

Perhaps when WebGL gets better it will become a reality. Who knows.
It looks pretty awesome as a 6ft banner. So awesome in fact that my girlfriend actually asked
me if I was going to put it up in our flat our not. She seemed pretty down about me saying no
(it smells pretty horrible).

This is a photo of me in front of the banner at my university end-of-year show. If you think it
looks small then let me put it into perspective by telling you that it’s about 8ft away.
es
                                                                 u
                                                               ss ge
                                                              I     n lle
                                                                    ha
                                                                  ac
                                                          be
                                                       an
                                                    esc
                                                 gam
                                         aking
                                        M


It’s not all plain sailing when making a game using HTML5 and JavaScript.

I’m going to cover a few of the main issues that tripped me up during the development of
Rawkets.
io  n
                                                     a t
                                              n  im ontrol
                                          g a         r in
                                                           c

                                    akin          ow
                                                    se
                                  we         he
                                                br
                                 T    uttin
                                           gt
                                            P



One of the simplest fixes is to stop using setTimeout or setInterval and to use
requestAnimationFrame instead.

If you use setTimeout or setInterval and don’t manage it then you put a huge amount of
stress on the CPU and continue that stress even if you switch tabs or minimise the browser.

By using requestAnimationFrame you give the browser control over when a new animation
loop should occur, reducing load on the CPU and saving battery life on mobile devices.

requestAnimationFrame also automatically limits the number of updates if you switch to
another tab or minimise the browser, again saving resources and keeping your players happy.

Right now you can’t easily set a specific framerate when using requestAnimationFrame but so
long as you use time-based updates (not frame-based) in your game then you’ll be fine.
in g
                                                       o  rk
                                                    etw          ug
                                                                   ht
                                                   N         Itho
                                                        y as
                                                        as
                                                      se
                                                    ta
                                                  No




Issues with networking have plagued development of the game right from the beginning.

This probably stems from my lack of prior experience with socket connection and multiplayer
gaming in general.

In the original prototype of the game the network communication was woefully simple and
everything was transmitted in a verbose format with no further thought.

In hindsight it’s obvious why I was experiencing massive performance issues with the
network communication. I was basically sending way too much data back and forth.
col
                                                            to n
                                                          ro atio
                                            e            p
                                         sag        mun
                                                       ic

                                       es       tcom
                                      M      hor
                                                ds
                                              an
                                         ured
                                       ct
                                   Stru


One of the ways that I solved these problems was by implementing a structured protocol for
the messages that are being sent and received.

This included assigning each message type a number and using enumeration to represent
those types in the code.
Enumeration

     types = {
        PING: 1,
        SYNC: 2,
        SYNC_COMPLETED: 3,
        NEW_PLAYER: 4,
        UPDATE_PLAYER: 5,
        UPDATE_INPUT: 6,
        REMOVE_PLAYER: 7
     };

By enumerating the messages types like this I was able to refer to them in a verbose format
within the code, but benefit from only sending the one or two digit number when
transmitting a message.

This is only possible if both the client and server follow the same protocol in regards to which
number refers to which message type.

It’s a simple but effective solution and allowed me to cut a large number of characters from
transmitted messages.
Message package



         MSG_ID        PLAYER_ID                 TIMESTAMP                X       Y

            1 | 1234567890 | 1316763202872 | 5 | 34




Put together with the message types, a full message package is put together as a simple
string representation of a JavaScript object.

All the other pieces of data are attached to the object with a key that is as short as possible.

The MSG_ID that you can see above is a reserved key that is used solely for the message type.

The other items in this example are the player id, timestamp, and the player position.
io n
                                                          s
                                                      es ible
                                                    pr         ss
                                                  om         po
                                                 C    uch
                                                          as
                                                    asm
                                                ata
                                              gd
                                           cin
                                         du
                                       Re


Data in WebSockets is normally transmitted as verbose plain text, so it’s important to cut
down and compress it as much as possible.

Some of the ways that I’ve done this include rounding numerical values, reducing the length
of words if they’re only used for reference, and generally removing any data that isn’t
necessary.
ge  s
                                                        essa ion
                                                       m      icat
                                           ary           mun

                                        Bin       ste
                                                     rcom
                                              , fa
                                                er
                                              rt
                                           sho
                                        en
                                      Ev


I never got around to implementing this but there is now binary message support in
WebSockets.

By switching to binary you can reduce the size of your messages by a noticeable amount
while also increasing the amount of data that you can transmit at a single point in time.

http://hobbycoding.posterous.com/websockt-binary-data-transfer-benchmark-rsult
http://hobbycoding.posterous.com/the-fastest-websocket-module-for-nodejs
in  g
                                                          it
                                                     lim ation
                                                 ate        un
                                                              ic
                                                R      om
                                                         m
                                                       c
                                                  n on
                                                ow
                                              gd
                                         uttin
                                        C



Aside from the message protocol, one of the biggest issues with networking has been dealing
with the sheer number of messages being sent back and forth during the lifetime of a game.
MESSAGES IN                                                  MESSAGES OUT



            1                                                            1
                                          1   1




Having only one player in the game is easy, you have one message coming in to the server,
saying the player has moved, for example, and one message coming back out, updating the
player with details from the server.
MESSAGES IN                                                    MESSAGES OUT



             2                                                              4
                                           1    2




                                            2   1




So say we now have two players, there is still only 1 message in from each player, but now
each player receives 2 messages back from the server; one for them, and one for the other
player.

This isn’t too bad, but notice how the server is having to send 4 messages – 2 for each
player.
MESSAGES IN                                                    MESSAGES OUT



             4                                                           16
                                             1    4

                                       4                1

                                       1                4

                                             4    1




4 players now, look how the server is having to send 16 messages, yet it only receives 4.

If you haven’t already noticed, the messages out from the server are the square of the
number of players.

But 16 messages out is alright, it’s hardly going to tax the server.
MESSAGES IN                                               MESSAGES OUT



           30                                                      900
                                           1    30

                                     30               1

                                     1                30

                                          30    1




So imagine if we now move into properly multiplayer territory.

30 players in the game would mean 30 messages coming in to the server, and 900 – NINE
HUNDRED – messages going out, every update. That’s a silly amount of data for just 30
people.

But let’s go further still…
MESSAGES IN                                                    MESSAGES OUT



        100                                                        10000
                                            1   100

                                    100                1

                                     1                100

                                          100   1




Say we go massively multiplayer and have 100 players in the game at one time.

It’s not so bad for each individual player, they send one message in and get 100 back – that’s
bearable.

But check out the server, it’s getting 100 messages in and is having to send out 10,000 back,
every update. That’s just a mentally stupid number that’s going to cause a lot of grief.
nce
                                                         lige es
                                                      tel essag
                                                    In se m
                                                         iti
                                                    prior
                                                  e
                                                am
                                            theg
                                      tting
                                    Le


Fortunately there is a way around this that cuts down the amount of messages sent; you just
need to send data only for players visible to another player, in essence filtering out game
data that doesn't affect the current player.

Another trick I used is to only send updates when a player is active and moving. If they
haven’t moved since the last frame and nothing else has changed then why bother sending
an update and wasting bandwidth?

These are such simple solutions, but ones that I never even considered at first.
TC P
                                                    ing
                                                ect        lw
                                                             ith
                                                                 it

                                             esp       .D
                                                         ea
                                            R    sesT
                                                     CP

                                               etsu
                                             ck
                                           So
                                        Web



Something else that I discovered is important to be aware of when making a game with
WebSockets is that you’re using TCP.

This is a problem as such, but it means that you need to play by a certain set of rules, and to
expect a certain set of issues.

By the way, I should point out that that you could argue that the icon that I’ve used could
represent WebSockets, but that’s not why I used it. It’s the US plug symbol and I just thought
it was funny because it looks like a surprised face. The UK plug symbol is boring in
comparison.
e r
                                                         ord
                                                  th   e       ou
                                                                  t it
                                               ey            ab
                                             Ob        om
                                                         uch
                                                   ’t d
                                                     can
                                                 You




One issue with TCP is that packets will come through in order and get queued up if there are
any significant connection issues.

This can be a problem with a real-time game as it can cause hang-ups in the transmission
and subsequently a hang-up in the graphic display.

In short, the ordering issue can result in jumpy gameplay. Not fun.

With UDP this wouldn’t be so much of a problem, but we don’t have that luxury yet. Although
similar protocols are in the pipeline and may make their way into our lives relatively soon,
things like Media Streaming APIs and WebRTC.
ters
                                                             ea
                                                           Ch      urse
                                                                 ac
                                                                    and
                                                              ssing
                                                           ble
                                                       A




There’s no denying it, your code is going to be visible to anyone who wants to look at the
source.

I experienced this early on in the development of the game with players adding in their own
features, like invincibility, epic speed, rapid-fire, and even creating completely new weapons
like cluster bombs!

Now don’t get me wrong, I actually appreciate the cheaters because they highlighted all the
errors of my ways, for free. One of the benefits of the open nature of JavaScript is that it can
be looked at and poked very easily by others, which means that I can fix bugs quicker than if
I was testing on my own.
a d
                                                          b
                                                     a re pen
                                                 als       ide
                                                               o
                                              lob        ew
                                             G       pc
                                                       od
                                                         ee
                                                     ’t k
                                                  Don




There are two reasons why cheating was so prevalent and so easy to do.

The first is that by keeping all the game code in the global namespace and not using
anything like closures I was practically inviting people to come in and edit the game code. It
was too easy to do!

It was so easy in fact that after a few hours of releasing the first prototype, players were
already sharing code snippets that others could paste into their browser console to get new
features. Annoying, but actually pretty cool.
rity
                                                            o
                                                        th hing
                                                    a u
                                                 nt          oo
                                                                dt
                                             Clie       ys
                                                           ag
                                                       a
                                                    alw
                                                     ’t
                                                  isn
                                               er
                                            Pow



I’m not going to lie, the first version of Rawkets was way too trusting.

I used what is referred to as the authoritative client model, which basically means that the
client, the player, made all the decisions regarding its position and then sent those positions
to the server.

The server than trusted those positions and transmitted them to all the other players, which
is fine until the client edits their position and increments it by 100 pixel per frame, rather
than 5. Bad times.

This can be referred to as the “Here I am” approach.
ri ty
                                                       o
                                                     th wer
                                                 a  u
                                               r
                                             ve ish th   at
                                                            po
                                           er
                                          S     elinqu
                                                      R




The solution is to make the server authoritative, which means that you prevent manipulation
of the client’s code from doing any damage.

All the movement logic is now performed on the server, meaning that when a client moves it
simply lets the server know which direction it wants to move. From there the server calculates
the new position and sends it back to the client.

This can be referred to as the “Where am I?” approach, and if done right it can completely
remove the ability to cheat.
Inherent latency


                           40ms                           40ms
         Client                         Server                            Client
           +0                            +40                               +80


                    80ms total round-trip

However, the problem with the authoritative server model is that there is some inherent
latency within the system.

What I mean by this is that it obviously takes some time for a movement to be sent from the
client to the server, then for the server to move the client, and then for the server to send the
new position back again.

In the example here imagine that there is a 40ms latency between the client and server,
which means that a message sent to the server will take a total of 80ms to make the round-
trip.

The problem here is what happens during that 80ms period that you’re waiting for the
updated position? If you do nothing then there’s going to be an 80ms delay between you
pressing the up arrow and your rawket moving forward. Not good.
io n
                                                           dict h
                                                        pre      no
                                                                   ug
                                              nt         ’t e
                                          Clie hority isn
                                                 ut
                                                 vera
                                              Ser




To solve the latency issues with the authoritative server you need to implement some element
of prediction on the client.

What I mean by prediction is an ability for the client to guess, quite accurately, where it
should move the player before the message comes back from the server detailing the new
position.
Instant movement


                          40ms                            40ms
         Client                         Server                          Client
           +0                            +40                             +80


                        Prediction happens here


The prediction happens as soon as the client performs some sort of movement (a key-press,
etc), before the server has received the input.

All the prediction does is run the same physics as the server, based on the new input.

This is exactly as if were using the authoritative client model, apart from one important
difference.
ion
                                                             ct
                                                           re rong
                                                         or
                                                        C     oesw
                                                                 ng
                                                              tio
                                                         redic
                                                        p
                                                 hen
                                                W



Whereas the authoritative client model would be in control, with the authoritative server
model and client prediction, the server is in control.

The whole point of using the authoritative server is because the client can’t be trusted. So it
makes sense that prediction can’t be trusted either.

To get around this you use periodically check the client position against the server and
perform a correction if necessary.

This may sound simple in concept, but it’s one of the hardest aspect of multiplayer gaming to
get right. Simply because it’s obvious when you get it wrong.
ility
                                                              b
                                                            ta ning
                                                           S      un
                                                               er
                                                             am
                                                         theg
                                                    ping
                                                 Kee




Keeping the game running is massively important, especially while it’s in rapid development
and is prone to crashing (through errors of my own I must add).

I needed a way to automatically restart the game server if it crashed or something went
horribly wrong.

I also needed a way to scale the game and keep it running as fast as possible.
Forever

I use a little Node module called Forever. It’s amazing!

https://github.com/nodejitsu/forever
Forever




                       forever start game.js




All I have to do now is make sure the game process quits on a catastrophic error and Forever
will automatically restart it for me.

Using Forever is as simple as installing the module with NPM and then starting your Node
script using the Forever demon. The rest is taken care of for you.
Hook.io

Some of you may also be interested in hook.io, which can help create more stable Node
applications.

The concept is to decouple your application logic by breaking it into individual processes so
that if one process goes down the rest can continue to run and your entire game doesn’t
crash.

You use hook.io through its event system that lets you communicate between these separate
processes, regardless of whether they’re on the same server or not. It’s a pretty cool concept.

https://github.com/hookio/hook.io
Rob Hawkes
             @robhawkes




             Rawkes.com
             Personal website and blog

   RECENT PROJECTS                              MORE COOL STUFF


             Twitter sentiment analysis                   Rawket Scientist
             Delving into your soul                       Technical Evangelist at Mozilla


             Rawkets.com                                  Slides
             HTML5 & WebSockets game                      slideshare.net/robhawkes



Get in touch with me on Twitter: @robhawkes

Follow my blog (Rawkes) to keep up to date with stuff that I’m working on: http://
rawkes.com

I’ve recently worked on a project that analyses sentiment on Twitter: http://rawkes.com/
blog/2011/05/05/people-love-a-good-smooch-on-a-balcony

Rawkets is my multiplayer HTML5 and JavaScript game. Play it, it’s fun: http://rawkets.com

These slides are online at http://slideshare.net/robhawkes

More Related Content

What's hot

Geek Meet - Boot to Gecko: The Future of Mobile?
Geek Meet - Boot to Gecko: The Future of Mobile?Geek Meet - Boot to Gecko: The Future of Mobile?
Geek Meet - Boot to Gecko: The Future of Mobile?
Robin Hawkes
 
Python in education
Python in education Python in education
Python in education
pyconfi
 
MDN Hackday London - Boot to Gecko: The Future of Mobile
MDN Hackday London - Boot to Gecko: The Future of MobileMDN Hackday London - Boot to Gecko: The Future of Mobile
MDN Hackday London - Boot to Gecko: The Future of Mobile
Robin Hawkes
 
PHP Doesn't Suck - Notes
PHP Doesn't Suck - NotesPHP Doesn't Suck - Notes
PHP Doesn't Suck - Notes
John Hobbs
 
Browserscene: Creating demos on the Web
Browserscene: Creating demos on the WebBrowserscene: Creating demos on the Web
Browserscene: Creating demos on the Web
Robin Hawkes
 
Open Business @ DMY Berlin 2011 - MakerLab
Open Business @ DMY Berlin 2011 - MakerLabOpen Business @ DMY Berlin 2011 - MakerLab
Open Business @ DMY Berlin 2011 - MakerLab
Massimo Menichinelli
 

What's hot (6)

Geek Meet - Boot to Gecko: The Future of Mobile?
Geek Meet - Boot to Gecko: The Future of Mobile?Geek Meet - Boot to Gecko: The Future of Mobile?
Geek Meet - Boot to Gecko: The Future of Mobile?
 
Python in education
Python in education Python in education
Python in education
 
MDN Hackday London - Boot to Gecko: The Future of Mobile
MDN Hackday London - Boot to Gecko: The Future of MobileMDN Hackday London - Boot to Gecko: The Future of Mobile
MDN Hackday London - Boot to Gecko: The Future of Mobile
 
PHP Doesn't Suck - Notes
PHP Doesn't Suck - NotesPHP Doesn't Suck - Notes
PHP Doesn't Suck - Notes
 
Browserscene: Creating demos on the Web
Browserscene: Creating demos on the WebBrowserscene: Creating demos on the Web
Browserscene: Creating demos on the Web
 
Open Business @ DMY Berlin 2011 - MakerLab
Open Business @ DMY Berlin 2011 - MakerLabOpen Business @ DMY Berlin 2011 - MakerLab
Open Business @ DMY Berlin 2011 - MakerLab
 

Viewers also liked

Love-stories.net statistic in Meeting#4
Love-stories.net statistic in Meeting#4Love-stories.net statistic in Meeting#4
Love-stories.net statistic in Meeting#4Rawin Windygallery
 
Learning Sessions #5 Pre Incubator - WindSync
Learning Sessions #5 Pre Incubator - WindSyncLearning Sessions #5 Pre Incubator - WindSync
Learning Sessions #5 Pre Incubator - WindSync
jvielman
 
Hw fdb(2)
Hw fdb(2)Hw fdb(2)
Hw fdb(2)
Raisa Anjani
 
Learning sessions #5 pre incubator - aperio
Learning sessions #5 pre incubator - aperioLearning sessions #5 pre incubator - aperio
Learning sessions #5 pre incubator - aperio
jvielman
 
Jurnal gandrung vol2 no1 (e jurnal)
Jurnal gandrung vol2 no1 (e jurnal)Jurnal gandrung vol2 no1 (e jurnal)
Jurnal gandrung vol2 no1 (e jurnal)
Nur Agustinus
 
ZinZin - Para Pengunjung Misterius
ZinZin - Para Pengunjung MisteriusZinZin - Para Pengunjung Misterius
ZinZin - Para Pengunjung Misterius
Nur Agustinus
 
大山里的人(二)
大山里的人(二)大山里的人(二)
大山里的人(二)yangbqada
 
海峽西岸經濟區
海峽西岸經濟區海峽西岸經濟區
海峽西岸經濟區
Toomore
 
Present Maps
Present MapsPresent Maps
Present Maps
Toomore
 
ASJA_O'FLAHAVAN_1May2011
ASJA_O'FLAHAVAN_1May2011ASJA_O'FLAHAVAN_1May2011
ASJA_O'FLAHAVAN_1May2011LeslieOflahavan
 
EA Governance as IT Sustainability
EA Governance as IT SustainabilityEA Governance as IT Sustainability
EA Governance as IT Sustainability
Eric Stephens
 
PHP Underground Session 1: The Basics
PHP Underground Session 1: The BasicsPHP Underground Session 1: The Basics
PHP Underground Session 1: The Basics
Robin Hawkes
 
If you can see it, you can change it
If you can see it, you can change itIf you can see it, you can change it
If you can see it, you can change it
James Smith
 
Laporan Eksperimen Peroketan
Laporan Eksperimen PeroketanLaporan Eksperimen Peroketan
Laporan Eksperimen Peroketan
Nur Agustinus
 
AQA English Unit 1 Section B
AQA English Unit 1 Section BAQA English Unit 1 Section B
AQA English Unit 1 Section B
missbec
 
May 28 2010
May 28 2010May 28 2010
May 28 2010
Jody Watson
 
Hw fdb(2)
Hw fdb(2)Hw fdb(2)
Hw fdb(2)
Raisa Anjani
 
MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...
MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...
MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...
Dov Winer
 
HTML5 Technologies for Game Development - Web Directions Code
HTML5 Technologies for Game Development - Web Directions CodeHTML5 Technologies for Game Development - Web Directions Code
HTML5 Technologies for Game Development - Web Directions Code
Robin Hawkes
 

Viewers also liked (20)

Love-stories.net statistic in Meeting#4
Love-stories.net statistic in Meeting#4Love-stories.net statistic in Meeting#4
Love-stories.net statistic in Meeting#4
 
Learning Sessions #5 Pre Incubator - WindSync
Learning Sessions #5 Pre Incubator - WindSyncLearning Sessions #5 Pre Incubator - WindSync
Learning Sessions #5 Pre Incubator - WindSync
 
Hw fdb(2)
Hw fdb(2)Hw fdb(2)
Hw fdb(2)
 
Learning sessions #5 pre incubator - aperio
Learning sessions #5 pre incubator - aperioLearning sessions #5 pre incubator - aperio
Learning sessions #5 pre incubator - aperio
 
Jurnal gandrung vol2 no1 (e jurnal)
Jurnal gandrung vol2 no1 (e jurnal)Jurnal gandrung vol2 no1 (e jurnal)
Jurnal gandrung vol2 no1 (e jurnal)
 
ZinZin - Para Pengunjung Misterius
ZinZin - Para Pengunjung MisteriusZinZin - Para Pengunjung Misterius
ZinZin - Para Pengunjung Misterius
 
大山里的人(二)
大山里的人(二)大山里的人(二)
大山里的人(二)
 
海峽西岸經濟區
海峽西岸經濟區海峽西岸經濟區
海峽西岸經濟區
 
Present Maps
Present MapsPresent Maps
Present Maps
 
ASJA_O'FLAHAVAN_1May2011
ASJA_O'FLAHAVAN_1May2011ASJA_O'FLAHAVAN_1May2011
ASJA_O'FLAHAVAN_1May2011
 
EA Governance as IT Sustainability
EA Governance as IT SustainabilityEA Governance as IT Sustainability
EA Governance as IT Sustainability
 
Wiraswasta
WiraswastaWiraswasta
Wiraswasta
 
PHP Underground Session 1: The Basics
PHP Underground Session 1: The BasicsPHP Underground Session 1: The Basics
PHP Underground Session 1: The Basics
 
If you can see it, you can change it
If you can see it, you can change itIf you can see it, you can change it
If you can see it, you can change it
 
Laporan Eksperimen Peroketan
Laporan Eksperimen PeroketanLaporan Eksperimen Peroketan
Laporan Eksperimen Peroketan
 
AQA English Unit 1 Section B
AQA English Unit 1 Section BAQA English Unit 1 Section B
AQA English Unit 1 Section B
 
May 28 2010
May 28 2010May 28 2010
May 28 2010
 
Hw fdb(2)
Hw fdb(2)Hw fdb(2)
Hw fdb(2)
 
MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...
MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...
MOSAICA: Semantically Enhanced Multifaceted Collaborative Access to Cultural ...
 
HTML5 Technologies for Game Development - Web Directions Code
HTML5 Technologies for Game Development - Web Directions CodeHTML5 Technologies for Game Development - Web Directions Code
HTML5 Technologies for Game Development - Web Directions Code
 

Similar to MelbJS - Inside Rawkets

WebSockets - Embracing the real-time Web
WebSockets - Embracing the real-time WebWebSockets - Embracing the real-time Web
WebSockets - Embracing the real-time Web
Robin Hawkes
 
MDN Hackday London - Open Web Games with HTML5 & JavaScript
MDN Hackday London - Open Web Games with HTML5 & JavaScriptMDN Hackday London - Open Web Games with HTML5 & JavaScript
MDN Hackday London - Open Web Games with HTML5 & JavaScript
Robin Hawkes
 
Awesome Technology on the Web - Oxygen Accelerator
Awesome Technology on the Web - Oxygen AcceleratorAwesome Technology on the Web - Oxygen Accelerator
Awesome Technology on the Web - Oxygen Accelerator
Robin Hawkes
 
Qualitative Data and UX Design
Qualitative Data and UX DesignQualitative Data and UX Design
Qualitative Data and UX Design
Chris Palmieri
 
The State of HTML5 Games - Fluent JS
The State of HTML5 Games - Fluent JSThe State of HTML5 Games - Fluent JS
The State of HTML5 Games - Fluent JS
Robin Hawkes
 
Sse wumart group5b_2011
Sse wumart group5b_2011Sse wumart group5b_2011
Sse wumart group5b_2011
erikingemansson
 
Open Web Games using HTML5 & JavaScript
Open Web Games using HTML5 & JavaScriptOpen Web Games using HTML5 & JavaScript
Open Web Games using HTML5 & JavaScript
Robin Hawkes
 
Flight of the Agile
Flight of the AgileFlight of the Agile
Flight of the Agile
Agila Sverige
 

Similar to MelbJS - Inside Rawkets (8)

WebSockets - Embracing the real-time Web
WebSockets - Embracing the real-time WebWebSockets - Embracing the real-time Web
WebSockets - Embracing the real-time Web
 
MDN Hackday London - Open Web Games with HTML5 & JavaScript
MDN Hackday London - Open Web Games with HTML5 & JavaScriptMDN Hackday London - Open Web Games with HTML5 & JavaScript
MDN Hackday London - Open Web Games with HTML5 & JavaScript
 
Awesome Technology on the Web - Oxygen Accelerator
Awesome Technology on the Web - Oxygen AcceleratorAwesome Technology on the Web - Oxygen Accelerator
Awesome Technology on the Web - Oxygen Accelerator
 
Qualitative Data and UX Design
Qualitative Data and UX DesignQualitative Data and UX Design
Qualitative Data and UX Design
 
The State of HTML5 Games - Fluent JS
The State of HTML5 Games - Fluent JSThe State of HTML5 Games - Fluent JS
The State of HTML5 Games - Fluent JS
 
Sse wumart group5b_2011
Sse wumart group5b_2011Sse wumart group5b_2011
Sse wumart group5b_2011
 
Open Web Games using HTML5 & JavaScript
Open Web Games using HTML5 & JavaScriptOpen Web Games using HTML5 & JavaScript
Open Web Games using HTML5 & JavaScript
 
Flight of the Agile
Flight of the AgileFlight of the Agile
Flight of the Agile
 

More from Robin Hawkes

ViziCities - Lessons Learnt Visualising Real-world Cities in 3D
ViziCities - Lessons Learnt Visualising Real-world Cities in 3DViziCities - Lessons Learnt Visualising Real-world Cities in 3D
ViziCities - Lessons Learnt Visualising Real-world Cities in 3D
Robin Hawkes
 
Understanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisationUnderstanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisation
Robin Hawkes
 
Calculating building heights using a phone camera
Calculating building heights using a phone cameraCalculating building heights using a phone camera
Calculating building heights using a phone camera
Robin Hawkes
 
WebVisions – ViziCities: Bringing Cities to Life Using Big Data
WebVisions – ViziCities: Bringing Cities to Life Using Big DataWebVisions – ViziCities: Bringing Cities to Life Using Big Data
WebVisions – ViziCities: Bringing Cities to Life Using Big Data
Robin Hawkes
 
Understanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisationUnderstanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisation
Robin Hawkes
 
ViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGL
ViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGLViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGL
ViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGL
Robin Hawkes
 
Beautiful Data Visualisation & D3
Beautiful Data Visualisation & D3Beautiful Data Visualisation & D3
Beautiful Data Visualisation & D3
Robin Hawkes
 
ViziCities: Making SimCity for the Real World
ViziCities: Making SimCity for the Real WorldViziCities: Making SimCity for the Real World
ViziCities: Making SimCity for the Real World
Robin Hawkes
 
The State of WebRTC
The State of WebRTCThe State of WebRTC
The State of WebRTC
Robin Hawkes
 
Bringing Cities to Life Using Big Data & WebGL
Bringing Cities to Life Using Big Data & WebGLBringing Cities to Life Using Big Data & WebGL
Bringing Cities to Life Using Big Data & WebGL
Robin Hawkes
 
Mobile App Development - Pitfalls & Helpers
Mobile App Development - Pitfalls & HelpersMobile App Development - Pitfalls & Helpers
Mobile App Development - Pitfalls & Helpers
Robin Hawkes
 
Boot to Gecko – The Web as a Platform
Boot to Gecko – The Web as a PlatformBoot to Gecko – The Web as a Platform
Boot to Gecko – The Web as a Platform
Robin Hawkes
 
Mozilla Firefox: Present and Future - Fluent JS
Mozilla Firefox: Present and Future - Fluent JSMozilla Firefox: Present and Future - Fluent JS
Mozilla Firefox: Present and Future - Fluent JS
Robin Hawkes
 
Hacking with B2G – Web Apps and Customisation
Hacking with B2G – Web Apps and CustomisationHacking with B2G – Web Apps and Customisation
Hacking with B2G – Web Apps and Customisation
Robin Hawkes
 
HTML5 Games - Not Just for Gamers
HTML5 Games - Not Just for GamersHTML5 Games - Not Just for Gamers
HTML5 Games - Not Just for Gamers
Robin Hawkes
 

More from Robin Hawkes (15)

ViziCities - Lessons Learnt Visualising Real-world Cities in 3D
ViziCities - Lessons Learnt Visualising Real-world Cities in 3DViziCities - Lessons Learnt Visualising Real-world Cities in 3D
ViziCities - Lessons Learnt Visualising Real-world Cities in 3D
 
Understanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisationUnderstanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisation
 
Calculating building heights using a phone camera
Calculating building heights using a phone cameraCalculating building heights using a phone camera
Calculating building heights using a phone camera
 
WebVisions – ViziCities: Bringing Cities to Life Using Big Data
WebVisions – ViziCities: Bringing Cities to Life Using Big DataWebVisions – ViziCities: Bringing Cities to Life Using Big Data
WebVisions – ViziCities: Bringing Cities to Life Using Big Data
 
Understanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisationUnderstanding cities using ViziCities and 3D data visualisation
Understanding cities using ViziCities and 3D data visualisation
 
ViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGL
ViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGLViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGL
ViziCities: Creating Real-World Cities in 3D using OpenStreetMap and WebGL
 
Beautiful Data Visualisation & D3
Beautiful Data Visualisation & D3Beautiful Data Visualisation & D3
Beautiful Data Visualisation & D3
 
ViziCities: Making SimCity for the Real World
ViziCities: Making SimCity for the Real WorldViziCities: Making SimCity for the Real World
ViziCities: Making SimCity for the Real World
 
The State of WebRTC
The State of WebRTCThe State of WebRTC
The State of WebRTC
 
Bringing Cities to Life Using Big Data & WebGL
Bringing Cities to Life Using Big Data & WebGLBringing Cities to Life Using Big Data & WebGL
Bringing Cities to Life Using Big Data & WebGL
 
Mobile App Development - Pitfalls & Helpers
Mobile App Development - Pitfalls & HelpersMobile App Development - Pitfalls & Helpers
Mobile App Development - Pitfalls & Helpers
 
Boot to Gecko – The Web as a Platform
Boot to Gecko – The Web as a PlatformBoot to Gecko – The Web as a Platform
Boot to Gecko – The Web as a Platform
 
Mozilla Firefox: Present and Future - Fluent JS
Mozilla Firefox: Present and Future - Fluent JSMozilla Firefox: Present and Future - Fluent JS
Mozilla Firefox: Present and Future - Fluent JS
 
Hacking with B2G – Web Apps and Customisation
Hacking with B2G – Web Apps and CustomisationHacking with B2G – Web Apps and Customisation
Hacking with B2G – Web Apps and Customisation
 
HTML5 Games - Not Just for Gamers
HTML5 Games - Not Just for GamersHTML5 Games - Not Just for Gamers
HTML5 Games - Not Just for Gamers
 

Recently uploaded

High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024
Vadym Kazulkin
 
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdfMonitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Tosin Akinosho
 
AppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSFAppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSF
Ajin Abraham
 
Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
ssuserfac0301
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving
 
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
Edge AI and Vision Alliance
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving
 
Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
Antonios Katsarakis
 
"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota
Fwdays
 
Mutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented ChatbotsMutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented Chatbots
Pablo Gómez Abajo
 
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
Jason Yip
 
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillinQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
LizaNolte
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
Jason Packer
 
Apps Break Data
Apps Break DataApps Break Data
Apps Break Data
Ivo Velitchkov
 
PRODUCT LISTING OPTIMIZATION PRESENTATION.pptx
PRODUCT LISTING OPTIMIZATION PRESENTATION.pptxPRODUCT LISTING OPTIMIZATION PRESENTATION.pptx
PRODUCT LISTING OPTIMIZATION PRESENTATION.pptx
christinelarrosa
 
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
"Scaling RAG Applications to serve millions of users",  Kevin Goedecke"Scaling RAG Applications to serve millions of users",  Kevin Goedecke
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
Fwdays
 
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin..."$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
Fwdays
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
Zilliz
 
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfHow to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
Chart Kalyan
 
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development ProvidersYour One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
akankshawande
 

Recently uploaded (20)

High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024High performance Serverless Java on AWS- GoTo Amsterdam 2024
High performance Serverless Java on AWS- GoTo Amsterdam 2024
 
Monitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdfMonitoring and Managing Anomaly Detection on OpenShift.pdf
Monitoring and Managing Anomaly Detection on OpenShift.pdf
 
AppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSFAppSec PNW: Android and iOS Application Security with MobSF
AppSec PNW: Android and iOS Application Security with MobSF
 
Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
 
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
 
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
Northern Engraving | Modern Metal Trim, Nameplates and Appliance Panels
 
Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
 
"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota
 
Mutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented ChatbotsMutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented Chatbots
 
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...
 
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillinQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
 
Apps Break Data
Apps Break DataApps Break Data
Apps Break Data
 
PRODUCT LISTING OPTIMIZATION PRESENTATION.pptx
PRODUCT LISTING OPTIMIZATION PRESENTATION.pptxPRODUCT LISTING OPTIMIZATION PRESENTATION.pptx
PRODUCT LISTING OPTIMIZATION PRESENTATION.pptx
 
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
"Scaling RAG Applications to serve millions of users",  Kevin Goedecke"Scaling RAG Applications to serve millions of users",  Kevin Goedecke
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
 
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin..."$10 thousand per minute of downtime: architecture, queues, streaming and fin...
"$10 thousand per minute of downtime: architecture, queues, streaming and fin...
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
 
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfHow to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdf
 
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development ProvidersYour One-Stop Shop for Python Success: Top 10 US Python Development Providers
Your One-Stop Shop for Python Success: Top 10 US Python Development Providers
 

MelbJS - Inside Rawkets

  • 1. Hi, I’m Rob Hawkes and I’m here today to give an inside look at the development of Rawkets, my HTML5 and JavaScript multiplayer space shooter.
  • 2. If you don’t already know, I work at Mozilla. My official job title is Technical Evangelist, but I prefer Rawket Scientist, which is what it says on my business card. Part of my job is to engage with developers like you and me about cool new technologies on the Web.
  • 3. Throughout this talk I plan to take a quick journey through some of the issues that plagued early development of the game, and cover the subsequent solutions that helped resolve them.
  • 4. ion t ta lab e n erim from m y Exp ate adu a gr is kets Raw Rawkets is a project that originally came out of this experimentation, from a desire to learn more about WebSockets in regards to multiplayer gaming. Now, the game is much more mature and I’d consider it as a separate entity aside from the experiments. It’s something that I plan to develop and support way beyond the original scope of learning WebSockets.
  • 5. ts ? ke aw ckets is R Ro at ts, d an Wh ocke bS s, We ke Raw Rawkets stands for Rawkes (a merging of my names), as well as WebSockets, and Rockets.
  • 6. Rawkets is a multiplayer space game that allows you to shoot your friends in the face with HTML5 technologies. It’s still not really at a beta release level yet, hence the bugs you might notice in this video. http://rawkets.com
  • 7. By now you’ve probably realised that the graphics at the beginning of this talk and on the posters aren’t the real game graphics. They are actually an awesome “artists impression” illustration that I commissioned a guy called Reid Southen to create. Perhaps when WebGL gets better it will become a reality. Who knows.
  • 8. It looks pretty awesome as a 6ft banner. So awesome in fact that my girlfriend actually asked me if I was going to put it up in our flat our not. She seemed pretty down about me saying no (it smells pretty horrible). This is a photo of me in front of the banner at my university end-of-year show. If you think it looks small then let me put it into perspective by telling you that it’s about 8ft away.
  • 9. es u ss ge I n lle ha ac be an esc gam aking M It’s not all plain sailing when making a game using HTML5 and JavaScript. I’m going to cover a few of the main issues that tripped me up during the development of Rawkets.
  • 10. io n a t n im ontrol g a r in c akin ow se we he br T uttin gt P One of the simplest fixes is to stop using setTimeout or setInterval and to use requestAnimationFrame instead. If you use setTimeout or setInterval and don’t manage it then you put a huge amount of stress on the CPU and continue that stress even if you switch tabs or minimise the browser. By using requestAnimationFrame you give the browser control over when a new animation loop should occur, reducing load on the CPU and saving battery life on mobile devices. requestAnimationFrame also automatically limits the number of updates if you switch to another tab or minimise the browser, again saving resources and keeping your players happy. Right now you can’t easily set a specific framerate when using requestAnimationFrame but so long as you use time-based updates (not frame-based) in your game then you’ll be fine.
  • 11. in g o rk etw ug ht N Itho y as as se ta No Issues with networking have plagued development of the game right from the beginning. This probably stems from my lack of prior experience with socket connection and multiplayer gaming in general. In the original prototype of the game the network communication was woefully simple and everything was transmitted in a verbose format with no further thought. In hindsight it’s obvious why I was experiencing massive performance issues with the network communication. I was basically sending way too much data back and forth.
  • 12. col to n ro atio e p sag mun ic es tcom M hor ds an ured ct Stru One of the ways that I solved these problems was by implementing a structured protocol for the messages that are being sent and received. This included assigning each message type a number and using enumeration to represent those types in the code.
  • 13. Enumeration types = { PING: 1, SYNC: 2, SYNC_COMPLETED: 3, NEW_PLAYER: 4, UPDATE_PLAYER: 5, UPDATE_INPUT: 6, REMOVE_PLAYER: 7 }; By enumerating the messages types like this I was able to refer to them in a verbose format within the code, but benefit from only sending the one or two digit number when transmitting a message. This is only possible if both the client and server follow the same protocol in regards to which number refers to which message type. It’s a simple but effective solution and allowed me to cut a large number of characters from transmitted messages.
  • 14. Message package MSG_ID PLAYER_ID TIMESTAMP X Y 1 | 1234567890 | 1316763202872 | 5 | 34 Put together with the message types, a full message package is put together as a simple string representation of a JavaScript object. All the other pieces of data are attached to the object with a key that is as short as possible. The MSG_ID that you can see above is a reserved key that is used solely for the message type. The other items in this example are the player id, timestamp, and the player position.
  • 15. io n s es ible pr ss om po C uch as asm ata gd cin du Re Data in WebSockets is normally transmitted as verbose plain text, so it’s important to cut down and compress it as much as possible. Some of the ways that I’ve done this include rounding numerical values, reducing the length of words if they’re only used for reference, and generally removing any data that isn’t necessary.
  • 16. ge s essa ion m icat ary mun Bin ste rcom , fa er rt sho en Ev I never got around to implementing this but there is now binary message support in WebSockets. By switching to binary you can reduce the size of your messages by a noticeable amount while also increasing the amount of data that you can transmit at a single point in time. http://hobbycoding.posterous.com/websockt-binary-data-transfer-benchmark-rsult http://hobbycoding.posterous.com/the-fastest-websocket-module-for-nodejs
  • 17. in g it lim ation ate un ic R om m c n on ow gd uttin C Aside from the message protocol, one of the biggest issues with networking has been dealing with the sheer number of messages being sent back and forth during the lifetime of a game.
  • 18. MESSAGES IN MESSAGES OUT 1 1 1 1 Having only one player in the game is easy, you have one message coming in to the server, saying the player has moved, for example, and one message coming back out, updating the player with details from the server.
  • 19. MESSAGES IN MESSAGES OUT 2 4 1 2 2 1 So say we now have two players, there is still only 1 message in from each player, but now each player receives 2 messages back from the server; one for them, and one for the other player. This isn’t too bad, but notice how the server is having to send 4 messages – 2 for each player.
  • 20. MESSAGES IN MESSAGES OUT 4 16 1 4 4 1 1 4 4 1 4 players now, look how the server is having to send 16 messages, yet it only receives 4. If you haven’t already noticed, the messages out from the server are the square of the number of players. But 16 messages out is alright, it’s hardly going to tax the server.
  • 21. MESSAGES IN MESSAGES OUT 30 900 1 30 30 1 1 30 30 1 So imagine if we now move into properly multiplayer territory. 30 players in the game would mean 30 messages coming in to the server, and 900 – NINE HUNDRED – messages going out, every update. That’s a silly amount of data for just 30 people. But let’s go further still…
  • 22. MESSAGES IN MESSAGES OUT 100 10000 1 100 100 1 1 100 100 1 Say we go massively multiplayer and have 100 players in the game at one time. It’s not so bad for each individual player, they send one message in and get 100 back – that’s bearable. But check out the server, it’s getting 100 messages in and is having to send out 10,000 back, every update. That’s just a mentally stupid number that’s going to cause a lot of grief.
  • 23. nce lige es tel essag In se m iti prior e am theg tting Le Fortunately there is a way around this that cuts down the amount of messages sent; you just need to send data only for players visible to another player, in essence filtering out game data that doesn't affect the current player. Another trick I used is to only send updates when a player is active and moving. If they haven’t moved since the last frame and nothing else has changed then why bother sending an update and wasting bandwidth? These are such simple solutions, but ones that I never even considered at first.
  • 24. TC P ing ect lw ith it esp .D ea R sesT CP etsu ck So Web Something else that I discovered is important to be aware of when making a game with WebSockets is that you’re using TCP. This is a problem as such, but it means that you need to play by a certain set of rules, and to expect a certain set of issues. By the way, I should point out that that you could argue that the icon that I’ve used could represent WebSockets, but that’s not why I used it. It’s the US plug symbol and I just thought it was funny because it looks like a surprised face. The UK plug symbol is boring in comparison.
  • 25. e r ord th e ou t it ey ab Ob om uch ’t d can You One issue with TCP is that packets will come through in order and get queued up if there are any significant connection issues. This can be a problem with a real-time game as it can cause hang-ups in the transmission and subsequently a hang-up in the graphic display. In short, the ordering issue can result in jumpy gameplay. Not fun. With UDP this wouldn’t be so much of a problem, but we don’t have that luxury yet. Although similar protocols are in the pipeline and may make their way into our lives relatively soon, things like Media Streaming APIs and WebRTC.
  • 26. ters ea Ch urse ac and ssing ble A There’s no denying it, your code is going to be visible to anyone who wants to look at the source. I experienced this early on in the development of the game with players adding in their own features, like invincibility, epic speed, rapid-fire, and even creating completely new weapons like cluster bombs! Now don’t get me wrong, I actually appreciate the cheaters because they highlighted all the errors of my ways, for free. One of the benefits of the open nature of JavaScript is that it can be looked at and poked very easily by others, which means that I can fix bugs quicker than if I was testing on my own.
  • 27. a d b a re pen als ide o lob ew G pc od ee ’t k Don There are two reasons why cheating was so prevalent and so easy to do. The first is that by keeping all the game code in the global namespace and not using anything like closures I was practically inviting people to come in and edit the game code. It was too easy to do! It was so easy in fact that after a few hours of releasing the first prototype, players were already sharing code snippets that others could paste into their browser console to get new features. Annoying, but actually pretty cool.
  • 28. rity o th hing a u nt oo dt Clie ys ag a alw ’t isn er Pow I’m not going to lie, the first version of Rawkets was way too trusting. I used what is referred to as the authoritative client model, which basically means that the client, the player, made all the decisions regarding its position and then sent those positions to the server. The server than trusted those positions and transmitted them to all the other players, which is fine until the client edits their position and increments it by 100 pixel per frame, rather than 5. Bad times. This can be referred to as the “Here I am” approach.
  • 29. ri ty o th wer a u r ve ish th at po er S elinqu R The solution is to make the server authoritative, which means that you prevent manipulation of the client’s code from doing any damage. All the movement logic is now performed on the server, meaning that when a client moves it simply lets the server know which direction it wants to move. From there the server calculates the new position and sends it back to the client. This can be referred to as the “Where am I?” approach, and if done right it can completely remove the ability to cheat.
  • 30. Inherent latency 40ms 40ms Client Server Client +0 +40 +80 80ms total round-trip However, the problem with the authoritative server model is that there is some inherent latency within the system. What I mean by this is that it obviously takes some time for a movement to be sent from the client to the server, then for the server to move the client, and then for the server to send the new position back again. In the example here imagine that there is a 40ms latency between the client and server, which means that a message sent to the server will take a total of 80ms to make the round- trip. The problem here is what happens during that 80ms period that you’re waiting for the updated position? If you do nothing then there’s going to be an 80ms delay between you pressing the up arrow and your rawket moving forward. Not good.
  • 31. io n dict h pre no ug nt ’t e Clie hority isn ut vera Ser To solve the latency issues with the authoritative server you need to implement some element of prediction on the client. What I mean by prediction is an ability for the client to guess, quite accurately, where it should move the player before the message comes back from the server detailing the new position.
  • 32. Instant movement 40ms 40ms Client Server Client +0 +40 +80 Prediction happens here The prediction happens as soon as the client performs some sort of movement (a key-press, etc), before the server has received the input. All the prediction does is run the same physics as the server, based on the new input. This is exactly as if were using the authoritative client model, apart from one important difference.
  • 33. ion ct re rong or C oesw ng tio redic p hen W Whereas the authoritative client model would be in control, with the authoritative server model and client prediction, the server is in control. The whole point of using the authoritative server is because the client can’t be trusted. So it makes sense that prediction can’t be trusted either. To get around this you use periodically check the client position against the server and perform a correction if necessary. This may sound simple in concept, but it’s one of the hardest aspect of multiplayer gaming to get right. Simply because it’s obvious when you get it wrong.
  • 34. ility b ta ning S un er am theg ping Kee Keeping the game running is massively important, especially while it’s in rapid development and is prone to crashing (through errors of my own I must add). I needed a way to automatically restart the game server if it crashed or something went horribly wrong. I also needed a way to scale the game and keep it running as fast as possible.
  • 35. Forever I use a little Node module called Forever. It’s amazing! https://github.com/nodejitsu/forever
  • 36. Forever forever start game.js All I have to do now is make sure the game process quits on a catastrophic error and Forever will automatically restart it for me. Using Forever is as simple as installing the module with NPM and then starting your Node script using the Forever demon. The rest is taken care of for you.
  • 37. Hook.io Some of you may also be interested in hook.io, which can help create more stable Node applications. The concept is to decouple your application logic by breaking it into individual processes so that if one process goes down the rest can continue to run and your entire game doesn’t crash. You use hook.io through its event system that lets you communicate between these separate processes, regardless of whether they’re on the same server or not. It’s a pretty cool concept. https://github.com/hookio/hook.io
  • 38. Rob Hawkes @robhawkes Rawkes.com Personal website and blog RECENT PROJECTS MORE COOL STUFF Twitter sentiment analysis Rawket Scientist Delving into your soul Technical Evangelist at Mozilla Rawkets.com Slides HTML5 & WebSockets game slideshare.net/robhawkes Get in touch with me on Twitter: @robhawkes Follow my blog (Rawkes) to keep up to date with stuff that I’m working on: http:// rawkes.com I’ve recently worked on a project that analyses sentiment on Twitter: http://rawkes.com/ blog/2011/05/05/people-love-a-good-smooch-on-a-balcony Rawkets is my multiplayer HTML5 and JavaScript game. Play it, it’s fun: http://rawkets.com These slides are online at http://slideshare.net/robhawkes