7.1 UGC Definitions

This chapter defines exactly what kinds of content are considered to be UGC within the Nintendo 3DS Guidelines.

7.1.1 Types of UGC

There are four types of UGC, listed in items 1 to 4 below. Different rules apply to each type of UGC.

  1. Simple UGC
    The degree of expression available in this type of UGC is restricted, in order to prevent the exchange of personal and other sensitive information. There are three categories of simple UGC, as shown below. See chapter 7.3 Simple UGC for details about each category. If your application exchanges UGC but cannot comply with all guidelines in chapter 7.3 Simple UGC, then you must handle the UGC as rich UGC rather than simple UGC.

    • Freely composed message with restrictions
    • "Decorated images" of application screens
    • Images with restricted sizes
  2. System User Name
    This is the user name configured in the Nintendo 3DS System Settings. Stored in the nn::cfg::UserName structure.
  3. Mii nicknames
    If your application exchanges Mii data by exchanging the CFLStoreData structure, it is not necessary to treat the Mii data as UGC. However, if your application exchanges Mii nicknames as text data, you must comply with section 7.2.5 Profanity Checking. This is because Mii nicknames obtained by receiving Mii data in the CFLStoreData structure are automatically checked for profanity by the CFL library, but Mii nicknames received as text data do not undergo any automatic profanity check. (No other guidelines in the UGC volume apply to Mii nicknames exchanged as text data.) See section 8.1.5 Exchange of Mii Data via Communication Features for further information about the exchange of Mii nicknames as text data.
  4. Rich UGC
    Rich UGC refers to UGC that is not covered by categories 1, 2, or 3, and allows for a higher degree of expression. There are more rules governing the exchange of rich UGC than the exchange of other forms of UGC. Rich UGC is broken into the following six categories. If your application uses rich UGC, you must comply with chapter 7.4 Rich UGC.
    • Text
      Character names, chat text, freely composed text, or other user-input strings.
    • Photos
      Still images captured from the camera, and the results of processing such captured image data. Any and all image data from external sources, that is loaded into the Nintendo 3DS system via the SD card or a network, must be handled as photos unless it is guaranteed not to contain image data captured from a camera.
    • Images, 3D models, and stages
      Pictures drawn by the user in an application, hand-written messages, 3D models, user-generated stages, or screenshots containing rich UGC. See also section 7.1.3 Images Created by Combining Items. This volume collectively refers to all these kinds of UGC as "images."
    • Video
      Any video that includes "photos" or any data captured from a camera. Any and all video data from external sources, that is loaded into the Nintendo 3DS system via the SD card or a network, must be handled as camera video unless it is guaranteed not to contain image data captured from a camera.
    • Animation
      Any sequence of images containing rich UGC that does not fall under the definition of "video."
    • Audio
      (1) Audio data recorded using any microphone (not limited to the Nintendo 3DS system microphone) or the results of processing such audio data, (2) voice chat audio data, (3) audio data created using speech synthesis, and (4) any music or other audio data created in an application. Note that "audio" is a general term referring to all audio data, not just recorded human voices.

No required guideline items.

7.1.2 Content That Is Not UGC

The following kinds of data are not considered to be UGC. You do not need to comply with the UGC Guidelines for these kinds of data.

  • Text entered using keywords
    Strings created by the user by combining keywords preset by the application. Such strings are not considered to be UGC. However, take adequate precautions to prevent any inappropriate keywords, or inappropriate combinations of otherwise acceptable keywords.
  • Text entered using preset characters
    Strings created by the user by combining characters preset by the application, rather than freely entered by the user. Such strings are not considered to be UGC. You do not need to handle strings created this way, such as in a word-formation game, as UGC. However, do take adequate precautions to prevent users from easily creating inappropriate strings. Also take adequate precautions to check strings as they are being created to prevent users from using such strings for chatting or other purposes. Allowing the creation of long strings equates to freely composed text, which is considered to be UGC.
  • Application screenshots
    Screenshots of an application are not considered to be UGC, unless the screenshot itself contains UGC in the image. However, you must comply with the UGC Guidelines for screenshots that contain UGC as shown in Figure 7-1 Example of a Screenshot Containing UGC; for example, screenshots of user-created maps, screenshots of characters with comment bubbles containing user-created text, or any user-altered screenshots.
