Bullet Hell Survive Alpha

In the last post I wrote a simple state machine to delay some initialisation code until the required resources had loaded. It was quite an ugly hack, so this time I'm going to refactor that and make it a lot nicer. I will be adding a state manager system and three different states: Loading, Title Screen and Game.

In the last post I added fonts to the game. This worked.. but there was a small bug which meant that printed text sometimes didn't appear. Now I need to fix that. Welcome to gamedev! To fix the defect I first need to be able to reliably reproduce it - how else will I know if I've fixed it? I'll be using the debugger in Google Chrome for my testing, and I've got the game code saved on my webserver . I've noticed that the first time I load this page the font is missing, but if I hit F5 to refresh the page then the font appears. My hypothesis is that this is related to caching of resources, so let's start investigating that. If I open Chrome's debug console (hit F12) and then right click on the reload button there's an option to "Empty Cache and Hard Reload". If I select that then the cache is emptied, the page reloads and.. the font is missing. Bingo! The bug is reproducible, and now I can start looking at what the problem is. Now I'll

Dodging bullets is fun, but we need to start communicating information to the player. One of the most basic ways to do this is with text. In this post I'll add old school mono-spaced pixel font support to the game, and use that to show some simple placeholder info. It all starts with a font sheet:

Last time, I added coarse "box" collision to the game. Box collision is fast, but it's not accurate enough for a shoot-em-up. What I need is pixel perfect collision. This works using "collision maps" for the two objects. A collision map is basically the same as a sprite image (which is sometimes called a pixel map), but instead of storing a colour value for each pixel, I store a true or false value - true if the pixel is set, false if not. When it comes to checking for collision, I walk across the two collision maps and check for any pixel where both maps are set to true. If that happens then the two objects are colliding. In the following image, you can see the difference between the two types of collision:

This time I'm going to add collision to the game. Perfect collision detection is super important in bullet hell games, so I'll be making sure I get it right. I'll split this into two steps - first I'll add the code to support collisions and put in some coarse "box" collision. That's not going to be good enough, but it works well as a first pass. Once the box collision has decided that two objects are potentially  colliding, then we'll switch to pixel perfect collision, which I'll add next time. First, let's talk about that simple box collision..

A quick one this time. I'm heading towards getting collision into the game, but before I do that I need to get the game objects better managed. So this time I'm going to refactor the code a little bit to add an object manager. It's going to mean several small changes across the codebase..

Three steps in and we're already onto the fun stuff - adding bullet spawners. In this post I'll add an object to represent a bullet spawner, give it a bunch of configuration parameters, and then place a couple of them on the playfield. Bullet spawners are usually pretty simple objects - they just spawn a number of bullets at regular intervals. What makes them interesting is the configuration parameters that can be used to create intricate patterns of bullet hell. You only really need a handful of simple parameters before you can start to create complex patterns, so it might surprise you to see how little code is required. Let's first talk about how I want my spawner to act, then I'll dive into how I make that happen

In this post I will be adding bullets to the game. As part of that work I will also be adding an Object class that both the bullet and player classes will extend. This will allows me to lump all of the game objects together in one big list and treat them all exactly the same way, which makes things way easier to manage. Each object will need to support just a few basic operations: Creation - This will be done through the constructor update() - I've split the update and rendering of the object into two steps. Update is where the object calculates it's new state based on the current one and any inputs render() - The current state of the object is rendered to the canvas isAlive() - This is a function that returns true if the object is still alive, or false if it isn't. For instance: a bullet can be considered "dead" when it has traveled outside the screen area