Inside Rawkets - onGameStart

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 sayson my business card.Part of my job is to engage with developers like you and me about cool new technologies onthe Web.

Created by Phil Banks (@emirpprime)Aside from that I spend most of my time experimenting with HTML5 and other cooltechnologies.I basically have an addiction to visual programming and hacking around with code.It’s fun!

Throughout this talk I plan to take a journey through some of the issues that plagued earlydevelopment of the game, and cover the subsequent solutions that helped resolve them.There’ll be some code, but I’m more interested in highlighting the concepts and theoriesinvolved.So far the talks have all been awesome and have often gone into some great detail aboutparticular technologies and techniques. This talk will be quite light-hearted in comparisonand more of an overview of technologies and techniques, so hopefully I’ll be able to postponethat feeling of death-by-awesomeness for a little while longer.However, if you have any questions with what I talk about then feel free to grab me after thetalk either in person or online. I’ll be putting my contact details up at the end and the slideswill be put online at my blog, which I’ll also mention at the end.

ion t ta lab e n erim from m y Exp ate adu a gr is kets RawRawkets is a project that originally came out of this experimentation, from a desire to learnmore 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 theexperiments. It’s something that I plan to develop and support way beyond the original scopeof learning WebSockets.

ts ? ke aw ckets is R Ro at ts, d an Wh ocke bS s, We ke RawRawkets stands for Rawkes (my blog), WebSockets, and Rockets.

Rawkets is a multiplayer space game that allows you to shoot your friends in the face withHTML5 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 theposters aren’t the real game graphics.They are actually an awesome “artists impression” illustration that I commissioned a guycalled 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 askedme if I was going to put it up in our ﬂat 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 itlooks small then let me put it into perspective by telling you that it’s about 8ft away.

g y o lo chn ing Te ebg am W in ed olv inv tech fthe eo SomThere are a few key technologies that are involved in the development of the game.All of them bar one are tightly related to HTML or JavaScript.

vas an C tfo rm pla ics raph g 2DCanvas for 2D graphics.

d io a u sh sic Fla nd m u rou ackg db an cts effe nd SouFlash audio for game sound effects and background music.I’ll explain why I use Flash over HTML5 Audio further on in the talk.

e ts ock bS ation e W omm un ic yerc ltipla MuWebSockets is used for the communication between each player and the game server.For anyone not up to speed with WebSockets, you effectively use HTTP to upgrade aconnection and access fully bi-directional streaming communication.

e.js od N cation uni m com rk etwo dn an logic e GamNode is used as the game server, controlling the logic and handling the WebSocketsconnections to the players.It will eventually be used for player authentication and the storage of data so gameplay canpersist over multiple game sessions.This is all made relatively easy with great third-party modules, like Socket.IO for WebSockets,and others that handle Redis and MongoDB for storage, for example.http://nodejs.org

es u ss ge I n lle ha ac be an esc gam aking MIt’s not all plain sailing when making a gaming using HTML5 and JavaScript.I’m going to cover a few of the main issues that tripped me up during the development ofRawkets.

in g o rk etw ug ht N Itho y as as se ta NoIssues 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 multiplayergaming in general.In the original prototype of the game the network communication was woefully simple andeverything was transmitted in a verbose format with no further thought.In hindsight it’s obvious why I was experiencing massive performance issues with thenetwork 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 StruOne of the ways that I solved these problems was by implementing a structured protocol forthe messages that are being sent and received.This included assigning each message type a number and using enumeration to representthose 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 formatwithin the code, but beneﬁt from only sending the one or two digit number whentransmitting a message.This is only possible if both the client and server follow the same protocol in regards to whichnumber refers to which message type.It’s a simple but effective solution and allowed me to cut a large number of characters fromtransmitted messages.

Message package { z: 1, id: 1234567890, t: 1316763202872, s: { x: 5, y: 34, v: 3, a: 0.46 } }Put together with the message types, a full message package is put together as a JSONrepresentation 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 z key that you can see above is a reserved key that is used solely for the message type.The other keys in this example are a timestamp, the player id, and the player state.

