Glenn's Development Blog


Leave a comment

Pencils down

The soft deadline has passed and that means every student should be wrapping up by now. The patches that need to be submitted to Google, can only contain code written before 16 September. In the time up until 23 September we are supposed to write documentation, and that is exactly what I have been doing the last 2 days. I’ve accomplished quite a lot this summer and am pretty satisfied, though a lot has still to be done before my work is ready for a release. I’ll definitely try to continue development after GSoC and keep on promoting SuperTuxKart.

In the last period I did some GUI for the achievements and provided a way to let people change their passwords via the client. Besides that I did some bug fixes and a lot of small improvements. As with previous posts, I am probably forgetting to mention some stuff but you can expect a rather large post after the final evaluation where I’ll try to summarize everything I achieved this summer.  I’m pretty sure I’ll pass the final evaluation and consequently receive my Google certificate. ^^

-Glenn


Leave a comment

Achievement Unlocked

Only 2  weeks left and while most of the features present in my proposal are implemented, it seems like I will not be able to finish all the small details . The main reason for this, is the unforeseen work on the GUI Engine. Even last week I encountered yet again a rather painful bug there, that resulted in certain requests being performed twice. As this caused no problems before, I assumed the error originated from my own code but after careful debugging, I noticed that it resulted from a hover event being propagated when it shouldn’t. Besides the many bugs I’ve also did multiple additions to the engine that weren’t planned and that certainly has cost me a rather large amount of time too.

So what new stuff did I achieve.. achievements! Though without much GUI support at the moment and thus no screenshots in this post. This feature required quite some considerations as you can imagine. The first one was cheating, with as end conclusion that it is impossible to make achievements cheat-proof for an open-source game; at least with our current code-base. (There was a separate GSoC project on the list which aimed at preventing such behavior but apparently nobody came up with solid ideas. So any suggestions on that subject are definitely welcome too!)

A solid framework for achievements isn’t straight-forward and every new achievement will still need some “hacking”  to gather the needed information. At this moment there are two different types supported called “single” and “map”. The first one is used for achievements that only need to store one value. A simple example of this is “Hit 10 karts with a bowling ball.”; only the current number of karts, that you’ve hit by a bowling ball, needs to be stored. The moment you reach 10, the achievement is accomplished. The other type uses a map to store its progress. As example here we have “Win a race on every track.”. As you can guess, the id’s of the tracks are used as keys and the mapped values contain the progress. As an extra, every achievement also has a flag whether or not it should be reset after a race. This way challenges like “Collect 10 nitro bottles in one race.” are also easily supported.

I believe that with these categories a lot of achievements can be added rather easily, as the users (i.e. other developers/me) don’t need to worry about loading, saving, succeeding, and notification as my framework takes care of that. Ok. Moving on. Another hard task was (and actually still is) to take care of to which user the achievements belong. The issue here is the presence of offline and online accounts. Currently when you are offline, your progress is attached to you offline account (the ones STK uses for Story Mode at the moment). When you sign in, the progress is of course bound to your online id. I know this doesn’t make that much sense, but it’s the perfect way to let new players try out the achievements, without them having to register for an online account. In the future we’ll probably provide a way to bind those offline achievements to a new account, so that you don’t lose your progress when registering.

No real new features will be added anymore (as part of GSoC). I still need to add possibilities to change profile information, an achievements page and enhance the lobby room. So I’ve still got plenty to do!

-Glenn


1 Comment

Friends and notifications!

While writing this I’m about the finish the last pieces of what is mentioned in this post’s title! It has been a rough week (and sadly enough the following weeks won’t get any easier) as I now have to combine the GSoC work with my thesis. But this post isn’t about my university work (I might do a post on that in a few months though), no-no, it’s about fascinating online multiplayer features for a superb racing game.

The situation right after performing a friend request.

The situation right after performing a friend request.

So how did I start with this first user interaction task? Well as always I added the needed database table. A simple design: a row contains the id of the performer of the request, the id of the receiver, and a flag whether or not it’s still waiting for an answer. This construction only needs one table entry for every relationship, but it has as counter-effect that the queries on this table get rather large as you have to search in both ways (like 2 sub-queries joined by a UNION :o). By the way don’t hesitate to suggest a better database structure or any other improvement!

The receiving of a new friend request!

The receiving of a new friend request!

Having that functionality in there was quite useless without being able to actually use it, so I added a search feature to let people look for friends. A list gets presented with the results, where clicking on a nickname presents you a dialog containing basic information and a few possible actions. This same dialog will appear any time you click on a user’s name somewhere in the application; like for instance in the game lobby, giving you the option to friend people you’ve just raced against . Another presented option is to view one’s complete profile. For this I added some sort of caching functionality, that you don’t have to re-fetch a user’s information each time you encounter him/her on your online adventure.

The confirmatin of accepting a friend request.

The confirmation of accepting a friend request.

