2.22 Other

2.22.1 Fatal Error Screen

Use the NN_ERR_THROW_FATAL macro of the CTR-SDK to have an application deliberately display a fatal error screen. This consists of the error message shown on a black background. Because control does not pass back to the application, the user can only turn off the power. Consequently, Nintendo recommends only displaying the fatal error screen when having the user turn off the power is the only effective option left.

No required guideline items.

2.22.2 Image Display That Depends on Subpixel Ordering

We recommend using a screen display that does not depend on the LCD subpixel order. This is because subpixel ordering may be changed in the future. For instance, if an application uses a technique that depends on subpixel ordering to artificially increase the resolution, any change in the subpixel order will lead to corrupted display.

To illustrate depending on the subpixel order, displaying a one-pixel white point on a black background by using a group of subpixels that span different pixels as a single pixel, as shown on the right of Figure 22-1, is a display method dependent on the subpixel order.

Figure 2-20 Display Methods That Depend and Do Not Depend on the LCD Subpixel Order

No required guideline items.

2.22.3 Software Reset

A software reset refers to the act of an application jumping to its title screen (or other screens early in the startup sequence). Jumps to the very first sequence of the application and jumps to states that skip the logo screen are both considered to be software resets. The following types of jumps, on the other hand, are not considered to be software resets:

  • Jumping to a screen that lets the user manage the application’s save data or other info
  • Reloading from the last saved state
  • Jumping to a mini-game selection screen in titles that consist of a collection of mini-games
    • The last jump would be considered a software reset if skipping the logo display screens would go directly to the mini-game selection screen.

Each application implementing its own software reset command could confuse users. Consequently, if you implement a software reset feature, software reset is the only operation you are allowed to assign to button combinations which include a simultaneous press of START+L Button+R Button. This is to avoid accidental resets caused by other button combinations overlapping with the reset combination. For instance, implementing both a software reset using the START+L+R button combination and an in-game feature using a simultaneous combination of START+L+R+A+B buttons could lead to the user accidentally resetting the software if they miss pressing the A and B buttons.

If your application implements software resets, then you may choose to perform software resets when only the START+L+R buttons are simultaneously pressed; or alternatively, your application can perform software resets when those buttons are simultaneously pressed in combination with any other buttons. Either is acceptable.

If your application does not implement a software reset feature, it is nevertheless prohibited to assign the START+L+R button combination to any other feature. Doing so could train users out of associating this button combination with software resets. However, if you assign L+R, or L+R+(Some button other than START) to some other operation in your application, it is not a guideline violation if that other operation is triggered as designed when the user presses the START button in addition to the assigned button combination. This is acceptable because START is not part of the actual button combination assigned to that operation.

Although this restriction is complicated, it has the following two main goals:

  • Raising user awareness that in applications that implement software resets, the command for a software reset will always be simultaneously pressing START+L+R.
  • Avoiding specifications which cause the user to simultaneously press the START+L+R buttons for purposes other than performing a software reset.

If the user initiates a software reset while data is being written to backup memory or an SD Card, do not interrupt the process of writing data to perform a reset. You may either cancel the reset request itself or reset after you have finished writing data. There are two exceptions: while formatting save data, and during the initial data creation that takes place immediately after formatting save data.

The table below describes each possible type of command and the associated cautions.

Table 2-10 Software Reset Command Combinations
Number Command Type If Software Resets Are Implemented: If Software Resets Are Not Implemented: Example Cases
1 Simultaneous press of START+L+R
  • Must trigger software reset in scenes allowing software reset.
  • Acceptable to not trigger software reset in scenes not allowing it.
  • If software resets are not possible in a specific scene, comply with the If Software Resets Are Not Implemented column.
  • Implementation of operations unique to this button combination is prohibited.
  • Acceptable to assign other operations to other combinations containing a subset of these three buttons (for example, simultaneous press of L+R, or pressing the START button alone).

Acceptable Example:

  • An application which does not implement software resets includes a command to take a screenshot when the L+R buttons are pressed simultaneously. The application will also take a screenshot if the START+L+R buttons are pressed simultaneously.

Unacceptable Example:

  • An application which does not implement software resets assigns a command to save the game state to the simultaneous press of the START+L+R buttons.
2

Supersets of combination 1

Example:
Simultaneous press of START+L+R+A, or similar combinations

  • In scenes where software resets are possible, actually performing a software reset is optional.
  • If software resets are not possible in a specific scene, comply with the If Software Resets Are Not Implemented column.
  • Implementation of operations unique to this button combination is prohibited.
  • Acceptable to trigger other operations that are assigned to other combinations containing a subset of these buttons.

