A data store uses the data storage features to manage and save large volumes of data over the network. This allows you to upload and download files of up to 10 MB. This also allows users to rate data uploaded by other users. See the CTR-NEX Library Function Reference for details.
6.12.1 Limits on Data Handled by Data Stores
Data handled by data stores must comply with the following limits.
- No more than 100 data files must exist at a time per each single PrincipalID (including data files consisting solely of metadata).
- Data files handled by storage server features must be no more than 10 MB in size per file.
- The total size of all data files handled by storage server features must be no more than 10 MB (not including metabinaries) per each single PrincipalID.
- The number of upload/download requests for data (not including metabinaries) handled by storage server features must be no more than 1000 requests per month per each single PrincipalID.
- For data handled by storage server features, the sum total of amount of data uploaded plus amount of data downloaded (not including metabinaries) must be no more than 100 MB per month per each single PrincipalID.
- No more than 100 KB of metabinary capacity existing at a time per each single PrincipalID.
Design your usage of the features with the above limits in mind, and describe your usage in the application forms on OMAS. Contact Nintendo at support@noa.com if you are planning a design that exceeds any of these restrictions.
No required guideline items.
6.12.2 Extent of Data Disclosure
When uploading data, you can configure access permission to allow access by just the owner (the PrincipalID which created the data), by users specified by the owner, by friends, or by everyone (completely open access).
If data uploaded to a data store is disclosed to other users, you must explain the extent of disclosure of said data, either in the manual or by displaying an explanation in the application before the data is disclosed. When data disclosure is not limited to just the owner, Nintendo also recommends displaying a message in the application (such as “Friends will also be able to view the uploaded data” or “Anyone will be able to view the uploaded data”) and obtaining user consent.
6.12.2.1 Informing Users of Extent of Data Disclosure
Guideline Item |
An explanation of the extent of data disclosure must be given to the user, either in the manual or in the application before the data is disclosed. |
---|---|
Software to Be Tested |
Applications that disclose data to other users via a data store. |
Test Method |
|
Pass/Fail Determination |
Passes if at least one of the following conditions is met.
|
6.12.3 Data Collection via Data Stores
If the publisher collects only the minimum data necessary to provide a service, and uses it for no other purpose than to provide a service, it is not necessary to obtain user consent.
But if the publisher collects play histories or other data by uploading it to a data store, and uses it for other purposes such as statistics or analysis, the application must inform users of the content of the uploaded data and obtain their consent to sending the data.
Applications must not set up data stores for the purpose of exchanging highly confidential information, such as personal information. Therefore, it is prohibited to collect personal information (including NNIDs) using features that upload to a data store.
Additionally, if the application obtains consent and collects data either periodically or each time it connects to the network, you must implement a feature that allows the user to stop the sending of data. If the user has stopped the sending of data, then the application must get user consent again in order to start collecting data again.
These steps must be performed separately for each save data.
For background information on why applications are required to obtain consent and provide a way to opt out of sending data, see sections 6.14.4 User Consent Prior to Beginning Downloads and 6.14.5 Application Feature to Opt Out from Receiving Data in the BOSS chapter.
6.12.3.1 Prohibition of Collecting Personal Information on Data Stores
Guideline Item |
Applications must not use data store upload features to collect personal information (including NNIDs).
|
---|---|
Software to Be Tested |
Applications that use data stores to collect data.
|
Test Method |
Check the source code.
|
Pass/Fail Determination |
Passes if no personal information or NNID is included in the collected data.
|
6.12.3.2 User Consent to Start Data Collection on Data Stores
Guideline Item |
Applications that collect data using data stores must inform users of the types of data to be collected and obtain user consent before sending the data. Consent must be obtained separately for each set of save data. |
---|---|
Software to Be Tested |
Applications that collect data using data stores and use it for some purpose other than purely providing a service (for example, for statistics or analysis).
|
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
6.12.3.3 Supporting a Feature to Stop Data Collection on Data Stores
Guideline Item |
Applications that collect data either periodically or each time they connect to the network must implement a feature that allows the user to stop the sending of data. |
---|---|
Software to Be Tested |
Applications that collect data using data stores, either periodically or each time they connect to the network, and use it for some purpose other than purely providing a service (for example, for statistics or analysis). |
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
6.12.3.4 Resuming Data Collection on Data Stores
Guideline Item |
When resuming data collection after the sending of data was stopped, applications must again obtain user consent in accordance with section 6.12.3.2 User Consent to Start Data Collection on Data Stores. Consent must be obtained separately for each set of save data.
|
---|---|
Software to Be Tested |
Applications that collect data using data stores, either periodically or each time they connect to the network, and use it for some purpose other than purely providing a service (for example, for statistics or analysis). |
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
6.12.4 Support for Handling Multiple Save Data Files
Data is managed based on the owner’s PrincipalID, which creates the possibility that your application may not be able to distinguish between multiple save data files. Data uploaded from a save data file might be overwritten when the user uploads data later from a different save data file, so make sure to implement a means in your application to be able to identify the data itself. For example, you could add a SlotID attribute to the metadata for uploaded data and use this metadata to manage the data, thereby allowing for quick identification.
You must get user confirmation before deleting or overwriting data previously uploaded from a different save data file. Cases where deleting upload data does not adversely affect the game progress are exception to this rule. For instance, if only a limited number of data files can be saved and saving a new save data file requires that other data be deleted, display a message such as “You can only save up to XX data files. Delete data that came from another save data file, and create new data?" and get user confirmation before proceeding.
6.12.4.1 User Confirmation When Handling Multiple Save Data Files
Guideline Item |
The application must get user confirmation before deleting or overwriting data previously uploaded from another save data file. |
---|---|
Software to Be Tested |
Applications that allow deleting or overwriting data uploaded from other save data files. |
Exceptions |
When deleting upload data does not adversely affect the game progress.
|
Test Method |
|
Pass/Fail Determination |
Passes if the application displays the following or an equivalent message and gains user confirmation before deleting or overwriting data: “You can only save up to XX data files. Delete data that came from another save data file, and create new data?” |
6.12.5 Support for Using Different Cards
Starting up the same system with a different card inserted still allows the local user to access the same data store region, since the PrincipalID does not change. Consequently, your application must implement some means of preventing the user from accidentally deleting or overwriting data. One possible method is to add a NEX unique ID to the metadata of data files uploaded by your application. This will allow you to distinguish between data, based on the card the data is associated with.
No required guideline items.
6.12.6 Automatically Deleting Data
A valid period (expiration date) is set for all data uploaded to a data store except data that uses a permanent slot. The server checks periodically, and automatically deletes any data that has expired. Therefore, if the application attempts to access data that has been automatically deleted, Nintendo recommends taking care to ensure that failure to access that data does not result in any problems in the application.
No required guideline items.
6.12.7 Configuring Ratings
The rating feature allows users who have accessed uploaded data to rate the data. The library does make it possible to give negative ratings or for the same user to give multiple ratings to the same data file, but Nintendo recommends setting maximum and minimum allowed rating values in your application to prevent any extreme ratings from raising potential problems between users.
Example ratings:
- Rate as “Good”
Rates a data file as +1. - Rate in three levels, as “Good,” “Fair,” or “Not Good”
“Good” rates a data file as +1, “Fair” rates a file as ±0, and “Not Good” rates a file as -1. - Rate using stars (up to 10)
A rating of ☆☆☆☆☆☆★★★★ would equate to a rating of +6.
The design of your rating system will depend on your application. Take care in your implementation to prevent a user from repeatedly giving negative ratings to the same data file or from otherwise using ratings to harass other users.
No required guideline items.
6.12.8 Submitting Multiple Ratings
You can configure the ratings settings for data when the data is first uploaded to a data store. When doing so, you must set RATING_FLAG_MODIFIABLE in the option flags. If you do not set this value, it is possible to submit multiple ratings by calling the nn::nex::DataStoreClient::RateObject function. The term "multiple ratings" means the ability of the same user to post multiple ratings for the same data. In such cases the previous rating will not be overwritten, so it will be as though multiple users had rated the data.
Allowing multiple ratings can degrade the fairness of the ratings for a game by allowing multiple biased ratings to be posted by the same user. Consequently, if you allow multiple ratings, Nintendo recommends not allowing a user to rate the same data item more than once in a short period of time. CTR-NEX provides the following features to restrict rating the same content more than once in a short time.
- Limiting by interval:
Configure an interval such that after rating a data file, the user must wait for that period of time before being able to rate the same data file again. - Limiting by specified date:
Configure a date until which the user cannot rate the same data file again. For example, you could configure your application to prevent rating the same data file again until the next Monday, or the first of each month.
No required guideline items.