Progress in the Background

It’s been a long time since I’ve written a blog post. Several things have slowed me down since then. I’ve developed pains in my hands and arms – not constant, but regular – that have often made it difficult to keep working. When I was able to get work done, I’ve often taken on more outside contracts to keep money coming in. I haven’t stopped work on Balloon Platform Defense altogether though, but what time was available for it was always focused on actually adding features rather than making them presentable. And I’ve been acutely aware of how out-of-date was the currently uploaded version – every time I applied for some programming work, I’d link to this game as an indication of what I could do, while having mixed feelings about doing so because it was old and buggy, which was a constant reminder that anyone who had subscribed for updates hadn’t had any in over a year!

Those problems mostly started a month or two after releasing the early-access version spoken of in my last post. I noted in the last paragraph of the previous post that sound effects were added in the following week – in fact, so was some music, and some particle effects for when balloons were popped. Since the first introductory level featured a bunch of basic red balloons waiting to be popped, bits of red rubber burst out. This meant I received a complaint about blood splurting all over the place in what’s supposed to be a family game. It seemed pretty clear to me. I also added the capability for characters to wrap around a level, whether horizontally or vertically. This continues to be a pain every time a new feature is added, whenever distances between objects are relevant to game logic in some way, it can always be thrown off by the metric of a wraparound level, until the code has been really carefully written to take account of every circumstance.

In the next half a year or so I added the occasional feature, but mostly I was working on outside paid projects. I made a more functional GUI system and a cloud shader to finally get the clouds visible through the windows looking decent. I had always intended to come up with a way of making ropes between balloons, or between balloons and players, and eventually after learning a lot of extra math, I figured it out – but didn’t end up doing anything with it besides testing it at this time. Following that trend, I also wrote a routine to guide certain balloons toward the windows for a greater challenge, and haven’t used it so far.

Another thing that had always been intended was to give the simple round balloons proper round collisions. Of course, although they are usually circular, they can be squashed at any time, so they can only be generally defined as ellipses, and the math for elliptical collisions took a while to work out. While I could find routines online for simply determining whether two ellipses intersected or not, I needed to know how much force they should exert on each other and in what direction, which meant writing my own routine. While this has worked well in Windows, the browser version currently has to stick to rectangular collisions, or else it gets slowed down drastically.

The pain in my hands was particularly bothering me when playing games, and I thought that it would be easier to try new level ideas if an AI player could do the playing. I didn’t realise how long I would spend on this – it’s a good thing to have learned for the future, but was a lot of delay at the time. But while it’s not visible in the game at present, I think the AI players will make it into the finished game, at least into a multiplayer mode, so this won’t have been wasted time.

Wanting to add some more interesting level features, I tried to start improving the level editor – adding the capability to place balloons inside other balloons like crates. (The crate had been drawn ages ago, but never used because the level editor functionality to put anything into it would be the hard part.) Also added was the ability to change the size of windows, and to put the ropes between certain balloons. Again, so far, these features haven’t been implemented on any levels.

In time for some friends coming round one day, I added a quick party game, in which you have a balloon tied to you with a string, and must pop the other players balloons before they pop yours. This is only one of the five party-style rounds that was available on ‘Balloon Party’ game made previously from a previous version of the game with different physics and graphics – I’ll at some point replicate the other party games as well.

Finally, yesterday I released an updated version of the game – it’s a bigger file, but apart from a few bug fixes, very few improvements are actually visible. The elliptical collision isn’t used in the online version, the AI isn’t currently used, neither are the new level editor features, so the main changes visible are improved clouds through the windows, the party game, and the fact that the game can be played with 4 players (although the controls are a bit awkward, unless using the Windows version). But the other improvements are in the code and waiting to be made visible, and shouldn’t be too far away now.

Preparing for Early-Access

When you’re making a game, of course, it’s hard to tear yourself away from programming to manage stuff like writing. So ignore the date on this entry – this will be about getting the game ready for early access, which happened on 23rd December. (I know details like that because I do actually keep a daily development log detailing what progress has been made each day, it’s just a lot less well-formatted than this.)

Behold! The Bumpmap-creatinator!
Behold! The Bumpmap-creatinator!

In November I made a new, and hopefully the final, iteration of the Bumpmap-creatinator, which is used for rendering the game’s balloon-animal enemies. The first thing I made with it was the UFO enemy, shown in the picture having one of its frames rendered. Next came a logo screen, and a basic opening screen and the font needed to display things in it.

Welcome to the Minus World!

Shortly into December, I started trying to add the balloon animal.  Since I had some slowdown when I had lots of them, I soon found myself profiling and optimising, and feeling that I should try the game under all conditions, I tried compiling the HTML5 version, and found that the game displayed slightly incorrectly – the colours were basically inverted, although not quite, and I spent hours trying to rectify this before realizing that a Chrome plugin was affecting it, and all I had to do was disable that plugin and it worked fine.

In the weeks leading up to releasing an early access version I was mainly making new enemies – which frequently highlighted more bugs with collision detection or rendering, the ironing out of which would actually take up the majority of the time.  For example, it was while making enemies that could jump that I realised that my player could never actually jump high enough to reach the platform above him – he only managed it because, having reached a few pixels below, the bit of code that wouldn’t allow him to be stuck inside the floor pushed him up the extra bit that was necessary.

