D-pad: move your ship
A: fire bullets
B: fire a beam
Your score is also your health meter. Each time you are hit you lose 100 points, and if you reach negative points then the game is over. For every enemy bullet you shoot down you get one point, and for every enemy ship 10 points. Firing the beam costs 50 points, but if you have 50 or fewer points then it will simply refuse to fire rather than cause a game-over. Enemies destroyed by the beam do not earn points.
Thanks for pointing me at Arduboy2, that looks helpful. As for using the Arduino IDE, I code this stuff for fun and I would rather not code it at all than be forced to use Arduino IDE. I’m distributing the compiled hex files in addition to source specifically because the setup I use is far beyond reproduction by most Arduboy users.
If that were true than platformio itself would be unable to load the binaries it compiles. There may not be a GUI, I guess.
Either way, I’m coding this for my own entertainment and sharing it because I like to share what I do, not because I want as many people as possible to play it. If using more sophisticated tools than Arduino IDE makes it difficult for some users to load, it is at least possible. Using Arduino IDE would make it impossible for -everyone- to play the game because I wouldn’t develop it in the first place.
You don’t even need the GUI to compile (yes, I can’t stand it either). I use makefiles that simulate running the Arduino stuff to build. Unfortunately, I haven’t updated them to the modern Arduino stuff, so they can’t be used with Arduboy.
Is there a writeup somewhere on how to set up platformIO? If it’s really Windows only, I’ll not bother looking into it at all
Due to me running Linux and not using PlatformIO, I haven’t had time to spend the extra effort to upload the game, but looking at the screenshots and video, I personally feel that the game would probably look better white on black instead of black on white. Plus, doing so would increase battery life by a few hours.
Please don’t use the reserved system area at the start of EEPROM for sketch storage. Any EEPROM used by a sketch should start at or past EEPROM_STORAGE_SPACE_START.
It’s better to use EEPROM.update() instead of EEPROM.write() to prevent unnecessary writes to EEPROM.
For sound mute handling you should use the library’s audio subclass functions. That way, the mute state will be carried over from sketch to sketch.
To test if sound is muted, use audio.enabled(). If it returns true then sound is on, otherwise it’s muted.
To set sound on, use audio.on() and use audio.off() to mute the sound. (The Arduboy2 library additionally has audio.toggle() to toggle the mute state.) None of these functions permanently save the state in EEPROM. To save the current mute state to EEPROM use audio.saveOnOff().
If you were to change your sketch to use the Arduboy2 and ArduboyTones libraries, you wouldn’t need to do mute testing yourself, as you currently are with the if(options.mute) statments. Muting would be handled automatically by just using the audio subclass functions.
I suggest you use a different method to enable screen mirroring. With the now recommended Arduboy2 library, holding buttons during startup is reserved for system boot features. begin() waits for all buttons to be released before returning.
If screen mirroring is only used occasionally, such as for creating screenshots for a .arduboy file, you could use a #define to enable it.
If you want it to be controllable without having to re-compile, perhaps look for a specific button or multiple button chord for exiting the intro screen. Or, you could add a menu option for it.
The functions in the ArduboyTones libraries are made static only to save code space. You should still create an object to call them because initialisation is done in the constructor. Your sketch is resetting because the pointer to the “sound enabled test” function passed to the constuctor has not been established.
As per the instructions in the ArduboyTones README:
After creating the Arduboy2 object, create an ArduboyTones object: