Home button functionality

The Home button is a button meant to have a consistent behavior across all games. You use it to exit games, adjust volume and light, take screenshots, etc.

When you "exit" the game, it flashes the "loader" from the SD card. It's a graphical browser that let you select a game, preview screen shots, adjust system-wide settings, etc. 

This way the loader can easily be updated without having to recompile all the games, and leaves more free memory for your programs. The flash memory wearing out is not an issue, this has been taken into account.

Wearing out the flash was something I was worried about with the Classic, though in practical terms I can't imagine anyone actually doing it unless they where swapping lots of data in and out of flash dynamically.

I assume that we'll be able to acess the settings that the loader sets within our games, correct? or detect that the home button has been pressed so that we can pull up a 'do you wish to save your game' prompt if appropriate?

You don't have to care about the global settings because everything is handled by the home menu (for the common ones like volume) and the loader (for the less common ones like language). Currently the game can't know when the home button is pressed to save the game beforehand, but you can either use auto-save frequently or use the menu button for everything game related (save game, inventory, map...).

I consider adding home button detection available to the developers, but I know already people are going to abuse it and override the home menu, which is very, very bad for the user experience. The most simple way would be to trigger the home menu when the home button is released, so you can trigger your auto-save (but is has to be non blocking, with no intermediate menu) when the button is pressed.

For now, just use the menu button instead ;)

Couldn't you have the user provide a callback function handler to Home that it would always called first?  That could block, show a dialog, etc... and then just have it so that if you hold Home when booting that would ALWAYS trigger reflashing the loader?  You could even potentially embed that into the bootloader itself - though I suppose that boat might have shipped already - but you could still easily add it to the boot sequence of the core library.

Advantages:

- allows showing a save dialog, save state, letting the user decide

- still allows access to Home if "this sketch is very badly behaved" via holding a key at boot time to "reset"

Disadvantages:

- Home button press doesn't IMMEDIATELY hit loader?

- Users have to learn the reset procedure for any apps that are badly behaved.

I think developers would be encouraged by this pattern to do the right things (particularly if given examples).  So they only case you'd have to worry about:

1. A bug that makes it into production that caused the save to lock up or something (which you could handle with a reset)

2. A user who purposely decided to do this ANYWAYS because they feel the user experience of losing their progress would be WORSE - and if everything is OSS you really can't stop users from doing this.  So I think it'd be best to find a potentially consistent usable pattern than to just say no and let people invent 5 or their own patterns.

Just my 0.02.

I'll think about this, but there should never be a blocking menu when hitting the home button, to have a consistent user experience. You can use auto-save and add a game menu with a save option in it too. The home button is meant not to be used by the devs. The Gamebuino Classic has proven me that you can't trust devs to provide a menu.

One other option is to encourage "instant resume" style apps... but that requires thinking about things differently... ala like the early (and still I guess) iPhone apps... that when they are force quit they save the full state and when you reload them they pick up right where they left off - as if they had still been running the entire time.  

Also it should be also be easily possible to have it BOTH ways... have a user function that is called and then if it doesn't return in a given amount of time you just take control back and jump to the LOADER anyways.  I can think of several different ways to do that on the Atmtel chip and I'm sure there are a few more ways to accomplish it on the ARM M0+.

Out of curiosity what happens if you let dev provide a menu?  They don't?  Or they screw it up? Or it's buggy or what?  I'm curious exactly what we're trying to protect people from.

I  get what you're saying about a consistent experience, but just killing my application when I press the "Home" button sounds pretty annoying to me - without some type of "are you sure you want to quit this app" dialog.  Even if the library had control of the dialog that would be one thing (see how PICO-8 does this).  It has a "hardware" menu but you can add text to it that then calls use functions.  So you hit home and  you have two choices: 

1. Quit game, return to loader (whatever it was be called)

2. "Save Game", text and pointer to function provided by the running application

That way the library GUARANTEES a consistent experience... either an immediate jump to loader or showing a library generated menu with one developer generated option.  If the developer REALLY botched their save completely you'd just reset the device, hit Home and then choose "Quit" instead of "save".  

I also like the idea of a long hold for a "Reset" vs menu.  If I hold the button for 3 seconds then I'd be fine with "Rebooting".  A momentary press just sounds scary to me. 

From PICO:

The "AutoSave", "Save", and "Restore" options are application specific (PICO-8 allows you to add up to 4 choices I believe).  The other options are part of the core menu - and the menu is part of the "hardware", not driven by the application.

Actually I think a long-hold with "instant dialog" would be pretty nice... making it impossible to EVERY trigger accidentally.  You hit Home and *immediately* a dialog saying "continue holding Home another 3 seconds to access the loader" (or whatever) pops up.  If you continue holding you go Home.  If you release the dialog erases itself and the apps next render pass would re-render the app.

I  get what you're saying about a consistent experience, but just killing my application when I press the "Home" button sounds pretty annoying to me - without some type of "are you sure you want to quit this app" dialog.

Hitting home opens the home menu, off of which one option is to exit the game. So only hitting the home button once will just, well, pause your game. If you hit the home button again it will just close the home menu

OH, so there already is a menu. :-)  Well that solves my "accidentally reboot" issue completely I think.  Also means you're really only one step away from custom menu hooks like I mention above - if that was found to be a good idea. 

oh! so it pulls up a menu that you can then go back to the game from, that's good to know. That makes the worry about save prompts less of an issue.

An 'on pause' event might only be needed for backpacks that do in-game calculations, then.

That also means that every game, no matter how basic, has a pause menu.

Currently when you press "Home" you have a menu with the following items:

- LIGHT => adjust the light effects intensity (or disable)

> EXIT => goes to the loader, we might add a call back to save games

- VOLUME => adjust the sound volume (or mute)

- SAVE IMAGE => takes a screenshot

- SAVE VIDEO => starts a screen recording of 2 seconds (hold A to make longer recordings)

You navigate the menu with UP/DOWN. When you open the menu, "EXIT" is selected by default. LIGHT and VOLUME are just 1 button press away (UP and DOWN respectively), because these are the more commonly used settings.

This way we have a consistent way to exit the game and adjust the settings. On the Gamebuino Classic, it's a nightmare to find the right key/menus combination to exit a game. Here, it's just always the same. You can pause and exit any game, no matter what the dev did.

Everybody wins: devs don't waste time making a home menu, users have a consistent experience :)

huh, I spotted the screenshot thing in the kickstarter, but didn't know it could record clips!

Ease of use was a big focus on the new Gamebuino META. Our goal is that a kid that can't read should be able to use the console. So, no key combination, as little text as possible, as many pictograms as possible. And of course, as un-brickable as possible.

As unbrickable as possible

*looks over at his bricked classic* Good for some of us adults too.  I gotta get around to fixing that...

As for the key combos, that might be a requirement for at least one of the games I make, just to work around having 7 keys. I'll try to keep that to the bare minimum, however.