14.1.1 Handling When the User Touches an amiibo to the Touchpoint
When the user touches an amiibo to the touchpoint in scenes where the application interacts with amiibo, the application must respond in some way, no matter what type of amiibo it is. Specifically, the application must respond in some way even if the user touches to the touchpoint an amiibo with a character ID the application has no plans to support, or an amiibo with an NFP tag format version that the application does not support. If the application does not respond at all, the user has no way to tell whether this behavior is normal, or whether the system's NFC reader/writer or the amiibo itself is malfunctioning.
This requirement is tested using all three of the amiibo types below.
# | amiibo Type | Location of NTF File |
---|---|---|
1 | amiibo supported by the application | amiibo Data List |
2 | amiibo with a special character ID that will never be used for a retail product (amiibo written with NVL-DUM1_00_00.ntf) | amiibo Data List |
3 | amiibo with a special format version that will never be used for a retail product (amiibo written with NVL-DUM4_00_00.ntf) | amiibo Data List |
Testing with type 2 above checks whether the application responds when the user takes an amiibo with a character ID the application does not support and touches it to the touchpoint. This test uses an amiibo with a special character ID that the application has no way to know ahead of time. (For example, if the application has a preexisting internal list of character IDs it does not support, this character ID will not be on the list.)
Testing with type 3 above checks whether the application responds when the user takes an amiibo with an NFP tag format version the application does not support and touches it to the touchpoint. The format version of NFP tags may change in future. If an amiibo having an unsupported format version is touched to the touchpoint, the library returns a ResultInvalidFormatVersion error when mounting the amiibo. Nevertheless, even in this case the application must still respond in some way.
Types 2 and 3 in Table 14-1 amiibo to Test are the same among all applications, regardless of what amiibo each application supports. Therefore you do not need to prepare new tags for each application when testing these categories of amiibo.
If the user takes an NFC tag that is not an amiibo and touches it to the touchpoint, that falls outside the scope of this item and is not subject to these requirements.
14.1.1.1 Responding When the User Touches an amiibo to the Touchpoint
Guideline Item |
In scenes where the application recognizes amiibo, the application must respond in some way to all amiibo that the user touches to the touchpoint. |
---|---|
Software to Be Tested |
All applications that support amiibo. |
Test Method |
Enter any scene where the application recognizes amiibo, and perform the following steps.
|
Pass/Fail Determination |
Passes if, in steps 2 through 4, the application responds in some way. |
14.1.2 Handling When the User Touches a Corrupted amiibo to the Touchpoint
The data region of an amiibo may become corrupted if the amiibo figure is moved away from the touchpoint while it is being written to. When the application recognizes corrupted amiibo data, the application must notify the user that the amiibo they touched to the touchpoint is corrupted. Nintendo also recommends checking with the user about whether to restore the amiibo before transitioning to the process that restores it.
The Nintendo 3DS system saves backup data that is used to restore amiibo, but in some cases—such as if the user is playing on a different system than the one they backed up the amiibo on—this backup data does not exist. When the system recognizes that the user touched a corrupted amiibo to the touchpoint, the system is also able to check whether backup data exists for that amiibo. You must handle this situation in one of the following two ways depending on whether the backup data exists.
- If no backup data exists for that amiibo, the application must notify the user that it may be possible to restore the amiibo on a system where they have used that amiibo before, and also inform them that it is possible to reset the amiibo from amiibo Settings in the HOME Menu Settings.
- If backup data exists for that amiibo, the application must either call the amiibo Settings menu in restore mode, or transition to an independently implemented restore feature.
In scenes in your application that only use factory-hardcoded data (from this point on referred to as “permanent data"), Nintendo recommends using the nn::nfp::MountRom function instead of the nn::nfp::Mount function to mount the amiibo. The nn::nfp::MountRom function can mount the tag even if the amiibo touched to the touchpad has corrupted data, and if the data being accessed is permanent data, this function is able to get the permanent data with no need to restore the amiibo first. However, if your application uses the nn::nfp::Mount function to mount tags in any scene—even in a scene that only uses permanent data—that scene becomes subject to the requirements in this section. This is because the nn::nfp::Mount function is always able to recognize corrupted amiibo data.
For details on the differences between the nn::nfp::Mount function and the nn::nfp::MountRom function, see their pages in the Function Reference or see the “Mounting a Tag” subsection in the 3DS Programming Manual: NFP Library.
Permanent data cannot be corrupted by user operations such as moving the amiibo away from the touchpoint while it is being written to.
14.1.2.1 Handling When the User Touches a Corrupted amiibo to the Touchpoint
Guideline Item |
When the user touches a corrupted amiibo to the touchpoint, the application must notify the user that the data on the amiibo is corrupted. The application must then handle the situation in one of the following ways, depending on whether backup data exists.
|
---|---|
Software to Be Tested |
Applications that use amiibo.
|
Exceptions |
Scenes that only use factory-hardcoded data and do not detect amiibo data corruption.
|
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
14.1.3 Using the Application-Specific Region
You must submit a list of the amiibo used in your application to Nintendo, and receive Nintendo's approval. amiibo used by applications fall into the two categories below.
- amiibo whose application-specific region is used by the application
- amiibo whose shared region only is used by the application
If your application uses the application-specific region of amiibo, you must comply with the following two requirements.
- The application must only access the application-specific regions of amiibo that you submitted on your list to Nintendo in advance.
- To access the application-specific region, the application must use only the access ID assigned to that application.
14.1.3.1 Restrictions on Reading and Writing the Application-Specific Region
Guideline Item |
Applications must only access the application-specific region of amiibo for which access to this region was requested on the list submitted to Nintendo in advance. |
---|---|
Software to Be Tested |
All applications that access the application-specific region of amiibo.
|
Test Method |
|
Pass/Fail Determination |
Passes if, in step 2, the application cannot read or write the application-specific region of the amiibo. |
14.1.3.2 Checking the Access ID
Guideline Item |
The application must use the access ID assigned to that application by Nintendo. |
---|---|
Software to Be Tested |
All applications that access the application-specific region of amiibo.
|
Test Method |
|
Pass/Fail Determination |
Passes if the access IDs checked in step 1 and step 3 are the same. |
14.1.4 Restricting the Frequency of Writes
Every time the application writes to amiibo, system NAND memory is accessed in order to back up the amiibo data.
For this reason, keep in mind that system NAND memory has a limited number of erase-write cycles (see section 3.1.5 Write Frequency to Various Media) and if at all possible, avoid game designs that write to amiibo with a high frequency. In particular, if your application writes to the amiibo at repeated automatic intervals while it is in contact, you must write to the amiibo no more than four times per minute. Here, the word "automatic" specifically means that while the amiibo is left in contact with the touchpoint, the application writes to the amiibo without any associated user operation triggering the write.
This restriction does not apply to applications that write to amiibo only at limited, specific scenes in the application, such as the character selection screen.
14.1.4.1 Restriction on Automatic Writes
Guideline Item |
Applications which have the user leave an amiibo continuously in contact with the touchpoint, and which write to the amiibo at repeated automatic intervals while it is in contact, must write to the amiibo no more than four times per minute.
|
---|---|
Software to Be Tested |
Applications that write to amiibo.
|
Exceptions |
Writing to amiibo only at limited, specific scenes in the application, such as the character selection screen.
|
Test Method |
Check the source code. |
Pass/Fail Determination |
Passes if automatic write operations occur no more than four times per minute throughout the application as a whole. |
14.1.5 On-Screen Indication When Reading and Writing
If your application does not clearly indicate where to place the amiibo when prompting the user to use it, they may touch it to the wrong place and mistakenly think the amiibo is faulty when the application cannot detect it. To prevent this, applications must clearly instruct the user to touch amiibo to the NFC touchpoint when prompting the user to use amiibo. Be aware that the location of the touchpoint is different depending on whether your application is running on a CTR or a SNAKE system. The amiibo Artwork Collection includes images that indicate where the touchpoint is. If necessary, feel free to use these images in your application. Note that for SNAKE systems, the NFC touchpoint is the lower screen. Users may have trouble seeing indications displayed on the lower screen while they are touching an amiibo to the touchpoint, because the amiibo is in the way.
If your application uses NFP, it is also generally important that the user knows when to touch an amiibo to the NFC touchpoint and how long to hold it to the touchpoint before moving it away. Although Nintendo simply recommends that applications display some "reading in progress" indication on screen while reading amiibo, you are required to display a "writing in progress" indication on screen when writing amiibo. An on-screen indication is required specifically when writing amiibo because failures to write data and data corruption occur more easily with NFC technology than with system NAND memory or SD cards.
For the on-screen indication when reading, Nintendo recommends the following.
- While reading, display some sort of on-screen indication that lets the user know the application is currently reading data.
- If reading fails, display some sort of on-screen indication that lets the user know the read operation has failed.
For the on-screen indication when writing, Nintendo requires the following.
- While writing, display some sort of on-screen indication that lets the user know the application is currently writing game data.
- While writing, display some sort of on-screen indication instructing the user not to move the amiibo away.
You must display the on-screen indication during the intervals described below.
- From the call that starts execution of the CreateApplicationArea function through to when the CreateApplicationArea function completes.
- From the call that starts execution of the WriteApplicationArea function through to when the Flush function completes.
In addition, if you use NFP you must make it clear to the user whether the write succeeded or failed.
In particular, when a write fails, the application must prompt the user to write to the amiibo again.
The reason the application must clearly indicate success to the user when the write succeeds is to let them know it is now okay to move the amiibo away from the touchpoint. Otherwise, if the application requires some sort of other user operation to progress to the next sequence, the user has no way to tell how long they must hold the amiibo to the touchpoint. Consequently, if the application properly handles cases where the write fails and automatically proceeds to the next sequence when the write succeeds, then the user is already able to tell that the write succeeded and there is no need to explicitly indicate so.
Note that if the user touches a corrupted amiibo to the touchpoint, you must also let the user know it is corrupted. For how to handle corrupted amiibo, see section 14.1.2 Handling When the User Touches a Corrupted amiibo to the Touchpoint.
14.1.5.1 On-Screen Indication When Reading and Writing amiibo
Guideline Item |
Applications must display some sort of on-screen indication instructing the user to touch the amiibo to the NFC touchpoint when prompting the user to use an amiibo. In addition, applications must do the following when writing amiibo:
|
---|---|
Software to Be Tested |
Applications that use amiibo. |
Test Method |
|
Pass/Fail Determination |
Applications that only read amiibo: Passes if, in step 1, the application displays some sort of on-screen indication instructing the user to touch amiibo to the NFC touchpoint. |
Applications that write to amiibo: Passes if all of the following conditions are met in addition to meeting the conditions for Applications that only read amiibo.
|
14.1.6 Security of NFP Tags
Because of the nature of NFC technology security, Nintendo recommends not storing data on NFP tags that would cause problems if it were copied or altered.
No required guideline items.
14.1.7 On-Screen Indication in Wireless-Disabled Mode
When the system is in wireless-disabled mode, the NFP library returns ResultWifiOff and does not detect tags.
If a function returns ResultWifiOff, Nintendo recommends displaying a message somewhere in your application prompting the user to enable wireless communication. This is because it is not intuitively clear to the user that disabling wireless also disables the ability to read and load amiibo.
No required guideline items.
14.1.8 Displaying the Owner's Mii
When displaying the owner's Mii, specify CFL_DATASOURCE_STOREDATA_ALWAYS for the source argument of the following functions:
- CFL_InitCharModel function
- CFL_MakeIcon function
- CFL_SetToNetPacket function
- CFL_GetAdditionalInfo function
If you specify CFL_DATASOURCE_STOREDATA, the appearance of the owner's Mii will differ depending on whether the Mii is stored in the front-end database or not. Specify CFL_DATASOURCE_STOREDATA_ALWAYS to avoid this and ensure that the owner's Mii always retains the same appearance it had when the owner first registered it to the amiibo.
14.1.8.1 Method of Displaying the Owner's Mii
Guideline Item |
When displaying the owner's Mii, applications must specify CFL_DATASOURCE_STOREDATA_ALWAYS for the source argument of the following functions:
|
---|---|
Software to Be Tested |
Applications that use Mii data from the amiibo owner's Mii.
|
Test Method |
|
Pass/Fail Determination |
Passes if the owner's Mii data displayed in step 4 has not changed from what was displayed in step 2. |
14.1.9 amiibo Nicknames
Because amiibo characters can move to other game systems, unrestricted by those systems' region or platform, any given game system or application may interact with an amiibo whose nickname was set under the amiibo settings of some other region. This means that the amiibo nickname could include characters that are not supported by all regions.
Therefore, if the amiibo nickname contains characters not supported by the application, replace the unsupported characters with question marks (?) or with character U+E06B (Figure 14-3 System Font Character U+E06B) from the system fonts. The range of characters available for input in the amiibo settings for each region may be extended in future, so make sure that the presence of unknown characters does not corrupt the display or impede progress in the application.
Use NfpUtil, a tool included in the CTR-SDK, when checking whether unsupported characters are handled appropriately.
Replacing unsupported characters with spaces, or with characters that look like spaces (such as underscores), can cause the words they appear in to resemble profanity depending on the strings before and after, or make it appear as though nothing has been entered for the nickname or creator name. Replace unsupported characters with the specified alternate characters instead.
If your application displays the owner's Mii nickname or Mii creator name, see section 8.1.3 Displaying Nicknames and Creator Names for further details.
14.1.9.1 Displaying amiibo Nicknames
Guideline Item |
If an amiibo nickname contains characters the application does not support, the application must replace the unsupported characters with question marks (?) or with character U+E06B from the system fonts when displaying the nickname, and the presence of unsupported characters must not cause any bugs. |
---|---|
Software to Be Tested |
Applications that use amiibo nicknames. |
Test Method |
|
Pass/Fail Determination |
Passes if in step 2, the amiibo nickname is replaced with question marks (?) or with character U+E06B from the system fonts. |
14.1.10 Repeatedly Starting and Stopping Tag Detection
Repeatedly detecting and losing tags many times within a short amount of time may cause the NFC chip to exceed its reliable operating range.
Therefore, it is prohibited to call the nn::nfp::StartDetection and nn::nfp::StopDetection functions once or more per second. These functions must be called less than once per second.
Nintendo is investigating setting a system-side restriction on high-frequency calls to the nn::nfp::StartDetection function.
14.1.10.1 Prohibition of Highly Frequent Tag Detection
Guideline Item |
Applications must start and stop tag detection (call the nn::nfp::StartDetection and nn::nfp::StopDetection functions) less than once per second. |
---|---|
Software to Be Tested |
All applications that support amiibo. |
Test Method |
Check the source code. |
Pass/Fail Determination |
Passes if the application calls the nn::nfp::StartDetection and nn::nfp::StopDetection functions less than once per second. |