For notifications to show, I had to adapt the GUI engine again: I postponed the popping up of dialogs and pushed them in a queue. When there is no active dialog, the queue gets checked and if a next one is present, it gets activated.  I also added in functionality to let a notification kill any previous dialog for callback purposes.  The first use case of these notifications is to show when a friend comes online. This is possible because of the polling functionality I’ve added. After a certain amount of time has passed, the client contacts the server for any updates. This time interval depends on whether or not you’re in a race, as the updates are less wanted while actually playing. This polling is also used by the server to check if a user is still online; when the client gets closed without signing out, the server is now able to clear the session entry using a cron job. The second use case exists out of ‘new friend request’ notifications, for this I added a new table which will also be used for future notification-needing-features like private messages.

A notification when a friend comes online!

A notification when a friend comes online!

To not let important sets of queries get interfered by others, I added transaction functionality to my database layer complete with automatic roll-back in case errors occur. The main reason I added this is to be able to fetch data from the database and subsequently perform other queries using the result, without the possibility of other sessions making the data outdated. Besides transacions I’ve also spend some time again on improving the server connection layer on the client-side. In the current state, users of the API don’t have to worry about thread safeness any more. I’ve accomplished this, again using a queue (hurray for queues!) and by exploiting the game loop. Next week or so, I’m starting on the achievements architecture… Oh and we use SSL now!

-Glenn


1 Comment

First networking video!

Yes! Already a new blog post! A short one though, I thought I should share this video real quick :

It only features a small part of my work in an earlier stage. It’s mostly a summary of Robin Nicollet’s work so far. He’s the other GSoC student working on the networking core, which mostly concerns synchronizing the different clients during races (so pretty low-level packet sending shizzle). As soon as he publishes some more information I’ll include a link here (already updated!), but for now the screen recording in combination with his stereotypical French accent should do. Enjoy!

-Glenn


Leave a comment

Mid-term evaluation result

With the start of the second part of summer, I’m glad to announce that I successfully completed the first evaluation period! A perfect occasion to thank the STK development team for guiding me with my project. So yeah.. thanks! Back to the usual stuff. Giving a complete status report is getting pretty hard, as I tend to forget the things I achieved, but I’ll do my best. I recall some annoying server-side work after my last blog post, so lets start with that.

I’m sure everyone is familiar with registration processes where you have to provide your email address to receive an activation link? Well that’s exactly what STK now has. After signing up I put the user info in the database, passwords all salted and hashed, but the account remains inactive until it has been verified by a random generated code send by mail. As I could not easily test the mail process on my local setup, I basically had to re-push my code to the API server on every update. The struggling to get this thing up and working, again pointed out that the server-side code I build upon has some unusual flaws. One I remember is the fact that all possibly needed sources are included at every top-level file (like for instance index.php) and that all the utility classes beneath don’t do any including themselves although they should. Me not knowing this, of course ran into the problem that sending mails worked when invoked from those top-level files but not from my API. With warnings turned off on the API server, it cost me some time (and lots of sweat) to realize what was going on. Once fixed, I could also use the mail functionality for account recovery. When you provide a valid username/mail-address combination you’re allowed to change your password, so you don’t have to worry about forgetting it.

The next task on the list was addon voting, a feature I thought would only take a day to implement. However, the needed GUI engine additions, the setting up of test data and adapting the server-side code made it take a few days longer. The result however is quite awesome. If you now hover the rating widget, the stars fill up to your mouse. A click then sets the new value, based on your mouse position. It’s linked to your user account, so you can only vote once for each addon (though you can change your rating afterwards).

Voting stars following my mouse!

Rating stars following my mouse!

Currently I started working on user profiles and friending options. This will take a while if I want to obtain a nice design, that is easily extendable to also showcase one’s stats and achievements in the future. So don’t expect much from my following updates, they’ll get shorter with every post.

-Glenn


2 Comments

Mid-term evaluation coming up!

Although I don’t actually feel like writing a blog post (I’d rather work on the project instead), there are a few reasons why I convinced myself of doing it anyway. First of all, it has already been 2 weeks since my last post and I kinda promised myself to keep this thing updated. A second reason is that some people requested more implementation details, mostly concerning the server-side and the needed connection for that. And last but not least : the mid-term evaluation is coming up! With this post I can present the mentors with a nice overview of my work so that they can easily let me pass ;).

So what did I achieve? Most of my time was spend on an asynchronous networking layer. Now for those of you who don’t know what that could possible be, I’ll explain the difference between the two options. With my first draft of the layer, which was thus synchronous, the game would be blocked during a server request until a reply has been received. With asynchrony the application just keeps running while a separate thread takes care of the incoming requests.  This has the extra advantage of being able to show progress widgets and cancelling options.

Developing a working solution of this, is actually not that hard at all. The difficulty lies more in making an API that’s easy to use for not only myself, but for every developer that needs access to the server. This resulted in an iterative process where I had to rethink the design 3 to 4 times before reaching a nice level of usability. The fact that thread safeness had to be kept in mind, didn’t exactly make everything go smooth. The result consists of a priority queue to which different types of requests can be added; the XML request will probably be used most frequently. When adhering to my XML reply standard, the manager will automatically parse the result and check for success. The initiator of the request can then obtain extra info from the answer and he can even extend the request to define the callback which will be automatically called after a response has been received.