Figure 7-1 Example of a Screenshot Containing UGC

  • Ghost data or replay data
    Ghost data for a racing game or replay data for an action game that was created using only key input data is not considered to be UGC. However, you must comply with the UGC Guidelines if the application design allows UGC to be included in such ghost or replay data.
  • Characters created by only configuring parameters
    Characters created by adjusting parameters that do not affect display, such as strength or speed, are not considered to be UGC.
Figure 7-2 Example of Non-UGC: Ranking Using Only a Score and Initials

Although the content below is created by the user with relative freedom, it is not necessary for applications to comply with the UGC guidelines when handling this content.

  • Account IDs
    A 6- to 16-character alphanumeric string configured for an account. The user can set this string to whatever they want, but since the string is profanity-checked it is not possible to use a string that contains profanity. The user is also given an onscreen display of caution text about the handling of account IDs when the user creates their account ID.
  • Mii characters
    You do not need to handle Mii characters as UGC if your application uses the CFL library to exchange the Mii models and additional information. However, if your application strips out Mii nicknames or creator names and exchanges this information as text data, you must handle them as "Mii nicknames," as described in section 7.1.1 Types of UGC .
  • amiibo nicknames
    The user can set this string to whatever they want, but since the string is profanity-checked it is not possible to use a string that contains profanity.

 

No required guideline items.

7.1.3 Images Created by Combining Items

These images can include emblems, characters, avatars, or decorated application screenshots, as long as they were created by combining limited items. Figure 7-3 Example of Image (Character) Created by Combining Items shows an example. As a general rule this type of image is handled as rich UGC.

Figure 7-3 Example of Image (Character) Created by Combining Items

However, it is in some cases permitted to handle images created by combining items as simple UGC if it seems unlikely that any expressions unpleasant to others or personal information would be contained in said image. Contact support@noa.com if you would like to handle images created by combining items as simple UGC. Even if you handle them as simple UGC, however, you will generally be required to comply with the sections below.

 

If the image is created by combining items in a very highly restricted way, it is not necessary to treat this content as UGC. Specifically, the image does not need to be treated as UGC if it meets all of the following conditions.

  • The user cannot freely change the locations of items
  • It is not possible to enlarge, shrink, or rotate items

For example, it is not necessary to treat the content as UGC in cases like Figure 7-4 Example of Image (Character) Created by Combining Items That Does Not Need to Be Treated as UGC, where the character’s appearance can be changed by changing its equipment, or in cases where it is only possible to select the character’s expression, hairstyle, hair color, and other characteristics from a list of predetermined choices.

Figure 7-4 Example of Image (Character) Created by Combining Items That Does Not Need to Be Treated as UGC

No required guideline items.

7.1.4 Exchange of UGC

In these Guidelines, exchange of UGC refers to sending UGC to other users and/or receiving UGC from other users using the features of Nintendo products. Note that "other users" refers not only to other users of Nintendo 3DS systems, but all users of other Nintendo products, computers, or other devices which allow them to browse or send UGC.

Examples of UGC Exchange that is Subject to the Guidelines
  • Using local communication, StreetPass, Internet communication, or infrared communication to send UGC to or receive it from another user
  • Uploading or downloading UGC to/from a server where other users can view or acquire it
Examples of UGC Exchange that is Not Subject to the Guidelines
  • Writing UGC to the SD card
    Distributing this UGC to other users requires additional steps (transferring to PC, etc) that cannot be done on Nintendo products, so this is not considered to be "exchange of UGC" that is subject to these Guidelines.
    However, if you write a graphical code such as a bar code or QR Code pattern to the SD card, Nintendo recommends showing the creator name and the UGC itself alongside the graphical code, even though this UGC is not subject to these Guidelines. Doing so makes it easier for the user to determine whether the UGC is problematic before they load it.
  • Displaying graphical codes onscreen, allowing other physically-present users to read and load these codes through the cameras of another Nintendo 3DS
    If your application displays graphical codes onscreen in a way that allows other physically-present Nintendo 3DS users to use the cameras on their Nintendo 3DS to read and load these codes, this feature is not considered subject to these Guidelines. This is because the two users are next to each other, so the one loading the graphical code can directly ask what it contains.
Figure 7-5 Examples of UGC Exchange

No required guideline items.

 


CONFIDENTIAL