Suggestion: pressing A+B sometimes lead to skipping the level, so I think maybe a new mechanic could be implemented, i.e: a popup menu with reset/skip/back
ps: added to http://arduboy.ried.cl
Thank you for adding the game to the collection! Yes, I’ve also had the issue that you mentioned, and agree that a small popup menu would work very well in this game.
Note: The lead programmer on this project now has account on the community forums @jay.
What a great little game although I must admit I am stuck on level 2!
Another suggestion - can you save the level to the EEPROM once completed?
The YouTube video was actually my second take on filming the game. On the first take I kinda got stuck on level 2 and it took me 100+ moves (and one f-bomb!) to finish it So yeah, it’s easy to get stuck for a while on a level (even if you have finished that level before).
EEPROM saves is one of our top priorities for this game and the Huhuu is Hoo?! game. We also want to do the saving in the ‘right’ way, and there is quite a bit of information to read through before we’ll be ready on that front Eprom saves list
Note: One of the reasons we want to do the saves in the ‘right’ way is because many of us have Circuit Dude save games that are on 40+ level that we don’t want to lose!
Once we have EEPROM saving figured out, the lead developer on this project Aster (@jay) may decide to disable the level skipping functionality.
I’m pretty sure there’s a tool somewhere that lets you save/restore your EEPROM. If not it shouldn’t be too hard to make one, you just need to transfer the EEPROM contents via serial (probably in hex format for simplicity).
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.
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: http://www.hpcalc.org/hp48/docs/programming/libnums.txt). 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.
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
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!