The current version of the server selection interface.

The current version of the server selection interface.

In my proposal I stated that I wouldn’t need to extend the GUI engine to obtain my desired lay-out, unfortunately I keep discovering bugs and hacked-in functionality that doesn’t translate to what I want to use it for. The most time consuming task here was making a basically new list-widget, that is furthermore backwards-compatible with the old list widget as it was already widely used. Now why did I had to renew it? Well the old widget didn’t fully support columns. The header did, but the content did not. With a tab hack though, the content could support up to 2 columns if they where left-aligned. Of course this doesn’t suffice for my server-selection screen and thus I improved it to fix the alignment and allow more columns. I present you with a screenshot of the temporary server selection interface above.

Other changes to the GUI engine include being able to change the color of text while already on the screen, a callback to the current screen when a dialog(pop-up window) is closed and a way to intercept closing attempts of such a dialog. I also had to do some more complex work on the ribbon widget  (a row of icon buttons as used in almost every menu screen).  For my project I need to be able to change the actions a user is allowed to do, depending on his state and rights. For instance when someone is signed in, he’ll have the option to sign out. This is a separate icon button and thus I needed to provide a mechanism to show and hide buttons. This is not so evident, as the lay-out has to be recalculated on every change as well as the order in which buttons get selected on key navigation.

On the left you see the online menu screen while signed out, on the right while signed in. See the difference in action buttons on the bottom right.

On the left you see the online menu screen while signed out, on the right while signed in. You can see that all options get disabled for unregistered users and that their actions differ as seen on the bottom right.

Automatically signing in : an interesting feature which I had marked as optional, but got implemented anyway because of it’s helpfulness in testing the registered-user-only features. So yeah, a checkbox got added to the login dialog to remember your session. I’m not going to put another screenshot of that in here, as it already had 2 appearances on my blog. Nevertheless you can just check out my branch and see for yourself ;).

As requested I’ll now go into some database stuff. I was planning on doing this quite extended together with a diagram of the relations, but this post is already getting quite long. The first adjustment I did, was replacing the database engine with InnoDB, everywhere MyISAM was used. This allows me to use foreign keys as constraints and has some other advantages (but also disadvantages) like row-level locking instead of table-level locking, that I won’t go further into. The foreign keys allow me to do checks on database level. A field in one table, gets linked to a field in another table by value. With these properly set, I can’t for instance let people join non-existent servers or let a user that doesn’t exist be host of a server. Another cool use is that when a key gets deleted in a table, it can delete everything that is related to it. For example when deleting a server, every connection with that server is also deleted.

The session table has as engine MEMORY, which basically means it is never saved to disk. It’s faster, but all data is lost when TuxFamily’s server decides to shut down. Which is not that bad, as users will just be signed out.

No harm done.

-Glenn


Leave a comment

Summer has come

Week 3 is already coming to an end and the temperatures in Belgium are rising to unusual heights, perfect time for a blog post! As I’m writing this, I’m preparing the server selection interface where users will be able to pick a game server they want to join. In the end this will have lots of filtering options but as with any other feature, I’m starting with a simple version first. You can already see this evolution with my login form :

The current version of my login form.

The current version of my login form.

If you compare the screen-shot above with the one from my last post you see that I switched the buttons to icons. Five buttons in a row was just too messy and as most of the SuperTuxKart interface already uses icons, it was a logical decision to change.  (The designers are working on new icons, placeholders to the rescue. 😉 )

Of course that’s not the only thing I did. I just finished the creation of servers (well for as far my part goes) and cleaned up a lot of server-side code. I need to do the latter because the user creation process shares a lot of code with the STK Addons website and thus for every improvement I make in the shared functionality, I need to adapt everything that uses it. I also need to do this for every database call because of the change in access-method I explained in my previous post. There is a significant advantage here though (else we would just separate everything), namely all registered users on the website will be able to use their account for online gaming and vice-versa. So accessing your profile from your web-browser, is a nice feature that could be easily implemented in the future.

For the sake of having another image in this post, I included my first draft of the networking lobby. This actually revealed a few bugs in the GUI engine : the grid wasn’t nicely aligned and the content didn’t fit perfectly. Luckily Marianne fixed this quite fast, resulting in the screen-shot below. I know it doesn’t really have a “wow-factor” (yet?), but functionality comes before appearance and I’m sure it’ll look better with some content in it. 🙂

The temporary look of the lobby where players will gather before a race.

The temporary look of the lobby where players will gather before a race.

Communication with the other networking student is now getting very important, we’re at the point where we need to discuss our decisions on a daily basis. Although our mentors tried to assure that we could work separately from each other, I kinda expected that a close cooperation would be needed to establish an efficient implementation. Luckily we’re both on schedule and we believe that everything will work out just fine.

I’m glad to end this post with my final grades I received this week. With an average of 80% this year, I won’t need to worry that much about university work during GSoC. I’ll be spending roughly one day a week preparing my thesis though, so it seems I’ll be having a busy summer. 😉

May the temperatures decrease to a more comfortable level.
– Glenn