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.
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!
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.
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.
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!