woensdag 9 februari 2011

why java sucks for game development

In my previous post on GWT, I praised how easy it is to develop a complex web application with a server backend with it. You are also saved from having to write code in javascript, which is obviously a very good thing, as javascript is one of the worst languages ever designed. However, you're still programming in java; and java is a terrible language for game development. Defenders might argue that it's a great language to write clean, modular game code; that its performance has greatly improved over the years; that it's different from writing games in c++, but not necessarily worse. I argue that it is. And here's why.

  1. No stack variables. This is the big one. Every variable (except primitive types) is a pointer, and is allocated on the heap. This is great for large objects, but not so great for smaller ones that are allocated all the time. Allocating an object on the heap has obviously been optimized to a great extent by the java compiler, but it's still orders of magnitude slower than stack variables. And you're also subject to the whims of the uncontrollable garbage collection mechanism of java, which makes it unpredictable.

    This issue arose when I was writing an AI opponent for the Line Wars game. Writing AI for a board game comes down to traversing a HUGE tree, repeating the same relatively simple function millions of times in a recursive manner. Up to this point, I was using a Coordinate class, which just contains x and y members and some functions to manipulate these. This is much cleaner than having separate x and y ints for every coordinate you're working with. However, since I was allocating these objects in the recursive functions, the entire algorithm slowed down incredibly, because I was allocating millions of tiny objects on the heap. Additionally, the garbage collection couldn't keep up, and our-of-memory errors quickly emerged, due to leftover, unused Coordinate objects from previous function calls not being deleted fast enough.

    To fix this, I had to pre-allocate all the relevant Coordinate objects and re-use them. In some places, I just removed the Coordinate and replaced it by two separate int's, resulting in much less readable code. None of these were a good solution, but at least I could move on.

    A second, less obvious consequence of this is that it's impossible to efficiently return two values in a recursive function. In C++, you would just return a struct with the data in it, which would be stored on the stack. Or you could use pass by reference variables to return the data. Since java does not support pass by reference and always allocates on the heap, there is just no way to cleanly and quickly return more than one primitive type value in a function.
  2. Automatic garbage collection. For many applications, such as desktop or corporate tools, automatic garbage collection means less error-prone code, less memory leaks and an all-round faster development time. In game development, it can cause you nightmares. Basically, you never know when the garbage collection is going to happen, so you are at the whims of the virtual machine. You can suggest to the VM that it needs to garbage collect by means of the System.gc() function, but this is just a suggestion, and nothing tells you that the VM will listen. In highly recursive code with no stack variables, not having control over the garbage collection can cause serious troubles, as described above.
  3. No operator overloading. This one is pretty obvious. Ever did some heavy duty matrix calculations with java? Then you surely noted how your code quickly started looking like a terrible unreadable mess of getters, setters and other function calls. Operator overloading is great, because it allows the programmer to map functionality to symbols that logically represent this functionality, in a infix notation (the operator is placed BETWEEN arguments). Function calls use a postfix notation: the function is mentioned first, followed by its arguments. This is counter-intuitive, especially in mathematics, where (mostly) everything is infix. ((A * x) + B) / C is just much cleaner and easier to read than B.add(A.multiply(x)).divide(C).
    Oh, and just for the record: this method of matrix manipulation in java will assign a shitload of temporary, quickly discarded objects on the heap, once again slowing down the entire calculation considerably.

vrijdag 4 februari 2011

GWT web development