io n s es ible pr ss om po C uch as asm ata gd cin du ReData in WebSockets is transmitted as verbose plain text, so it’s important to cut down andcompress it as much as possible.Some of the ways that I’ve done this include rounding numerical values, reducing the lengthof words if they’re only used for reference, and generally removing any data that isn’tnecessary.There is also BISON, which is a binary representation of JSON that can cut down the amountof data sent back and forth even further, but I’ve heard conﬂicting reports about itsperformance so your mileage may vary.http://kaijaeger.com/articles/introducing-bison-binary-interchange-standard.html

in g it lim ation ate un ic R om m c n on ow gd uttin CAside from the message protocol, one of the biggest issues with networking has been dealingwith the sheer number of messages being sent back and forth during the lifetime of a game.

MESSAGES IN MESSAGES OUT 1 1 1 1Having 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 theplayer with details from the server.

MESSAGES IN MESSAGES OUT 2 4 1 2 2 1So say we now have two players, there is still only 1 message in from each player, but noweach player receives 2 messages back from the server; one for them, and one for the otherplayer.This isn’t too bad, but notice how the server is having to send 4 messages – 2 for eachplayer.

MESSAGES IN MESSAGES OUT 4 16 1 4 4 1 1 4 4 14 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 thenumber 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 1So 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 – NINEHUNDRED – messages going out, every update. That’s a silly amount of data for just 30people.But let’s go further still…

MESSAGES IN MESSAGES OUT 100 10000 1 100 100 1 1 100 100 1Say 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’sbearable.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 LeFortunately there is a way around this that cuts down the amount of messages sent; you justneed to send data only for players visible to another player, in essence ﬁltering out gamedata that doesnt affect the current player.Another trick I used is to only send updates when a player is active and moving. If theyhaven’t moved since the last frame and nothing else has changed then why bother sendingan update and wasting bandwidth?These are such simple solutions, but ones that I never even considered at ﬁrst.

TC P ing ect lw ith it esp .D ea R sesT CP etsu ck So WebSomething else that I discovered is important to be aware of when making a game withWebSockets 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 toexpect a certain set of issues.By the way, I should point out that that you could argue that the icon that I’ve used couldrepresent WebSockets, but that’s not why I used it. It’s the US plug symbol and I just thoughtit was funny because it looks like a surprised face. The UK plug symbol is boring incomparison.

e r ord th e ou t it ey ab Ob om uch ’t d can YouOne issue with TCP is that packets will come through in order and get queued up if there areany signiﬁcant connection issues.This can be a problem with a real-time game as it can cause hang-ups in the transmissionand 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. Althoughsimilar protocols are in the pipeline and may make their way into our lives relatively soon,things like Media Streaming APIs and WebRTC.

t.IO e ck ages So se ess U drop sm tly en tellig It inI use Socket.IO for all the WebSockets communication for Rawkets simply because it’s easy touse and it has Flash fallback for browsers that don’t support the technology yet.The cool thing about the latest version of Socket.IO is that is has introduced the concept ofvolatile messages.These volatile messages are completely voluntary, and messages sent with them arentactually sent if the client is having network problems, saving bandwidth for other moreimportant messages.It’s not an ideal solution, but it’ll certainly help alleviate some of the issues that come withTCP.

ters ea Ch urse ac and ssing ble AThere’s no denying it, your code is going to be visible to anyone who wants to look at thesource.I experienced this early on in the development of the game with players adding in their ownfeatures, like invincibility, epic speed, rapid-fire, and even creating completely new weaponslike cluster bombs!Now don’t get me wrong, I actually appreciate the cheaters because they highlighted all theerrors of my ways, for free. One of the benefits of the open nature of JavaScript is that it canbe looked at and poked very easily by others, which means that I can fix bugs quicker than ifI was testing on my own.

re s su ad lo is b d c an op en als wide b lo ping code G ee KThere are two reasons why cheating was so prevalent and so easy to do.The ﬁrst is that by keeping all the game code in the global namespace and not using anyclosures, I was practically inviting people to come in and edit the game code. It was too easyto do!It was so easy in fact that after a few hours of releasing the ﬁrst prototype, players werealready sharing code snippets that others could paste into their browser console to get newfeatures. Annoying, but actually pretty cool.

