Ever since Nintendo started developing the CTR system, one of its goals has been to enable all card applications to also be sold from Nintendo eShop, without modification. Nintendo designed the CTR-SDK to minimize the amount of separate code that must be written for card-based software and downloadable applications, and whenever possible, the requirements in the Guidelines are the same for both versions of the application.
This chapter describes the steps required to sell the same application both as a card-based software application and a downloadable application (this is called "dual distribution"). It describes the procedures for two different scenarios: when you are developing a new application for dual distribution, and when you have already developed a card application, and want to offer if for sale via download. It also describes the steps to take when you need to revise your application.
If you submit a master submission as a downloadable application (CIA file), you will not be able to request sales as a card-based application later. If you are considering dual distribution, submit the master submission as a card-based application (CCI file).
8.1. Developing a New Application for Dual Distribution
The procedures for developing a new card application for dual distribution as a downloadable version are essentially the same as for developing an ordinary card-based software application. This section describes aspects of the development process that require special attention.
8.1.1. The Planning Stage
Card-based software applications and downloadable applications for the same title are treated as the same product, with different sales channels. Make sure that the card and downloadable applications work the same.
Contact Nintendo support at support@noa.com if you want your card applications and downloadable applications to work differently.
If Nintendo approves differences, note the specific differences in Checksheet Editor in the Program Specifications checksheet, under "Nintendo-Approved Specifications."
8.1.2. Getting the Product Code and Unique ID
A dual-distribution application uses the same product code and unique ID for both the card and downloadable versions. Do not get separate product codes or unique IDs for the package version and downloadable version.
Examples: For example, if you have obtained the product code CTR-P-AAAJ(JPN)
for your card application, you would use CTR-P-AAAJ
for the downloadable application’s product code. You would not use CTR-N-AAAJ
, which would indicate that the product is a downloadable application.
You actually manage your product using the product code for the downloadable version—in this example, CTR-N-AAAJ
. When you produce the software or submit the master ROM, however, it is fine to consider these to be the same product code and unique ID.
8.1.3. E-Manual
You must include the same e-manual with your card and downloadable applications.
To create your e-manual, use the latest version of the CTR Electronic Manual Creation Guide, Part 2 – Template Units.
8.1.4. Save Data and Extra Data
If a system has both the package and downloadable versions of an application, each application will access separate save data (the package version will access the backup memory on the Game Card, and the downloadable version will access the SD card), but both will access the same extra data (extended save data). Consider the following when deciding how your application will deal with this situation.
This situation will also occur if a user plays multiple Game Cards for the same title on a single system. Regardless of whether you support download sales, a card application should be able to handle this situation without any fatal bugs occurring. And if your application can support multiple Game Cards, it should be able to support download sales through some additional handling.
Your application need not offer special handling for such cases (such as enabling users to migrate their save data if they own the package version and later purchase the downloadable version), but if you implement a feature to support multiple Game Cards (such as data migration), confirm whether this feature can be repurposed to handle the situation of a package version and downloadable version co-existing.
8.1.5. Save-Data Rollbacks
Although users cannot roll back the save data of a card application to an earlier state, it is easy to do so for a downloadable application using a personal computer. (Users can back up the contents of the entire SD card to their PC at the desired save point, and then roll back the save data by copying the PC backup to the SD card.)
Applications can detect save-data rollbacks using the following functions from CTR-SDK 4.2.2 and later: SetSaveDataSecureValue()
and VerifySaveDataSecureValue()
(or VerifySaveDataSecureValueLoosely()
). When called from a card application, the SetSaveDataSecureValue()
function will have no effect, and the VerifySaveDataSecureValue()
and VerifySaveDataSecureValueLoosely()
functions will always return true
. You can also safely use these functions in a card application that supports download sales, because they have no effect if your application is running as a card application.
When planning your game, consider using these functions if rollbacks of save data would have a fatal effect on game balance or other factors. If you create game-ending penalties for users (such as making all save data unusable in the event of a rollback), cases such as the following may occur. When deciding on your application's specifications, also fully consider how you will communicate this to your users, and how you will provide support.
- The user may create a backup of the save data on a PC without knowing about the penalty for rollbacks, and delete the data recorded to the SD card in the last call to the
SetSaveDataSecureValue()
function.
For downloadable games that do not take measures against rollbacks, there is a risk that users will lose their data without knowing that they are doing something that is not allowed.
- If the system is repaired, support technicians may be able to rescue the save data on the SD card, but not in the system NAND memory.
The value stored using theSetSaveDataSecureValue()
function will be lost, and become inconsistent with the value in the remaining save data. In this situation, the penalty will be incurred if you are using theVerifySaveDataSecureValue()
function, but if you are using theVerifySaveDataSecureValueLoosely()
function, the user can use the save data on the SD card before repair, because this function will returnTRUE
in this instance. However, the save data on the SD card before repair might have been rolled back, so you must decide whether your business model can allow this.
8.1.6. In-Game Notations and Displays
The text messages, copyright notations, and other content in the game must not pose problems on either the card or downloadable application version.
The following are examples of in-game messages where you must take into account the differences between card and downloadable applications when drafting effective messages.
- Different storage media
Card-based software applications store the software and save data to a Game Card.
Downloadable applications store the software and save data on an SD card.
Sample good and bad in-game messages:
Bad: "Saving. Do not remove the Game Card."
Good: "Saving. Do not remove the Game Card or SD card."
Good: "Saving. Do not remove the card."
- Inclusion of printed materials
Card applications come with printed material, such as a quick start guide, but downloadable applications do not.
Following are good and bad examples of in-game messages.
Bad: "See the included quick start guide for instructions on game controls."
Good: "See the e-manual for instructions on game controls."
Good: "See the in-game Help for instructions on game controls."
Use the following language in user-facing text if you want to communicate information to users differently depending on whether they are using a card or downloadable application.
Downloadable application → Downloadable version
Card application → Package version
Use user-friendly terminology as in the examples.
8.1.7. Download Play
If the parent system is using a card application for Download Play on the 3DS, a system update is performed via local communication (DUP) during the Download-Play sequence. However, the specifications do not allow the use of DUP if the parent system is using a downloadable application. For this reason, the child system must perform a system update beforehand if its firmware version is earlier than the required version.
Do one of the following to communicate this effectively to your users.
- Display the following message on the parent system for Download Play, either while or before accepting child systems:
"If the message "System update required" appears on the other system, Download Play will not be available.
Have the other player press Cancel, and update the system from System Settings. Selecting "OK" will not update the system."
If This message is too long to display, you must, at a minimum, inform the user that Download Play is not available on old system versions.
Only display this message if the argumentpNotice
is set toTRUE
in the functionnn::dlp::Server(WithName)::Initialize
. The parameterpNotice
is set toFALSE
when either a DUP is available because the parent system is using the card application, or a future system update has made DUP available for downloadable applications as well.
- Explain in the e-manual that a system update is required for child systems.
Sample user-facing text can be found in CTR Electronic Manual Creation Guide, Part 2 – Template Units.
8.1.8. Media Access Speed
The File System guidelines document recommends that implementations generally not depend on the access speed of recording media, but note that ROM and save-data access speeds differ depending on whether an application is run as a card application or a downloadable application.
Although there is no significant difference in the read speeds of ROM data between Game Cards and SD cards, data reads and writes from/to an SD card by a downloadable application are much faster than when using the backup memory of the Game Card.
For more information about access speeds, see 3DS Performance Tips.
When accessing data from the ROM and extra data (on the SD card) simultaneously, a card application will be accessing two different media, but a downloadable application will be accessing the SD card for both. This could cause a difference in processing time for the same action, depending on whether it is a card or downloadable application.
You can set the priority of file access (see Access Priority Setting in 3DS Programming Manual: System). For example, if you do not set a high priority for streaming data from an SD card, this may not cause any problems for a card application, but result in streaming delays in the downloadable application.
8.1.9. Generating (Building) Application Binaries
For your master ROM submission, you only submit a CCI file (binary for card applications). Build your application in the same way as you have done with card applications previously.
To test the application as a downloadable application, convert the CCI file into a CIA file, and import it onto an SD card.
To convert a CCI file into a CIA file, run makecia
with the cci
option.
Use the Master Editor tool to make sure that the CIA file was generated correctly from the CCI file. Specifically, look on the CXI and CFA tabs for the CCI and CIA files (all of them if there are more than one), and under "Hash value (CRC32)," make sure that the value for "Content total" is the same for both.
8.1.10. Debugging
Debug both your card application and downloadable application. You do not need to perform twice as much debugging as you have performed previously. Just devote a certain portion of your debugging on the system to the downloadable application.
If you test running both a card and downloadable application on a single system, perform the same tests as when you test running multiple card applications on a single system.
Debug using the SD card bundled with the development hardware or a genuine Nintendo SD card.
See Media Access Speeds in the File System guidelines document.
8.1.10.1. Reusing Save Data
You can use the SaveDataFiler
tool (included in CTR-SDK) to write a card application’s save data to an SD card, and then load it from the downloadable version.
8.1.11. Master ROM Submission
The procedure for submitting a master ROM for a card application that will now be sold as a downloadable application is the same as for a standard card application. Submit the same master data (CCI file) for the card and downloadable applications. You do not need to submit a separate CIA file for download sales, nor do you need to create separate packages for submitting the package version and downloadable version.
Use CTR Master Editor to submit your master data. Under "Application purpose," select "General sales," and select both the "Card sales" and "Download sales" check boxes to show explicitly that you support download sales. This submits your application as a dual-distribution application, but contact Nintendo support at support@noa.com beforehand if you want to start download sales immediately, before the cards go into production.
If you want to treat card applications and downloadable applications differently (with special approval from Nintendo), describe the specific differences in "Nintendo-Approved Specifications" on the Program Specifications checksheet in Checksheet Editor.
8.2. Selling a Previously Launched Card Application as a Downloadable Application
In most cases, making a previously launched card application support download sales only requires adding an e-manual. This section describes aspects of the development process that require special attention.
8.2.1. SDK Version
If you have a master ROM that you submitted as a card application, and you want to use it as a downloadable application, or if the only change is an added or modified e-manual, the rules listed under the CTR-SDK Versions Accepted for Master Submission page on WarioWorld currently do not apply. In other words, it is fine to use the same SDK version that you were using.
Contact Nintendo support at support@noa.com if you need to rebuild your application due to some change. However, it is fine to keep the current SDK version for the following types of change:
- Minor revisions, such as changing some of the messages or UI displays.
- Remaster to include content in a previously released patch.
If you rebuild a modified version of your application, you must submit a revision history in the applicable checksheet of Checksheet Editor or a separate document that describes in detail each of the changes from the previous version that passed Lotcheck. See the CTR Master ROM Submission Guidelines for details.
8.2.2. E-Manual
In general, you must support the items that require immediate support as spelled out in the latest version of the CTR Electronic Manual Creation Guide, Part 2 – Template Units. Create or revise your e-manual as required, and add it to your previously released binary (replacing any existing e-manual) using CTR-ROM Editor. If adding the e-manual causes the ROM to exceed the maximum size available to the application, also change the media size.
E-Manual | Necessary Changes |
---|---|
None | Create a new e-manual and submit it. |
Yes | Total replacement is not necessary, regardless of the transition period. You just need to modify any parts that require immediate support subsequent to the version of the Creation Guide that was in effect at the time of the product launch. |
Currently, the E-Manual Production manual is bundled with the CTR E-Manual Template collection, and the name has been changed to the E-Manual Production manual.
8.2.3. Save Data Compatibility
When revising applications that support dual distribution, if there are multiple versions on the market as a result of revisions to the card-applications side of distribution, consider the following.
When there is no save data compatibility between any version of the card application on sale and the distributed downloadable application, after the save data has been migrated with the Move Save Data tool, a fatal error results and the save data is unusable. If this situation applies, contact support@noa.com. Nintendo will work to ensure that relevant save data is not migrated by the Move Save Data tool.
8.2.4. Save-Data Rollbacks
As described in 8.1.5 Save-Data Rollbacks, users of downloadable applications can roll back their save data by using a PC to manipulate their SD cards—something that was not possible with card applications. You must verify during the planning stages whether rolling back save data will disrupt the game balance.
8.2.5. In-Game Notations and Displays
Check whether the text messages, copyright notations, and other content in the game pose problems for downloadable application sales.
If the application has not changed, Nintendo will not re-check the messages, notations, displays, and other content for problems.
8.2.6. Download Play
8.1.7 Download Play describes the operations of Download Play. If your application supports Download Play and does not display the messages set forth in 8.1.7 Download Play, you must place them in the e-manual.
8.2.7. Testing the Application
You must also test your application for bugs, even if you run it from an SD card as a downloadable application.
Also pay attention to the information in 8.1.4. Save Data and Extra Data, 8.1.8. Media Access Speed, and 8.1.9. Generating (Building) Application Binaries.
8.2.8. Master ROM Submission
Resubmit a CCI file with an attached e-manual, in accordance with the CTR Master ROM Submission Guidelines.
Use CTR Master Editor to submit your master data. Under "Application purpose," select "General sales," and select both the "Card sales" and "Download sales" check boxes to show explicitly that you support download sales.
The following table shows the required deliverables and their versions.
Submission Items | Version | |||||
---|---|---|---|---|---|---|
Master ROM Submission Sheet | Master ROM | Checksheet | Revision History | Remastered Version | Submission Version | |
Master ROM data identical to data submitted previously | Required | Not Required | Not Required* | Not Required | Same as last time | Same as last time |
Only added or replaced e-manual | Required | Required | Not Required* | Required | Same as last time | Previous + 1 |
Application has been changed | Required | Required | Required | Required | Previous + 1 | 0 |
* If the card application and downloadable application differ, and you did not note this difference in the previous submission documentation, describe the specific differences under "Nintendo-Approved Specifications" on the Program Specifications checksheet in Checksheet Editor. If any of the following applies to your title, and you did not note this in the previous submission documentation, you must resubmit your checksheet.
- Titles that use the save-data rollback prevention support function
- Titles that access the save data of other applications
In general, use the latest version of the Master Editor and Checksheet Editor to create your deliverables.
However, using the newest version of Master Editor can cause the following errors. Ignore this error if you have not yet rebuilt to include fixes.
- Settings with values configured and settings with no values configured can get mixed up for the long title, short title, and publisher name settings.
8.3. Revising Your Application
This section describes the steps required when you revise an application marketed via dual distribution as a package and downloadable version.
We recommend that you use a patch to make revisions. See the chapter about patches in the 3DS Overview.
When revising a title that uses a fake client, special consideration is required if a fake client that differs from the remaster version will connect to the DLP server.
See the chapter about fake client features in the Patch Manual.
8.3.1. Revising Your Application After Launch
As a general rule, create and submit a patch for any revisions.There is no need to submit revised versions.
Only submit a revised version if you plan on producing a revised version with a new Game Cards with the revisions applied. In this case, select only the card sales option under the "Application purpose" section of the Master ROM Submission Sheet. This master ROM will only be used to manufacture Game Cards. It will not be distributed through Nintendo eShop.
Patches work for the majority of cases where a fix is needed. In such cases where a patch cannot be applied, submit the updated version for dual distribution. In this case, in the Master Editor tool, in Application purpose, select both Card sales and Download sales.
E-manual revisions and fixes for Download Play child programs are also applicable with patches.
8.3.2. Distributing a Card Application That Has Already Been Released and Patched
It is fine to make the unpatched version of the application (the content that was released on the card) ready for dual distribution in accordance with 8.2. Selling a Previously Launched Card Application as a Downloadable Application, and then resubmit it. However, you must confirm that the downloadable application runs correctly when it is patched.
You can also submit a revised version.