MazezaM - Puzzle Game

OK, thanks. Is saving/restoring EEPROM what people in the community typically do when they want to try out a new game? Or do most people just load in a new game and hope that it doesn’t conflict with previous EEPROM saves?

Yes, or they examine the code first to check for conflicts.

Although heavily discussed, there’s currently no agreed upon standards or methods for the use of EEPROM in Arduboy sketches (other than avoiding the library system area of 16 bytes. User EEPROM starts at EEPROM_STORAGE_SPACE_START).

All of the games I have made state in the Arduboy file the save location in EEPROM. The Arduboy Game Center, I have built, asks for the location in EEPROM the game being added is saving to and shows it on the webpage. Eventually i plan on writing a function to let a user know if the game they are downloading will overwrite the EEPROM location of a game they have favorited.

1 Like

OK thank you both for your replies.

Is the current best practice to simply choose a specific location at EEPROM_STORAGE_SPACE_START or beyond, and then always use that specific location? Also, is there currently a list of locations that are currently being used by other applications so that we know which locations to avoid? (It sounds like Michael is making some progress towards this.)

EEPROM is currently the Wild West. To my knowledge there is no master list, my list is only partial from games i have dissected. I do suggest staying above 100 since several games are currently overwriting each other in the low numbers. My games are in the upper 900’s, Crait and Circuit Dude are in the 400’s. As for size i suggest best practice is to not use a lot of EEPROM there are a few games i’ve come across that clobber many games by chewing up over 100 bytes.

This is a little off topic but in the old HP calculators world each library had to use an specific number, and this number was used for installing and everything so collisions were not good (old rules are here: That worked nice for several generations of calculators. I am sure that this community is smaller, hence easier to organize.

If we eventually get an official repo, the smart thing would be to register your games to get an eeprom address start and size sequentially.

The current best practice for EEPROM is to use well commented _#define_s in a prominent place near the start of your code, so it’s easy for someone to change it if they have a conflict with another favourite game.

For pre-compiled code, best practice is to release your game as a .arduboy file, which has fields in the included info.json file to specify the EEPROM area used (if any). This allows the possibility of an upload manager or standalone program to be able to parse the .arduboy files and create a list of EEPROM areas used. Such a program could also alert about conflicts.

Hopefully we’ll eventually get the mythical Arduboy v2 with a micro SD slot so people no longer have to worry about EEPROM. Then people won’t have to worry about what ‘index’ they’ve been assigned, they just have to pick a unique name for their game.

1 Like

Looks good. I would make the reset menu look a bit better. One idea I have is having a popup style menu show up and arrows for selecting yes / no.

Agreed… or a frustrated self destruct like circuit dude

1 Like

Thank you all for your responses! I will be fixing the reset button issues in the next couple of days, and I’ll have version 2 of the game (including EEPROM saving) within two weeks or so.


As promised, the updated version 1.1 can be found here.

Great … can’t wait to download it!

1 Like

Version 2.0 of MazezaM is now complete, located here! The game now includes saving, a level select screen, an in-level menu, and the controls have changed slightly. Undo is now mapped to the A button and the menu is accessed with the B button.

1 Like

You should probably get @ardubeast to edit that into the main post as well.

1 Like

Version 2.5 is now available, the download link can be found in the original post. In addition to some menu changes, this version allows you to save your progress midway through a level to come back to later, and includes an extra level at the end.


I’ve been playing with this updated version for about a week now and it is very enjoyable. The save feature tracks which levels you have completed (and with how many moves you made on each), and you can also save your intermediate progress on one level. This has encouraged me to work through to some of the higher levels for the first time. As @jay mentioned the button functions have now been ironed out as well. Overall, this is probably my new favorite version of MazezaM. Congratulations Aster!

1 Like

re: extra level. The level that @jay mentioned is based on a new academic paper on MazezaM which will be presented at a conference in Japan in late-August. Despite the compact 128x64 resolution of the Arduboy, this new level alone takes over 200 moves to solve.

More generally, the paper shows that MazezaM levels can take an exponential number of moves to solve with respect to the size of the level. This property is shared by other notoriously difficult puzzle games like Sokoban and Rush Hour and maybe @crait’s Circuit Dude has this property too? :thinking: :face_with_raised_eyebrow:

For those who are interested, the levels in the paper can only be solved by following a specific pattern known as the binary reflected Gray code and a larger level is shown below. MazezaM was previously shown to be NP-hard, and the new result is one reason to believe that it could be PSPACE-hard. The paper was written with the original creator of MazezaM (Malcolm Tyrrell), the author of the NP-hardness result (Ben North), a student from MIT (Justin Kopinsky), and with @jay from Bard College at Simon’s Rock contributing to the work this summer.


I’d love to pretend I understood it all, but I never get on well with formal academic papers. (I find they tend to be formal to the point of obfuscating the explanation (and yes, I see the irony in that), or quite maths-heavy.)

I sort of get the idea of it at least, even if not through the RBC approach.
From the image alone I can see how that level is composed of the same pattern repeated many times, and that each time you extend the pattern you exponentially increase the number of moves required to solve the level (thanks to required back-tracking).

Also I can see the relation to sokoban.
In sokoban the player can move in 2 dimensions and boxes can move in 2 dimensions, whereas in mazezam the rules are similar but the player moves in 2 dimensions and ‘boxes’ only move in 1 dimension.

Wait a minute, why does this link to my comment in particular?

Did I accidentally suggest something that might suggest Circuit Dude is NP-Complete?
Or do you just want the world to buy a pigeon dating-sim? (I regret nothing!)

It well might be though.
A lot of these sorts of puzzle games have similarities to the travelling salesman problem in that they consist of a sequence of choices (in particular, which direction to travel in at any given point) and have a well defined start and end point.

Hi @ardubeast and @jay - sadly it seems your private certificate has expired for the site, preventing access to your GIT source… any chance your institute will reinstate it?