rity o th hing a u nt oo dt Clie ys ag a alw ’t isn er PowI’m not going to lie, the ﬁrst version of Rawkets was way too trusting.I used what is referred to as the authoritative client model, which basically means that theclient, the player, made all the decisions regarding its position and then sent those positionsto the server.The server than trusted those positions and transmitted them to all the other players, whichis ﬁne until the client edits their position and increments it by 100 pixel per frame, ratherthan 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 RThe solution is to make the server authoritative, which means that you prevent manipulationof the client’s code from doing any damage.All the movement logic is now performed on the server, meaning that when a client moves itsimply lets the server know which direction it wants to move. From there the server calculatesthe 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 completelyremove the ability to cheat.

Inherent latency 40ms 40ms Input Move Update +0 +40 +80 80ms total round-tripHowever, the problem with the authoritative server model is that there is some inherentlatency within the system.What I mean by this is that it obviously takes some time for a movement to be sent from theclient to the server, then for the server to move the client, and then for the server to send thenew 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 theupdated position? If you do nothing then there’s going to be an 80ms delay between youpressing 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 SerTo solve the latency issues with the authoritative server you need to implement some elementof prediction on the client.What I mean by prediction is an ability for the client to guess, quite accurately, where itshould move the player before the message comes back from the server detailing the newposition.

Instant movement 40ms 40ms Input Move Update +0 +40 +80 Prediction happens hereThe 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 importantdifference.

ion ct re rong or C oesw ng tio redic p hen WWhereas the authoritative client model would be in control, with the authoritative servermodel 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 itmakes sense that prediction can’t be trusted either.To get around this you use periodically check the client position against the server andperform a correction if necessary.This may sound simple in concept, but it’s one of the hardest aspect of multiplayer gaming toget right. Simply because it’s obvious when you get it wrong.

ility b ta ning S un er am theg ping KeeKeeping the game running is massively important, especially while it’s in rapid developmentand 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 wenthorribly wrong.

mmonit.com/monitTo do that I originally went with Monit scripts that monitor the WebSockets port for activity.If the port is inactive for 3 separate checks in a row then the game is automatically restartedin Node.Ideally the game shouldnt crash, but this has proven to be a great solution that allows me tocontinue rapidly developing the game without worrying about it going down permanently ifIm not around.http://mmonit.com/monit/

Monit script check host rawkets.com with address 127.0.0.1 start program = "/etc/init.d/rawkets start" stop program = "/etc/init.d/rawkets stop" if failed port 8000 type tcp for 2 times within 3 cycles then restartJust as a quick example, here is the entire monit script for keeping the game up and running.I’d say four lines of code was pretty impressive!This effectively checks port 8000 on rawkets.com for an active tcp connection every cycle (60seconds), and will only restart the game if there is a problem for at least 2 cycles.The time between cycles can be changed in the monit conﬁguration ﬁles.

Init.d script #!/bin/sh case "$1" in start) cd /rawkets /usr/local/bin/node rawkets.js 2>&1 >> /var/log/node.log & exit 1 ;; stop) /usr/bin/pkill -f node rawkets.js exit 1 ;; esac exit 1This is the init.d script that I use to start and stop the game server from the command line.All it does is binds a particular set of shell commands to “start” and “stop” keywords, which Iuse to start and stop the Node process for the game.I’m not massively experienced with init.d scripts so I’m sure that it can probably beoptimised, but it works perfectly for my needs and is pretty damn cool.

github.com/indexzero/foreverNow I use a little Node module called Forever. It’s amazing!https://github.com/indexzero/forever

Forever forever start rawkets.jsAll I have to do now is make sure the game process quits on a catastrophic error and Foreverwill automatically restart it for me.Using Forever is as simple as installing the module with NPM and then starting your Nodescript using the Forever demon. The rest is taken care of for you.

github.com/hookio/hook.ioSome of you may also be interested in hook.io, which can help create more stable Nodeapplications.The concept is to decouple your application logic by breaking it into individual processes sothat if one process goes down the rest can continue to run and your entire game doesn’tcrash.You use hook.io through its event system that lets you communicate between these separateprocesses, regardless of whether they’re on the same server or not. It’s a pretty cool concept.https://github.com/hookio/hook.io

