Amarok Blog

On the third day, the developers all rose from their beds to meet up in the lobby of the hostel and then proceed to breakfast. Here, Sacha could tell us that he had just recieved an email from our final sprint participant. As it turns out, poor Eugene was so unfortunate as to miss his plane and thus be unable to show up. So, with heavy heart we decided that there was nothing to be done about that, accepted it, and continued on to go forth into the new day. Of course, it continued in the same vein, as the tram we were supposed to catch decided to be a no-show Luckily Munich has so many public transport options that it wasn't a problem - there was a five minute walk to the nearest S-bahn station, so everything soon found its way back on track.

The first thing that happened when we got to the office was, interestingly, that it was discovered that some of my code was causing horrible crashes all over the place. So... that needed instant fixing - which Albert was so nice as to provide While that was going on, Arjen began working on a small example showing how to actually use the Definition Language handler, and later on he worked on creating a Qt Model (the Model/View sort) which represents a GameObject hierarchy - during process, of course, a large number of bugs in my untested code was found, and for the most part fixed. There are still some left, which will be worked on tomorrow.

All the while that was going on Sacha, Sandro and Jure worked hard on Blok, the first Gluon game which was included with the tech preview last week, and the Blok Editor. Kim and Morten continued their work on KCL's MacOS X support, and towards the end of the day reached a point at where they realised that KCL in its current form does not function well in a cross-platform environment. So, they are planning on restructuring the entire library over the course of Monday.

Just before lunch the manager of all things not actually programming in Qt joined us, and he hung out with us for lunch (pizza sponsored by Nokia) and according to Knut his managerial roles included the pizza we were eating - so, much applause happened there Other than that, over lunch was discussed the visions for the project, and what sort of things Gluon would actually have on existing solutions. This, of course, is something which would be very interesting to have as a document - for example on the wiki - stating the goals of the project, and its unique selling points (to use a term which sounds a lot like marketing... which of course is what it is ).

After lunch, people go back to the room - after finding out that someone has borrowed the projector so that Wii Tennis is not possible - and return to working at their respective tasks. One highlight of this: At 15.45 Harald exclaims: "Good news - Gluon builds and runs on Maemo5. Bad news - It uses the wrong style. Good news - 50 fps. Bad news - doesn't render anything." At 18:28:41 he posts the following on IRC: "gluon on Mac OS X (native 64-bit Cocoa application): http://chaos.troll.no/~harald/Block.tiff"

In between Harald's two statements the team decided to do some brainstorming on the user interface of Gluon Creator. As can be seen on the image to the left, a lot of investigation was performed on what other similar projects have done - in this case you see a search for Game Maker. Other projects looked at were the already mentioned Unity3D, Blender Game Engine and Virtools. As an experiment, the mocking up was done in two places at once: Leinir did the mocking up on the flip-board, and Sacha did mocking up in Qt Designer simultaneously, shown on the wall with the projector (sorry, no image of this, but you can see the flip-board on the picture to the right ).

Having learned on Saturday that going out for dinner late is a really bad idea in Germany, we left the Nokia offices at around eight. We headed for a restaurant recommended by Harald named Hacker-Pschorr and arrived there in good time - there were almost noone else in the positively enormous restaurant (as it turns out, the huge hall we were in, with surely enough room for at least three hundred seated guests, probably more, was only one of two of such halls) and ordered ourselves some food and beer. Of course, since this is a Bavariant themed restaurant, when you order a large beer... You get what you ask for. The picture to the left shows just how big those beers really were Even better yet, the beer (their house brew) was absolutely stunning - wonderfully smooth and very tasty - and the food was just as good. Brilliant food and drink, coupled with good company, equalling a very pleasant evening of dining out with the team. Afterwards, we all walked home (the restaurant was well within walking distance of our hostel) and went straight to bed. So, all in all, a really great day at the Gluon Developers' Sprint!

Game concept of the day: Knitting Hero (multi-touch, with two styluses)

Final point: i need a new camera... hey, is that an N900?

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!

Friday, everybody's arriving. After driving for 12 hours, the 4 person Danish contingent arrived in Munich safe and sound, and found two people already at the hostel, Arjen Hiemstra and Dirk Leifeld, both sitting in the lobby, where we joined them.

As most people were slowly trickling into the hostel, we all hung around the lobby while the rooms were made ready for us. Much random talking happened, and around four the room keys were finally handed to us, and everybody put their stuff in the rooms and such.

After this we all went out for a meal at a nice little restaurant down in town, where we were introduced to a mix of beer and soda named Radler - since only one person in the group is German (Dirk Leifeld), he was our interpreter. However, as it turned out, this was not really needed - everybody at the restaurant spoke English, so we could all order. One of the guys, of course, forgot to tell us that he is a vegetarian before we actually started ordering, so much fun ensued attempting to find a vegetarian dish in a place whose specialty is grilled foods

However, everybody was fed, and again much talking happened. One thing which was discussed around the table was the sound systems available to us for creating games. As we know already, Phonon is not really geared for such things as it is currently, and we do not know of QtMM is useful for it either. However, in Gluon there exists a library named KAL, which currently knows of two things: Playing sound effects and playing music.

Furthermore was quickly discussed input systems. Qt currently lacks an input handling system powerful enough for use in games - there's keyboard, but it is not entirely fast enough, there is mouse support, which is fine for point-and-click things, but not so good for e.g. first person shooters, however there is no handling of joysticks and the like. In Gluon we're working around this by having KCL, which is already extremely powerful - the problem it has is that it needs a new backend for each new operating system. The backend on Linux is the very powerful evdev, but on MacOS X we have one person who through the last couple of weeks has been ripping his hair out trying to get input out of the system itself, and on Windows there's nothing so far (though the idea of using DirectInput has been tossed around).

So, discussion points for Saturday now also include sound and input, on top of scripting and showing off Blender Game Engine and Unity3D which was already on the agenda. So, much to be done!

After the meal, we went back to the hostel - which has really nice rooms, with en-suite bathrooms and plenty of room for the four people sleeping in each room - and people went straight to sleep. Personally, i went to sleep after sitting in the lobby for a while, not managing to stay awake. As i later find out, around half an hour later, two more of our team scheduled to show up Friday showed up (saw the texts on my phone this morning, telling me they had luckily found their way into their room), but at time of writing i have yet to hear from the final member (Sanro Andrade) coming in from Brazil. Hopefully he will be ok - i will find out when we meet up for breakfast in a few minutes.

So, the first day went quite well, all things considered - people were tired after a long day of travelling (for most anyway, Leifeld only had three hours in a train, and others a couple of hours in a plane, bah! ) - a really good day, with much talking both shop-talk and non-shop talk, which of course is at least as important at this type of thing. Getting to know how people work is just one of those things that's difficult to pick up through email only. So, good stuff all 'round! Looking forward to this sprint

P.S.: Yeah, i know - this entry isn't tl;dr compliant, and contains no pictures. Sorry, i shall endeavour to do better tomorrow when i'm not tired!