[ACCEPTED]-Good language to develop a game server in?-networking

I hate to say it, and I know I'm risking 19 a down mod here, but it doesn't sound like 18 there's a language out there for you. All 17 programming languages have their quirks 16 and programmers simply have to adapt to 15 them. It's completely possible to write 14 a working server in Python without classes 13 (eliminating the "self" variable class references) and 12 likewise just as easy to write C++ with 11 clean syntax.

If you're looking to deploy 10 cross-platform and want to develop cross-platform 9 as well, your best bet would probably be 8 Java. It shorter development cycles than 7 compiled languages like C and C++, but is 6 higher performance (arguable, but I've always 5 been anti-Java =P) than interpreted languages 4 like Python and Perl and you don't have 3 to work with unofficial implementations 2 like Mono that may from time to time not 1 support all of a language's features.

I might be going slightly off-topic here, but 31 the topic interests me as I have (hobby-wise) worked 30 on quite a few game servers (MMORPG servers) - on 29 others' code as well as mine. There is literature 28 out there that will be of interest to you, drop 27 me a note if you want some references.

One 26 thing that strikes me in your question is 25 the want to serve a thousand users off a 24 multithreaded application. From my humble 23 experience, that does not work too well. :-)

When 22 you serve thousands of users you want a 21 design that is as modular as possible, because 20 one of your primary goals will be to keep 19 the service as a whole up and running. Game 18 servers tend to be rather complex, so there 17 will be quite a few show-stopping bugs. Don't 16 make your life miserable with a single point 15 of failure (one application!).

Instead, try 14 to build multiple processes that can run 13 on a multitude of hosts. My humble suggestion 12 is the following:

• Make them independent, so a failing process will be irrelevant to the service.
• Make them small, so that the different parts of the service and how they interact are easy to grasp.
• Don't let users communicate with the gamelogic OR DB directly. Write a proxy - network stacks can and will show odd behaviour on different architectures when you have a multitude of users. Also make sure that you can later "clean"/filter what the proxies forward.
• Have a process that will only monitor other processes to see if they are still working properly, with the ability to restart parts.
• Make them distributable. Coordinate processes via TCP from the start or you will run into scalability problems.
• If you have large landscapes, consider means to dynamically divide load by dividing servers by geography. Don't have every backend process hold all the data in memory.

I have ported a few such 11 engines written in C++ and C# for hosts 10 operating on Linux, FreeBSD and also Solaris 9 (on an old UltraSparc IIi - yes, mono still 8 runs there :). From my experience, C# is 7 well fast enough, considering on what ancient 6 hardware it operates on that sparc machine.

The 5 industry (as far as I know) tends to use 4 a lot of C++ for the serving work and embeds 3 scripting languages for the actual game 2 logic. Ah, written too much already - way 1 cool topic.

Erlang is a language which is designed around 5 concurrency and distribution over several 4 servers, which is perfect for server software. Some 3 links about Erlang and game-servers:

http://www.devmaster.net/articles/mmo-scalable-server/

http://www.erlang-consulting.com/euc2005/mmog/mmog_in_erlang.htm

I'm 2 thinking of writing a game-server in Erlang 1 myself.

Speaking of pure performance, if you can 14 run Java 6 you get about 1:1 performance 13 when compared to optimized C++ (special 12 cases notwithstanding, sometimes Java is 11 faster, sometimes C++), the only problem 10 you will have is of course stuff like database 9 libraries, interconnectivity, scalability 8 and such. I believe there's a variety of 7 good to great solutions available to each 6 of these problems but you won't find one 5 language which would solve everything for 4 you so I have to give you the age old advice: Choose 3 the language you like and use that one.

Oh, you're 2 still reading this? :) Well, here's some 1 extra pointers.

• EVE Online uses Python for its client and server side code and it's both bug-ridden and laggy as something I don't think I should write here so that'd be an example of how Python can be extended to (poorly) serve vast amounts of users.
• While Java has some good to great solutions to various related problems, it's really not the best language out there for vast amount of users; it doesn't scale well to extremes without tuning. However there's multi-VM solutions to this which somewhat fix the issue, for example Terracotta is said to do the job well.
• While C++ is rather cumbersome, it allows for such a low-level interaction with the system that you may actually find yourself doing things you thought you couldn't do. I'm thinking of something like dynamic per-core microclustering of runtime code blocks for "filling" every possible clock cycle of the processor as efficiently as possible for maximum performance and things like that.
• Mono is far behind the .NET VM/equivalent on Windows platforms so you wouldn't be able to use the latest and fanciest features of C#. However Windows XP (x64) OEM licenses are so laughably cheap at the moment that with small investment you could get a bunch of those and you could then run your code on the platform it was meant to be. And don't fall into the Linux hype, Linux is your saviour only if you really know how to use it and especially XP is pretty damn fast and stable nowadays.

What kind of performance do you need?

twisted 7 is great for servers that need lots of concurrency, as 6 is erlang. Either supports massive concurrency 5 easily and has facilities for distributed 4 computing.

If you want to span more than 3 one core in a python app, do the same thing 2 you'd do if you wanted to span more than 1 one machine — run more than one process.

