Google Summer of Code - Students View

After more than 2 weeks of deliberation and discussions among all mentors and admins we have finally reached a conclusion for GSoC. First of all congratulations to the three selected students:

• Hilnius: Network Core for SuperTuxkart - implementing network multiplayer but not lobby or rewind
• Cand: Graphical improvements
• Uni: Networking lobby

It was a very difficult decision for us to make. For each proposed idea to us we usually had at least two students we would have loved to pick. But we had only three slots (which is for a first time GSoC organisation quite high), so we had to choose. Congratulations to Hilnius, Cand, and Uni.

Unfortunately, this means that we disappointed 75 other students. We would have gladly taken 6 or so more (but it would not have been realistic to try to mentor that many students). We hope that next year we might have more mentors and more slots, and will be able to accommodate more proposals. In case that you are interested in some statistics: here are the number of proposals we got for each of our suggestions, and the average ranking in each category (1 to 5). There were 6 proposals suggesting new things (including one that proposed to make a 3d kart racing game where you have powerups ... hello, did you even play SuperTuxKart??)

We won't have time to give individual feedback to all students, but here are some common issues we noticed in various sections. First of all, it certainly helps if you spell the name SuperTuxKart correct - we saw quite a few variations ;)  But otherwise some comments about frequent problems we noticed:

Patches

While most students had no problems with the patches, we noticed that many of the patches were not tested. A simple example is our suggested patch of replacing printf with Log::warn/error etc calls.
Assuming a patch is correct just because it compiled is not really sufficient. In one case a patch would compile on linux, but not on Windows. Reason were missing parameters in function calls - something that is easy to notice if you verify that your patch works. And people did not notice that e.g. Log::warn would already print "[warn]", so any 'Warning:' included in the text is not necessary and should have been removed. But for the record, we did not really exclude anyone because of those problems, since we stated that we mainly wanted to see that using SVN etc. worked. We did rank someone who attached a patch as image (png) ... quite low, since this showed us that the basics of a versioning system were not fully understood, and this is an essential skill any student needs to have.
Some students surprised us by taking on some rather complex bugs that were in our tracker, so we already have quite a few improvements for the next release because of this.

Battle Mode

The most popular proposal. Many proposals were suffering from missing details, e.g. not explaining what information was exported by blender into SuperTuxKart, and how it was used - they just assumed that there would be a graph. Or missing was just how a target kart or target item were selected, how the AI was meant to drive (i.e. could the existing AI code be used). Some proposals were more research oriented - and while I'd love to do more AI research work, for GSoC we had to accept proposals that had in our opinion more chances of success - last thing we want is to have a good student, with an idea that just doesn't work properly.

Race Verifier

That somewhat simple sounding idea proved to be quite difficult. Many people suggested to just include the stk_config.xml file (careful study of the code would show that also all kart.xml files needed to be included). More advanced proposals suggested to encrypt the file, in order to prevent tampering with the data. While this sounds really convincing, they are all missing the point that if you compile your own sources it is trivial to write into that file whatever you want, and use completely different values in-game. Only a few proposals suggested to actually use STK itself to verify if a race is correct, and only one proposal suggested to analyse statistically what items were collected in a race (this suggestion can easily be improved by just storing the random number seed for each box - from that number the sequence of collected items can be reproduced).
Overall, this project idea had the fewest good proposals in the end. I guess that because it could potentially be a stand-alone program many students either underestimated its complexity, or just missed the point.

Rewind

Many proposals ignored that you need to store the user events, e.g. steering, and firing. When you rewind and replay from a previous state, you still need to fire, accelerate and steer at the right time, otherwise the whole point of rewinding is missed. Better proposals suggested to make other use of the replay data, e.g. to use this data to show a slow-motion shot of finishing the race.

Summary

Some general comments to wrap this up: Similar things can be said for almost any proposal. Generally proposals of people who have spoken to us received much higher rankings. Especially in the section of new proposals that was obvious - if it hadn't been for Hilnius's proposal, its average would have been much lower.

One frequently asked question or concern was that many students had no prior experience to open source development. We made a point of reading first the actual proposal before reading the background of students, but still in general people with more practical experience received better scores. Their proposals were just more complete, i.e. thought out every step of the way to the goal. For any student who might be interested in participating in a future GSoC I would strongly recommend to use the time till then to get more experience - and participating in Open Source would be a very good candidate. While I can't speak for all Open Source projects I know many will welcome new contributions, and will be happy to help anyone who wants to learn and is willing to put effort into this.