io ? u d h a et la s ad yy y F ite re Wh isn’t qu dio Au L5 HTMSo why in a proud HTML5 and JavaScript game have I resorted to Flash?To put it bluntly, HTML5 Audio support is severely lacking in areas for the needs of gamedevelopment.One particular example is support for looping, which is severely lacking and inconsistentacross most browsers.Opera has the best implementation so far, but the rest all have some kind of pause betweenloops, which makes short and constantly looping audio very obvious and annoying.There are some solutions, like using JavaScript to try and loop the audio just before it isﬁnished, or using the audio data APIs in Firefox and Chrome, but none are ideal so I wentwith Flash audio for now until it gets ﬁxed.

o re s m ot ad al Lo hy ou eac est am L5g HTMThere’s loads of stuff that I couldn’t ﬁt in that I’d love to have talked about.Things like:- Canvas optimisation.- Using internal events to decouple game logic.- Using the same code for client and server.- setTimeout vs. requestAnimationFrame.- How to handle storage.- Control systems for different platforms, like Seb Lee-Delisle’s approach.

tu re e fu ng Th tg am i ip cr aS in Jav ee os liket I’d hat WThere are a few things that I’d like to see in the near future to help with game development.Need a way to benchmark browsers, connections and operating systems.- Like Google Analytics, but for game performance and feature detection.- Measuring FPS.- Measuring network performance.Better HTML5 audio.Hardware accelerated canvas on Mac and mobile devices.Better documentation for game development in JavaScript. This is something I’m working onwith Mozilla, but more documentation is needed in general. I’d love to see more gamedevelopers sharing their solutions to problems that they encountered during their games.

fun in g eth little to ol om a S rking on wo en be I’veSo before I ﬁnish I’d like to show you one more thing, something that I’ve been working onrecently to help with my game development.

Game profilerIt’s a JavaScript game performance proﬁler that I’m working on for Rawkets.The purpose is to visualise performance of key areas of game and network logic in a way thatmakes it easy to see where things can be improved.It’s early days, the idea and resulting code are only a week old, but the hope is to eventuallyrelease it as a browser addon or module for other games developers and animators to use.Right now I’m focussing on getting it working well for my own requirements and making surethe resulting visualisation is easy to understand (which it isn’t yet, as you can see).

Webkit timeline-likeThe idea is to create something very much like the Webkit timeline panel, just customised forapps and gaming to give a much more ﬁne-grained view of performance.I’m by no means a competent tools developer, but I’m hoping something like this will at leastgive me a better idea about exactly where I can increase the performance of Rawkets.

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 ExplicitWeb.co.uk HTML5 & WebSockets game Web development podcastTwitter - @robhawkesRawkes - http://rawkes.com

Foundation HTML5 Canvas Out now Paperback and digital formats Become a canvas master Learn how to animate Make two cool space games RAWKES.COM/FOUNDATIONCANVASFoundation HTML5 Canvas is out now on Amazon and other reputable book stores.

Mozilla Dev Derby Every month Next month is CSS Media Queries November is HTML5 canvas Win prizes (like an Android) DEVELOPER.MOZILLA.ORG/EN-US/DEMOS/DEVDERBYAlso, you should deﬁnitely take part in the Dev Derby, which is a monthly competition run bythe Mozilla Developer Network to see what can be done with the latest Web technologies.This month the focus is on Geolocation, next month is on CSS Media Queries, and Novemberis on HTML5 canvas.The winners get cool prizes, like an Android phone. It’s a great excuse to play around withthese technologies.https://developer.mozilla.org/en-US/demos/devderby

Ask MDN One hour every fortnight Web development topics ASKMDN Hand-picked experts Great discussions onGameStart special (hopefully) @ASKMDN & #ASKMDN ON TWITTERAnd lastly, I’d like to quickly mention Ask MDN which is a project that I’m working on atMozilla.The concept is simple. One hour every fortnight we gather a bunch of experts on Twitter toanswer your questions about a particular topic.We’ve had 4 sessions to date and it’s going down really well. If you follow @AskMDN onTwitter you’ll be sure not to miss the next session.http://twitter.com/AskMDN

Thank you.If you have any questions feel free to grab me on Twitter (@robhawkes), or emailrob@rawkes.com

http://rawkes.com	1032
http://feeds.feedburner.com	74
http://paper.li	43
http://daringfireball.net	1
http://www.rawkes.com	1

Inside Rawkets - onGameStart

by Rob Hawkes on Sep 23, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 1,151

Statistics

Inside Rawkets - onGameStart — Document Transcript