Bullet Hell Survive Alpha

When we last met, I had just started work on a level editor. I'd got as far as adding the ability to select an object and move it around, and then I added an undo/redo system using the command pattern. That was a good start, but dragging items around the level is only fun for so long. What I really want to be doing is.. ..editing the properties of the bullet spawners! And I want to be doing this in realtime as the game plays so that I can immediately see what effect my changes have made to the gameplay of the level.

I started this blog back in November of last year. My aim was to document the development of a Bullet Hell shoot-em-up, written in JavaScript. Here we are, six months later, and lots has happened. With 20 posts already written, I thought that now would be a good time to take stock of what I've already done, and to look to the future and see what's to come.

As I continue work on the level editor for the game I decided that adding an undo/redo system would be pretty handy. Because such a system will end up being quite tightly integrated into the editor code it makes sense to add it sooner rather than later - so that's what I'll be doing in this post Implementing an undo systems in an editors is a programming problem that has been solved many times. The solutions usually fall into one of two categories:

I'm going to get started on the level editor now. I'll start off simple with object selection and re-positioning using the mouse. Before I get to the editor code itself, there are a couple of things that I need to add first..

Most games work best when you have more than one level, but ip until now that's all I've had - one level. Even worse, that level has been created directly from code written into the game itself - to change it I have to rewrite the code. What I need is data driven level loading - the levels should be defined by a data file. In this post I will be defining a level format and writing code to load it into the game. Let's start by talking about how the data will be laid out..

One thing that I always try to do when I'm writing a game/app/whatever is to use simple placeholder graphics. There are a couple of good reasons for this. Firstly, it makes you concentrate on the gameplay - if the game doesn't feel fun with simple graphics then it's not going to feel fun however good you make the graphics. When I worked at Denki  we had a rule about not making our graphics any more "real" than basic coloured shapes until the core gameplay felt fun. Secondly, it gives a blank canvas to whichever artist comes in to create the proper graphics. At some point in the development of this game I'll get an artist in (applications for the position are open!) and I don't want to prejudice their view of how the game should look - I want the artist to tell me  how it should look. Finally.. it stops me from getting distracted and spending too much time tweaking the graphics when (see first point) it doesn't make any difference at this stage. U

In this post I want to make the game time limited. By doing this, I make it more of a challenge to beat the high score. I'm going to set the time limit for a level to 30 seconds - I think that's a good amount. Also, I don't want to just dump the player straight into the action unprepared, so and I'm going to add a couple of bits of  "ceremony" before and after the gameplay to make it a nicer experience. There are a few main things that need to be added to make this happen: Add "sub" states to the Game state: intro, game and outro Intro state needs to show a countdown Game state will run the game as normal, but with a visible "timer bar" to show how long is left Outro state will show a summary of the game - score, high score, etc. Let's start with defining these states:

Now that I have an animation system, why don't I use it to try and implement a new enemy type with minimal code? I'm going to implement an XY Zapper enemy. This is an enemy that periodically spams out a horizontal or vertical laser beam that instantly fries everything in it's path. The Zapper tracks the player's position and homes in on it, which makes it hard for the player to sit still in one place on the screen. This is good as it helps to stop the player from being lazy, sitting still and exploiting holes in the bullet patterns.

In the last post I touched on how easy it is to score in this game - you can just camp out on the score bullet spawner and watch the points rack up. I'm going to add a little delay to the score bullets so that they start out in a deactivated and uncollectable state, and then change to active and collectable after a short time - say, half a second. To make it clear what state they are in I'm going to add code to let me change the look of Objects and allow them to be animated.

Up until now, the player control has felt very "digital" and harsh. Whilst there's an argument to be made that that is how it should be in a shoot-em-up, I didn't like it that much. I'm going to add a little bit of momentum to the player sprite to give the ship a feeling of weight.

The images in the game are being loaded by creating an Image element and using a .png file, stored as a Base 64 encoded string, to load the data: Every time I need to change a sprite in the game the process is: Edit the source .png image file in a paint program and save it Convert the file to a Base 64 encoded string (I use https://www.base64-image.de/ for this) Copy the encoded string Paste it into the source code Refresh the game in the browser This works ok when there are only a few graphics, but it doesn't scale very well. The workflow that I really want is: Edit the source .png image file in a paint program and save it Refresh the game in the browser Much better! So how do I do that? I'm going to add a resource manager that loads the .png files directly from the server.

Up until now I've been mostly focusing on the game technology and neglecting the game play . I'm going to address that a little bit by adding scoring to the game. I want to add some risk/reward to the gamplay - score higher by taking more risks. From now on I'm going to try to make sure that I remember to add gameplay features as well as tech features. So how do you score in a shoot-em-up where you can't actually shoot? There are a few possible ways that come to mind: Score bullets: Fired from spawners like normal bullets, but instead of hurting you when you collide with them they give you score Bullet grazing: Score points by flying very close to bullets  but not close enough to be killed Score zones: Marked areas of the screen that award you points when you fly over them I like all three of these scoring methods and I'll probably implement them all over time. If you have any more good scoring ideas that you'd like to see in the game, please let me know

In this post I'm going to do some housekeeping on the game and add four small things that each make the development process a little bit nicer: A constants file to keep all the configuration magic numbers in one place A script to serve the game files up to your browser from your machine, so you can build and test the game locally and very quickly A better way to see the debug console output without having to open up the browser debug console A favicon to stop the browser complaining that it can't find one