Amarok Blog

Starting the day with a hearty breakfast is very important, and for the people at the Gluon developers' sprint this is of course no different - anything but, in fact, as the sprint is quite intensive. And so, the day started out with having breakfast in the hostel's cafeteria, which served a quite straight forward continental style breakfast service with cereal, bread, cheese, meats and all that's included. Oh yes, and cocoa milk.

After the breakfast, Harald Fernengel picked us up. For those of you who don't know, this is the guy who made sure that we had hacking space at the Nokia offices in Munich. He is, as his name implies, an angel. Well, technically he's a troll, but you get the idea. But we already knew that trolls are, in essense, just angels without wings So, he picked us up, and had even been so good as to buy us tickets for the duration of the sprint. We then got on the tram, and en ruite Harald informed us of the interesting points - one of the best beer gardens in Munich is right next door to us, there are beautiful churches, and the shopping street was where we changed to the U-bahn.

Finally we got to the office, which is in the business area - a surprisingly green area all things considered - on the fifth floor of an office building. Very nicely laid out offices, where had been arranged coffee and soft drinks for us - news of course received by the team with sounds of glee and much joy. After setting up the laptops and checking our mail and news and such after a couple of days, it was time to start the first topics which, as it turns out, ended up taking most of the day.

Just before the first point, Knut Yrvin (for those who don't know, he's the community managet for Qt Nokia) showed up to hang out with us. In the tradition of such things, he brought along a toy for us to play with, namely an N900. Now, of course, everybody wants one (even more than they already did ).

Kim then started his presentation, in which he described what Unity3D's workflow is like, and some of the base concepts in it. One thing that i personally got out of this refresher is how scripted Components are handled. They are not handled in any magical way, like i thought i remembered. In stead, they are handled very simply by a Script Handling Component, which has a script Asset attached. The component then analyses the script, and exposes the public fields in the script as properties. This means that the concept is much cleaner as well - scripts are no longer a special case, they are simply assets. Furthermore, it meant that everybody in the team now has an at least superficial understanding of how Unity3D works, and what sort of workflows we are working towards supporting.

Afterwards, Sacha requested i describe the GameObject hierachy in some more deep detail by describing what you would do to create Pong using this method. After a bit of talking about the GameObjects and how you add Components to them, and the fact that a Prefab is really just an instance of a GameObject that you can change a few values in, but which stay the same as the prefab, we eventually came up with a layout with two instances of a Paddle Prefab (which is just a GameObject with a sprite renderer, a box collider, a mouse input component and a small scripted component which reacts to the mouse input), one GameObject named ball with most of the actual game logic inside it (a motion handler which simply moves the ball in a set direction at a set speed per frame, and a collission handler which simply checks whether the ball has collided with something, and reacts accordingly (hit one of the end walls the person owning that wall looses one point, hit one of the paddles or one of the side walls the ball bounces), and a sound emitter which the collission handler tells to make a sound at appropriate times) and four bits of wall with a box collider (made of by a sprite renderer and a box collider). The end result of this is visible in the picture to the right. Coding on your feet is fun!

Around two in the afternoon, a little later than originally planned, and after people had spent some time hacking around, working on the different parts of Gluon, it was decided that it was time to grab something to eat. So, we all got ready to go out, and as we gathered in the social area of the office, Harald handed out meal tickets to everybody and we went down to the mall next to the offices. The problem with this plan, as it turned out, was that in Munich, a lot of places are closed on Saturday. So, we ended up going to the super market, where Harald bought lots of food type things (bread, toppings and the like), and instructed the rest of us to buy random other things (i.e. snacks). So, we all ended up buying all kinds of silly things, like bisquits, crisps and so on. This mishap ended up turning out quite well, since what happened when we got back to the office was that we all gathered around the social area, where we talked much about open source in general.

