Applications that connect to friend servers or game servers must comply with all the guidelines listed in this chapter.
6.4.1 Unnecessarily Logging In and Out
Logging in to and out of the game servers and friend servers is a process that places a heavy load on the servers.
Excessive logins and logouts greatly increase the load on the servers and prevent the servers from providing normal services, so Nintendo has set a number of restrictions on login/logout processing.
■ Prohibition of Unnecessary Logins and Logouts
It is prohibited to unnecessarily log into or out of the game server or friend server.
Log in no sooner than when online features are used, and only log out when the wireless switch is used to disable wireless, or when the application is closed.
For the game server only, it is acceptable to log out if the application is explicitly transitioning to an offline mode, and there is no incentive for the user to repeatedly go back and log in again. (For example, it is acceptable to log out if explicitly transitioning to an offline single-player mode that uses local communication.)
Note that the following and similar specifications will not pass Lotcheck.
- Logging in every time the application performs matchmaking, and then logging out every time when the match ends (when communication with the communication partner ends).
- For applications which upload a score to ranking servers upon completion of every stage, logging in every time when uploading a score and then logging out.
- For applications with multiple sets of ranking data, logging in every time when downloading a different ranking and then logging back out.
- For applications where there is an incentive for the user to frequently access data on the data store, logging in every time when accessing the data store and then logging back out.
■ Prohibition Against Automatic Re-Login
It is prohibited to automatically re-login to the game server or friend server.
If a connection to either the game server or friend server has been lost and your application’s specifications necessitate logging into that server again while staying connected to the network, do not log in automatically. Instead have the user log in manually. It is also prohibited to implement any feature that allows frequent, repeated logins in the background. If your application does not need the user to log in again, gameplay can continue unchanged.
When the server is under heavy loads, your connection may be lost immediately after login. If you continue to retry under these conditions, you may unintentionally cause the system to log in over and over. Applications are therefore prohibited from automatically logging in again. It is acceptable to have the user manually log in again.
■ Prohibition of Periodically Logging In and Out
It is prohibited to implement any process that regularly or periodically logs in to or logs out of the game or friend servers.
There may be cases in which you clearly need to log into a game server again at intervals of several minutes after using a service, such as with NEX ranking and matchmaking. If this is the case for your application, consider an implementation that avoids unnecessary logins and logouts by maintaining logged-in status.
Below are example implementations that would classify as periodic logins and logouts. Contact Nintendo at support@noa.com if you have any questions.
- Applications that automatically switch between local and Internet communication at regular intervals.
⇒The application will periodically log in and log out, because starting local communication ends the Internet connection. - Applications that stand by for an Internet matchmaking opponent in the background, while playing in a single-player game mode that does not generate local communication.
⇒After logging in to the game server, do not log out until the user ends the standby status. - Applications that implement several different multiplayer modes as part of their overall Internet multiplayer features, and log in and out every time the system enters or leaves a given multiplayer mode.
⇒Log in and log out only when entering and leaving the overall Internet multiplayer mode. - Applications that repeatedly log in and out when uploading or downloading ranking scores.
⇒If there are multiple types of rankings, log in and log out only when entering or leaving the mode(s) under which all types of rankings can be accessed.
■ Note When Suspending Network Daemon Manager (ndm)
The Nintendo 3DS system runs a variety of network processes in the background, which are controlled by the ndm. The ndm manages connections to the Internet, StreetPass, SpotPass, and Friend Presence. Keep in mind that the specifications of the application and the way it suspends and resumes the ndm could cause the application to log in to and log out from the friend server unnecessarily.
If an application explicitly logs in after using the nn::ndm::SuspendScheduler function (which suspends the ndm), it will reestablish the Internet connection that was already established by the ndm and log in again to the friend server. This increases the load on the server and the user's wait time. Therefore, avoid use of this function as a general rule. Likewise, do not call the nn::ndm::Suspend or nn::ndm::SuspendDaemons function to suspend the Friend Presence daemon, because this could result in the same issue.
If your application design requires you to suspend the ndm daemon during communication, call the nn::ndm::SuspendScheduler, nn::ndm::Suspend, or nn::ndm::SuspendDaemons functions only after explicitly logging in. This will avoid unnecessary logins and logouts. Similarly, call the nn::ndm::ResumeScheduler, nn::ndm::Resume, or nn::ndm::ResumeDaemons functions before explicitly logging out using the nn::friends::Logout function. (You only need to call Resume before logging out if you have previously suspended the ndm using Suspend. It is not necessary when logging out normally.)
See the section on the Network Daemon Manager Library (nn::ndm) in the CTR-SDK Function Reference Manual for details.
6.4.1.1 Prohibition Against Unnecessary Logins and Logouts to/from Game Servers
Guideline Item |
The application must log in to the game server only when starting an Internet connection and log out only when closing that connection. It must not log in or out unnecessarily.
|
---|---|
Software to Be Tested |
Applications that use CTR-NEX to connect to a game server. |
Test Method |
Login:
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
The PID can be obtained from the friend code by using the BMAS ID Conversion feature.
Points that tend to cause Lotcheck failures include:
- Logging in/out every time a ranking is registered.
- Logging in/out when switching ranking modes.
- Logging out upon completion of a matchmaking game session.
6.4.1.2 Prohibition Against Unnecessary Logins and Logouts to/from Friend Servers
Guideline Item |
The application must log in to the friend server only when starting an Internet connection and log out only when closing that connection. It must not log in or out unnecessarily.
|
---|---|
Software to Be Tested |
Applications that use the Friend Presence library. |
Test Method |
|
Pass/Fail Determination |
Passes if, in step 5, no changes in the online/offline status occur except when connecting to or disconnecting from the Internet. |
6.4.1.3 Prohibition Against Automatic Re-Login to the Game Server
Guideline Item |
The application must not re-login to the game server automatically (without a user operation).
|
---|---|
Software to Be Tested |
Applications that use CTR-NEX. |
Test Method |
|
Pass/Fail Determination |
Passes if, in step 8, the library member function named Login(1) is only called once. |
6.4.1.4 Prohibition Against Automatic Re-Login to the Friend Server
Guideline Item |
The application must not re-login to the friend server automatically (without a user operation). |
---|---|
Software to Be Tested |
Applications that use the Friend Presence library. |
Test Method |
Check the source code.
|
Pass/Fail Determination |
Passes if the application does not log in to the friend server automatically (without a user operation). |
6.4.1.5 Prohibition of Periodically Logging In and Out
Guideline Item |
The application must not implement any process that regularly or periodically logs in to or logs out of the game servers or friend servers. |
---|---|
Software to Be Tested |
|
Test Method |
Check the source code. |
Pass/Fail Determination |
Passes if the application does not implement any process that regularly or periodically logs in to or logs out from the game servers or friend servers. |
6.4.1.6 Cautions Concerning NDM
Guideline Item |
To prevent unnecessary logins and logouts to and from the friend and game servers, the application must call nn::ndm::SuspendScheduler, nn::ndm::Suspend, or nn::ndm::SuspendDaemons after any explicit login. When logging out, the application must call nn::ndm::ResumeScheduler or nn::ndm::Resume before calling nn::friends::Logout to explicitly log out. |
---|---|
Software to Be Tested |
Applications that suspend the ndm when starting Internet communication and then resume the ndm when ending Internet communication, and that use the CTR-NEX or Friend Presence libraries. |
Test Method |
|
Pass/Fail Determination |
Passes if system B is still shown as online in steps 4 and 6. |
6.4.2 Connecting to and Disconnecting from the Friend Server
■ Handling Canceled Logins to the Friend Server
The user might have to wait several seconds when a connection to the network must be established to log into the friend server. If you cancel a login request without confirming that asynchronous processes have failed, the login request you sent may persist. Nintendo recommends canceling login requests by calling nn::friends::Logout.
■ Handling Disconnections from Access Points
- Handling Login Request Cancellations
First cancel any pending login request before performing operations where the system might become disconnected from an access point while processing a login request from the application. Failure to do so can result in the user's online status not matching the user's actual online state for up to 1 minute after performing operations. Consequently, be sure to first cancel login requests by calling nn::friends::Logout before performing operations that may result in disconnection from an access point. For example, this can occur when calling nn::ac::Close or switching to UDS communication. - Handling Unintended Disconnections
When unintended disconnections occur, it can take a short period of time for the system to automatically cancel a pending login request. For example, this can occur when the wireless signal degrades or when moving outside the range of an access point. Nintendo therefore recommends that you cancel any pending login request by calling nn::friends::Logout when the application receives notification that the system has detected a disconnection.
No required guideline items.
6.4.3 Disclosing Information to Friends
The friend list shows online/offline status of both the user and the user’s friends, in addition to information about the titles they are currently playing. Users can configure the friend list to not disclose their own information if they do not want to show it to others.
- Items that can be set to “Do Not Disclose”:
- The user’s own online status
- The title the user is currently playing
Nintendo recommends that you use the information obtained from the Friend Presence library when displaying the online status of friends within an application. This allows your application to respect the settings of friends who have chosen not to disclose their own online status by showing such friends as offline.
However, it is not a problem for your application to indirectly show that a user is online, such as by indicating that the user is seeking matchmaking partners during online play with friends.
No required guideline items.