Applications that exchange rich UGC must comply with the guidelines in this chapter.
7.4.1 Rich UGC-Related Parental Controls
One of the Parental Controls restrictions on the Nintendo 3DS system is Sharing Images / Audio / Video / Long Text Data. This allows parents to restrict the exchange of rich UGC by young children. If this Parental Controls restriction is enabled on a Nintendo 3DS system, it is necessary to ensure that absolutely no rich UGC is exchanged by that system.
Thus, your application must not exchange any rich UGC if the system's Parental Controls restrict Sharing Images / Audio / Video / Long Text Data. Also, if restricted, then before scenes where rich UGC exchange is possible you must display the following or an equivalent message to explain why rich UGC cannot be exchanged: “This feature is not available because Sharing Images / Audio / Video / Long Text Data is restricted by Parental Controls.”
You can use the nn::cfg::CTR::IsRestrictPhotoExchange function in the CTR-SDK to determine whether Sharing Images / Audio / Video / Long Text Data is restricted.
7.4.1.1 Support for Using Parental Controls to Restrict Sending and Receiving Rich UGC
Guideline Item |
When the sending and receiving of rich UGC is restricted by Parental Controls, the application on the restricted system must display an appropriate message at an appropriate time and not exchange any rich UGC. |
---|---|
Software to Be Tested |
Applications that exchange rich UGC. |
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
7.4.2 Redistribution
Allowing users to redistribute UGC received from other users raises the possibility of problematic content being distributed. It is therefore prohibited to allow the redistribution of rich UGC created by other users. However, it is acceptable to redistribute UGC in the following cases.
-
It is acceptable to redistribute UGC received from friends, provided that the creator has explicitly allowed such redistribution.
Nintendo does not anticipate that exchanges between friends will lead to excessive content distribution. The fact that rich UGC was received from a friend does not necessarily mean it was created by a friend. The application must obtain permission from the creator of the rich UGC before redistribution of UGC, so that content is not redistributed without the creator's knowledge.
- It is acceptable to redistribute rich UGC received via local communication where the communication partner can be identified beforehand. In the same way, it is acceptable to redistribute rich UGC read and loaded from a graphical code displayed on the screen of another Nintendo 3DS.
- It is acceptable to redistribute rich UGC uploaded to a server by another user only if the publisher has confirmed beforehand that there are no problems with the content.
For the definition of redistribution, you must refer to Table 7-1 UGC Terminology.
7.4.2.1 Prohibition Against Redistributing Rich UGC
Guideline Item |
The application must not redistribute rich UGC. |
---|---|
Software to Be Tested |
Applications that exchange rich UGC. |
Exceptions |
Implementations corresponding to any of the following:
|
Test Method |
|
Pass/Fail Determination |
Passes if the application cannot send the rich UGC in steps 4 and 5b. |
7.4.3 Photos and Video
To prevent offensive or indecent data from being circulated, it is prohibited to have specifications that allow users to send photos or video via the Internet.
Specific features and services subject to this restriction include features allowing any users (whether friends or strangers) to send or receive photos or video from each other using NEX or SpotPass, and services that use independent servers to allow upload of photos or video, as well as similar services.
However, Nintendo may allow use of some such services as special exceptions, if they fulfill certain conditions. If you have plans for such services, contact Nintendo at support@noa.com.
See section 7.1.1 Types of UGC for the definitions of "photos" and "video."
It is also prohibited to send photos via Miiverse. For more information, see section 2.5.5 Use of Screenshots by Miiverse.
7.4.3.1 Prohibition of Sending Photos or Video via the Internet
Guideline Item |
Applications must not implement any specifications that allow users to send photos or video via the Internet.
|
---|---|
Software to Be Tested |
Applications that are able to do all of the following:
|
Test Method |
|
Pass/Fail Determination |
Passes if the photo or video cannot be sent in step 2. |
7.4.4 Audio, Video, and Animation
It is prohibited to exchange any audio, video, or animation not created on a Nintendo 3DS system.
Audio created on the Nintendo 3DS system includes the following kinds of data.
- Audio recorded using the Nintendo 3DS microphone
- Audio synthesized on the Nintendo 3DS system
- Music or other audio created on the Nintendo 3DS system
Video and animation created on the Nintendo 3DS system includes the following kinds of data.
- Video taken with the Nintendo 3DS system cameras
- Animation created by sequential display of images created on the Nintendo 3DS system
Your application must not exchange any audio, video, or animation with other users other than the kinds described above, even if the user has obtained other audio, video, or animation from the SD Card or by download.
7.4.4.1 Prohibition of Exchanging Audio, Video, or Animation Not Created on a Nintendo 3DS System
Guideline Item |
The application must not exchange audio, video, or animation that was not created on a Nintendo 3DS system. |
---|---|
Software to Be Tested |
Applications that can load audio, video, or animation not created on a Nintendo 3DS system, and that exchange audio, video, or animation. |
Test Method |
|
Pass/Fail Determination |
Passes if the application cannot send the audio, video, or animation in step 3. |
7.4.5 Preventing the Exchange of Rich UGC with Offensive Users
UGC created by malicious users might offend other users, even if the application itself is designed in a way to discourage such UGC. Therefore, if the application exchanges rich UGC with strangers, the application must implement measures appropriate to the design of the game, to prevent any further exchange of rich UGC with senders that the user has flagged as offensive. Possible ways of accomplishing this include:
- Allowing users to hide all UGC they have ever received.
- Blocking certain UGC creators and no longer receiving any UGC from them.
Nintendo 3DS provides the following features you may use to accomplish this:- Implementing the blocked-user list
The blocked-user list is a list built into Nintendo 3DS systems. If you receive UGC created by another user, you can block that user by registering the unique ID of their 3DS system to this list. If your application supports the blocked-user list, your application must also comply with chapter 7.5 Blocked-User-List. - Supporting an NEX matchmaking blacklist
If the user registers a peer to the matchmaking blacklist, then as a basic rule they are no longer matched with that blacklisted peer in matchmaking sessions unless they request to allow matchmaking with the blacklisted peer. This also allows the user to prevent the exchange of rich UGC.
- Implementing the blocked-user list
There are some exceptions. Your application is not required to comply with this guideline in any of the following situations.
-
Exchange of UGC during local communication where the communication partner can be identified beforehand, or reading and loading UGC from a graphical code displayed on the screen of another Nintendo 3DS.
Since the user must deliberately choose their partner and choose to exchange the UGC in these situations, there is no chance of communicating with a partner the user has previously found to be offensive. -
Loading UGC from a graphical code
The user must deliberately choose to load the UGC in this situation; it will never be loaded automatically. -
Making UGC publicly available on a server, as long as it is either (1) appropriately moderated or (2) swiftly taken down or otherwise handled in response to user reports.
This is because when UGC is publicly available on a server, it is possible to suppress exchange of offensive UGC by checking it either before or after it is posted, or by handling it appropriately in response to user reports. -
Using the OLV library to send UGC.
This is because the Miiverse application allows the user to block other users who have posted to Miiverse. However, if you use the OLV library to receive Miiverse posts or application data, you must implement appropriate handling in compliance with section 6.18.5 Exchanging UGC via Miiverse.
If you use the instant messaging feature of the nn::nex::MessagingClient class to exchange UGC, it is acceptable to use the matchmaking blacklist instead of the blocked-user list when exchanging UGC via this feature. However, the matchmaking blacklist only applies to matchmaking, so if the user receives messages from a sender whose principal ID is registered on the matchmaking blacklist, it is the application's responsibility to discard those messages. You must also create a user interface in the application that allows users to register message senders to the matchmaking blacklist.
Note that the principal ID (used to identify individuals on the matchmaking blacklist) is not interchangeable with the UGC author ID (used on the blocked-user list).
7.4.5.1 Measures to Prevent the Exchange of Rich UGC with Offensive Users
Guideline Item |
The application must support appropriate measures to prevent exchanging rich UGC with offensive users. |
---|---|
Software to Be Tested |
Applications that exchange rich UGC with strangers. |
Exceptions |
Implementations that correspond to any of the following:
|
Test Method |
|
Pass/Fail Determination |
Passes if at least one of the following conditions is met.
|
7.4.6 StreetPass/Local Communication Where Communication Partner Cannot Be Identified Beforehand
It is prohibited in principle to exchange the following types of rich UGC with strangers via StreetPass or local communication where the communication partner cannot be identified beforehand. Contact Nintendo at support@noa.com if you want your application to be able to exchange the following types of rich UGC with strangers via StreetPass or local communication where the communication partner cannot be identified beforehand.
- Photos
- Video
7.4.6.1 Prohibition of Exchanging Photos or Video with Strangers
Guideline Item |
The application must not exchange photos or video with strangers via StreetPass or local communication where the communication partner cannot be identified beforehand. |
---|---|
Software to Be Tested |
Applications that support StreetPass or local communication where the communication partner cannot be identified beforehand, and that exchange photos or video with strangers. |
Test Method |
|
Pass/Fail Determination |
Passes if the user is unable to send the photo or video in step 3. |
7.4.7 Voice Chat
If voice chat starts suddenly without any prior warning while the user is playing the application, they may unintentionally relay their voice to peers or suddenly hear peers' voices without any idea that this could happen. (Note that although these Guidelines use the term "voice chat," using this term as user-facing text in your game is prohibited by the Nintendo 3DS Family Terminology. See the terminology for details and alternative terms.) To avoid such situations, applications that support voice chat must disable the voice chat feature by default, and only allow use of voice chat after the user agrees.
"Disabling the feature by default" means designing the feature in such a way that it will not start unless the user deliberately turns it on. Consider how best to do this in a way that suits the user interface of voice chat in your application. For example, if you display a dialog to the user where they select ON or OFF before voice chat can start, consider making the "OFF" option selected by default, and consider making it impossible to select "ON" by button-mashing.
7.4.7.1 Default Setting of Voice Chat
Guideline Item |
Voice chat features must be disabled by default, and must not be enabled unless the user deliberately turns them on. |
---|---|
Software to Be Tested |
Applications that implement voice chat. |
Test Method |
Play a scene where voice chat is implemented. |
Pass/Fail Determination |
Passes if the voice chat features are disabled by default, and they never become enabled unless the user deliberately turns them on. |