So there's this hack https://www.justin.tv/hextator/b/281099551
I've been working on, working offline beautifully
As someone of you may know from my complaining, it doesn't work online because the game desynchronizes whenever saves are loaded.
As the hack currently is, the first save is loaded in multiplayer so that your save data can be used for co-op play when you press the L button while in multiplayer.
When you do this while playing online with Mupen and Kaillera, the only way to currently do so, the game desynchronizes instantly and even crashes the emulator at times.
Obviously whoever coded Mupen and/or Kaillera fucked up, because Kaillera is only supposed to synchronize key presses and be entirely agnostic of what the game is doing.
So I'm proposing a solution that will resolve this problem not just for this game, but for all applications...a way for people to synchronize the input received by any application on any PC.
Moving on, this is basically an RFC for this project.
- Requirements suggestions (my own to follow)
- Interface ideas (related to the above)
- Implementation suggestions (would I be able to prototype this in C#? I hope so but I don't know if it can do what I need)
Here are the ideas I have.
- There will be an application which, when it has the focus, will forward input to the application specified.
- The specified application will need metadata concerning a benchmark for synchronization, such as an address of execution that can reliably be broken upon to ensure input is sent to it at "the same time" on all clients.
- Following the previous, the implementing application will forward input to the application only while it is waiting for input as per the synchronization utility (as suggested above, I'm thinking breakpoints) after negotiating with other clients what the input to forward even is.
- It will not be necessary to forward the input to anything, and input could simply be assumed to be synchronized on clients who are not forwarding their "negotiated" input to anything - in this case, only one "player" needs to have the application receiving the input running, and if other players can see what the "host" sees through other means they will be able to play (although they will be able to play anyway whether they can see what they're doing or not, in this case)
The pros of this include
- No need to actually have the game that's even being played
- If implemented correctly, this solution will be cross platform and be application agnostic, even allowing someone playing one game in something like Project 64 to be able to be synchronized with someone playing the same game in Mupen.
- The application will be open source, so ways to resynchronize will be able to be implemented (or perhaps in the case of synchronizing emulators, save states could simply be passed between clients...an FTP widget could be added to facilitate this).
- The application will only forward input while it is in focus, so it will be secure.
The cons, of course
- Limited to the same input device (in other words, it will virtually be as though clients are sharing the same keyboard, fighting over which keys to use)
- Settings for the applications being synchronized will need to be precisely mimicked across clients
- Latency could be an issue? (This is mostly negligible, latency will ALWAYS be an issue...but if it's synchronized, it should be fine, right?)
- Ensuring synchronization may be difficult
- How the heck are we supposed to do cross platform breakpoints?
Optimizations could be made to this model. For example, emulators keep track of the input status of the emulated controllers. Following the note about application metadata for synchronization purposes, the implementing application could add an interface for specifying how to translate keyboard and other input device input (hopefully support for input devices such as mice and USB controllers, rather than just the keyboard, will be implemented in the future if this idea works out) into the format the emulated controllers use, and then that data could be synchronized and given to the emulator instead of the less abstract raw keyboard status of the clients.
Final note: I know this is basically what Para did for the SRDP - post a good idea (I'm hoping this qualifies anyway), request suggestions for how to improve the implementation and then expect people to do so. That seems to have fallen through and as I'm one of the people that offered to help with that project it probably doesn't look so great for me to go and ask for ideas about my own.
All I can say about that is all of this shit needs to get done eventually anyway.