What are some of the mistakes one can make when creating a multiplayer game in a Node Server

[Kitanga Nday (NDAY Games)]

I have been working on a multiplayer game and have been wondering what are some of things one should be aware of when creating a multiplayer game in node. As in are there things you should never do?

Also does anyone think using a client-server architecture is a bad idea (it's not a pure implementation, but has some peer-to-peer design in there)?

[mattstyles]

If you're adopting a hybrid model make sure you know what you're doing, adds even more complexity (any multiplayer game is already complex). Of the 2 methodologies client-server is probably far easier to think about conceptually and much easier to implement.

Make sure you're on top of handling network latency, this can be a pretty big deal depending on your app and your structure.

 

[Kitanga Nday (NDAY Games)]

It's a turn based game with a max time of 17 seconds per turn. So as for latency I know I'll be good. There will be some predicting done on the client side, but I will not truest the client at all. I'm starting now (hopefully) to implement some of my ideas

 

[rgk]

Honestly be prepared for a lot of situations, are you using socket.io?
Client-server is way easier to implement like @mattstyles said, I created a more peer-to-peer setup to reduce how much my server has to do and it took a year to perfect.

[Kitanga Nday (NDAY Games)]

Goodness, I don't think I have that much time

[Kitanga Nday (NDAY Games)]

54 minutes ago, rgk said:

...are you using socket.io?
Client-server is way easier to implement like @mattstyles said, I created a more peer-to-peer setup to reduce how much my server has to do and it took a year to perfect.

Yes I'm using socketio and have a lot of the connection stuff ready. Have you by any chance done match-making?

What caused you to take a year to perfect your multiplayer game. Please share your experiences here.

[rgk]

Yeah I do have a queue manager in place, honestly I never had experience with it before and many things happen, different packets get sent at different times and you have to always have fail safes and lag compensation. When I say it took a year to perfect, the initial implementation was done in a few months but bugs kept arising.

[Kitanga Nday (NDAY Games)]

@rgk are you willing to share a little more. Mine is mainly client-server and it's pretty simple to implement. I'll tell you about it as soon as I finish it.

Are there any tools you recommend?

[rgk]

I use primus.io with primus-rooms but a lot of my implementation was very custom. Also express to serve the site. A list of what I used can be seen here: http://aerialdrop.com/credits

[Kitanga Nday (NDAY Games)]

@rgk thank you for that list, I'll see if I can peruse through the libs and see what they are good for.

[namel]

Some of the major obstacles in writing multiplayer games are reconciling the server view and the client view of the game state.

Syncing the game loop on the server and the game loop (and the render loop) on the client is usually performed by extrapolation.

I wrote an open-source nodejs multiplayer library which does many of these things for you.  

http://incheon.gg/

Check it out

 

 

 

[Kitanga Nday (NDAY Games)]

On 1/12/2017 at 0:15 PM, namel said:

Some of the major obstacles in writing multiplayer games are reconciling the server view and the client view of the game state.

Syncing the game loop on the server and the game loop (and the render loop) on the client is usually performed by extrapolation.

I wrote an open-source nodejs multiplayer library which does many of these things for you.  

http://incheon.gg/

Check it out

 

 

 

Yes I'm aware of these issues. This is exactly why I choose a turn-based game instead of a fast paced game. So that I could practice the basics before heading to more advanced techniques like Client-side predictions.

Your api sounds great, but I had trouble playing the demo (ping of 300+). OK so my ping most probably was the cause. But one thing I noticed was how there isn't any client side prediction. My ship would just sit there and not move at all. And when I pressed the fire button it just plays the sound. 

EDIT: I noticed when I played the heroku app that it started to show client side prediction, that with a lot of teleporting. I plan on making games that take the bandwidth into consideration to the point that one could argue that the type of internet connection I'm expecting could be what determines the game itself.

I might folk it though, so that I can use it as a foundation

[namel]

First of all, thanks for trying it out.

Your plan of doing a turn-based game first, and fast-paced game later makes a lot of sense.

The server was down last night, and it sounds like what you saw was just that... 300ms is not great but it is reasonable.  I believe that it should handle that.  

 

 

[Kitanga Nday (NDAY Games)]

@namelWell now it's 700. but still no client side predicting. I don't know why I want that so badly lol. Probably, because I don't want to implement it myself later on lol. But anyway, I'll find better internet and definitely try it out. But tell me, I believe I saw some bots running on the server some time ago. So please share your experiences, was that very cumbersome to implement. Like were there any issues with running those bots' calculations.

[b10b]

A non-technical mistake is to design a multiplayer game that needs multiple players.  Really the extra players should add to the fun of the single player experience, rather than be fundamental to it.  Else there is nothing to retain initial players sufficiently long enough for others to join so the game never achieves "fun-velocity".  I made that mistake before, with an arena style game that was hectic fun with 6+ players, but absolutely pointless with 1, monotonous with 2, formulaic with 3, etc ...

[Kitanga Nday (NDAY Games)]

2 hours ago, b10b said:

A non-technical mistake is to design a multiplayer game that needs multiple players.  Really the extra players should add to the fun of the single player experience, rather than be fundamental to it.

Of course unless your game has a large player base from the start thanks to hype (e.g. Titanfall 1 is fully online, no offline game mode).

But I get what you mean and agree with it. Especially for the HTML5 games industry. Actually, I was thinking of adding bots later to the game, but after this comment I'll implement it along with the multiplayer mode. So players can practice or just have fun playing against bots. My game only needs two players so it's all good. I also plan on adding an invite feature for those who want to play with friends.

[namel]

@Kitanga Nday (NDAY Games)

client-side prediction is not a simple thing that I can summarize in a post  and I can understand why you don't want to have to deal with it.  In fact, that's how Incheon.gg was born!  It started with a javascript game that needed client-side prediction and didn't have the cycles to work on that heavy load.

Feel free to join the Incheon.gg slack channel and ask specific questions about client-side prediction over there: http://incheongg-slack.herokuapp.com/

Also, if you want to know the nuts and bolts of client-side prediction, you will probably need to read GafferOnGames http://gafferongames.com/networked-physics/introduction-to-networked-physics/

or get the Addison-Wesley book: https://www.amazon.com/Multiplayer-Game-Programming-Architecting-Networked/dp/0134034309

 

 

[Kitanga Nday (NDAY Games)]

@namel Thanks I'll send a request immediately, but I haven't been on slack in a long time. So I don't know. And I spend most of my time with the Phaser guys anyways lol.

Actually, a lot of my initial knowledge about game networking came from reading gafferongames' articles. Came there looking for the fixed step algorithm during js13k (2016).

And I don't know why, but I hate reading books (ebooks to be more exact), I prefer tutorials and much shorter articles.

But, yes, thank you for the advice I'll look into it.