3.1. General NEX Usage
This section describes general considerations when using the NEX library.
Initialization and Login
The NEX library and other libraries must be initialized before logging into the game server.
Login/Logout Frequency
Logging in and logging out creates a high server load. Minimize the frequency of logins/logouts as much as possible. For example, if your title includes an offline gameplay mode in which rankings are uploaded to the server at the end of every level, do not log in/log out at the end of every level. Instead, after logging into the game server for the first time, maintain the login state unless you have a specific reason to do otherwise.
AC Disconnection During Asynchronous Processing
If AC gets disconnected, NEX cannot function normally. Therefore, NEX must be finalized. This is also true when AC gets disconnected while asynchronous processes are still running. If AC gets disconnected during asynchronous processing, cancel the asynchronous processes and finalize NEX. If it is not feasible to cancel the asynchronous processes, just finalize NEX.
Canceling Asynchronous Processes
Although it is possible to cancel all asynchronous NEX functions that are currently running, some of the processes may still be completed on the server depending on when the cancellation took place. For example, if you cancel the asynchronous process associated with the MatchmakeExtensionClient::CreateMatchmakeSession
function, a matchmaking session may still be created on the server. If the matchmaking session is open to participation, an unmanaged matchmaking session may take place. In general, Nintendo recommends avoiding canceling asynchronous processes unless you have a specific reason to do otherwise.
Threads On Which NEX Functions Are Called
The recommended thread mode is ThreadModeUnsafeTransportBuffer
. In this thread mode, all NEX functions calls must be made from the same thread. In this thread mode, make all function calls from the same thread regardless of whether the function performs communication, or is implemented as a synchronous process, or an asynchronous process. Alternatively, you can use exclusive control as appropriate.
Working with IDs Issued by Game Servers
The IDs issued by a game server are not unique outside of that game server. Not only are these IDs not unique across different titles, they are not unique across the various server environments for the same title (development environment, Lotcheck environment, production environment). As a result, be careful when working with these IDs on an independent server or similar. For example, data IDs for data in the data store may be the same for data from the Lotcheck environment and data from the production environment. Do not manage data solely by data ID on your independent server because there may be duplicate data IDs. When saving IDs issued by the game server on your independent server, include the environment metadata included in the service token.
NEX Data Size Limits
NEX can handle up to 10 million pieces of data for each of the following modules: rankings, matchmaking, and data stores. Data in excess of these limits may impact server performance to the point that the user experience is negatively affected. Data stores are designed to handle up to 10 million pieces of data regardless of whether a dedicated storage server is used. For example, if you predict that your title will have 100,000 unique users and each of those users uploads 100 pieces of data, the total number of pieces of data will be 10 million. For rankings, each user can only post one score to each ranking category. Therefore, if you predict that your title will have 100,000 unique users and you have 100 ranking categories, the total number of pieces of data may reach 10 million. For matchmaking, in most cases the number of matchmaking sessions will never exceed 10 million. However, as a precaution, make sure to close matchmaking sessions that are no longer in use.
Contact Nintendo on the OMAS message boards (or similar) in advance if you think that your title may generate more than 10 million pieces of data.
Automatic Copying of Server Settings
Game server settings configured on NMAS are automatically copied to the Lotcheck environment and the production environment when setting up each. Therefore, if you need to update your game server settings on NMAS, make sure to do so before starting the Lotcheck phase. You can still use NMAS to modify the settings for the development environment and the production environment after the respective servers are set up. If you need to change your server settings for the Lotcheck environment after the Lotcheck server has been set up, communicate with your Lotcheck contact directly.
Connection Environment Required to Connect to the NEX Server
Simply configuring your machines to access the server IP address and port number displayed on OMAS may not necessarily make it possible to connect to the NEX server. The NEX server cannot be accessed from a dedicated company LAN or other restricted connection environments by simply configuring your machines to access the IP address and port number displayed on OMAS. Nintendo cannot release all of the IP addresses needed to access the NEX server. Use an unrestricted network environment to access the NEX server.
3.2. Rankings
This section describes general considerations to consider when using the ranking features.
Using RankingConstants::ORDER_CALCULATION_123
When
is specified and there are several instances of the same score, older scores are ranked higher. Furthermore, if the same user uploads the same score, the score data is also updated. This means that the score may be ranked lower than it was previously. RankingConstants::ORDER_CALCULATION_123
If you are using
for your time scope or just filtering scores by periodically resetting them, you can prevent the order in which scores are ranked from changing when a score equal to a score that has already been uploaded is posted. This is performed by not uploading the newer instance of the score. RankingConstants::TIME_SCOPE_ALL
If your time scope is defined as some period of time relative to the present, the date score uploaded must be updated even if the score is equal to an existing score, so the method above will not work. This is by design.
3.3. Matchmaking
This section describes general considerations to keep in mind when using the matchmaking features.
Using MATCHMAKE_SELECTION_METHOD_SCORE_BASED as a Matchmaking Selection Condition
Contact Nintendo in advance on the OMAS message boards (or similar) if you are considering using MATCHMAKE_SELECTION_METHOD_SCORE_BASED
as a matchmaking session selection condition in conjunction with parameters other than the examples provided in the Server Services > Web API > Score-Based Auto-Matchmaking Feature section of the NEX Programming Manual. Depending on how you configure these parameters, you might not obtain the intended search results when searching matchmaking sessions.
Empty Matchmaking Sessions
Leaving a large number of unclosed (empty) matchmaking sessions on the game server will increase the cost of searching matchmaking sessions and may negatively impact overall game server performance. Make sure to close matchmaking sessions that are no longer being used by the application.
Moreover, although unlikely if you are using the auto-matchmaking feature, if you are using the MatchmakeExtensionClient::BrowseMatchmakeSession
and MatchmakeExtensionClient::JoinMatchmakeSession
functions to implement your own matchmaking scheme, some search conditions may cause matchmaking sessions to never be found and a large number of empty sessions to be left on the server. If no matchmaking sessions can be found, consider specifying MATCHMAKE_SYSTEM_TYPE_ANYBODY
as a search condition and joining the sessions that are retrieved in order to fill up the empty rooms.
Searching for Password-Protected Matchmaking Sessions
Matchmaking sessions can be configured to have a password in order to allow specific users to matchmake with each other. If you include such password-protected matchmaking sessions in your search results by default, the number of matchmaking sessions that other users can join may decrease. This makes it necessary for users to repeatedly search for a matchmaking session, which both degrades the user experience and increases the server load. Therefore, Nintendo recommends excluding password-protected matchmaking sessions from the search results when searching for matchmaking sessions using the MatchmakeExtensionClient::BrowseMatchmakeSession
function.
Auto-Matchmaking With a Single Matching Condition
If you choose to use auto-matchmaking and only have a single search condition for matchmaking sessions, the server load may increase drastically when there are a large number of users looking for a matchmaking session at the same time. If you predict that your title will have a large number of simultaneously connected users looking for a match, consider using game modes to divide matchmaking sessions into two or three categories behind-the-scenes. Perform this in a way that still makes it still appear like the search conditions are the same to the user, for example. Contact Nintendo during the planning phase of your title if you predict a large number of simultaneously connected users and cannot use a workaround such as dividing up matchmaking sessions into different categories.
3.4. Data Stores
This section describes general considerations to keep in mind when using data stores.
Data Search Conditions
You can use tags specified when data is uploaded to search for data in a data store. However, server performance may suffer if the tagging scheme causes most data to be tagged in the same way. For example, if data is tagged with categories that represents the country of origin such as "jp" and "us", all data that is uploaded will have one of these tags. If you then try to use one of these tags to search for data in the data store, there will be a large number of matching records in the database. This results in high server load and slow search performance.
Therefore, make sure to design your tagging scheme and tag searches in a way that prevents this type of tag concentration from occurring. If you want to categorize data by country of origin as in the example above, Nintendo recommends also adding a tag that represents the data type.