[WIP] Arducopter - A top-down attack-helicopter game

Yearning for my childhood favourites Desert-Strike, Jungle-Strike, Etcetera-Strike, I wanted to make a top-down helicopter shooter with the same satisfying sense of momentum found in that series (in particular how you would spin off after crashing into a building - sometimes I’d just crash and spin and crash and spin until I ran out of fuel it was that much fun).

Overview showing flight modes & controls

I started work on this as soon as my Arduboy arrived: git shows my first commit logged in October 2016 with my final commit just 2 weeks after that. I stopped when I realised that there was a small bug in my approach: Arduboys aren’t PCs but I was coding as if they were. I ran out of RAM as soon as I tried to put more than about 3 mobile objects on screen at once.

I’ve been meaning to pick this up again so I’m posting this now in the hope that I’ll be embarrassed into getting on with it, starting with the urgent refactor in which, among other things, I will replace all floating-point variables with something less byte-hungry.

Other than getting the basic game to work, one interesting feature I’m hoping to implement is some kind of procedural level generation algorithm, to save on ROM space. At present, each background tile is selected by passing its x,y coordinates to a fast hashing algorithm, which returns a number which defines the tile type at that location. This means the road tiles, rocks, corpses, ammo crates etc. you see are arranged in the playfield pseudo-randomly: although the level is 256x128 tiles big in this demo (or in other words there are 32768 tiles), each tile will appear in the same place every time you fly past it.

Close-up view of arduboy screen

Clearly, totally random tile arrangements do not make for a very compelling game, so I’ve made the tile manager an interface so that other people could potentially implement their own experimental level generation algorithms, once I open the project up for collaboration.

Anyway stay tuned.


You could use @Pharap’s fixed point library instead of the floating points. Of course, where you can you should try to use integers but to get that some movement integers may not cut it.


Looking good, dude! Procedural level generation would be great for this kind of game!

I really like the helicopter movement in this game. Much nicer angle than my choplifter ‘side-on’ perspective.

Thanks I’m quite pleased with how it moves currently. Let’s hope the feel of it survives the type-ensquishening.

My thinking was I’d use bit fields to really cram the RAM during the refactor. For example the chopper’s heading is currently stored as a double-precision float which IIRC is 32 bits, but actually I doubt there’d be a noticeable change if I limited the possible directions the helicopter can face to just 32, meaning it could be stored in a 5 bit bit-field. If that’s too clunky, I could always throw it another bit or two.

I’ll take a look at @pharup’s library too to see if it’ll help.

Hopefully I can get something working. The current fast hashing algorithm could be used to give the basic landscape some randomness, and then perhaps the road tiles could all be joined up on-the-fly, and little forests or villages made whenever two trees / houses happen to exist within a certain distance of each other.

It seems that although the arduboy is very memory constrained, the processer is actually pretty decent so something like a metaballs algorithm for creating blobs of features might be possible.

Then it’ll just be a case of searching through the billions of possible levels given different random seeds to find the handful which happen to have interesting layouts and baddies in the right places. Et voila - a whole level defined with just a seed, a few bytes for augmentations and a few more to give the mission a name. Could then potentially pack several large levels in a single arduboy ROM.

1 Like

An IEEE 754 double-precision floating point number is 64 bits.

But the compiler used by the Arduino IDE to compile for ARM implements double as an IEEE 754 single-precision floating point number, which is 32-bits.

However, the compiler still considers float and double to be different types, so they aren’t synonymous, even though they’re implemented the same for AVR.

That sounds like a good idea.

Bear in mind that the Arduboy has no barrel shifter though, so when it compiles to assembly you can often end up with multiple single-shift instructions if there’s a lot of shifting.

I think after a certain point the compiler actually writes a multiple shift algorithm and embeds it as a function, like it does with floating point arithmetic.

If you need sin and cosine at any point, I have a solution for that.

Oops … wrong forum.

1 Like

I am forever writing one instead of the other.
On both forums I end up writing the opposite of the one I mean.
First time I’ve let it ‘go to print’ before catching it.