7.4 Rich UGC

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
  1. Prepare two Nintendo 3DS systems, system A and system B.
  2. On system A, create rich UGC.
  3. In System Settings on system A, select Parental ControlsSet Restrictions Sharing Images / Audio / Video / Long Text Data and restrict such sharing.
  4. Attempt to send the UGC created in step 2 from system A to system B.
  5. In System Settings on system A, lift the Parental Controls restriction.
  6. In System Settings on system B, select Parental ControlsSet Restrictions Sharing Images / Audio / Video / Long Text Data and restrict such sharing.
  7. Attempt to send the UGC created in step 2 from system A to system B.
Pass/Fail Determination

Passes if all of the following conditions are met.

  • At an appropriate time during the sequence of steps 3 to 4, system A displays the following or an equivalent message informing the user “This feature is not available because Sharing Images / Audio / Video / Long Text Data is restricted by Parental Controls.”
  • At an appropriate time during the sequence of steps 6 to 7, system B displays the following or an equivalent message informing the user “This feature is not available because Sharing Images / Audio / Video / Long Text Data is restricted by Parental Controls.”
  • Passes if the application cannot send the rich UGC in steps 4 and 7.

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.

 

Note:

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:
  • Redistribution of rich UGC received from friends, where the creator of the UGC allowed redistribution.
  • Redistribution of rich UGC received via local communication where the communication partner can be identified beforehand or via a graphical code displayed on the Nintendo 3DS screen.
  • Writing UGC to the SD card (see section 7.1.4 Exchange of UGC)
  • Redistribution of rich UGC downloaded from a server (if the publisher has confirmed beforehand that there are no problems with the content).
Test Method
  1. Prepare three Nintendo 3DS systems (system A, system B, and system C).
  2. On system A, create rich UGC.
  3. Send the UGC created in step 2 from system A to system B.
  4. Attempt to send the UGC received in step 3 from system B to system C.
  5. If the application has a feature to edit received rich UGC:
    1. On system B, edit the UGC received in step 3.
    2. Attempt to send the UGC edited in step 5a from system B to system C.
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:

  • Support Internet communication
  • Exchange photos or video
Test Method
  1. Prepare a photo or video on a Nintendo 3DS system.
  2. Take the UGC prepared in step 1 and attempt to send it via the Internet.
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
  1. Prepare two Nintendo 3DS systems, system A and system B.
  2. Start the application on system A, and load audio, video, or animation not created on a Nintendo 3DS system.
  3. Attempt to send the audio, video, or animation loaded in step 2 from system A to system B.
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.

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.

 

Note:

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:

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:

  • Receiving rich UGC via local communication where the user can identify the communication partner beforehand, or via graphical codes displayed on the screen of another Nintendo 3DS system.
  • Loading UGC converted to graphical codes
  • Writing UGC to the SD card (see section 7.1.4 Exchange of UGC)
  • Making rich UGC publicly available on a server, as long as it is either (1) appropriately moderated or (2) promised to be swiftly taken down or otherwise handled in response to user reports.
  • Using the OLV library to send UGC
Test Method
  1. Prepare two Nintendo 3DS systems (system A and system B) that are not mutually registered as friends.
  2. On system A, create rich UGC.
  3. Send the UGC created in step 2 from system A to system B.
  4. On system B, perform the operation to ensure that rich UGC will no longer be exchanged with system A.
  5. On system A, create rich UGC.
  6. Attempt to send the UGC created in step 5 from system A to system B.
  7. On system B, check the UGC received in step 6.
Pass/Fail Determination

Passes if at least one of the following conditions is met.

  • Passes if in step 6, the application cannot send the rich UGC.
  • Passes if in step 7, the UGC received in step 6 is not displayed.

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
  1. Prepare two Nintendo 3DS systems (system A and system B) that are not mutually registered as friends.
  2. On system A, create a photo or video.
  3. Attempt to send the UGC created in step 2 from system A to system B via either StreetPass or local communication where the communication partner cannot be identified beforehand.
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.

 


CONFIDENTIAL