Balancing Act

BalancingAct.ino.leonardo.hex (59.6 KB)

Banner art created by LENZ .

Balance falling objects puzzle game


Release Page


What’s a person to do when given superhuman strength?

Join a circus and show the world your superhuman strength by holding up heavy objects!

The secret to your power is that you can lift anything as long as you don’t have too much weight on one side.

How to Play

Place objects on the platform and try to avoid filling the gauge bar up either all the way to the left or right.

You can balance out the weight on one side by placing objects on the opposite side.

The goal is to try and keep the balance gauge from reaching the ends by balancing the weight on both sides of the platform.


Use left/right button to move falling objects.

Use up/down button to fast drop objects.

Use A/B button to pause/unpause game.


Great little game. I love it!

1 Like

Interesting game. Very fun to play. No source code?

1 Like

If you want to download the source code it is in the Release link, if you just wanted to see it you can go here or click Code from the release page.

1 Like

I suggest you don’t include
in setup()

Let arduboy.begin() set the audio mute state based on the current setting in EEPROM.

1 Like

why the almost all object’s methods accesses Arduboy2::audio.on();
but not;

A better question would be why is nobody calling Arduboy2Audio::on().

All three of these call exactly the same function:

  • Arduboy2::audio.on()
  • Arduboy2Audio::on()

This is because of an obscure C++ rule that allows static member functions to be called like normal member functions via an object (despite being tied to the type rather than the object). (Most other languages don’t have this rule.)

Personally I prefer the third form because it makes it clear that neither the arduboy or the objects are being manipulated.

(The object is actually completely redundant - the object itself is empty and all the class’s functions are static and operate on static member variables.)

At any rate, @MLXXXp’s point still stands.

Under the majority of circumstances Arduboy2Audio::on() shouldn’t be used because it will enable audio regardless of the user’s preferences.

If arduboy.begin() is being used then it will call Arduboy2Audio::begin(), which will set the audio according to the user’s preferences (as set in the first 16 bytes of EEPROM).
If arduboy.begin() is not being used for some reason, Arduboy2Audio::begin() should be called manually to enable audio (if audio is needed).


When first added to the original Arduboy library, the audio class functions were not declared static, so that form wouldn’t have worked. There was a mixture of static and non-static members in the library (with a few being changed over time) until recently, when a conscious effort was made to make everything that could be, static.

Personally, I prefer the first form because it will work regardless of whether a function is static or not, without having to consider it (and doesn’t invoke any penalty for doing so).

(I probably won’t say anything more on this but if anyone wishes to continue the discussion, it should probably be done in a new topic.)

1 Like