Week 7 – Balloon Popping Plane

Week 7! Bit of a mixed bag this week. Download and play here.


So the idea isn’t the most original in the world. You may be able to tell that I took some inspiration from Luftrausers, the definitive 2D plane flying and shooting experience. I think there are a couple of areas worth talking about this time, so I’ll just delve into them below.


The thing in this game I’m proudest of is the camera. It uses the plane’s current velocity and scans ahead of it, proportional to how fast the plane is going. I think it feels pretty natural most of the time, keeps the view ahead of the plane and doesn’t jerk around too much or anything like that. The only times it falters is during a collision, which is why the balloons are so squidgy when you run into/through them. If I had more time I would’ve made the camera a bit more elastic , so it’d move into place more naturally in such situations, but overall I think the effect I achieved is good.


I spent some time on the controls of the plane themselves, but I already have a few regrets. Namely, I thought if I attached a rigid body to it and did everything through the physics, I’d get free gravity and hopefully it would feel pretty natural. I think in the end, though, the result is debatable. The plane feels pretty loose to control, you can’t really change direction very quickly. You lose speed when doing so as well, which doesn’t feel right; in a real plane, if you took a sharp dive you’d expect to carry that momentum with you when you pull back up. It all means you have to plan your movement a bit more, but that’s tough because it can be difficult to even keep track of the balloons you’re aiming for. I think I could get better feeling controls by ditching the physics system for flying and trying some more direct control. But that would take some experimentation, and this implementation was an experiment as well, and that’s kind of the point of the game a week thing, so I’m not going to lose any sleep over it.

Oh, one final note on the controls. I initially had firing on the space bar, but when I tested this out using the cursor keys for the directions, I found it would not register three inputs at once. I’m pretty baffled by this because I’d have thought it would be a common use case, but apparently this is a real constraint with a lot of keyboards called ghosting. This article explains the issue really well, and the little app at the top confirmed my beliefs. When I try pressing space, up and left, the left key does not register. Right works fine, but not left. So that’s why the firing is on x and m instead. If you ever come up against an issue where some of your input is mysteriously disappearing, ghosting might be to blame.


One area I did exert some real effort into was getting the plane to glide properly. I figured while the plane is horizontal, some upward force should be exerted. I drew a graph while thinking about this, rotation on the x axis and desired effect from lift on the y, which started at zero, hit 1 at 90°, back to zero for 180°, then 1 for 270°. Obviously this ended up strongly resembling a sine curve, so I figured I could put that to use in my game. I found this great website which allowed me to play with and tweak the parameters until I had the curve I desired, allowing me to re-learn some basic trigonometry without having to dig out my old maths notes. I applied it in-game, and I found the result mostly satisfactory, but the plane would slow down even if it was going at no horizontal speed, just falling. So I tweaked it to be proportional to the plane’s horizontal speed as well, meaning when you let go of the throttle, the plane will glide for a while but eventually start falling.

One seemingly obvious addition I made later, but which for some reason completely evaded me for the duration of that implementation, was to just reduce the gravity scale when the thruster is engaged. I don’t know why I didn’t think to implement it sooner, because until that point going up in the plane had been stupidly slow thanks to gravity. Oh well. To conclude, do please note that the plane glides. Thanks.

Stars and Balloons

The stars and balloons all spawn in randomly at the start, in their given area (just over the size of the screen for the stars, about three times the screen width and height for the balloons). As the player moves, the objects that go out of the area disappear and are replaced with another at some point, skewed so that most of them are placed within the future trajectory of the camera. It’s similar to what I did in week 2 for the floor, backgrounds and clouds, but a bit more well rounded. I can see me using something similar again in the future, but the game would have to be right. I’d rather work on more deliberately designed experiences than the randomly generated things that are more suited for game a week.

I went through some additional pain for the balloons when I decided I wanted them to be constrained to a certain area. In the case where the spawn area touches this new boundary, the balloons are now safest to spawn behind the player rather than in front (as with my previous algorithm, a case could occur where an object would spawn on screen if there was no gap between the screen and the spawn area edge). It’s not perfect, but it works, I think. I didn’t see any objects popping in in any of my tests.


My initial concept was purely the idea of ramming into balloons to pop them. When I got that all implemented, though, the resulting game was difficult and boring. I added guns to the plane to combat this, and it makes the experience a bit more compelling, but I kept the score higher for balloon pops via ramming just to add a bit of an incentive there. It’s also the only way to regain ammo if you totally run out.

I was actually done with the game on Saturday; I’d spent all day fixing little things (the balloon spawning algorithm, tweaking with the plane controls and the camera) and was, honestly, pretty sick of it and looking forward to putting it behind me. I put a lot of effort into these little things and had felt that it didn’t really shine through, but that’s just the way things are, sometimes. I found the actual game I’d made from all this really unsatisfactory, so I resolved to just leave it.

However I woke up the next day and figured there were a couple of little things I could implement it to, in theory, make the experience much better.

The main differences are:

  • The controls. As I mentioned before, I didn’t think to reduce the gravity for the plane while the thrusters were activated until right at the end. I think this change makes the plane much better to fly.
  • The limits. In the Saturday version, I’d spent so long fussing with other things I didn’t want to bother constraining the level area. But without any limit on the level, it’s possible to just hold a direction, build up speed, and then just continually hit balloons to extend time and score, without requiring any skill from the player whatsoever. I figured if I could limit the balloon spawn area, the player would be forced to zig zag a bit throughout their play, and therefore to think a little about what they’re doing. I made the top and bottom constraints explicit, as they have easy real life counterparts (planes can’t fly underwater or outside the atmosphere) and just added a tooltip for when they go out of bounds on the left or right. In the finished version, if you fly in one direction from the start you will be forced to change direction at least once before the timer runs out, which in my tests was enough to make the cheap kind of gameplay much less effective.

So that’s more or less it for this week.  I think the end result is okay, but all the annoying little areas I put all the effort into didn’t pay off like I thought they would. Trying to get good control purely from the physics engine and messing with other little things means this one was quite experimental, but mostly in obscure bits and pieces that don’t really shine through in the finished product. Regardless, I’ve definitely learned some lessons there for future projects.