Server architecture for a multiplayer game? [closed]

Question

I'm planning to build a small multiplayer game which could be run as a java applet or a flash file in the web browser. I haven't done any server programming before, so I'm wondering what sort of server architecture i should have.

It'll be easy for me to create perl/php files on the server, which the java/flash code contacts to update the player position/actions, etc. But I'm considering whether i should get a dedicated web host, which OS to use, which database, etc. Also, the amount of bandwidth used and scalability is a consideration.

Another option could be using a cloud hosting system (as opposed to a dedicated server), so they would take care of adding additional machines as the game grows. As long as each server ran the core perl/php files for updating the database, it should work fine.

Yet another option could be using Google app engine.

Any thoughts regarding the server architecture, OS/database choice, and whether my method of using perl/php/python scripts for server-side programing is a good one, will be appreciated!

Thereof

Can you elaborate what kind of game this is? This will help us help you :) – Cosmonautics

It'll be a small multiplayer RPG game, so real time as opposed to turn based :) – Thereof

I think you're better off managing all the state in memory of a single machine and regularly backing it up to a database (transactionally?). Much easier to synchronize all the clients that way. – Cosmonautics

Answer 1

You need to clarify more about the game, and think more about architecture rather than specific implementation details.

The main question is whether your game is going to be in real time, turn based, or long-delay based (e.g., email chess). Another question is whether or not you are going to be freezing the state for subsequent reloads.

I would highly recommend figuring out in advance whether or not all players in the same game are going to be hosted on the same server (e.g., 1000 of 4 player matches compared to 4 matches of 1000 players each). If possible, go with the first and stick everyone who is in the same game under the same server. You will have a hard enough time synchronizing multiple clients to one server, rather than having multiple servers against which players are synchronized. Otherwise, the definition of consistency is problematic.

If possible, have each client communicate with the server and then the server distributing updates to the clients. This way you have one "official state", and can do a variety of conflict resolutions, phantoms, etc. Peer to peer gives better performance in faster games (e.g., FPSs) but introduces tons of problems.

I cannot for the life of me see any convincing reason to do this and perl or PHP. Your game is not web based, why write it in a web oriented language? Use good old J2EE for the server, and exchange data with your clients via XML and AJAX. If possible, run a real Java application on clients rather than servlets. You can then benefit from using JMS which will take a huge load off your back by abstracting a lot of the communication details for you.

Cosmonautics

The client would run it as a java applet. Do you mean that the server should run java servlets or that the server should run a full-blown application? its just that perl/php tends to be more common and supported on servers, so I thought creating the server code in them might be a better idea – Thereof

The server should be a full blown application. You may want to manage system state and synchronization between clients in memory. – Cosmonautics

If you run perl/php on a normal web server, you would have a separate process per client. If you run a multithreaded server that can serve multiple requests in a high-level language, things may be simpler. – Cosmonautics

Ahh, i see. But the server must be very powerful to support that. What OS/database would you recommend, and do you suggest cloud hosting or a dedicated server? – Thereof

You are probably overestimating your game requirements. I once ran a 50 player MUD on a dual Pentium 166. Read ready client, process, update all. Time tick, process, update all. Unless your "process" step is massive (what, neural net AI?) the network will bottleneck first. – Winifred

Answer 2

For your server architecture, you might have a look at Three Rings' code. They have written a number of very scalable games in Java (both client- and server-side).

Fishing

+1 for Three Rings - also check out their www.gamegardens.com - it provides a nice and easy entry point for folks wanting to create their own multiplayer games by giving you a framework for creating games and letting you use their game servers – Demetriusdemeyer

Answer 3

I would also discourage from using PHP, also HTTP isnt the best idea as it is stateless and talkative. I was working for some time in company currently developing really massive multiplayer game. The back-end is plain JVM (being connected thru tomcat by multiple clients and from mobiles one per client). So I know the less data you transfer the smaller buffers you need on server -> more clients on one machine and also a bit faster responses. Also consider security, https is quite expensive, especially if you need to transfer graphics and sounds. Binnary protocol of your own with non-browser client container would do the best (good choice is switchable protocol for the development-debugging time). Maybe sounds complicated but it isn't.

@Sarah nice hint, thanks too ;)

Ial

btw three-rings and gamegardens links are being blocked by AntiP2P guardians, anyone knows why is that? – Ial