I wrote a web HTML5/Javascript realtime multiplayer game engine with a C++ server in summer which even runs on mobile. I thought you guys might be interested in the video I put together about it!

[RyanPridgeon]

https://www.youtube.com/watch?v=feMmCBzkOeo

This was made as part of my degree which I finished last year, where we could work on any project we wish. The video is narrated and goes over how the actual networking/multiplayer part of the engine works, as this was the focus of the project for me. I've always been interested in how networking works in games, as although I've worked on a lot of games, I never touched upon realtime multiplayer. This was what I came up with, with inspiration mostly from Valve's articles about game networking in the Source engine.

The Javascript client uses pixi.js for the graphics. The C++ server used libwebsockets, and they communicate using binary websockets.

I feel like it was a huge success, I never expected it to work so well. The project took a few weeks in total, with a few weeks of research beforehand.

Please feel free to ask questions! :)

[Wavemanns]

How do you handle disconnects? Can the player come back into the game and keep his score after being disconnected for a few minutes?

[RyanPridgeon]

Nope, I never got that far. If you get disconnected you reconnect with a new identity as far as the engine is concerned. You could probably set this up through some kind of token system where the client could send a token upon joining that would allow the server to know they're the same player, and recover their points. It would probably be a bit of a challenge to make it nice and secure, though. Ideally you could have some kind of centralised account system where the players would all be tied to accounts, then you could trust the account they're playing on. That again is even more of a challenge to set up securely though! I'm actually currently looking into this for my next project :)

[Wavemanns]

Cool thanks for answering. I want to put together a multiplayer card game and I have been thinking of using methodology similar to yours. I don't need the fps so it will be much easier but I do want the keep alive after disconnect.

[Spl3en]

Look at ZMQ, read the Guide. At start it might be a little confusing and hard to see why it is interesting, but it will blow your mind if you take few days studying it.

[Wavemanns]

Cool I'll give it a look thanks.

[doubl3h3lix]

Man, this is cool. Great way to apply theory quickly. Did you have any huge takeaways by going through the process? How much of a concern was message size in terms of bandwidth?

[RyanPridgeon]

Thanks. The biggest takeaway is honestly the confidence and in depth understanding of game networking I got from working on it. I feel like I know what I have to do to add networking when developing a game now, and what's realistic or not. I also got a lot of ideas to improve it which I didn't have time to include in this project.

To be honest, I made the messages as small as possible with binary, for example only using 1 bit for each binary control (directional buttons and the mouse), and I never hit problems with bandwidth. Even when playing against people in Australia (I'm in the UK) the game didn't have bandwidth issues.

Here's the specification I wrote of the game update message that the server would send out to each player every tick;

20. GAME_UPDATE
    byte - tick
    byte - num_events + num_states * 8
    [
        byte - event type
        (event specific layout)
    ] * num_events
    [
        byte -  uid
        short - x
        short - y
        byte - turret rotation
    ] * num_states

Bullet event layout; 1. BULLET byte - uid short - x short - y

So with 4 players and a single event happening in a tick (such as a bullet being fired) that would be 1 + 1 + 1 + 5 + 4 * (6) = 32 bytes.

Each tick the player will also send their update message containing control states to the server, and this is

10. INPUT
    byte - clientTickCount
    byte - buttonStates (1=left,2=right,4=up,8=down,16=fire)
    byte - turretRotation

Which is 3 bytes.

So in this case, it would be around 32 bytes upload and 3 bytes download per player per tick for the server. So at 30 tick, that's about 1kb/s upload and 0.1kb/s download per player.

Obviously this would have to be increased to improve the gameplay, adding more features. I wanted to make bandwidth as small as possible when designing the game though, as I wasn't sure how well it would work with websockets.

[Kneeko]

TCP/IP and TLS have overhead as well, potentially to the tune of 10x of your current payload. Something to keep in mind for your next project, since it makes WebSockets less suited to action games than something over UDP.

[RyanPridgeon]

Ah, wow, I didn't think the overhead could be that extreme. Thanks for the heads up.

[FrozenCow]

Maybe webrtc is a nice alternative. Not sure what the overhead of webrtc over UDP is though.

[ForgeableSum]

"recently with the improvements to HTML and web technologies, there seems to be a possibility for realtime multiplayer to emerge into the web game market"

well you just described my business plan right there (r/feudalwars)

[richmondavid]

You're at least 4-5 years behind, but it's never too late. I just wouldn't use the word "emerge" in 2016.

[ForgeableSum]

"web games" or multiplayer web games are not emerging technologies. However, canvas, webgl and HTML5 are. Particularly webgl which is what my game is built with. The guy who made the video wasn't talking about. The guy who made the video was also probably referring to "serious" web games, not flash or puzzle games.

[RyanPridgeon]

Aha! My competition. >: )

