Rawkets - A Massively Multiplayer HTML5 Game [Mozilla GameOn10]

Hinweis der Redaktion

1. Hi everyone, I'm going to talk to you briefly about Rawkets, my HTML5 canvas and WebSockets game.\n
2. - For those who don't know me, which I imagine is a lot of you, my name is Rob Hawkes.\n- If you're into Twitter, then feel free to follow me, my username is @robhawkes.\n- I've worked on all sorts of projects, but the most recent and well known are the HTML5 version of the Google balls logo, and Rawkets.\n- I'm also working on a few things which I hope you don't mind me mentioning.\n- The first is my book on making games using HTML5 canvas. It's called Foundation HTML5 Canvas and will be out next spring. If you're interested in it you can always pre-order it from Amazon right now, it won't cost you a penny until the book is actually released. I can promise you I'm putting my all into it and I'm really enjoying writing it.\n- The second thing is the Web design and development podcast I co-host, called ExplicitWeb. Myself and my good friends John O'Nolan, and Hannah talk about all thing related to the Web industry in a light-hearted, completely random sort of way. We're on iTunes if you want to have a listen.\n
3. As I mentioned at the beginning, Rawkets is a game that is built using HTML5 canvas and WebSockets.\n
4. - To be more precise, you could describe it as a massively multiplayer online space shooter game, or a mamossga for short.\n- The purpose of the game is to be…\n
5. … massive…\n
6. …simple…\n
7. … experimental…\n
8. …and social.\n
9. \n
10. - Rawkets it actually the major project for my university degree in interactive media. It's still in very early development, in fact it's not even 2 months old yet.\n- I created it for a few reasons.\n
11. - Firstly, because I'm massively interested in open Web technologies. They fascinate me and I'm constantly left amazed at what can be achieved with them.\n
12. - Secondly, I'm passionate about the Web and technology in general. I thrive on mucking around stuff to see how it works and how I can break it.\n
13. - And finally, I absolutely love learning new things, whether that's game development theory or WebSockets. If it interests me, I want to learn more about it.\n
14. - Developing Rawkets seemed like the perfect way to satisfy all those things, but really I can’t think of a legitimate reason why not to make it!\n
15. - Rawkets came as a result of wanting to learn more about HTML5 canvas and WebSockets, so the technologies behind it were very much decided in advance.\n
16. - On the client-side I'm using HTML5 canvas for the graphics…\n
17. - …and WebSockets for the communication between the player and the server.\n
18. - On the server-side I'm using node.js for the game logic and WebSockets communication.\n
19. - And, although not implemented yet, data storage on the server is going to be done via MongoDB a document-based database.\n- It's honestly quite amazing what can be achieved by mashing together a few open technologies.\n
20. - Overall, I'm quite shocked at how well these technologies perform. Even with my shoddy code I've been able to knock together a fully functional real-time multiplayer game that is generally very playable.\n- However, there are a few issues with performance that I'd like to highlight.\n
21. – The main issues have been with network communication and the WebSockets protocol.\n- For those who aren't that clued up on WebSockets, it's basically a way for a server to send data to a user, while at the same time allowing that user to send data back to the server, practically instantaneously. In comparison, Web traffic normally only allows data to be sent in one direction at a time, which can quite slow and annoying if you're wanting to send lots of data back and forth at the same time.\n- Originally I was sending data, like the position of players, through WebSockets as quite verbose, plain text.\n- This caused a lot of bottlenecks and performance issues because there was helluva lot of position data being sent back and forth.\n- To get around this I did 2 things…\n
22. - Firstly, I created a communication protocol that dictated how data would be sent back and forth. I coupled this with the use of BISON (a binary version of JSON), which compressed the data a bit and chopped off anything unnecessary – for example, by cutting down large floating point numbers for pixel values.\n- The data is still sent as plain text, such is the nature of WebSockets, but putting this protocol in place cut the size of data immensely, allowing for more users to be on at the same time whilst having less of an impact on network performance.\n
23. - Secondly, I limited the rate position data was sent at. At first I was sending position data every time a keyDown event was fired. What I failed to realise was that this event fired much faster than 30ms, the framerate of the game. By limiting the rate position data is sent to 30ms, it also cut down the amount of data being sent back and forth immensely.\n- Even with these 2 issues solved, each player still currently receives data for all players in the game, regardless of whether they appear on your screen or not. This is a really bad way to do things, for one very good reason. It requires a stupid amount of resources. Let me explain…\n
24. - 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.\n- But one lonely player does not equal a multiplayer game, let alone a massively multiplayer one.\n
25. - So say we now have two players, meaning the game is now technically multiplayer, but still not massively.\n- 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.\n- This isn’t too bad, but notice how the server is having to send 4 messages – 2 for each player.\n
26. - 4 players now. It’s still not quite massive, but look how the server is having to send 16 messages, yet it only receives 4.\n- If you haven’t already noticed, the messages out from the server are the square of the number of players.\n- But 16 messages out is alright, it’s hardly going to tax the server.\n
27. - So imagine if we now move into properly multiplayer territory, although still not quite massive.\n- 30 players in the game would mean 30 messages coming in to the server, and 900 – NINE HUNDRED – messages going out, every 30ms. That’s a silly amount of data for just 30 people.\n- But let’s go further still…\n
28. - Say we really do go massive and have 100 players in the game at one time.\n- It’s not so bad for each individual player, they send one message in and get 100 back – that’s bearable. \n- But check out the server, it’s getting 100 messages in and is having to send out 10,000 back, every 30ms. That’s just a mentally stupid number that’s going to cause a lot of grief.\n- Fortunately there is a way around this that cuts down the amount of messages sent from the server; 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. It’s such a simple solution, but it’s one that I never even considered at first.\n
29. - Now, canvas also has a performance issue, but only really when doing lots of animation – it just loves to hog the CPU.\n- Fortunately this will get much better with the introduction of things like hardware accelerated JavaScript that delegates intensive work with canvas to the graphics card.\n
30. - Aside from technical limitations, the main issue has been with cheating, or manipulation of the game code.\n- Because the game is built in JavaScript, the code is easily accessible and is open for attack.\n- But there are ways to stop this…\n- One way to foil cheaters would be to perform all important calculations on the server, rather than on the client-side. That way, although the cheater may be able to manipulate his own game, it shouldn't affect other players.\n- Another way is to use private properties and methods in JavaScript objects in an effort to prevent them from being manipulated. This is a really simple way of making it difficult for cheaters to override the game code.\n- Finally, you could just obfuscate the code and minify it to make it unreadable. That’d help too.\n
31. - All in all, I've been left enlightened by the open Web technologies that lie behind Rawkets, and its development is proving to be a valuable experience for me. I really hope that it has a bright future ahead of it as I’m enjoying developing it.\n- I'll be putting these slides up soon, so check out my website rawkes.com if you're interested in seeing them or finding out more about Rawkets and what I get up to.\n
32. Thank you for listening, and I hope you enjoy the rest of your evening.\n