Garbage collection considered harmful

I think garbage collection is one of the biggest disservices modern programming languages brought upon us. It is touted as a silver bullet and apparently no new language can live without it. Java, Python, PHP, ActionScript, VisualBasic, C#, Ruby, ...

Why do I think garbage collection is evil?

• the problem it promises to solve isn't actually solved. You can still easily get memory leaks by building circular references or forgetting to unregister event handlers. However now these leaks are much harder to track down and fix.
• the problem of memory management, i.e. efficiently using the available memory is made tremendously harder. You give up all control over when or even if your objects get collected. There is no easy way to make use of the problem domain knowledge the programmer has and the garbage collector hasn't. If I know in advance I'll need a lot of memory the next frame it makes sense to clean up ahead of time. The garbage collector can't know this and will be caught off guard, causing performance drops. Also, how much memory is wasted for "zombie objects", that just linger around, waiting to be collected? Trying to fine tune an application's memory profile and reducing it's footprint feels like having to work blindfolded, in a straight jacket with your feet stuck in the mud.
• as far as I know no one has figured out yet how to combine garbage collection with deterministic destruction. Destructors in garbage collected languages are either non-existent or worthless because you don't get any guarantees when or if they'll execute. This kills one of the most useful programming idioms ever invented: RAII, or Resource Acquisition Is Initialization. You acquire a resource in a class' constructor and release it in the destructor. There is a well defined sequence of events and the destructor is guaranteed to be called, you cannot forget to release the resource. And before you say garbage collection makes alloc/release patterns obsolete think again. There are other resources besides memory that follow the exact same pattern with potentially catastrophic consequences if you forget to release them: file handles, network connections, vertex buffers, audio loops, database connections, database transactions, locking textures, mutexes... I'm sure you can think of more. And this is not even accounting for application specific logic like undo/redo patterns.
• this is related to the previous point about RAII. Without deterministic destructors writing exception safe code becomes very hard indeed. Instead of having all your classes clean up automatically after themselves you have to manually remember to bracket everything with try/catch/finally clauses. As a direct consequence you'll need absolute information about what code may throw exceptions and when. Knowledge that often has nothing to do with the problem at hand, is easily forgotten and is often buried under layers and layers of code. Hence Java-like crutches of requiring exception specifications for every method.
• you lose value semantics for everything but the simplest native types. There is a distinct divide between native types like int and objects. While the former are passed around by value the latter can only be passed by reference. This causes lots of confusion and ugly hacks (Java's int vs Integer) and often forces you to write less efficient code.

Contrary to popular belief memory management is not a problem in C++. In fact, in modern C++ you hardly ever allocate memory directly. I can't remember the last time I had to search for a memory leak but I do have to minimize memory usage of my programs constantly. Yes, even in times of multi gigabyte RAM machines you easily exhaust that memory when dealing with lots of concurrency or just large complex problems. Now garbage collection solves a problem I don't have (leaking memory) while making a problem I do have (using too much memory) infinitely harder to solve. And before anyone says I just haven't discovered my leaks yet - some of my stuff has to run 24/7 under heavy load, even small leaks will quickly become apparent in such a situation.

Trusting the garbage collector to solve memory issues for you is like sitting in a burning house, closing your eyes to the problem and repeating to yourself: "Everything's gonna be fine. Everything's gonna be fine." until you go up in flames. Memory leaks aren't the problem, using too much of it is.

Summary: I hate garbage collection and the sooner the world rids itself of that addiction the better.

Operation Survival Server

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

Flash, Silverlight, JavaScript, Java, Unity - oh my!

I have decided to make Operation Survival a browser game. Given my design ambitions. I think that is pretty much the only viable choice. The next thing to decide is what exact technologies to use client side. The game requires some interactive 3D graphics (the globe and the isometric tactical view) and should look and feel like a dynamic game not like a static website. My options pretty much boil down to the following:

• JavaScript: There are huge differences in performance and feature sets as implemented by the various browsers. People are still trying to figure out the best way to achieve even the most basic of tasks. It does not offer a good development environment I'd feel comfortable with. It doesn't offer the breadth of libraries other languages do and it doesn't support socket connections which will be required for client server communication.
• Java: A fully featured "real" programming language with a huge selection of libraries and development tools. However, the browser experience leaves a lot to be desired and lives a niche existence. Java applets feel slow to load, slow to display and don't integrate well in the browser. Still, there are good examples as well and Java would certainly be a viable choice.
• Unity3D: Very cool technology. The only one of the bunch supporting 3D acceleration. The development environment and content creation tools are top notch. It runs on the iPhone. Unfortunately it requires a custom plug-in thus presenting an extra hurdle. It's also not as mature as the others and the plug-in crashed my browser the first time I have tried it. It is not yet widely adopted and probably needs a big killer application to spread (what videos did for Flash).
• Silverlight: Microsoft's offering trying to go against the dominance of Flash. Best of breed development environment in the form of Visual Studio. A choice of solid programming languages like C#. Hasn't spread nearly as far as Microsoft would have hoped for. I never could get the plug-in to work with FireFox. I also doubt Microsoft's ability and willingness to really offer wide platform and browser support. They are in a conflict of interests there - support Apple (Safari, iPhone)? Google (Chrome, Android)? Linux?
• Flash: The dominant platform for rich Internet applications. Runs pretty much anywhere. Offers a decent standardized programming language with ActionScript 3.0. Unfortunately it is controlled by single company, Adobe, as well. However, I don't think Adobe is in a conflict of interests as bad as Microsoft is. There is a free command line compiler and usable free open source development IDE in the form of FlashDevelop. There are tons of libraries for graphics, user interface and even 3D. Market penetration is close to 100%. Everyone who has ever used online video from Youtube and the likes will have flash installed.
• HTML(5), WebGL, ...: Although these sound very promising and some amazing demos of their capabilities exist they are not nearly ready for prime time yet. It remains to be seen whether they'll ever reach wide spread adoption and whether they actually offer what I need. My experience from working with HTML, CSS, JavaScript (i.e. Ajax) is that you spend the majority of your time fighting the tools and limitations of the environment rather than progressing with your actual content.

Given these observations I think Flash is the right choice. Write once, deploy everywhere is a huge advantage over write once, test everywhere like you had to do with HTML and JavaScript. It does require a plug-in, but the most ubiquitous and unobtrusive of the bunch. It is closed source and controlled by a single company, but again, I think the lesser evil of the given options.

So Flash/ActionScript it is.

Next up: What's it gonna be for the server?