UPDATE: Check my new blog about developing a Bullet Hell game at https://bhsalpha.blogspot.com/
I’m getting more interested in making my work more easily accessible. After dabbling around with Processing for a while (and enjoying it’s ability to publish-to-web fairly easily) I’ve decided next to take a look at Flash. This should make it even easier to get my work into the hands of more people.. excluding you people with iDevices of course ;P
For my first Flash project I’ve decided to write a game. More specifically, I’ve decided to update my old Bullet Hell Survive game that I wrote as part of the first one day game jam that I organised, Dundee Jam. I thought the game in its original form was fairly fun, but it certainly had a few flaws that needed fixing. I’ve been wanting to update it for a long time now.
(click on the picture to run the demo)
The premise of the game is pretty simple – dodge a storm of bullets while trying to maximise your score. In a normal bullet hell game you have to defeat enemies, but not here. In BHS you just have to survive against the clock. You can score in one of three ways: camp out in one of the level’s score zones, graze bullets (Ã la Crazy Taxi) or collect the special “score bullets”. Click on the image above and you’ll be able to play the work-in-progress build of the game. Use WASD or the arrow keys to move around. It’s only a couple of hours work so far and uses coder art mixed with a touch of hastily ripped Xenon 2 graphics. There’s still a hell of a lot more to add. Oh.. heh.. no pun intended there! ;D
The only really interesting piece of code so far is the part that controls the spawning of the bullets. Originally I toyed with the idea of having a complex, node based control method for spawning bullets, similar to the one I used in the original PC version of BHS. I quickly decided that that was overkill though. It’s also quite difficult to make nice levels with such a system – it’s more of an intellectual exercise in making clever node graphs than a fun exercise in making a good level.
Since I plan on allowing users to make their own levels in the finished game I decided that a simple to use system would win out over a more flexible, but much more complex one. In the end I settled for a fairly simple spawner that has just a few, easy to understand parameters:
- Delay – The delay in frames before a shot is fired
- Number of Bursts per Group – After the delay, a group of shots is fired. The group contains one or more bursts..
- Shots per Burst – ..and each burst contains one or more bullets
- Burst Spread – This is the spread of the shots in a burst, measured in degrees
- Bullet Type – Current bullet types are slow, fast and “score bullets”, which give you a score bonus when you collide with them
- Delay Between Bursts – This is the delay in frames between each burst in a group
- Rotation between Bursts – The rotation of the spawner between each burst in a group
- Rotation – The spawner roates by this amount after the entire shot group has been fired
- Flip After N Groups – If this is non-zero then the spawner will flip it’s rotation direction after this many groups have been fired
By tweaking these parameters for each spawner in a level you can easily come up with hundreds of pretty (and pretty deadly) bullet hell fire patterns. I think that the simplicity of this spawner has actually made it far easier to create good patterns than the old node based system because you can iterate much more quickly on your levels. And as we all know – fast iteration, and therefore fast development, is good.
Talking of fast development, I’m using the Flash Punk engine as a way to speed things up. Having never done any Flash coding before I thought I’d save myself a load of heartache and just use someone else’s engine. Flash Punk is pretty simple to get to grips with, as is Action Script to be honest. Thanks to Flash Punk’s great tutorials and community forums and some judicious use of Google I was able to go from downoading Flash Develop to having a basic tech test (a few thousand bullets flying around the screen, colliding with a player sprite) in an hour or so. The sheer power of modern computers makes it possible to prototype stuff like this really quickly without having to worry too much about how efficient your code is.. even if you’re writing a browser game.