Acceptable Example:

  • An application implements software resets, and opens a menu when the X button is pressed. The menu also opens when the START+L+R+X buttons are pressed simultaneously.
  • An application implements software resets, and opens a menu when the X button is pressed. A software reset is performed when the START+L+R+X buttons are pressed simultaneously.
  • An application implements software resets, and does not assign anything to the X button. Nothing happens when the START+L+R+X buttons are pressed simultaneously.
  • An application implements software resets, and does not assign anything to the X button. A software reset is performed when the START+L+R+X buttons are pressed simultaneously.
3

Other combinations

Example:
Simultaneous press of A+B, or similar combinations

  • Prohibited from triggering software reset.
  • No restrictions.
  • No restrictions.

2.22.3.1 Compliance with Software Reset Button Definition

Guideline Item

Applications must not define any button combination which includes a simultaneous press of the START+L+R buttons as any command other than a software reset command.

Software to Be Tested

All applications.

Exceptions

When the application type is Virtual Console.

Test Method
  1. Press START (or SELECT), the L Button, and the R Button simultaneously.
  2. Press START (or SELECT), the L Button, and the R Button together with some other button(s) all simultaneously.
  3. Press some other button combination different from those in steps 1 and 2.
Pass/Fail Determination

For applications that support software resets:

Passes if all of the following conditions are met.

  • In steps 1 and 2, either a software reset (and only a software reset) occurs, or an operation occurs that is not unique to the button combination that was pressed.
  • In step 3, no software reset is performed.

For applications that do not support software resets:

Passes if all of the following conditions are met.

  • In steps 1 and 2, an operation occurs that is not unique to the button combination that was pressed.
  • In step 3, no software reset is performed.

2.22.3.2 Prohibition of Software Reset Interrupts During Backup Operations

Guideline Item

Applications must not stop in-progress write operations for software reset processing, but must wait until write operations finish.

Software to Be Tested

Applications that support software resets and create save data or extra data.

Exceptions
While formatting save data, or while creating initial save data immediately after formatting save data.
Test Method

Execute the software reset command while writing to backup memory or an SD Card.

Pass/Fail Determination

Passes if the backup process is not stopped while in progress by a software reset.

2.22.4 Using Images of the Nintendo 3DS System Within an Application

Nintendo has established guidelines on displaying images of Nintendo 3DS systems within an application in order to form a standardized brand image of the Nintendo 3DS among users. Specifically, Nintendo recommends following the instructions provided in the Nintendo 3DS Illustration Usage Guide when you use images of the Nintendo 3DS or Nintendo 3DS XL system.

 

 

No required guideline items.

2.22.5 ImageDb Library

Images saved using the ImageDb library can be viewed with the Nintendo 3DS Camera built-in application. When the application uses the ImageDb library to save images, we recommend displaying a message such as “The saved image can be viewed in Nintendo 3DS Camera” to notify the user of this capability.

When you use the ImageDb library, make sure to comply with the restrictions in the ImageDb Programming Manual, which is included in the ImageDb package. Specifically, comply with the following restrictions.

  • Use the imgdb::JpegMpBaseSaver::SetTitleUniqueId function to configure the application’s unique ID, making sure that this unique ID is configured as the EXIF “Software” tag in the saved image.
  • Handle errors properly. (See section 3.5.4 Handling ImageDb Errors.)

2.22.5.1 Unique ID Settings

Guideline Item

Applications must set the unique ID assigned by Nintendo as the EXIF “Software” tag in saved images.

Software to Be Tested

Applications that use the ImageDb library to save images.

Test Method
  1. Take a still photo or save an image.
  2. Insert the SD Card that stores this still image into a PC and use some kind of imaging software to check the header information for the saved image.
Pass/Fail Determination

Applications that have versions in multiple regions or are part of a series:

Passes if in step 2 any one of the unique IDs in the relevant application is set as the EXIF “Software” tag.

Applications that do not have versions in multiple regions and are not part of a series:

Passes if in step 2 this application’s unique ID is set as the EXIF “Software” tag.

2.22.6 Wireless Communication Daemon Control

The Nintendo 3DS system engages in background wireless communication and the system’s CPU core processing load increases accordingly when the wireless communication daemons are running under the management of the ndm library. You can use ndm library functions to stop these daemon processes if this increased load prevents your application from operating normally.

You can start and stop ndm library daemons by using ndm library functions, and also by using the following functions from the uds and dlp libraries.

  • Functions that stop daemons managed by the ndm library:
    • nn::uds::CTR::Initialize function
    • nn::dlp::CTR::Server::Initialize function
    • nn::dlp::CTR::FakeClient::Initialize function
  • Functions that resume daemons managed by the ndm library:
    • nn::uds::CTR::Finalize function
    • nn::dlp::CTR::Server::Finalize function
    • nn::dlp::CTR::FakeClient::Finalize function

