Need help?

[joeldenning]

Hi @loganmc10, I'm excited to see some of the recent developments you've made with mupen64 netplay. I am an experienced developer (4100 contributions on Github this year, worked at Amazon, maintain a bunch of open source), albeit mostly in javascript rather than C.

I also have been an active member of the super smash bros 64 competitive scene for several years. We use a really old version of Project 64, which is unfortunate since it's Windows-only, has frequent desyncs, and is not under as active development as mupen64 seems to be.

After seeing recent progress in the gamecube emulation world, I recently became interested in seeing if I could help in implementing the following three features for the ssb64 community:

1. In-game netplay option
2. In-game, rated matchmaking
3. Rollback netplay

Much of the ssb64 community is using patched ROMs (notably 19XXNE and Smash Remix), and we have some expertise in that area which could potentially help with modifying the roms. However, we don't have anybody I know of who is involved in emulator development, which would also be needed for any of the things above.

For now, I think I'm most interested in the first two items, which is what led me to m64-netplay-server. I noticed in this comment that you mentioned you are considering eventually creating a matchmaking service, which made me think that our interests might align.

Is there anything you'd like help with?

[loganmc10]

Hi Joel,

Thanks for reaching out! Help is always welcome. My personal and professional life have become quite busy lately, so I haven't been able to devote much time to this.

The matchmaking is already mostly implemented, if you haven't, you can download the pre-compiled binary version here: https://m64p.github.io , it allows creating public or private "rooms", which can be joined by others. The rooms are announced in a Discord channel (there is a link to that on the website). Overall it works pretty well. I host 3 cloud based servers, one in Oregon, one in Virginia, and one in Paris. The only real issue the server currently has is that sometimes games don't close cleanly (ports stay open), so I have to login and reboot them every now and then, I haven't tracked down that bug yet.

I've had a few discussions with some members of the SSB64 netplay community on Discord, it didn't go very far because of a few philosophical differences:

• The main issue they had revolved around handling latency. m64p is designed to handle latency much like a "modern" game experience. For instance: if they are playing on the Oregon server, someone located closer to the server is going to have a lower ping, and therefore experience lower input latency. Someone located further from the server will experience higher input latency.
• This is very different from how traditional emulator netplay works, most emulator netplay implementations try to give everyone the same experience. Basically everyone experiences the same latency as the player with the highest ping. Also, if one player disconnects, the game freezes for everyone.
• In my implementation, if someone freezes/hangs, the game carries on, their player will just "idle", once they reconnect, their game will fast forward to catch up to other players.
• Most of the SSB64 community seemed to feel that this gave an unfair advantage to players with better pings. Despite my constant attempts to argue that this is the same situation for any modern game (Rocket League, CoD, Modern Warfare, etc..) they didn't like it.

I guess what I'm saying is that I'm not sure the competitive community really likes this implementation? When I was designing this, I had "fun" in mind, not competition. To me, having a laggy game because 1/4 players has bad lag, or having a game freeze, takes away from the fun, and it's better to slightly "punish" the 1 player that might experience higher lag.

Anyway, any help would definitely be welcome. m64p-netplay-server can be run locally, but I designed it with cloud hosted servers in mind, the goal being to provide a very user friendly experience, where players wouldn't need to worry about forwarding ports, etc..

I'm on Discord @ loganmc10#3257, or chatting here is alright with me as well

[loganmc10]

As to point #3, I never thought much about rollback netplay. This netplay implementation doesn't really have issues with desync, so I never looked into it much. The save states for m64p I think are around 16MB (though they can be compressed), so transferring the save states needed for rollback on a constant basis would probably be an issue.

This implementation can detect desyncs, so one potential, if a desync is detected, is to synchronize the save states to player 1 or something, to try and get the game back in sync.

There is only 1 real situation that I can think of where desyncs can occur: the N64 supports GPU readbacks; reading the contents of GPU memory into CPU memory. The GFX plugin, GLideN64 also supports this. It's possible that because everyone has slightly different GPUs, they are playing at different resolutions etc... That the contents of the GPU memory being read are slightly different between players. I ran into this with GoldenEye, and there is some code to explicitly disable GPU readbacks when playing GoldenEye over netplay, since disabling them doesn't seem to make any difference besides fixing the desync.

The only other desync I've come across is in Mario Tennis, it seems to desync sometimes when playing cross platform (when some players are on Windows and others on Linux). It's possible that there is a difference in how each OS does floating point math or something? These types are issues are very hard to track down, and there is a potential that some kind of rollback/save state sync implementation could help.