Basic networked multiplayer game example/template

[Arcanorum]

Greetings!

I see quite often around these parts and in further fields, that there are constantly people who are just starting out asking how to add networked multiplayer functionality to their HTML5 games. I was one of them, and I hated the near absence of practical explanations that were written in concise, plain-English, yet still detailed, of how to get started.

So, I made a simple game example/template using Socket.io and Phaser, and documented the hell out of it. Almost everything gets a few lines of comments to explain what is doing what, and I haven't assumed any prior knowledge, aside from core JavaScript and being able to set up NodeJS and how to view the game in a browser. The main focal point is using Socket.io, as the game framework can be easily interchanged to one of your preference.

Hopefully this will save a few hours and headaches for people who don't have a clue what they are doing.

https://github.com/Arcanorum/basic-networked-multiplayer-game

[mattstyles]

Thats awesome @Arcanorum! 

socket.io tends to be a little weighty for lots of interactions (slower, due to bandwidth mainly) so I'd love to see an example like this using something lighter like ws or micro sockets.

[Arcanorum]

I've looked into alternatives, but I think the pretty API and current stability of socket.io makes it attractive to newcomers, and thus suitable for this example. Once the basics are understood, naturally I expect people will want to use their brains and do some research and decide what is best for them. I wouldn't expect anyone to make an MMO with this.

[jedimasta]

I've only scanned down through some of the code there and thanks are in order for making the explanations clear and concise. I haven't yet drilled down into the nitty gritty yet, but I wanted to ask a few things before I do, to see if your example relates to my project or if I need to keep researching.

I've created an HTML5 clone of a game I saw in a casino recently wherein players "grab" cards as they are dealt in order to reach a target score determined randomly before the game starts. I specifically created it to be played using physical buttons around a TV embedded into a table. I used the CreateJS APIs and I'm pretty happy with the results. The next level, so to speak, would be in allowing players to use their mobile devices to grab cards from a main play area (i.e. the TV). If you've played any of the Jackbox Party games, you'll know what I mean.

I've gathered that in order to do this I'll need to leverage node.js and sockets.io (or similar) to get players' mobile devices talking to the main game screen, but that's where my understanding ends. I don't really intend on releasing this to the public or anything, more for just me and my gambling friends, so I wan't to spend as little as possible, ideally nothing, on server usage. I've already setup a webserver in my home, strictly to serve internal IPs, using XAMMP on Windows. 

Do you think I could glean anything from your example and further, would you have any advice or could you point me in the right direction for adding a node/socket server locally to handle the network requests? Much of this is still new to me, only having come from a PHP front end development background, so I might be in over my head, but I won't know until I ask.

Any and all guidance is appreciated.

[ClusterAtlas]

On 5/3/2017 at 4:00 AM, jedimasta said:

I've only scanned down through some of the code there and thanks are in order for making the explanations clear and concise. I haven't yet drilled down into the nitty gritty yet, but I wanted to ask a few things before I do, to see if your example relates to my project or if I need to keep researching.

I've created an HTML5 clone of a game I saw in a casino recently wherein players "grab" cards as they are dealt in order to reach a target score determined randomly before the game starts. I specifically created it to be played using physical buttons around a TV embedded into a table. I used the CreateJS APIs and I'm pretty happy with the results. The next level, so to speak, would be in allowing players to use their mobile devices to grab cards from a main play area (i.e. the TV). If you've played any of the Jackbox Party games, you'll know what I mean.

I've gathered that in order to do this I'll need to leverage node.js and sockets.io (or similar) to get players' mobile devices talking to the main game screen, but that's where my understanding ends. I don't really intend on releasing this to the public or anything, more for just me and my gambling friends, so I wan't to spend as little as possible, ideally nothing, on server usage. I've already setup a webserver in my home, strictly to serve internal IPs, using XAMMP on Windows. 

Do you think I could glean anything from your example and further, would you have any advice or could you point me in the right direction for adding a node/socket server locally to handle the network requests? Much of this is still new to me, only having come from a PHP front end development background, so I might be in over my head, but I won't know until I ask.

Any and all guidance is appreciated.

I ain't @Arcanorum but I think you're in the right direction!

Yes it would be node.js & socket.io, and yes a home server would already do the trick.

Some points to consider:

- Static IP for the server-side, so you can use / bind that IP & port in the client-side code. Hence when the players open / run the game in their mobile, the server will be reachable instantly.

- A great / battle-tested RNG (Random Number Generator) so the game really operates on a very randomized environment - many can be found in npm  

- It would help to draft it on the paper first on how the server will gather players, how one player can be the host, how can the server identify the host, how can the host start the game, how does the server manages each turns, how the server handles unwanted disconnection & reconnection of clients, etc etc  

[jedimasta]

5 hours ago, ClusterAtlas said:

I ain't @Arcanorum but I think you're in the right direction!

Yes it would be node.js & socket.io, and yes a home server would already do the trick.

Some points to consider:

- Static IP for the server-side, so you can use / bind that IP & port in the client-side code. Hence when the players open / run the game in their mobile, the server will be reachable instantly.

- A great / battle-tested RNG (Random Number Generator) so the game really operates on a very randomized environment - many can be found in npm  

- It would help to draft it on the paper first on how the server will gather players, how one player can be the host, how can the server identify the host, how can the host start the game, how does the server manages each turns, how the server handles unwanted disconnection & reconnection of clients, etc etc  

Thanks Cluster. Over the past few days I've been staying awake far longer than I should be running through various tutorials and examples to get a very rudimentary start. I started a new thread with specifics if you (or anyone else) cares to see where I'm at and how I got there. 

As for specifics:

1) yes, static IP. I'm running this all off one machine, but it's set up to feed out to my internal network, easy peasy.

2) the RNG is just a basic Math.random with a min max modifier. The random score is based on how many players in any given round and never more than ~60 so I'm not too concerned with being hardcore random

3) most of this is already worked out in the tabletop game. you might have a point on checking/handling disconnects and reconnects, but I don't know how much time I want to dedicate to that since rounds don't last more than 1 minute.

If curious, here's is what I'm emulating (ignore the spinner, that's for the casino payouts) https://goo.gl/photos/3QWfsm1ArbDozpm6A

[Arcanorum]

I just realised uWS is now the default websocket engine for socket.io 2.0.0. Good news.

https://socket.io/blog/socket-io-2-0-0/

[kaasis]

4 hours ago, Arcanorum said:

I just realised uWS is now the default websocket engine for socket.io 2.0.0. Good news.

https://socket.io/blog/socket-io-2-0-0/

But isn't it still slower than actual uWS? Like it's just based on it and socket.io by itself is really heavy.

[mattstyles]

10 hours ago, kaasis said:

But isn't it still slower than actual uWS? Like it's just based on it and socket.io by itself is really heavy.

It transmits some extra data, more than you'd need as a consumer, but it's had ways to reduce some of this for ages, the difference in perf probably isn't huge but µWS is currently the fastest solution out there, very well written.

socket.io is basically the transport, fallbacks and some wrapping to clean up the api. its a small high-level library, low-level is almost always more performant but it also usually much harder to work with. It never claims to be super speedy or anything else, just a clean socket implementation that is very easy to get started with, which I think it fulfils just perfectly.