The Future of Game Development in KDE

Do you want to go to Qt Developer Days in Munich, October 12th to 14th? If so, read on!

Traditionally, game development in KDE has happened much like how you would develop any other application: You start out with an idea, then you boot up your vi/emacs/kdevelop or whichever other coding tool you use, and you start hacking together your game logic. Later on, or during this, you team up with a graphics artist, and maybe a sound artist, and you all work together to create a pretty, well sounding game. Now, we have seen in KDE 4 that this actually works.

However, there is a fly in the ointment. One of those big, blue ones that just won't go away when you swat at it.

First, of course, the graphics people and the sound people at some point have to start pestering the programmer to change their code so that their work can fit into the game better. Unless they know a little code, they have to rely on the coder to change which pieces of graphic and sound are loaded and played when and where. This makes it difficult for the sound guy to time his sounds so they fire at the right time, and for the graphics guy to time his animations so they play at the right time.

But more than that, however, you have the problem that every time you start writing a game, you as a programmer end up rewriting the same code again and again. You write an input handler, you write a simple (or not) playing field, you write your gameloop, you write a structure to manage each of the objects in your game... Why is it that this needs to happen? Why can you not simply start up a tool, and start writing your game immediately?

In other worlds, you have a number of tools to assist you in your task when you want to create a game. In the Windows and MacOS worlds you have tools like Game Maker and Unity 3D, and in our own world we have... Not a single thing. The closest thing we have is KDevelop 4 which makes some things easy for us, but even that is just a generic IDE, it is not something really geared to making games, and most importantly: You could never give a graphics artist or a sound artist KDevelop 4 without risking them curling up in a small ball and making unpleasant squeaky noises, something which is not particularly conducive to getting a game made.

So, today i offer you the potential for a brand new scene, a new world: A world in which KDE ends up taking the indie games scene with a storm.

Today, i announce: Gluon Creator.

Based on the Gluon project's heavy legwork, the powerful systems inside KDevelop 4 and an investigation into workflows, Gluon Creator is a project which will aim at creating a tool designed specifically for creating games, which is useable by all the artists that make up the team behind them: Graphics, sound, level designers, game designers, coders and all others involved in the process.

The connection this has with DevDays? Simple: Nokia has gracioucly offered to sponsor up to 15 people attending Qt Developer Days in Munich*, and in connection with this it was suggested that a developer's sprint should happen the weekend leading up to DevDays, in the style of those held for the KOffice, Amarok, KDevelop and other teams. The topic of this sprint would then, is my suggestion, be the initial creation and investigation into what would be needed for Gluon Creator to happen.

So: To attend Qt Developer Days 2009 in Munich and the sprint leading up to it, get in touch with me, either by commenting on this entry, or by emailing me directly at admin@leinir.dk - please don't hesitate! And remember, just because you are not a coder does not mean you won't be useful here!

*: Yup, there's one in San Francisco as well, however the sprint there will have a different focus, and i'm only sporadically involved with that one anyway and will not be going