I seem to be at one of those stages where I keep on meaning to write things in here but other things (like work!) have got in the way. What I did in most of my spare time last week was polishing the Crystal Towers 2 demo for Clickteam's disc next month - after releasing the first test of the demo to testers, I've made some slight changes such as ripping out and replacing the entire sound and online communication objects and changing the way that the whole save system works.

Briefly, then - the sound change was from ModFusion to Onu, something that I'd tried before but abandoned when I found that Onu couldn't play music over separate frames. But it had been updated a lot since then, and with ModFusion's reputation for crashing a lot on computers that weren't mine, it was worth a try replacing it. That process went fairly quickly and gave me the chance to neaten up how music is loaded as well, with all the incidental music put on to separate tracks when the game is started up, rather than loaded on demand - now only the level music has to be loaded when one is entered. Curiously I found that like ModFusion, Onu can't change MOD orders correctly, but it just ignores the action and does nothing rather than crashing, which is a vast improvement as you can imagine. There was a brief panic when I realized that it wasn't looping music correctly, but it turned out that you just needed to turn MOD looping on specifically when you start playing one.

The online object is now the Get object instead of the Live Receiver - it's a sign that I've been taking too long that the earlier object has gone through its entire birth and death during the course of the development of the game, and I'd previously used it to replace the Moosock object that I used in Special Agent. I hadn't noticed any instability with the Live Receiver, but the author said that the Get object was a lot less prone to crashes, and it brings the file size down an insignificant amount, as well.

I've also succumbed to the will of Microsoft and changed the save system so that all of the game data that needs to be changed is now stored in the Application Data folder. It's ironic - for many years we tried to beat the idea into independent game makers that you should never touch the Windows directories and everything should be provided as a self-contained folder for ease of installation and deletion, but now we're all having to do the opposite and treat the user's Application Data folder as a sort of giant memory card. This has to be done because under certain circumstances, Vista and above won't let applications write to folders in Program Files, so players might be stuffed if they usually put games in there - this is the reason why you see some games putting a "My Games" folder into your My Documents, too.

Looking at it now, I can't imagine why I thought this diagram would be helpful

While doing up the site for the game, I ran into some issues caused by how I'd set up the online accounts in the game at first. The idea of the online feature is that you can submit your save to the site through the game, and have your progress displayed among other players. To do this, when you create your player you provide an online key that's meant to keep your account unique, and when you update, the game sends the information off to a script on the site and creates or updates the account (sending back a message saying whether it succeeded or not). There's even a dynamically generated image near the bottom of the page that you can display on a forum signature and so on.

Because I was just about feeling my way as I went, there were a number of problems with the way I did all this at first - one of the biggest was that accounts were identified by name. I did this deliberately at first because I didn't want two players to have the same name, but it made things more inconvenient than anything else, needing a whole extra process to check for existing names and then informing the player that someone was already called that, then providing a chance to change it. The other was the separation between creating and updating an account - if somehow something went wrong (like me fiddling with the database, which I frequently did during testing) then trying to update a player record that didn't exist would produce a cryptic error. Once you'd taken a name, you were stuck with it, too - you couldn't delete your save and start again with the same name, because that name would already be taken.

Shows about as much as you would expect.

I changed this to work in much the same way that I remember Unreal Tournament handling it. You can use any name you want, but the combination of the name and the online key has to be unique. As long as nobody chooses a painfully obvious online key and also has a really common name, this prevents collisions (and if two accounts do collide, then they just save over each other, with no need for an error message). It does leave a few menus I did up completely unused, but it works a lot more smoothly than the old idea. Because there can now be two players with the same name, the update script (which now creates an account if it isn't there already, rather than just throwing up an error) now passes back an ID to the game, so that it can use it to directly open the player's scorecard from the game itself.

What also happens now, when an account is updated, is that the differences between that account and the last time it was updated are also recorded in a separate "events" table - a new row is added for every update. Having a record of the differences recorded recently in these little 64-byte rows means that the site can parse those lists of numbers into something resembling English (which is more difficult than you'd might think) and display a news feed of what players have been doing recently in the game. It really is quite fantastic staying on the page and watching updates go past when people are playing it.

I think all the best online features are written because of people's love for spying on others.