Gluon Sprint Wrap-Up

On October 9 through 11, a dozen developers gathered in the Nokia Offices in Munich to bring the vision outlined in Dan Leinir's blog about the "Future of Game Development in KDE" to life. After three days of hard work, the developers joined hundreds of other Qt developers for the Qt Developer Days 2009 (thanks to free tickets provided by Nokia).

The purpose of this article is two-fold; first and foremost it is to describe the happenings at and results of the Gluon developer sprint. Secondly, however, it also aims to explain in further depth what Gluon actually is, so the casual observer is not left out. In the age-old tradition of defining something before using it, the second part shall happen first.

Gluon Sprint attendees


Many have been asking "So, what exactly is this Gluon thing?" Well, that's really where it becomes a little complicated. Gluon is not a single piece of software, but rather a collection of software and a community to go with it.

The info-graphic above shows how Gluon is a way for game creators to create games, distribute them to their players and get feedback on their game directly - all using a single set of tools. The game developer comes up with the idea, which they then use Gluon Creator to develop into a game. From Gluon Creator the game is published to the world, through, and Gluon Player then downloads those games. The players of the games can then talk with each other about the games, and give feedback to the game developers about the games they create.

The software itself is thus separated into three distinct parts:

  • A set of libraries (currently KGL, KAL and KCL, probably with more to come)
  • Gluon Creator
  • Gluon Client

Gluon rocks

The libraries contain common functionality that can be used by Gluon applications, exposing for example the audio playing capabilities of OpenAL in a Qt-friendly library, KAL.

Gluon Creator is the tool inside which games are created. It is a way of putting together building blocks that make up the game, named GameObjects and Components, in an efficient, easy and consistent manner. Furthermore it allows for easy distribution of the games to potential players through the next generation of GHNS publishing technologies, namely the specification Open Collaboration Services, of which is an implementation.

When dealing with Free Software the community is very important. Without the community a project is really just a potentially interesting academic exercise. In comparison Gluon Client is not just a way of consuming the games (which are downloaded via the OCS system). It allows gamers to report back to the creators and provide feedback through ratings, donations, comments and so on. Gluon Client also allows players to interact directly with one another by allowing them to chat, submit high scores and share screenshots as well as other game-specific content.


Gluon activity: 9th place on during the sprint

Gluon was conceived when the project's creator, Sacha Schutz, looked around the internet and saw how popular casual games based on Flash were. He saw the need for something which would make it possible to create similar games in a simple manner using technologies unrestricted by the closed world of proprietary software.

He worked on it more or less alone for just under a year until going public with the idea. He did not want to go out to the world with something which looked like vapourware; rather he wanted to have something to show first. When he finally showed off the work he had done to a small group of people at the Gran Canaria Desktop Summit, what he had were the libraries and some examples showing off the possibilities of those. These possibilities included the ability to handle input in a manner unprecedented in Qt software through KCL, a simple way of managing discrete objects of data in an OpenGL viewport through KGL, and a way of handling sound playback through KAL. What he lacked at the time was a more coherent vision for the project.

This is where the enthusiasm shown by Sacha inspired others from the community. They decided the project seemed sound, and that Sacha's initial project vision of creating a Flash-killer designed for creating the style of games he had seen was an interesting point of departure for a cool new Free Software project.

After this first presentation a vision slowly started to take shape, and finally during August, things started coming together as the team began work on a more game-centric set of libraries and concepts: the GameObject Hierarchy and the Gluon Game Project concept. The next step, then, was the developer sprint...

The Sprint

A pleasant working environment stimulated progress

The Gluon developers' sprint came about as the result of an idea of Knut Yrvin, community manager at Qt Frameworks Division at Nokia. During GCDS he was approached by yours truly regarding the community tickets for Qt Developer Days in previous years. He suggested Nokia could host a sprint leading up to the conference, and asked that a purpose be defined for the sprint. So, on the 8th of September, the first announcement of the sprint was launched, by way of a blog entry with the somewhat provocative and desperately hype-tainted title The Future of Game Development in KDE.

