Showing posts with label audiogame. Show all posts
Showing posts with label audiogame. Show all posts

2010-04-23

The fate of AudioGame

I lost motivation for this project somewhere around October/November last year. Things just weren't going how I wanted and I got a large swarm of bugs that caused me a lot of problems and I couldn't track down along with some nasty memory leaks springing up overnight in unchanged code. The game itself plays ok-ish for what it is (a very early example of what the engine is capable of).

Then recently I found Beat Hazard, which is pretty much exactly the 'feel' I was aiming for with my game, but works as an old arena-style shooter instead of a sideways shooter.
I read a brief interview with the author, who mentioned using beats in the music to increase counters instead of acting on them directly, which is a pretty cool idea. This made me go digging through AudioGame's code and see what happened if I implemented that technique myself. The results were pretty awesome, instead of huge waves of enemies, they appeared in spots and starts with a sort-of time to the music.

Unfortunately all the old issues are still prevalent. The memory leak I'm at a total loss for, I can't even remember what code I added just before it turned up. I have it set up so the enemies have no maximum speed as the "don't go faster than this" code is broken somehow. It's actually so broken that it has a habit of sending enemy ships shooting off at odd angles when I've only written code to have them move right to left.

This all leaves me with a bit of a conundrum. I could take this game all the way if I fixed the bugs. That tip from the Beat Hazard guy (btw, I strongly suggest buying the game, it's a lot of fun) essentially fixed the biggest problem I was having, which was how to make things work to the music. But the bugs are obscure and may take a long time to fix that isn't proportionate to the issues they cause. The memory leak for example isn't the "keep eating memory forever" sort, it's the "you didn't clean up properly when closing" sort, which is a non-issue for a user but annoying for a coder.

I may re-pick it up as part of the game-a-month stuff and make a prototype, maybe even in C# and OpenTK instead of C++. I may not and just let it rest.

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)

2009-10-05

Music playback

Music playback now works for WAV files.

Things are progressing slower than I'd like, but that can't be helped.

Just tying the music playback into the enemy generation right now so I can start fiddling and see what works best for generating enemies.

2009-09-02

The story so far.

So what is the game?
Well it takes an idea that Audiosurf has brought to the forefront, that is to take a user's music and create content from that.
This means every single song on your hard drive is a completely new "level" to play, which provides a lot of levels for some people. :o)

Taking from another genre: The sideways scrolling shooter, the idea is to have the music time bullet shots and enemy spawns. The user just moves the ship around and tries to rack up as high a score as possible.

Exactly how well this will work I'm currently unsure, will see.
Right now I've the skeleton of a sideways scroller with all the music analysis code still to do (big job).

Start of an era?

Creating this blog purely to track my indie game development project (hopefully projects).

Currently the game has no name and isn't very far along, hoping to change this quickly. :o)
Codename is just simply "audiogame" which I'll use for tagging throughout.
Once I have some gameplay running I'll post a youtube video.