Nicknames and Arduboy

I just had a great idea!
Would there be a way to make a application that can nickname your arduboy?
If that is so, is there a way to make that nickname stay on the arduboy, even once the app is replaced with another app?
Because I though maybe the arduboy could be nicknamed and that nickname could be used in other games.
As a bonus, is there a way to make there be only one application that can change your nickname, and every other application can only read the nickname? It would be like your Mii on Wii U or Xbox live character, except without the whole customization thing.

(The reason this is called development is because I thought this could be a thing more about the software, not so much arduboy as a whole.)

Yes! This is something that you can definitely do. I see potential in having something like this, actually. Maybe whenever you go to enter in your initials in a high-score screen or something, your name can be known by default. :smiley:

The problem is, that you’d have to save it in SRAM and as it wasn’t a feature from the beginning, there’s nothing stopping people from saving over it.
It may be something to think about for future revisions of the library, or even the next hardware version (if that’s a possibility).

If you stuck it way out at the end of EEPROM I can’t imagine that anyone else is writing there :slight_smile:

Nice idea. Slightly overlaps this original thread: Distinguishing one Arduboy from another in software?

1 Like

And as I mentioned in that thread, I could reserve the space in the Arduboy2 library’s system EEPROM area and provide functions to read and write it. I don’t see a problem with expanding it from 2 to 4 or 6 bytes, to allow storing a nickname in ASCII instead of just a numerical user ID.

A sketch to allow inputting and saving the ID could be included as an example in the library.

So, if this sounds like a reasonable approach and there is enough interest in having it, I can implement it. I don’t want to add it if it’s never going to be used, though.

1 Like

If you take the time to implement it into your new library, I’ll support it in my upcoming game.

I guess we have to decide how many bytes the ID should be. @crait, you previously said:

Every game I’ve seen saves 3 letters (generally intended for the user’s initials). So should the “nickname” be only 3 bytes? That may be a bit too short for the purposes others intended, but if it’s longer than 3 it may be difficult to use for high score auto-entry.

I think 3 is fine most cases. I know Arduventure uses 5, which I think is a good length, especially considering my name has 5 letters. If we had plenty of room, I would say having both a 3 (initials) and 6-letter long name would work separately. :open_mouth:

If I do add this feature, I was thinking of maybe displaying the ID near the bottom of the screen during boot up, below the ARDUBOY logo, if the game uses the Arduboy2 class and begin() (not Arduboy2Base because it doesn’t support text). I think it would be nice to have your initials, or whatever, displayed during boot.

This would be another “startup feature” function, separate from bootLogo(), so it could be left out when using boot(), as another option for saving space.

Pretty nifty idea, but with the simplicity of the Arduboy, it may look cluttered. Are we using a smaller boot logo? If so, it may work.

In general, I really like the idea of customizing the Arduboy somehow with universal settings. I love the global sound on/off feature.

I do too, but I also don’t want to get complaints that it’s too short, so I’d like to get some consensus before I do it.

Maybe we can compromise and make it 4. This way the set/get functions could use an ASCII packed uint32_t (a long) for the parameter, instead of needing some kind of string pointer or something.

I’m thinking I would display the ID only for a second or so, horizontally centred at the very bottom of the screen, and only after the ARDUBOY logo finishes scrolling down. The logo would scroll down and stop at the centre, the blue RGB LED would go out, then only after this would the ID be displayed for a short time.

If that looks too cluttered, we could see how it looks to clear the screen after the logo stops and then display the ID by itself for a second or so, centred both vertically and horizontally where the logo was.

Yeah, we can definitely play around with it and see what looks best.

The feature can be simulated, to see what looks best, even before adding it to the library. The ARDUBOY logo doesn’t automatically get cleared, so a sketch can set the cursor and write text anywhere on the screen with the logo still there. Or, you can clear the screen first, to see how it looks without the logo.

Personally I would keep more than just a few bytes free for this idea. Perhaps 8 or 16. That way it could be used for other user settings also, screen contrast (if that’s possible), sound on/off etc.

@spinal, we’ve already set a good amount of memory aside for stuff like that, but the only setting we’ve really ever come up with was sound on/off.

P.S. - There’s no contrast on the Arduboy. :slight_smile: Only black and white!

adding text to the boot, means adding a font, means more bytes used …
Because we do everything sprite based (even text), we probably won’t take advantage of it.

BUT on the other hand if you’re already using highscore with a font, it won’t take much extra bytes.
And besides all of that I would go for 5 bytes.

1 Like

(OT, so to discuss this further start a new topic.)
Actually, the display does have a contrast setting but its range is so narrow that it’s hardly worth changing.

Yes, that’s why I said it would only be available if the sketch used the Arduboy2 class, which pulls the font table and much of the text generation code in anyway.

The ideal length is going to depend on the actual purpose. (“stored” means stored in a non-volatile way, in this case in EEPROM, such that it survives power cycles):

  1. A “name” generally only stored once to identify a unit or its owner: e.g. “John Doe”. Since it’s only stored once, it can be quite long.
  • A text ID stored in multiple places, such as in each entry of a high score table. This should be long enough to allow many unique combinations but short enough not to take up too much space. 3 bytes is a common length used for this.

  • An ID used only to differentiate between multiple units for multi-unit/multi-player gaming, as discussed in this topic. This doesn’t even have to be human readable. It should be long enough to uniquely identify a fair number of units but short enough to allow any code written to compare them to be small and efficient. A 16 bit (2 byte) binary value would likely be sufficient for this. Even using only 1 byte would be good for up to 256 units but may require frequent changing to avoid conflicts.

How does this sound?:

Have both a 6 byte text ID and a 2 byte binary ID, making 8 bytes total stored in system EEPROM.

For the text ID, the get/set library functions would each accept a pointer to a null (0x00) terminated string array in RAM provided by the sketch. The allocated array would have to be at least 7 bytes long, to hold up to 6 characters plus a null terminator. It would probably be a good idea to disallow 0xFF, treating it as a null, since that’s the value of an erased EEPROM byte.

If a sketch wanted to pre-populate a high score entry, it could use the first 3 (or whatever) characters of the text ID then allow the user to change it if desired. This is no more difficult for the user than having to enter into a blank field.

For the binary ID, the get function would return a uint16_t and the set function would accept a uint16_t.

// prototypes in Arduboy2.h:
void setUnitName(uint8_t* name);
uint8_t getUnitName(uint8_t* name); // returns the actual length of the string

void setUnitID(uint16_t id);
uint16_t getUnitID();
// usage in sketch:
#include <Arduboy2.h>

Arduboy2 arduboy;

byte unitName[7];
unsigned int unitID;


unitID = arduboy.getUnitID();

1 Like