This gathered some amount of interest from a good selection of community members - those interested in using the finished tools, but also those interested in creating those tools. After only two weeks, twelve people were found who wanted (and had time) to take a week out of their calendar in the start of October and attend both the sprint and the conference.

Sharing ideas at the sprint

So, on the 9th - 11th of October, the participants converged at the Nokia offices in Munich, ready to work on the future of game development in KDE as the blog entry had indicated. During the weekend, a number of presentations were held, describing other tools that each of the participants had experience with (such as Unity3D, VirTools, Blender Game Engine and others). Many an active discussion was held, on topics such as input handling and sound management, as well as 2D versus 3D. Much brainstorming was conducted on topics ranging from the Game Project concept to the distribution model to the user interface of the Gluon Creator tool.

Last but not least, there was much socializing. This is a vital part of any developer sprint, as it means that the participants get to know each other in a way that is not possible simply using the normal channels of communication such as IRC and mailing lists. Most of you reading this article will be aware of what problems that can occur in those channels - most prevalent of course the misunderstandings brought on by the lack of emotion and body language in text-only media.

Tangible Achievements

Discussing Gluon

However, during the sprint not only these arguably somewhat fluffy goals were reached. More tangible results also appeared. After returning home from the sprint, the participants sent emails to yours truly with information on what they had conceived over the course of the sprint, both in terms of code and otherwise. Below is a summary of these.

Luciano "mikelima" Montanaro highlighted that other than that he "learned from you all about the Gluon components and the high profile objective that is to be achieved" he had "dusted up my svgoptimizer program" and that he was "adding features to it." Furthermore he hopes that "it could be useful in the Gluon Creator, as part of the final packaging steps -- or to KDE in general, since SVG graphics is used in so many places."

Sacha "DrIDK" Schutz was more direct about his coding achievements:

What I have done:

New class KGLPainter which help you to draw openGL primitif using VertexBuffer Array. For example you can code like this:

void QGLWidget::paintGL()
KGLPainter painter;

The Blok game in action

New class to add text as Item by generating an openGL texture: KGLTextItem * text = new KGLTextItem("gluon rocks")

Improve KGLFx: Now we have 5 shaders Fx:

  • KGLBlurFx
  • KGLMosaicFx
  • KGLPosterizeFx
  • KGLLightFx
  • KGLGrayScaleFx.

But We are waiting for QGraphicsEffects to have a deeper look at it.

Improve KGLView: Sandroandrade and me have worked on the KGLView and camera. I tried to replace KGLView by KGLLib::GLWidget and use the rivo library to use QGLProxyWidget. And it works great!!

The Blok editor

The same went for Sandro Andrade, who wrote the following:

Implemented features during Gluon Sprint:

  • Enhancements in KGLView: openGL camera parameters were configured in order to meet screen resolutions. This allows for really going fullscreen, in contrast to the squared GLView previously used in Gluon. Fixed a bug in mapping from view to scene by using OpenGL's gluUnProject() function.
  • Enhancements in Blok Editor: grid functionalities were implemented, levels were reconstructed, and level files now include background and ground textures.
  • Enhancements in Blok: use of new level files. Fixed a bug in sound playing.
  • Initial work for embedded widget support in KGLView: Using a QGraphicsView with a QGLWidget as viewport allows for the use of embedded widget for displaying score, lifes, and etc.

Current work:

  • Enhancements in Blok Editor to include physics and sound properties.
  • Refactoring of KGLView to ensure low coupling and separated concerns.

Kim Jung Nissen and Morten Justesen both worked hard most of the weekend on heavily re-factoring the KCL library which, until that point, had been tied too closely to the X11 and EVDEV based implementation. First work happened on the whiteboard and later it moved onto the computer, where KCL was ripped apart and slowly put back together again. This process is still on-going, but is looking to reach a conclusion very soon (potentially around the same time as this article is published).

