Err, yeah, hi

I do still exist. The Game-a-month project is still on my list of things to do, I'm just having a bit of a hiatus.
This is, of course, not particularly good, but it's where I'm at for the moment so it's happening.

I've spent most of the last two months not coding, so, not a lot to say here.
However recently I've picked up an idea for comparing track rollercoasters on Audiosurf that someone was interested in a while back.
The original thread is on the Audiosurf forums here and is basically asking for an easy way to sort tracks by the amount of traffic they have.
Retrieving traffic information involves digging through a .ash file locally or asking the servers for it. I've not done any experimenting in pulling that data from the Audiosurf servers yet, however I already had the code for retrieving the track shape, which is a good indication of the traffic a track will have and the speed it will run at.

So, in a few hours I put together a very quick program to pull the track shape (and global scores) for a named track. Very easy to do, and the result is posted in the thread mentioned.

But that doesn't technically compare the tracks, or order them or anything, it just allows for quickly viewing multiple songs outside of Audiosurf. Useful, but not ideal.
For a long while I left the application there, then I picked it up again a week or so ago and began work on a 'playlist' section of the application. This downloads a track shape for every song in a playlist with the eventual idea being that it will show an estimate for how 'quick' the track will be, allow sorting and re-tagging of [as-steep] to slower tracks.

It quickly became obvious once I had the "download lots of track shapes" code implemented that the Audiosurf server is struggling to stay up at the moment (indeed, whilst making the screenshots below, I had significant issues with the Audiosurf server timing out, even for single-song lookups). This is noticeable if you use the forums much and/or play the game a lot as the forum, scoreboards and logging in are often down. Obviously I don't want to make this workload any worse, so I've implemented a cache for the track shapes that stores this data locally as presumably a track shape shouldn't change unless the picked user is cheating.

To avoid accidentally pulling out cheaters, the app always goes for the last global score of the 'Elite' category, if there's no elite scores it goes for the last of the pro, then last of the casual. The assumption being that a cheater will hold the top spot and not be lower down on the scoreboard. Additionally the "single song" searcher that was initially implemented (and will be launchable from the playlist window) will allow you to store which rollercoaster you want to see locally.

Possibly will take it as far as YAAP (Yet Another Audiosurf Player) with tagging features, etc, not decided yet.

Oh, have an example image that's rather sparse. Much will be added, hopefully (click to view full size):

New game plan

Ok, so things didn't go quite as planned with my AudioGame. I'll explain the specifics in another post, but this one is more about what I'm planning to do for the rest of this year.

One thing that a lot of indie developers seem to do that allows them to enjoy the scene is to publish a "game a week" or something similar. So, I'm planning on doing the same. This will be hard for me because I'm not someone who easily works to deadlines. I code because I enjoy it and I want it to remain that way, so if I find I'm trying to do more work than I'm enjoying I tend to back off.

This has resulted in a rather large accumulation of half-finished projects however as I also enjoy exploring new ideas, but rarely see them through to completion.

One such example of this is a game I originally wrote for university called Hoshi which is a re-make of an old RISC OS game called Foray that in itself took a lot of inspiration from a BBC/Acorn Electron game called Starship Command. I spent many hours playing this game and it's one of my fondest gaming memories. Single-player, you fly around shooting enemies in waves. One hit kills on them, you have a shield bar, however the enemies shoot so quickly that if you remain still in a shot of their bullets you tend to die in around a second. Unfortunately I long ago lost the original, which is where my wish to remake it originally came from. And I succeeded, sort of. Things were going great, I had ~75% of the game in place and then the deadline approached and I rushed the next 15% and introduced a LOT of bugs that effectively stalled development. I handed in a game that was near enough completion to get high marks, but it was also bugridden as a result of that rush at the end.

What does this have to do with now? Well, I want to make it clear that I won't make that sort of mistake with these games. If I start introducing bugs like that I'll slow down. My plan is to make stable, fun games on a semi-regular basis, not unstable, broken games on a strict timetable.

What this leaves me with is that I won't set an exact time for each game. I also want to put more time into some of the ideas than has been done by some developers (that's not to say their games aren't good, but you can see where corners were cut to fit deadlines). I'll also be using OpenTK and C# instead of some of the more rapid development tools available. The reason for this is simply that I like the additional "wiggle room" that using a base language gives you over something like QuestViewer. Audiosurf is a good example of this. Fantastic game, but all it's bad points ultimately point to it being developed in Quest3D.

So my timetable is this: Average a game once a month. Sometimes it might be two months between releases, sometimes it might be 2 weeks. Updates will primarily be from here, hosted on DropBox, because it's easy and free. ;o)