Pyoro_1.0.hex (38.1 KB)
I just finished porting the game Pyoro (known as Bird and Beans in the US) to the Arduboy, and wanted to share the hex file (and code).
You can find the files here.
RIGHT - Move Pyoro
A - Shoot tongue
B (on main menu) - Clear save file
Name your .ino file Pyoro.ino instead of Project.ino so people compiling using the Arduino IDE don’t have to rename it or put it in a folder named Project.
It would be a good idea to include arduboy.flashlight() after arduboy.boot(), to allow recovery if a version of the game ever causes the “bootloader magic key” problem.
Forcing audio on in setup() may annoy some people who wish to play the game with sound muted. You should use arduboy.audio.begin() instead of arduboy.audio.on().
Along with the previous suggestion; since the game has no way for the user to toggle sound on and off, you could include arduboy.systemButtons() before arduboy.audio.begin() so the mute state can be set during startup.
Or, instead of all the extra function calls in setup, you could just use arduboy.begin() instead of arduboy.boot()
i don’t wanna use the arduboy.begin() screen. Too many splashes and it starts to look like a Hollywood movie.
Pushing an update in minutes Done!
The first 16 bytes of EEPROM are reserved for system use (such as saving the mute state). Sketches must only use EEPROM locations starting at or after the defined value
EEPROM_STORAGE_SPACE_START for the high score and
EEPROM_STORAGE_SPACE_START+2 for the save magic number
Just to make things a bit cleaner, in setup() you can use
I actually saw that snippet on another post of yours, so I just used that. Will do, then!
Difficulty now increases for every 500 points you score. Beans go faster, spawn more often and Pyoro goes faster too.
Save magic changed since the difficulty and gameplay are different, so you will lose your high score.
@Pharap Here are answers to your respective comments in order:
itoa because using the
print(int) overload is super laggy. My code only calls
itoa when score updates, instead of on every single frame. If I don’t redraw the score, it can get hidden by beans falling through.
aHeld works differently in that it uses
aPressed's previous value, which goes through the validation of the A press (leading to the tongue having extended) which
justPressed() does not do. I did try swapping out but it didn’t work.
Didn’t notice because
req() was only used for small amounts
Nope. As per C convention,
struct types can only be referred to by prefixing them with
typedef'd. And omitting the cast can create confusion for whoever reads the code afterwards.
It shouldn’t be, usually it’s fairly quick.
If I can’t prove otherwise then fair enough.
I see, I hadn’t noticed that you set
aPressed = false;.
This isn’t C, this is C++. In C++, the
struct is optional.
(If this was C, you wouldn’t be able to do
arduboy.display() because C doesn’t have a concept of member functions.)
The reason you are getting an error is because you named one of your images
bean as well (i.e.
PROGMEM const unsigned char bean), so the compiler can’t figure out whether you mean the struct
bean or the array
A simple fix would be to capitalise the type names to
That’s one of the reasons C++ tends to prefer constructors over C-style brace initialisation.
Personally I don’t think omitting the cast is particularly confusing, the array name is quite clear about what it contains, but fair enough.
I usually just code in C style, so I think I’ll stick with my
(struct bean) cast, should it only be for aesthetic purposes. It doesn’t cause any problems AFAIK. (plus it allows me to have an image called
bean next to it )
print(int) might be superfast, but still, converting only on change leaves more cycles per frame, so more room for improvement.