It is prohibited to excessively stop and restart the ndm library daemons using either ndm library functions or the above functions.
The following are examples of excessive implementation:

  • Stopping and restarting the daemons once per every Wi-Fi multiplayer match.
  • Repeatedly and automatically stopping and starting the daemons inside the same gameplay scene.
  • Stopping and starting the daemons in locations that most players pass through every time the application is started, such as during the transition between the title screen and main gameplay sequence.

Unnecessarily stopping and restarting the daemons causes unneeded logouts from and logins to the friend presence server, increasing the server load and causing the user’s online status on the friend list to repeatedly flip from online to offline and back again.

2.22.6.1 Prohibition of Excessively Stopping and Restarting the Wireless Communication Daemons

Guideline Item

Applications must not use the ndm, uds, or dlp libraries to excessively stop and restart the wireless communication daemons.

Software to Be Tested

All applications.

Test Method
  1. Prepare two Nintendo 3DS systems (system A and system B) that are mutually registered as friends.
  2. Start the friend list on system A.
  3. Launch the application on system B and play through all modes of the application from beginning to end.
  4. On system A, check the status of the friend card to which system B is registered during the performance of step 3.
Pass/Fail Determination

Passes if, in step 4, the status does not repeatedly and excessively flip from online to offline and back again.

2.22.7 Displaying URLs and Advertisements in Applications

It is prohibited to display any URL or advertisement or anything resembling either of these within an application without Nintendo’s prior approval. However, you do not need to contact Nintendo if your application uses BOSS to distribute notifications or data containing URLs or advertisements, since the user must opt in to receiving such content in advance, and an opt-out feature is provided. Likewise, it is not necessary to contact Nintendo when displaying the following URLs.

  • URLs for the publisher's official site
  • URLs for support sites
  • URLs appearing in the user terms of service agreement within the game
  • URLs contained in official legal notices

2.22.7.1 Prohibition Against Displaying URLs and Advertisements

Guideline Item
Applications must not display any URL or advertisement, or anything resembling either of these, without Nintendo’s prior approval.
Software to Be Tested
All applications.
Exceptions

If the following cases apply:

  • Notifications or data distributed by BOSS containing URLs, advertisements, or anything resembling them.
  • URLs for the publisher's official site
  • URLs for support sites
  • URLs appearing in the user terms of service agreement within the game
  • URLs contained in official legal notices
Test Method
Play through all modes of the application from beginning to end.
Pass/Fail Determination
Passes if the application does not display any URL or advertisement, or anything resembling either of these, without Nintendo’s approval.

2.22.8 Applications that Can be Carried to and Played in Other Market Regions

It is possible to design application features with the assumption that the user may take their Nintendo 3DS system with them and play the application in other regions. Such features could include the examples below.

  • When the system uses StreetPass with systems from other regions, the user gets access to items and characters specific to those regions.
  • The user takes their Nintendo 3DS system and applications with them when traveling, to do such things as browse sightseeing information.

These kinds of plans are not prohibited. However, for the reasons listed below, you must take special care when you inform users, either on-screen or in printed materials, of the benefits of carrying their system to other regions.

  • Wireless communication is not certified for use in all countries.
  • There is no guarantee that the system can be taken to every country.

You need to avoid text that implies that wireless communication is possible in all countries and you need to avoid expressions that imply with absolute certainty that the system can be carried overseas.

The determination of whether expressions are misunderstood by users can greatly depend on the specifications of applications. For this reason, contact Nintendo at support@noa.com if the plan for your application calls for it being played in other regions on systems carried to those other regions.

The need for prior consultation is limited to cases where there is some benefit to the user of playing the application on a system carried to another region and you want to inform the user of that benefit. There is no special need to contact Nintendo if all you plan for the application in other regions is simply StreetPass and local communication functionality.

No required guideline items.

2.22.9 Titles Available for Dual Distribution As Packaged and Downloadable Versions

If you are planning for dual-distribution of your application in a packaged version (card-based application) and a downloadable version (downloadable application), or if you have already released your application as one format and would like to make it available in the other, follow the instructions outlined in the "Developing Card Applications That Can Be Sold via Download" section of the Nintendo 3DS Programming Manual: How to Create Applications (released separately).
These Guidelines only mention items directly related to the content of the application.

A Nintendo 3DS title available as both a card-based and downloadable application is treated as a single product available by two different distribution routes.
Therefore, if your title is already available in one format and being prepared for distribution in the other, then when you make modifications to ensure that the new format will operate properly you must ensure that there is no difference in behavior between the downloadable and card-based versions. If there are intentional changes between the two versions, you must submit a revision history indicating the differences between this version and the one that previously passed Lotcheck.

This rule is not intended to apply to behavioral differences due to variances in launch media (access speeds, etc). This is a prohibition of design differences such as the addition of new features specific to one format, or to specific perks included in one version but not the other. However, since Nintendo does not offer a method for the application to determine its own launch media, there is no guideline check for this prohibition.

No required guideline items.

 


CONFIDENTIAL