Beginnings of the Gluon Creator

Dirk Leifeld spent most of his time hacking away at QtScript and Kross, the two scripting systems currently being investigated for use for the scripted components in Gluon. This work will allow programmers to extend games created in Gluon with custom scripted code. The reason for this happening in this manner is that Gluon, unlike many other game development frameworks, is designed to run interpreted rather than compiled. Only the components supplied with the framework itself are compiled code, while the game logic provided by the game writers is written in scripting languages that are interpreted at runtime. The reason for this is simple: Publishing a game becomes simply the distribution of a game project. When you look at the infographic at the top of the article here, it becomes apparent just why this is important.

Arjen Hiemstra and Dan Leinir Turthra Jensen worked on the Gluon Definition Language and the parser for it. They furthermore made a start on the Gluon Creator, which began its life at the sprint as an example application for testing out the GameObject Hierarchy model that Arjen wrote. See also his blog entry about the progress.

Our thirteenth participant, Harald Fernengel, who graciously offered to assist us with finding hacking space for everyone, decided to also take part in the sprint. This resulted in a lot of work from him on getting Blok to run on MacOS X. Nearing the end of Sunday, he had the game running. Without sound, mind you, but the game was running. Brilliant achievement there!


All in all, the Gluon Developer Sprint was a huge success, which boosted the already active development of Gluon into a state of overdrive: during the weekend the Gluon team ended up in the top ten most active teams on On top of this, all the participants reaped the benefits of a developer sprint as mentioned above. As Luciano puts it: "Finally, I have to say I really had a great time with the Gluon team, and it's been a pleasure to be with you during the event. And the Trolls have been great hosts, of course."

It was great to see the interest that Nokia put in us on another level - during Sunday we had a visit by Daniel Kihlberg, who is the head of Qt Service, Marketing and Sales at Nokia, who put many interesting questions in front of us about non-technical matters. This highlighted the need for Gluon to have a proper, solid vision which is actually written down. As a direct result of his visit, a document was started on the Gluon wiki named The Gluon Vision, in which is described on a higher, non-technical level what Gluon actually is. While this document is not yet completed, it is a good step on the way to something solid we can show to the world.

On a personal note, I must echo Luciano's sentiment: the Trolls at Nokia did an amazing job in hosting this sprint for us, and many thanks must go to both them and the KDE e.V. for sponsorship. It would not have been possible without you.

Dot Categories: 


I'm super excited about this project, and I hope it doesn't fizzle. Unity3D is a fantastic product, but not open source. I've wanted to make an open source game for a while using something like it, but never found anything suitable.

Hopefully we can do python scripting in Gluon... Wheee!

We're doing everything we can to avoid it fizzling :) As for python scripting, well, we're trying to figure out which scripting engine(s) to use :) Trick is, we can experiment with it without actually having to worry about impacting the rest, because of the way the whole system's built :) The way scripting is done is by creating a Component which takes care of interpreting scripts, which exist as Assets in the project. Best part is: Since your gamelogic sits in these interpreted scripts, there's no compiling or anything to get them to run on different platforms, once the player runs there... :)

Gluon seems very cool.

Do you plan to also write tools for designer (like the tools of Adobe for Flash) or the whole interface has to be created in code?

Well... i kind of thought that much was obvious from the vision document ;) We do indeed plan on (and are working on) a tool, named Gluon Creator :)

Gluon sounds great!

Do you plan to include bindings to scripting languages?
(I ask, because I wrote a fullfledged RPG rules-backend library in Python - currently mostly used for small commandline games - and Gluon sounds like a good way to publish graphical games developed with it)

All game logic will be written using one or another scripting language - either through Kross or through QtScript :) If you want to help with this, i know leifeld is happy to get any help :)