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.
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.
Number | Command Type | If Software Resets Are Implemented: | If Software Resets Are Not Implemented: | Example Cases |
---|---|---|---|---|
1 | Simultaneous press of START+L+R |
|
|
Acceptable Example:
Unacceptable Example:
|
2 |
Supersets of combination 1 Example: |
|
|
Acceptable Example:
|
3 |
Other combinations Example: |
|
|
|
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 |
|
Pass/Fail Determination |
For applications that support software resets: Passes if all of the following conditions are met.
|
For applications that do not support software resets: Passes if all of the following conditions are met.
|
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 |
|
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 |
|
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:
|
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.