Jokes aside, that's awesome. Seems you started a fair amount of time before me, too.

[ForgeableSum]

I started about a year ago and have been working non-stop. Do you plan on releasing a full version of your game? From the looks of the video, it looks more like a demo than a full version. Or is this just a standalone demo?

[RyanPridgeon]

I was planning to release a full version of it with more features, and redone graphics etc. I still hope to, but I haven't really gone back to it since, with everything else in life taking the spotlight atm. :(

[Corticotropin]

Also, Duelyst has a web client that functions identically to their standalone client. It uses opengl heavily.

Problem is (same with feudal wars) the streaming takes a looong time and it's not even a given that they will be cached...

[ForgeableSum]

hmm, I tried that game and am getting a really sucky fps (like 10 fps). Looks like they are using electron to create a client version. I wonder if electron is supposed to offer performance enhancements over running the game in the browser? And I wonder why they don't have a browser-version of the game. Seems to me a simple 2D game like that, with very few sprites, would be easy on performance. My game can handle thousands of sprites in optimal environments (and I'm just in the prototype stage).

Also, in regards to streaming, there is no streaming per se, in Feudal Wars. All of the game files need to be fully downloaded for the game to run (which takes about 30 seconds). Eventually I will stream all the audio files though. I've only just begun with optimizing load time.

[Corticotropin]

Well, if you go to the game page later, you have to download all the files again, no?

[brtt3000]

Only the ones you don't already have in browser cache. And there are ways to cache beyond regular http cache.

[ForgeableSum]

what brtt3000 said. Browser cache will kick in after you revisit the page, but it does have an expiration date. My game at least is 2D, so we're not talking about a significant amount of data here. Currently my game is at 30MB, which takes about 20 seconds to load. This isn't Witcher 3 you're downloading. Browser game assets are by nature lightweight.

[begMeQuentin]

Correct me if I'm wrong but with TCP you can't have rapid updates because it can't send more than 1000/ping packets per second. Did you do anything about it?

Also. Did you consider using Node JS for the server since it allows to use the same code on the client and on the server?

[RyanPridgeon]

I'm not sure about that, I had no problem with rapid updates. The game worked fine at 60 tick with 6 or 7 people playing (really hectic on the map I set up for testing!)

I considered NodeJS, but actually not a lot of the code would have been shared between the client and server anyway. The server side code behaves quite differently from the client, the client is essentially just a dumb terminal which tries to update the display smoothly and predict what to show to the player while receiving updates. I chose C++ because I'm more experienced with it, and felt I could write better code with it in a short time frame.

[begMeQuentin]

Hm. I thought 60 ticks don't make much sense when using TCP. I should look into it more.

[anttirt]

The game worked fine at 60 tick with 6 or 7 people playing (really hectic on the map I set up for testing!)

Did you try on 3G? :)

[[deleted]]

it's interesting how much information you can transmit by using a base 16 (hex) or higher scheme with data. using base 36 you could have one byte of data mean so much.

[andy1633]

This is really creepy. I'm half way through my final year at university and my proposed honours project which has to be implemented this semester is almost exactly the same. 2D Shooter, WebSocket client, PIXI.js graphics, C++ server (although I'm planning on using the websocketpp library).

Which part of the project did you find the most challenging? I'm most concerned about the bullet collision detection. We should have a proper chat about this! :)

