Building my Own Server, Help

What type of game are you wanting to make. That will be a big deciding factor. Generally the server verifies movements/shots taken by players to make sure no one is cheating and is a relay between players. Updating each client with the other clients positions (when its proper to do so), etc.

15 hours ago, Mike2343 said:

What type of game are you wanting to make. That will be a big deciding factor. Generally the server verifies movements/shots taken by players to make sure no one is cheating and is a relay between players. Updating each client with the other clients positions (when its proper to do so), etc.

I will be making a game that has 15-25 players fighting against each other in real time in 2D. (Fist Fighting) The game will run on ios and later android..

Real time, over mobile networks, is a real problem. People in un-crowded areas served by 4G will do pretty well (up to a few hundred ms latency.) People in crowded cells (popular places/cities, and so forth) or on slower networks (HSPA, 3G, etc) will have more lag.

For a fighting game, you might want to read up on the GGPO architecture; they use a rewind-and-re-simulate mechanism, and hide latency with wind-up animations, to make "street fighter" type games work OK even over medium latency connections.

I would recommend against using WebSockets, and socket.io. The reason is that TCP suffers when there are packet drops; a single packet drop means that all the data that comes after must wait for a re-send before the receiving end will actually deliver the data -- it'll sit waiting in the kernel for the earlier data to be re-sent, because of the in-order guarantee. For low-latency games, UDP is a better choice.

"how do I game server" is a slightly too large subject to write about in a single forum thread, though. There's matchmaking, basic packet framing, basic socket usage, NAT traversal, latency compensation, metrics and statistics, performance tuning, hosting, and so much more...

2 hours ago, hplus0603 said:

Real time, over mobile networks, is a real problem. People in un-crowded areas served by 4G will do pretty well (up to a few hundred ms latency.) People in crowded cells (popular places/cities, and so forth) or on slower networks (HSPA, 3G, etc) will have more lag.

For a fighting game, you might want to read up on the GGPO architecture; they use a rewind-and-re-simulate mechanism, and hide latency with wind-up animations, to make "street fighter" type games work OK even over medium latency connections.

I would recommend against using WebSockets, and socket.io. The reason is that TCP suffers when there are packet drops; a single packet drop means that all the data that comes after must wait for a re-send before the receiving end will actually deliver the data -- it'll sit waiting in the kernel for the earlier data to be re-sent, because of the in-order guarantee. For low-latency games, UDP is a better choice.

"how do I game server" is a slightly too large subject to write about in a single forum thread, though. There's matchmaking, basic packet framing, basic socket usage, NAT traversal, latency compensation, metrics and statistics, performance tuning, hosting, and so much more...

Thanks for the info. I am going to look into that. One game I really love and have wondered how they do their networking is Slither.io on mobile... I know it started as a web based game but how do they make a mobile game like that so smooth?

Also, I think for this first project I may just go with using something like SmartFox. However, I do want to learn more about building my own "Smart Fox" as a learning experience. Where can I start for this?

The thing about comprehensive 3rd party tools is that they're impractical to make "as a learning experience".

If you really want to understand how servers work then you can look at the source for node.js, and since you are already familiar with it as a user that might help you get a good handle on what it is doing when it serves up a request.