Ask HN: Resources for multiplayer game server development | Hacker News Reader

Ask HN: Resources for multiplayer game server development

12 pointsmcantor2 comments

I have been developing for many years in the friendly world of web apps, where HTTP requests are not persistent and the only shared resource is a database. I recently began an ambitious personal project, for both learning-by-reinventing-the-wheel and scratching my own itch, to write my own mostly-text-based game client and server. Think MUDs/MUCKs but maybe with avatars.

I've had great success on the client side so far. My language of choice for server and client is ruby. Qt has been kind to me, especially since this is the first non-trivial thick client app I've written.

On the server side I am somewhat at a loss. I need to handle multiple persistent connections with data being asynchronously transferred between the server and its various clients. I am spinning up a TCPServer which spins up a thread for each socket connection.

I am fairly certain that sockets are not thread-safe, and that some form of resource lock (such as a mutex) will be required around socket read/write operations. However, without any background in this kind of programming, I have no confidence that I am even reinventing the right wheel!

I do not want to use EventMachine or GServer because I don't understand what they do. My goal here is not "write a game", but "write a game and learn how some of the lower-level stuff works".

I've found some OK resources via Google, but I would love HN's recommendations for books, ebooks, websites, example implementations to study, bits of wisdom, and so forth.

Thank you!

The link is about FPS networking so not really applicable to what you are doing, but an interesting read non the less. http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...

I am spinning up a TCPServer which spins up a thread for each socket connection. I know this is just for learning purposes but this really isn't the way to do it. Use select or your platform specific enhanced version(kqueue, epoll, IO completion ports.)

I would probably have a separate communication thread handling all your sockets(with select) with two queues of messages, one for each direction. While the main thread handles processing messages.

This is probably a little too entry level but it makes a good reference. http://beej.us/guide/bgnet/

Take a look at the c10k problem, a classic resource for this problem domain: http://www.kegel.com/c10k.html

You probably don't want to spawn one thread per connection, but get notified by the operating system when one of a bunch of TCP socket connections has an event for you to handle. You can achieve this by the kernel calls epoll, poll, select, kqueue. For Python, I recommend taking a look at tornado (https://github.com/facebook/tornado), an asynchronous socket handling framework. In particular the "io-loop", which you could use for handling the connections.

As for serialization protocols, don't roll your own but consider JSON for maximum flexibility, and protocol buffers for maximum efficiency. For communication between servers consider well known libraries and protocols such as AMQP (eg RabbitMQ) and Redis pubsub.

Be sure to read up about Linux kernel settings to improve the number of maximum open sockets, etc. Here are several good readings referenced: http://serverfault.com/questions/10852/what-limits-the-maxim...

Also, you'll want to get familiar with some tools you'll be using a lot, such as lsof and netcat.

About the infrastructure design: you'll most likely end up with several different server applications and possibly a number of simultaneous running instances. Consider Amazon EC2 micro instances or something similar to start with.

I'd recommend to experiment with building several prototypes before the real product, getting to know the approaches, architectures, bottlenecks, etc. Enjoy the learning experience!

Finally, spend enough time on the supporting tools, such as automatic deployment (chef, puppet, fabric), automated clients, etc. which will make your life a lot easier! :)

Reply on news.ycombinator.com