Being a persistent multiplayer game Operation Survival needs a server running the show in the background. My first gut reaction was to use Apache and build the game logic on top of that. There is a host of programming languages to choose from and if that wasn't enough I thought I'd just implement my own cgi or plug-in module. Use an XMLRPC API to service game client requests and we should be all set - right?
Pondering this for a while I came to the conclusion that it would be a terrible choice. To start with I don't really need an HTML server for the game, so Apache won't help all that much. Of course the game will need a website, forum and all that stuff as well, but handling the actual game logic, database persistence and interactivity has nothing whatsoever to do with HTML. Second, a regular connection to your web server is stateless and one-way. Stateless means the client needs to re-authenticate (supplying its session id or user credentials) with every request. One-way means there is no way for the server to initiate communication with the client. This is essential though! Imagine how real time updates as you'd need them for a chat would work: The client has to poll in regular (short!) intervals and ask the server for new data. Most of the time the server will just answer: "Sorry dude, no news.", creating unnecessary traffic. Now imagine a thousand clients asking the server every half second. This quickly gets out of hand.
So what I really need is a persistent two way connection where clients only authenticate once for a session and the server can send data on its own initiative. That's a socket connection or socket server.
There are several free, open source and commercial offerings in this field. Unfortunately most of them are written in Java. I really don't like Java (a rant for another day) and since the most important ingredient for success of a hobby project is motivation, working in an environment you don't enjoy constitutes a really bad start. My language of choice is C++, so I'll want to have a server written in C++.
The server will have to implement pretty much all of the game logic (never trust the client), will have to do all authentication, database connection management and socket connection management. It'll have to run 24/7, be parallelized (in order to handle multiple simultaneous connections well and take full advantage of today's hardware) and be reasonably efficient so it won't break down too quickly under load. It should be stable and resilient against the most common types of attacks (SQL injections, floods, spoofed packets, ...). It should be able to compose individual messages into larger packets in order to bundle traffic into few packets per second/per client. It should be able to gracefully deal with error states like unexpectedly disconnected clients, slow connections or garbled packets.
Since browser games must be considered a service as opposed to shrink wrapped product, programming and content creation tasks once the game is successful will be at least as important as during initial development. This means hot-patching and updating the server with new content and bug fixes should be painless and without interruptions of service. C++, being a statically compiled and linked language, isn't very good for this type of problem. However, all things considered, I still believe it to be the best choice. I hope to work around it's limitations with a very data centric design and maybe one of these entity systems that seem to be all the rage amongst game developers lately.
Tall order? Probably. Fun? Sounds like it to me ;-)
No comments:
Post a Comment