The Google Web Toolkit is an extremely powerful tool for web development. It basically allows you to program a website in java as if you were designing a Swing application, and then compile it to html and javascript and run it in your browser. It comes with all sorts of incredible tools and features, such as:
  • Support for real-time debugging in your browser. No need to compile to javascript first: with a simple plugin, you can debug your java app directly in your browser as if it's a site. When using Chrome, it also provides very detailed performance and profiling information.
  • Built-in webserver so you can test everything locally (use Wampserver to run a local MySQL database on Windows, by the way, it's the best).
  • Java interfaces for lots of popular API's such as HTML5 Canvas, Youtube, Facebook, etc.
Basically, you write a java app that is translated to a static html/javascript website, which then communicates with a backend server. This backend can be a java (servlet/tomcat) server, or a simple php script that is called through ajax. The default option is the java servlet approach, which is neatly integrated with the client in a java interface. You can pass objects between the client and the server transparently, and they are serialized and deserialized without you realizing it. The disadvantage of this approach is that tomcat servers are hard to come by, hard to set up and hard to maintain.
Setting up a PHP backend is trivial, but interfacing with it is a little bit more of a challenge, as you have to handle the serialization of data yourself. This means a lot of tedious json/xml parsing and object creation. Either way, the choice is up to you, and GWT is fantastic in both scenarios.

The one main advantage of GWT is also its main disadvantage, in my opinion: you are programming in java. Java is a terrible, terrible language for programming games in. In between the total lack of control over your own heap, the lack of multiple inheritance, the lack of stack variables and the impossibility to write readable mathematical code, java is a pain in the ass to program games in. But it's still better than writing directly in javascript and html, so I guess I can live with that problem.

I have been experimenting with several GWT projects in the past month. Line Wars was my first project, and even though it isn't very succesful (nor profitable), it was a good learning school, and it really opened my eyes to the possibilities of GWT development with HTML5 canvas. The canvas context is an incredible versatile and complete drawing environment (much more so than OpenGL or SDL!), and with recent optimizations in javascript, it is no problem anymore to run an entire game in javascript and draw it on canvas. I will write a post mortem on Line Wars in one of the following posts, even though the game is not technically dead yet (I am still working on an AI opponent).

game development models

Thanks to digital distribution and social platforms such as Facebook, a lot of new development models have popped up that can earn you a good amount of money. Since I will be financing myself without any income until my first game is finished, I do need a good business plan to earn this money back. Right now, I am considering the following three models (or game types):

  1. Facebook/web games: as Zygna clearly demonstrated, facebook games, even without ads, are a viable way to earn millions. However, their business model is dubious to say the least. I don't like games that give you an advantage over other players if you pay money; I have always opposed this approach in Castle Quest. In order to make a succesful webgame, I would need a different business model. League of Legends has an interesting model, in which they offer part of their content for free, but require that you pay for additional content, without giving a disadvantage to non-paying players: they just have less variety in the heroes they can choose and how to customize them. Another option is to go for a subscription fee, or offer the full package as a one-time buy, just like normal standalone indie games.

    • Low setup cost: a server is all you need to get going, and you can expand your park or go to cloud services if the need arises.
    • I have a lot of experience with this genre through Castle Quest 1 and 2, as well as a huge fanbase which will immediately jump on a new webgame I develop, giving it a head start.
    • It's easy to reach a huge audience through social networking sites.
    • Games are almost automatically multiplayer, without requiring special effort.

    • For reasons quite unclear to me, people are still very averse to paying for webgames, while they have no problems paying money for standalone games, even though there doesn't have to be a major difference between them anymore in terms of quality. HTML5 Canvas even allows for 3D games played directly in your browser (see the Quake 2 GWT project)! Yet, it seems like, of the three models discussed here, this is the one which is the least predictable in terms of earnings. Will people be willing to pay for your additional content? Who knows?
    • Webgames are by definition asynchronous: this disables a lot of game genres. Every (multiplayer) game which depends on twitch action is not an option.
  2. Mobile games: mobile games are obviously a booming market. Success stories abound, with trivially simple and unoriginal games such as Doodle Jump gathering 5 million sales. The altometer, touchscreen and GPS open up new ways of control that were previously unavailable. Money is earned through direct sales of your games on the iPhone and Android markets, and games are often priced very low (below €1). This model lends itself more to simple, yet creative games that can be played for a few minutes and put down again without losing any progress. Most successful mobile games fall into this category.

    • If your idea is good, you can probably earn quite a lot of money with this. Everything hinges in your idea though; a good, balanced game concept will get you less far than a unique and fun idea.
    • Huge market ready to be explored, and very easy to get your game to your customers.
    • New control methods allow for unparallelled originality. This model is most likely to spawn new genres.

    • Extremely inaccessible industry. If you want to develop for iPhone (and you do want that), there are only a few options. Firstly you can get a macbook and develop on that. Secondly you can install MacOS on your PC or run a virtual machine, and develop from there, but as far as I can read, this is quite a tricky undertaking. Thirdly, you can use one of the cross-compiler tools such as Dragonfire SDK (tried it, WAY too limited), Unity 3D (you're scripting your game), or Adobe Flash. Of these, Flash and Unity 3D are both sensible options for serious projects, but still have quite a large learning curve, as I have no experience with actionscript of C#. If you also want to develop for Android, again Unity and Flash seem to be the only good options you have. Not ideal at all.
    • Some game genres just don't work well on a small screen, or without a mouse. I have played several ports of strategy games on a mobile, and it just doesn't feel right. Basically, you need to avoid clicking buttons repeatedly with the touchscreen, because they feels slow and cumbersome. Any game which requires a repeated hitting of buttons is not a good mobile game.
  3. Standalone game: the oldest trick in the book, but it still does the job. Thanks to the digital distribution revolution, publishing a standalone game is as easy as putting it up on a website and placing a paypal button next to it. Distribution platforms such as Steam make it possible to reach huge audiences with minor cost overhead, once your game has been picked up. Popular websites such as TIGSource can help your games reach an enthousiastic audience quickly.

    • I can develop in C++, which is my language of choice. I also have the most experience with this language, and have compiled and written a huge knowledge and library base over the years. Also, most of my most promising and developed projects at the moment fall into this category.
    • The Independent Games Festival seems heavily biased towards this model. This may be because mobile and webgames are just not on par with standalone games yet, but there's no objective reason for them not to be (besides that those industries are not mature enough yet, maybe). Mobile games are even put into a separate category (but are, theoretically, still eligible for the grand prize). Since the IGF is a very important source of income (through awards) and advertisement (through media attention), this is actually a huge advantage for the standalone game.
    • Developing a standalone game just gives the most freedom in terms of design.

    • Requires the largest allround investment of talent: a standalone game cannot go without proper graphics and sound, for example, while a webgame can.
    • More difficult to prototype, because it always requires substantial effort to prototype something using SDL or OpenGL.
    • Multiplayer is tricky, hard to implement and can be quite expensive. Between dedicated and central server architectures, no one choice is the best. Dedicated servers require a minimum popularity for the game so that people set up their own servers. A central server can cost a substantial amount of money right from the get-go.
Right now, I am leaning towards either standalone or webgame. But this might change considerably in the following months, as I experiment with the different models. I will also document these experiments here as they progress.

the state of the game industry

Five years ago, before I started my Ph.D, I also considered entering the game industry. However, at that time, I felt like the game industry was in a terrible slump, and wasn't ready for what I wanted to do. Indie games sales hadn't really picked up yet, Steam was still mainly a distribution tool for Valve games, and Facebook hadn't even been launched yet for the public. The game industry was a totally different world. I didn't feel like being a small cog in a large sequel-producing machine, and there didn't seem to be any other option at the time. I even got personally disappointed in the game industry as a whole, because all I got were sequels to the same games I had been playing for years.

But sometimes the stars align perfectly. Now, 5 years later, right as I am about to finish my Ph.D, things have changed completely. Whole new markets have opened up with endless new possibilities. Indie games through digital distribution are a viable way to earn money. Facebook games earn millions, and most of those games still kind of suck. The mobile market opens up the game industry to a whole new demography, and enables revolutionary control methods thanks to the touchscreen and GPS. After years of plowing through the desert of mediocrity, we have finally reached the lush shores of creativity. The perfect time for me to join the fray!

I have been doing a lot of research lately, following up on blogs and success stories of other game developers. I am starting up new prototype projects all the time, without finishing them. The idea is that, when I wrap up my Ph.D, I will pick the most promising of all these projects, and develop it for real. This will allow me to make an educated choice, instead of picking a promising idea randomly and going at it without knowing if it will lead to anything at all.

In the next blog post, I will discuss the three development models that I am considering.


Hello, and welcome to my new blog! The goal of this blog is to document my adventures (both successes and failures) as I work to become an independent game developer. As so many people out there, I have dreamed of earning my money with game development since I was a child. Many aspire this dream, and few succeed: I am well aware of that. I do, however, believe that several things set me apart from the typical "I have a great idea for a game, can anyone learn me 3D Studio Max so I can make it?" guy you see all the time on the gamedev.net forums or other similar websites.

First and foremost, I have been programming games since I was 11 years old (I am 26 now). Over the years, I have programmed hundreds of small to medium sized projects, but left most of them unfinished. My first experience as a coder was learning Superlogo, a programming language developed specifically for children. Then I moved on to Klik 'n Play, a graphical programming tool that has since spawned a lot of sequels (The Games Factory, Multimedia Fusion), which are still used today to succesfully develop commercial games (see the Knytt games, for example). I then moved on to scripting languages such as the mIRC scripting language, in which I wrote an entire RPG, and then finally PHP. In PHP, I developed Castle Quest 1 and 2. The second game was released to great success in 2002, and is still played up to this day, peaking at 2000 active players a couple of years ago. Today, about 800 active players remain. Since the release of Castle Quest 2, I have developed many small projects, most of which have been unfinished as of yet.

I also have a master's degree in computer science and will soon (hopefully ;)) have a Ph.D in computer science as well. I have a lot of experience in C++, having developed several libraries and games in it in the past (see, for example, the Cistron component-based architecture). I am by no means a newbie to programming, and am quite verse in most of the relevant modern programming languages and paradigms.

And finally, I have a real, genuine passion for computer games. And true passion and dedication can get you far. I hope that my passion, combined with my computer science experience and experience developing and finishing games will be enough to make this undertaking a success!