Glenn's Development Blog


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

Advertisements


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