Multiplayer server running on my website?

With having launched my new website, I have been pondering ways in which games can access it and store data on it. I have already made an account registration system that allows users to create an account in the game and save their score to be put onto the leader-board, or just to view personal scores. I even implemented this system in the game I made today, Speed Farrow.

To get to the point, I was thinking about using my website as a server to host multiplayer. Obviously my website is not a server and real-time multiplayer is not feasible. What I was thinking instead to do is to have some sort of turn based multiplayer; where each player takes turns in whatever the game may be, so that inconsistencies do not arise due to the latency between the upload and download of data.

For example: a tower defense game where one player is the enemy and the other player sets up the towers. The only data that is being exchanged could be just “go” and “stop” commands and the enemy vehicles run on a predefined path that is identical for both players. That way, one player wont be seeing something the other player isn’t.

What are yalls thoughts on this? Is it something that you would like to use in a game? Would this work?

A website is just a service running on a server, running through port 80 (HTTP) and 443 (HTTPS). You can run another service for your multiplayer game on a different port.

I don’t see any reason why it shouldn’t be able to run real-time multiplayer. It’s not your “website” that is hosting the game; it’s the server. Your website and game can share a database for the sake of credentials, displaying statictics, account settings, etc.

Now how would I get that set up?

One of the best features of Blender is having the full power of Python at your disposal. Since Blender doesn’t have any kind of multiplayer built in natively, you’ll have to add it yourself. It’s not a trivial task, as you’ll need to learn how network sockets work, decide if you want to go the UDP or TCP route, and figure out how to turn your game updates into small events you can fire off to the other players to update their games.

I’d suggest looking at Python networking tutorials. If you choose the UDP route, I’d suggest going with non-blocking sockets so your game won’t freeze up. If you choose the TCP route, I’d suggest running a separate thread for your network traffic and manage it with some kind of central class (also so your game won’t freeze up). Running a separate thread for TCP is also likely to cause Blender to crash if you forget to terminate it prior to stopping your game, which is why you’ll see recommendations around the forums to stay away from threads.

This isn’t something we can just tell you what to do. You need to understand how multiplayer games work, and by then you’ll have the knowledge to write the code you need anyway. Having said that, we can help you through the journey as you run into specific hurdles.

Do you really want to run a game server?

Why not just run a lobby server where players can find each other and connect directly (you need this anyway).

This way it is much easier for you, as you drive the lobby only without being the bottleneck in each single game session. To keep track of results the clients can update the lobby server while running the game. You could even do a pre-validation before a game session starts.

I’m not worried about the multiplayer part. I’ll play around with some networking and see what I can do.

For games where latency is not important, (like board games) your server may be an acceptable bottleneck. It also allows you to verify that the data send to other computers is valid before it actually gets there and can store unfinished game sessions.

In such case I recommend you to just use a REST API on your server, and access it from your game game/webpage. Using an API to manage data has the advantage of being easy and uniform across various tech, you can use it on your game, app or on your website, instead of accessing the database directly you access the API through http requests. Check for a back-end web framework to see how you can easily make such an API. I’ve used Symfony 3 (PHP) before and it would recommed it, I can’t say about the others.

EDIT: You could also use a third party API like http://gamejolt.com/api/doc/game

I’m not sure if REST is applicable for a game server.

Rests’s most powerful concepts are useful everywhere:

  • use a human readable encoding
  • use request/response
  • use stateless communications
  • use only Get and Set style of communications (GET and POST)

Point 2 doesn’t apply to mid-dame data (eg movement packets), and optimization often gets rid of points 1 and 3.
But for lobbies and scoring, Rest makes things nice and easy. I’ve used it for real time communication in robots, and a host of other things.

If you want a dedicated server to run things on, I have a web facing raspberry pi I can give you a user account on… (eg for python scripts)
But for a lobby, php and a database is likely fine.

The issue that I see is, that you need to submit the complete state. That can become quite large, which eats time. Within a game session this would be a lot of overhead. On a lobby server, this should be fine, especially as you could have sever servers parallel to provide load balancing.

Yes, sending the complete state takes too long. Fortunately…
You do not have to send the complete state - merely the communication should be stateless.

The original issue was that people were writing interface that say to a server:

  • Go into input handling mode (SET_MODE=input)
  • Here’s some data (DATA1=2, DATA2=8)
  • Go into processing mode (SET_MODE=processing
  • Here’s some data (DO_SUM, DO_CALCULUS)
  • Go into output mode (SET_MODE=output)
  • Here’s some data (REQUEST)
    (Server responds with output)

That is statefull communications. If you miss a command (eg a SET_MODE) or send something at the wrong time (eg DO_SUM before the SET_MODE), then baddness happens, as using DO_SUM as an input may be fatal (eg overflow issues, wrong formatting, blow up the parser).

There are two better options. First, send everything at once:

  • Here is some data (DATA1=2, DATA2=8, DO_SUM, DO_CALCULUS)
    (Server response with output)
    This is the ideal, but suffers from large state and bandwidth issues.

Second:

  • Here is some data (INPUT=[DATA1=2, DATA2=8])
  • Here is some data (PROCESSING=[DO_SUM, DO_CALCULAS])
  • Give me the output (REQUEST)
    (Server response with output)

This is stateless communication, so a missed message will not result in anything other than an incorrect answer. If you send the PROCESSING before the INPUT, chances are it will still work. If you drop the PROCESSING message, your answer will be wrong, but at least you haven’t fed values into the wrong part of your code.


At least, that’s how I read the REST api guidelines.

I think your second approach is separating the server into smaller responsibilities. This is a nice design as it supports modularity pretty good.

But it is outside of the scope of stateless or stateful communication.

The benefit of REST is that the states on both ends are always correct. The server knows the state only when processing the request, while the client received the latest state changes within the response.

My main concern with learning how to use REST is that it won’t be suitable for real time games, yet OP will probably try using it for that because it’s what they (now) know. Forgive my ignorance, but doesn’t using REST require polling for updates?

It’s not difficult to get started with TCP/UPD, but difficult to master, so the sooner they start learning it the better. The learning experience be much more forgiving while OP is creating turn-based games.

I tried using udp in some test programs but it just never worked with a remote server and all the resources I looked at demonstrated only on a local network (which works for me) so I just don’t know what to do at this point other than a turn based game.

That’ll be your routers firewall blocking it, plus the UPD traffic being sent to the wrong place. This example has silly IP addresses, so bare with me here…

Lets say you have an IP 192.168.0.5 and your friend is at 192.168.0.6. When you sent the message on your local network, it went straight to 192.168.0.6 and he got it.

Now you’re doing it online. Your houses IP address is 100.0.0.50 and your friend’s houses IP address is 100.0.0.60. The problem is, your message needs to first go to his house, then get sent on to his computer, but you’re only capable of sending it to one address. You can solve this by forwarding specific ports on his router to his computer, but imagine trying to guide all of your friends through doing that. This is where NAT (Network Address Translation) comes in (read more here: https://en.wikipedia.org/wiki/Network_address_translation).

TCP doesn’t have this challenge because you only need one side (the server) to have ports forwarded. Bascially, what happens is your client connects to the open port on your webserver and they form a connection. That connection is two-way, so the server can send information back down it again and it’ll get to the client.

TCP has a handshake that forms a two-way pipe between the client and server, making sure all packets arrive exactly once and in order, but will cause the connection to wait if one packet needs resending. Using UDP, each message needs to be addressed to its destination and is not guaranteed to arrive in order, or at all.