Is there going to be account enviroments for developers to debug homebrew apps?

dwyazzo90 · June 2, 2024, 7:01pm

Nintendo had enviroments for game developers to test their services (NEX, Miiverse API)

So i wondered, why cant Pretendo do the same?
I´m aware theres another instance (more like, another domain) for the account server for Cemu, but i was wondering if Pretendo was going to work on an instance for game-devs to test the NEX services / Miiverse API without affecting the normal production enviroment in any way.

I feel this would work great for developers (like me) who want to make homebrew apps / services and want to debug easily, and could be easily included along with the 3rd party plans…

MatthewL246_PNID · June 2, 2024, 7:11pm

Pretendo does have plans to support third-party servers in the account server. I believe that this could be used by third-party developers like you who want to make and test new game servers. However, this is definitely a long-term plan that will take a while to get implemented.

github.com/PretendoNetwork/account

[Feature]: 3rd party server support

opened 05:21PM - 31 May 24 UTC

jonbarrow

approved feature

### Checked Existing - [X] I have checked the repository for duplicate issues. … ### What feature do you want to see added? (Mostly only making this issue to add it to the tasks tracker) Add the ability to allow 3rd party developers to register both their own instances of NEX (game) servers, but also completely separate 3rd party services (such as those looking to integrate PNIDs into their systems) ### Why do you want to have this feature? This would allow for developers to create their own instances of game servers, and users would select which instance to connect to. This is most useful in cases like: - Heavily modded game sessions - Players who may not want to conform to our general rules (allowing all cheats, everywhere, for example) - Private tournaments - Etc. This would also allow non-game services, and games which are out of scope for us, to use existing PNIDs for authentication ### Any other details to share? (OPTIONAL) ***DUE TO THE WAY CERTAIN GAMES HANDLE USER GENERATED CONTENT, MIXING 3RD PARTY GAME SERVERS AND 3RD PARTY MIIVERSE IMPLEMENTATIONS, SPECIFICALLY, CAN VERY EASILY LEAD TO DATA CONFLICTS! THE IMPLEMENTATION NEEDS TO ACCOUNT FOR THIS!*** As an example, Mario vs. Donkey Kong: Tipping Stars uses ***BOTH*** Miiverse and NEX DataStore when uploading levels. The level data itself is uploaded to NEX DataStore, however a Miiverse post is ***ALSO*** created at the same time. The DataStore data and the Miiverse post are linked together through their unique IDs. This, very obviously, will create data conflicts if naively implemented. Say a user is using GameServerA and MiiverseA, and then uploads a level. Only GameServerA and MiiverseA have records of this data. Now say a user is using GameServerA, and MiiverseB. The user is given level data from GameServerA, attempts to load the linked Miiverse post from MiiverseB, and either fails to get data back or receieves incorrect data. Now say a user is using GameServerB and MiiverseA, and uploads a level. MiiverseA now has records for DataStore data which does NOT exist on it's own GameServer instance. ***This is not a trivial problem to solve. There are options, such as only allowing the user to connect if using the same A/B instances of servers which rely on each other, however this is unreliable and would lock users out of other users data.***

In the meantime, if you want to self-host your own Pretendo server and develop on that, I made a project for that.

PN_Jon · June 3, 2024, 3:55pm

We literally do support multiple account environments already, and have for many years. Since the very beginning if I remember correctly. It’s referred to as server_access_level internally

github.com

PretendoNetwork/account/blob/af54670fbc82b80f4500c943600c5019860cbbd3/src/models/pnid.ts#L38-L41


      
          	server_access_level: {

          		type: String,

          		default: 'prod' // * everyone is in production by default

          	},

This is how we’ve always controlled access to our beta servers, and you can see the environment switcher in your account settings

We make use of 3 environments officially: prod, test and dev. Only prod and test are accessible to normal users, dev is used internally by us. But we can use anything we want. I’ve put @ImoraPNID in a custom alpha environment before for debugging.

People outside of us can’t use them because there’s no reason to. We don’t allow 3rd party developers yet, and you can easily spin up instances of the entire network locally.