7 UGC

UGC stands for "user-generated content," and refers to text, images, characters, photos, video, audio, and any other content created by individual users when playing your application. Nintendo uses the term "UGC" in a somewhat narrower way. Under Nintendo's definition, UGC refers to user-generated content that meets all of the following criteria:

  • It is exchanged with other users via features of Nintendo products.
  • It has the potential to contain personal information, infringe the rights of others, or otherwise be misused.

This volume describes the rules and recommendations that applications that exchange UGC must follow.

If your application handles UGC, you must not only comply with the requirements written in these guidelines, but also avoid specifications that encourage UGC exchange that infringes upon the rights of any third party (such as copyright or privacy), and take due care to ensure no problems are caused by the distribution of inappropriate content.

For detailed definitions of UGC, see chapter 7.1 UGC Definitions. This table describes other related terminology.

Table 7-1 UGC Terminology
Term Description
Exchange of UGC

Exchange of UGC refers to sending UGC to another user and/or receiving UGC from another user using the features of Nintendo products. See section 7.1.4 Exchange of UGC for details.

Sending UGC

Sending UGC refers to use of local communication, StreetPass, Internet communication, infrared communication, servers from which other users can browse or download UGC, 2D codes and similar representations, or other such methods to send UGC from one Nintendo product to other devices on which UGC can be reviewed.

Friend

A user with whom the local user has exchanged user data (friend information). Users in a friend relationship are registered to the Friend List. Friends of friends are not included in the user's friends.

CTR-NEX includes a friend-matchmaking feature that can be used to enable communication between two friends. The friend matchmaking feature allows friends of the host to join, so there is no guarantee that all participants will be friends. However, it is fine to treat friend matchmaking as taking place between friends even in such a case. Even if the host leaves the matchmaking session, it is fine to treat all participants as friends until the session ends.

Stranger A user who is not a friend of the local user. Friends of a friend are strangers.

Friend-to-friend communication

Communication between a user and that user's friends. This also refers to situations in which StreetPass or data exchange only occurs between friends, or data uploaded to a server can only be viewed by friends.

It is fine to treat friend matchmaking on CTR-NEX as friend-to-friend communication, because other users participating in friend matchmaking on CTR-NEX are treated as friends.

Local communication See volume 5 StreetPass and Local Communication.

Local communication where communication partner can be identified beforehand

"Local communication where the communication partner can be identified beforehand" refers to communication where the local user can identify whom they are communicating with before starting communication. This could include the following.

  • Local communication that meets all of the following conditions:
    • Users of the client systems can select the host system to connect to.
    • The host system screen displays the usernames of all client system users.
      Note that if the host system performs a profanity check on usernames of its client systems, then profane client usernames are modified into non-profane versions before they are displayed to the host user. (For example, profane words in the username may be replaced by alternate characters.) This handling is fine, and this condition is still met as long as all client usernames that do not include profanity are displayed correctly to the host user.
    • Communication begins after the application confirms the communication with the user of the host system.
  • Local communication such as the following that requires the users of the host and client systems to coordinate their timing to connect.
    • Local communication where the host system only accepts client connections during a brief period of time.
    • Local communication that separates the scene where the host accepts communication partners from the networked play itself.
      In this design, a host accepts communication partners and starts the networked play after a necessary number of people for the game has been gathered. This does not apply to designs that allow the host to accept communication partners during communication play. This is because such specification would let a new player intrude into the game during communication play.
    • Local communication that allows the host to stop accepting new communication partners
      In this type of local communication, the host can limit communication partners by stopping accepting new partners after the users who the host intended to communicate with have joined.
  • Communication between the Download Play host system and all of its client systems.

Infrared communication between consoles does not fall under local communication as defined here, but it is handled as local communication where the communication partner can be identified beforehand.

Local communication where communication partner cannot be identified beforehand

The types of communication listed below do not fall under the category of "local communication where the communication partner can be identified beforehand." In other words, they are local communication where the communication partner cannot be identified beforehand.

  • The host system can receive client system connections at any time when in a certain game mode, and the client systems are automatically connected to the host system.
  • Local communication is initiated automatically once a certain number of client systems are present, without any confirmation sent to the user of the host system.

In this type of communication, the restrictions are strict compared to those on local communication where the communication partner can be identified beforehand, since there are concerns about strangers intruding during play and disrupting the game.

Redistribution

Redistribution refers to the act of a user that has received UGC from another user sending it on to a third user.

UGC author ID

A unique ID for each Nintendo 3DS system that identifies UGC creators. You can get this ID using the nn::ubl::GetUserId function. It is used when registering users to the blocked-user list, and determining whether a user is on the list.

UGC removal

In the context of UGC, removing UGC refers to automatically deleting or hiding UGC received from creators on the blocked-user list.
2D codes and similar representations of UGC ("graphical codes") The term graphical codes refers to QR Code patterns, bar codes, and all other 2D codes and similar representations. Sending or receiving UGC that has been converted to graphical codes is considered to be exchange of UGC. For details on what constitutes "exchange of UGC," see section 7.1.4 Exchange of UGC.
Note:

If your application exchanges UGC with peers who are playing on non-Nintendo 3DS platforms, the application those peers are playing is not required to comply with the 3DS Guidelines. For example, if a Wii U sends UGC to a Nintendo 3DS, the Wii U application must comply with the Wii U Guidelines and the Nintendo 3DS application must comply with the Nintendo 3DS Guidelines. The fact that they comply with different sets of Guidelines is not a problem.

Note that you must obtain approval from Nintendo in order to communicate with other companies' platforms. See section 6.1.6 Internet Communication With Non-Nintendo Platforms for further details.

Note:

If your application allows UGC to be included in Miiverse posts or direct messages, refer to section 6.18.5 Exchanging UGC via Miiverse and verify which guidelines your application must comply with.

 


CONFIDENTIAL