More details about this game server might 20 help folks better answer your question. Is 19 this a game server in the sense of something 18 like a Counter Strike dedicated server which 17 sits in the background and hosts multiplayer 16 interactions or are you writing something 15 which will be hosted on an HTTP webserver?

Personally, if 14 it were me, I'd be considering Java or C++. My 13 personal preference and skill set would 12 probably lead me towards C++ because I find 11 Java clumsy to work with on both platforms 10 (moreso on Linux) and don't have the confidence 9 that C# is ready for prime-time in Linux 8 yet.

That said, you also need to have a pretty 7 significant community hammering on said 6 server before performance of your language 5 is going to be so problematic. My advise 4 would be to write it in whatever language 3 you can at the moment and if your game grows 2 to be of sufficient size, invest in a rewrite 1 at that time.

You could as well use Java and compile the 15 code using GCC to a native executable.

That 14 way you don't get the performance hit of 13 the bytecode engine (Yes, I know - Java 12 out of the box is as fast as C++. It must 11 be just me who always measures a factor 10 5 performance difference). The drawback 9 is that the GCC Java-frontend does not support 8 all of the Java 1.6 language features.

Another 7 choice would be to use your language of 6 choice, get the code working first and then 5 move the performance critical stuff into 4 native code. Nearly all languages support 3 binding to compiled libraries.

That does 2 not solve your "python does not multithread 1 well"-problem, but it gives you more choices.

The obvious candidates are Java and Erlang:

Pro 8 Java:

• ease of development
• good development environments
• stability, good stack traces
• well-known (easy to find experienced programmers, lots of libraries, books, ...)
• quite fast, mature VM

Pro Erlang:

• proven in systems that need >99.9% uptime
• ability to have software updates without downtime
• scalable (not only multi-core, but also multi-machine)

Contra Erlang:

• unfamiliar syntax and programming paradigm
• not so well known; hard to get experienced programmers for
• VM is not nearly as fast as java

If your game 7 server mainly works as a event dispatcher 6 (with a bit of a database tucked on), Erlang's 5 message-driven paradigm should be a good 4 match.

In this day and age, I would not consider 3 using an unmanaged language (like C or C++); the 2 marginal performance benefits simply aren't 1 worth the hassle.

It may depend a lot on what language your 29 "game logic" (you may know this term as 28 "business logic") is best expressed in. For 27 example, if the game logic is best expressed 26 in Python (or any other particular language) it 25 might be best to just write it in Python 24 and deal with the performance issues the 23 hard way with either multi-threading or 22 clustering. Even though it may cost you 21 a lot of time to get the performance you 20 want out of Python it will be less that 19 the time it will take you to express "player 18 A now casts a level 70 Spell of darkness 17 in the radius of 7 units effecting all units 16 that have spoken with player B and .... " in 15 C++.

Something else to consider is what protocol 14 you will be using to communicate with the 13 clients. If you have a complex binary protocol 12 C++ may be easier (esp. if you already had 11 experience doing it before) while a JSON 10 (or similar) may be easier to parse in Python. Yes, i 9 know C++ and python aren't languages you 8 are limited to (or even considering) but 7 i'm refer to them generally here.

Probably 6 comes down to what language you are the 5 best at. A poorly written program which 4 you hated writing will be worse that one 3 written in a language you know and enjoy, even 2 if the poorly written program was in an 1 arguable more powerful language.

You could also look at jRuby. It comes with lots 4 of the benefits of Java and lots of the 3 benefits of Ruby in one neat package. You'll 2 have access to huge libraries from both 1 languages.

What are your objectives? Not the creation 26 of the game itself, but why are you creating 25 it?

If you're doing it to learn a new language, then 24 pick the one that seems the most interesting 23 to you (i.e., the one you most want to learn).

If 22 it is for any other reason, then the best 21 language will be the one that you already 20 know best and enjoy using most. This will 19 allow you to focus on working out the game 18 logic and getting something up and running 17 so that you can see progress and remain 16 motivated to continue, rather than getting 15 bogged down in details of the language you're 14 using and losing interest.

If your favorite 13 language proves inadequate in some ways 12 (too slow, not expressive enough, whatever), then 11 you can rewrite the problem sections in 10 a more suitable language when issues come 9 up - and you won't know the best language 8 to address the specific problems until you 7 know what the problems end up being. Even 6 if your chosen language proves entirely 5 unsuitable for final production use and 4 the whole thing has to be rewritten, it 3 will give you a working prototype with tested 2 game logic, which will make dealing with 1 the new language far easier.

You could take a look at Stackless Python. It's an alternative 6 Python interpreter that provides greater 5 support for concurrency. Both EVE Online's 4 server and client software use Stackless 3 Python.

Disclaimer: I haven't used Stackless 2 Python extensively myself, so I can't provide 1 any first-hand accounts of its effectiveness.

There is a pretty cool framework in development 3 that addresses all your needs:

Project Darkstar from Sun. So 2 I'd say Java seems to be a good language 1 for game server development :-)

I know facebook uses a combination of Erlang 5 and C++ for their chat engine.

Whatever 4 you decide, if you choose a combination 3 of languages, check out facebook's thrift 2 framework for cross language services deployment. They 1 open sourced it about a year+ back:

http://incubator.apache.org/thrift/