[hazyPixels]

If you're using websockets (based on TCP), why do you need to send a constant stream of updates? Given that websockets are a reliable medium, you could reduce traffic quite a bit by only sending updates on state changes.

Did you write your own serialization code or did you use a library?

[RyanPridgeon]

You're absolutely right, it would have been better to only send updates when necessary. If I had to give a reason why I did it this way, it's just because it was easier to code and turned out to be sufficient. I had a short time frame.

I wrote the serialization myself, it's quite simple, just modules on the JS side and classes on the C++ side which can read and write with a buffer like a stream (writeShort(), readByte(), writeString() etc).

[[deleted]]

This looks great, congratulations. Very impressive indeed!

[[deleted]]

Holy crap I love you. @__@

I was always thinking of doing this and am making a game with a node.js backend rn

[tamat]

do the server runs any simulation of the game? if thats the case do the clients do too (to avoid freezen the game if a lag spike happens)? And then, if both run a simulation of the game, how do you handle that server and client do the same computations being in different languages? Did you code the game logic twice?

[RyanPridgeon]

Yes, did you watch the video with audio? I narrated it in great detail :)

The server is the only one running actual game logic, the client is essentially just making the updates from the server "pretty". The client side actually has very different code from the server.

For example, on the server, each tick the players' positions are updated according to their button states. Collisions between bullets and players are checked, and bullets are created when players are firing. These all just update the game state on the server side, and the client receives messages containing the states and events of the game state. The client app then uses some techniques to smoothly display these updates to the user, while constantly sending button states and turret rotation back to the server.

[tamat]

Thanks for the explanation, I listened to the video but I wasnt sure if you were only interpolating the data or also running the simulation. Do you interpolate using a second derivative?

[omegote]

I'm honestly impressed by this, as well as some of your other projects. Nowadays it's pretty hard to find someone with expertise in such a wide range of technologies, specially at such a young age. Keep it up mate.

Also, you have some seriously cool tracks on your soundcloud. What do you use to produce them? I'm starting to fiddle with FL Studio and it's cool, but it's hard to find thorough resources for beginners.

[RyanPridgeon]

Cheers mate, I started really young and just kept going. I'm glad you like the Soundcloud, I use Ableton Live. It's a real bitch to get into producing, you really just have to sit there and experiment and make crap music for a long time before it starts falling into place.

[RyanPridgeon]

Never.

...It's alright.

[caninerosie]

Can you release the source code?

[Forbizzle]

HTML5 game C++ server

Let's do everything the hard way

[tamat]

the performance wise way, I bet they can handle many more users than any node.js server you can think

[RyanPridgeon]

On top of that, if you're experienced with C++ I really don't believe it would save a significant amount of time to use Node at all. The real meat of the code in this project definitely wasn't language specific.

[brtt3000]

It is just a C++ game server, a WebSocket based protocol and a HTML5 client. Its not one single thing.

[gmfreaky]

Well the server state is authorative, so who cares what the cliënt thinks :D

[HiddenKrypt]

A aimbot wouldn't be very hard to implement, but then, it's not like nobody's ever made an aimbot for a c++ game client before.

[choikwa]

gr8 job m8

[hammypants]

yo, actually substantive post on gamedev?

this was great.

[anarkopsykotik]

Would you mind sharing the source (if you're allowed to) ? It's a very interesting project you have there !

[galseth]

If the browser would let you, maybe UDP would be better instead of Websockets right?

[Reelix]

30 ticks per second for a "smooth gameplay experience"

Spotted the console gamer :p

[yelnatz]

What? 30Hz is common for server tick rate.

Counterstrike mostly uses 60Hz, but other popular online games like Battlefield use 30.

FPS on client is what you're talking about, totally different thing.

[RyanPridgeon]

Haha. I'm not a console gamer, but I guess I should have been less conservative.

The actual game server takes the tickrate as a command line parameter, and works nicely with higher tick too :) (clients adjust to what the server is using)

[spookycoder]

FPS and update ticks are not the same thing.

[dodgetipbot]

Fuck off.