Server architecture for a multiplayer game?

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!

Answer 1

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).

Answer 2

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.