What's the difference between a Web Server and a Game Server?

Question

I'd like to build a turn-based, multiplayer iPhone game that will require a game server somewhere to connect the players and dish out the world state data. I'm trying to understand how the game server will work so I can begin designing and building it. Up until now, I only have experience with building web applications and so naturally my mind wants to design the game server to work in a similar fashion as a web server, but can it?

The ASP.NET MVC web servers I've used in the past work by the client sending a request for some web page data to the server and the server generates the HTML or XML or JSON and returns it to the client in an HTTP packet. This process sounds exactly the same for a multiplayer game, except the client probably won't be requesting HTML, but it would make sense to request XML or JSON data, right?

So my questions are...

1. Can a game server be written using ASP.NET MVC and work the same as a web server using a RESTful API designed by me?
2. Is there a better approach to requesting and receiving game data than using HTTP packets with XML or JSON data packed into them? The data being returned from the game server will be small.
3. Using a RESTful API to access data from a web server makes good sense, but using a RESTful API to request game data from a game server doesn't make sense and, in fact, sounds like it could cause security issues, your thoughts?
4. Lastly, can anyone recommend any good game books that show examples on how to build a decent game server?

Thanks so much in advance for your help!

Verb

WCF services would probably make more sense than MVC, since there is really no UI, just a data exchange. – Cyr

Answer 1

Webservers are missing one important component...

IE. They're stateless. The whole platform of the web (and HTTP servers in general) is based on the pattern that they're stateless meaning they don't hold on to data when you switch from page-to-page.

There are ways around the limitation. On the client-side: you can use a session to hold data while the browser is open; or cookies to store data over a longer term. On the server-side: databases are usually used to store state long-term. So...

1. Yes, but depending on how much and how long you want to store the state of a game session, you might find that running the game server/engine separately (and not as a webserver) will give you a lot more room to scale/grow in the future.

2. Yes, and no... XML/JSON is pretty much the way to pass object state around the internet because it's simple and platform-independent. Since you may/not be writing your own server backend I'd suggest you take a look into using XML-RPC before you consider rolling your own solution from scratch.

3. I'm not sure why you're paranoid about security. If you implement a pretty strict access policy for what an acceptable request/response cycle is there shouldn't be any issues. Like I stated before, look into XML-RPC. The key is, don't give the user access to any more of the game server data than they need.

4. Nope, mostly because I don't write games. Although, I do have experience writing client/server architecture apps and it's not rocket surgery. I suggest you take a look into joining the Game Development Stack Exchange FAQ site that's about to hit beta.

Caparison

thanks, Evan, this XML-RPC looks really good. have you ever used any of the .NET implementations? if so, any suggestions/recommendations? – Verb

@BeachRunnerJoe No I haven't. I only brought up XML-RPC because it's a well known and well webservice architecture. If you're looking to get started with it, Stack Overflow should have plenty of info to offer from people who actually use it. See this to start. https://mcmap.net/q/690632/-how-to-use-xmlrpc-in-c – Caparison

Answer 2

The main difference is that a web server generates a lot of relatively static content using (relatively) little or no state information. Even when state is used, it is usually specific to the session or user. Reads are a lot more frequent than writes, so caching can help increase throughput. You can also trust web browsers to pass some state data and cookies in a (relatively) reliable way.

A game server on the contrary most of the time handles updates from clients, keeps a large amount of global state (all game, player, status state) and sends status updates to clients when they request them. Caching is impossible and you can't trust your clients to tell you the time of day - you have to assume they will try to cheat in whatever way they can.

Using a REST API is not such a problem, as you can use the standard authentication mechanisms you use already.

Chapter 3 of the book "Beautiful Architecture" describes the architecture of the Darkstar (now RedDwarf) project, a scalable application server for online games and virtual worlds. While the scale of RedDwarf is MUCH bigger than what you want, the book does describe what you need to address when creating a game server.

Handsome