Category: DevBlog

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.)

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.

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).

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.

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.

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.

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.

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.