It reached the day on which I was determined to get the release out, and I still had all the levels to make, the title screen with all it’s illustrations, game-over screens – all the bits of polish needed before a game can really be seen.  And then for it to go on a store, even an early access one, meant taking screenshots, cropping and scaling pictures (of course, every different store wants stuff like your logo in a different picture size from every other store, and usually decline to tell you any of the details of what artwork they’re going to want until you’re filling in the submission form, so you’re always left doing loads of art editing right when you’re tired from a day of getting the game finally ready).

A screenshot of the game, as it was at it's early access release.
And this is the result. This is why you need a daily log – otherwise you can easily think this shouldn’t have taken this long. You forget how much debugging every feature took.

But I made it, which still kind of surprises me (although not all features made the cut – it was supposed to have sound effects at that stage, for instance, which weren’t actually added until a week or so later).  In case you’re reading this and haven’t seen the early access release, you can get it here.  It’s not pretty, but it’s a playable game – to the extent that I keep on getting sucked into playing through levels when I’m supposed to be testing a certain bug-fix. There’s still a lot to be done to make it something that can have any success, and I’ll try to comment on that in my next post.

First Entry

Although I’ve been working on Balloon Platform Defense for seven weeks today, I’m starting my development blog now because it’s only now that a screenshot really shows all the crucial gameplay elements. This seemed vital because I’m never sure how to describe to people what sort of game this is. It’s clearly a kind of platform game, but often that gives people the idea of a puzzle game, which this certainly isn’t. And how often does an action platformer involve enemies being unable to harm your character at all? Or a complete absence of spikes or bottomless pits to fall into? You understand why I’m not sure it exactly fits the implications of that label, and why a simple description might give the wrong idea.

It should be noted that this isn’t the original Balloon Platform Defense. I already nearly-made a game by that name, everything was done except for the levels and the enemies, and I found that the levels and the enemies were actually a big job. That original version had everything physics-based, which meant partly that enemies often behaved in unpredictable ways, and making levels that counteracted that to prevent players getting frustrated would be difficult, and also that making more enemies to keep the levels interesting was extremely difficult – without precise programming, an enemy could often explode the moment it was initialised. You can play an early version of the original on Kongregate if your browser supports the Unity plugin (which I think only Firefox still does) or a special version for multiplayer play over at AirConsole. The point is, when GameMaker came up on a Humble Bundle, I looked at what it could do, and decided that starting from scratch and making a simplified version of the same game would still be quicker than trying to finish what I had so far.

Here is my player trying to push a balloon against a wall, although the balloon tends to slide upwards because of a problem with the player's bounding box at the time. The player doesn't animate at all yet.
Here is my player trying to push a balloon against a wall, although the balloon tends to slide upwards because of a problem with the player’s bounding box at the time. The player doesn’t animate at all yet.

So, during the first two weeks I mostly worked on getting the collisions to work as desired, and getting the balloons to deform when something presses against them. Naturally this involves many lines of calculations, and didn’t feel right at first – it initially had a bug in the code in which a y coordinate was used where an x should be, which I didn’t spot until weeks later. But it was enough for the moment to let me press on with other aspects of the game, and in my experience if you don’t progress, you get bored and end up stopping.

On 8th October, trying to get a shader working. Quite a few screenshots are taken so I can analyse the colours in Paint.NET for debugging.
On 8th October, trying to get a shader working. Quite a few screenshots are taken so I can analyse the colours in Paint.NET for debugging.

Then came time to make the nice graphics for the balloons. In the original version I’d drawn these using bumpmaps, and I saw no reason to alter this approach. That way, just one sprite could be used to draw balloons in any colour and any size and with any amount of distortion, and still show the shading looking right. It had to be altered a bit to fit the pixel-graphics style of the game, but I think it came across quite nicely in the end. I designed a snail as an enemy to play with, while I needed something to test my shader on, and from stuff that I’d done on the original game in the past, already had a C# application for creation balloon-animal style bumpmaps, although I had to change it a little to also encode colour information for each pixel that could then be decoded by the shader.

By the 15th, I'm quite happy with the way my balloons are looking - although it still takes the next few days to get the snail showing the shine in the right places when rotated.
By the 15th, I’m quite happy with the way my balloons are looking – although it still takes the next few days to get the snail showing the shine in the right places when rotated.

I’ve been concerned up to this point about whether I’m actually going to be able to make some level graphics, besides the basic tile I’ve been working with so far. My idea being that this world should look like a sort of office reception, I wanted to make the tiles look like countertops with a marble veneer, but eventually decided that wasn’t possible. I eventually found a look I was happy with, and found a way to draw it with subtle, automatically drawn shading. As it happens, someone was asking about how to do this the next day, so I’ve already written in detail in the community forums about what I was doing at this point.

During the next two weeks I made little progress on the actual game – partly because the end of a month is traditionally when other aspects of my life become the busiest. I set up this website, improved the C# application for drawing the enemies, and other stuff related to it, and occasionally made little improvements like allowing the character to jump different heights and fixing the x/y coordinate bug mentioned earlier. Then at the beginning of November, I started making a level editor, which is mostly what I’ve done since then. But in the last few days, I’ve made the windows that are such a key game mechanic – the means by which it is actually possible to lose as well as to win.

Now that the game is theoretically playable – even if only for a single level at the moment, though a single solid day’s work should solve that, not that a have a solid day free now until at least the weekend – I can work towards making an early access version available. Watch this space.