After lunch was completed it was time for the final run of presentations. So, after poking around with remote desktop a lot (since Rune had also forgotten his VGA converter, and had a laptop which was not compatible with the other converter) we ended up able to see him showing off the Blender Game Engine. Two important things came out of this: We saw how not to design user interfaces -around half way in, Rune mentioned that what people couldn't see too easily was that on his netbook's screen, sitting beside his laptop, he had the keyboard reference open - basically every key makes Blender do something, and they have decided to focus so much on effectiveness that learnability has gone completely out the window. As such, they have created the 3D modelling equivalent of the Vi editor. Extremely effective, but with a learning curve greatly resembling a mirrored version of the Debian logo. The other important thing which came out of this presentation was an introduction to the interaction management system in the Blender Gane Engine. Short short version is that in Blender, any object in the game world can have three types of game related data added to them: Sensors, Controllers and Actuators. A Sensor is something such as for example mouse input, a keyboard button or a magic 'always' sensor which is simply always true. A Controller is a piece of logic which can define a number of outputs associated with the sensor's values, and an Actuator acts on the game world (for example moving an object around, setting colour values and so on). So, most things can be scripted in this manner without writing any code. Afterwards Virtools was discussed, which has a similar graphical scripting system, which was described by someone as "Horrible for programmers, but amazing for game designers and graphics people".

After this Kim, Morten and i gave a short introduction to our university project about Behavior Trees, which will be implemented as a component for Gluon. A short explanation was given of what a behavior tree is, something i won't bother you the reader with (if you are interested, keep an eye on this blog as you can be sure there'll be something about it at a later date, when we're closer to project end), but the really interesting part here was the properties editor that is found inside the behavior tree editing tool. For those interested in the code to this thing, it can be found on gitorious: http://gitorious.org/gluon-bt/gluon-bt/blobs/master/src/gluon-bt-editor/btpropertywidget.h and http://gitorious.org/gluon-bt/gluon-bt/blobs/master/src/gluon-bt-editor/btpropertywidgetitem.h (plus their accompanying cpp files, of course). What this allows us is to basically just grab this code, do very few changes to it and have it work on GluonObjects, which are the generic objects that make up a GameObject hierarchy (GameObjects, Assets, Prefabs and Components are all GluonObjects). Much more on this later - when we've actually got something to say properly on Gluon Creator (hopefully tomorrow).

The final large-scale discussion that happened was regarding the Gluon Project concept described on the wiki. What came out of that discussion was a more or less straight forward resolution that building Gluon Creator on top of KDevPlatform might well make sense - the reasoning behind this being that this already has functionality for version control and handling projects, and that what we would need would be to implement a project management plugin for it, and then create a UI based around it. Whether or not we will be using Sublime is entirely up in the air, and it may be overkill for what we need, but KDevPlatform does seem like the logical choice. It would also mean that any scripting languages we would support needs some simple coding assistance. To implement this we could either do something simple ourselves, or we can create language support for it in KDevPlatform. The KDE way, it seems to us, would be the second option. Any help with this endeavour would be greatly appreciated! (as, of course, any help with any part of Gluon ).

At six, the larger discussions finally ended and people started to work on coding more heavily. People all started playing around with their respective parts - much pair-programming or group-programming happened, with a number of small teams gathering around one or two machines, working hard on getting this or that piece working (especially KCL on MacOS X and KGL in general is getting much love, as is the Definition Language handler, plus its assisting classes).

Finally at eight it was time for dinner... But people were so busy that we ended up working way past that, not leaving the office until an hour and a half later, when Knut stood up and exclaimed that we had to leave now or face the possibility of having nowhere to eat. This meant that when we got to a restaurant which was open, we went in there and were instructed that the kitchen was almost closed. However, a quick decision later, and everybody has beer on the table, and a few minutes later food starts getting served. Fastest service ever for twelve people, i'm sure! Kudos to the kitchen team at Weisses Brauhaus for providing us with such brilliant service - especially considering the waitress didn't understand a word of English, and still seemed very happy (stressed out though she was by the sudden influx). After dinner, which of course included the mandatory discussions of open source politics and general life stories, we decided that it was time for ice cream. In the words of the ice cream gurus: Pleasure is the path to joy!. We managed to find our way home at around 0100, and all went straight to bed.

All in all, a really nice day!

Game Concept of the day: Hungry Hungry Hakcers - keep your hackers fed, or they get angry and you lose the game!

Final point: We can do better!