rpfload VS Backroll

If you'd like to give it a try or tell me that everything I did was wrong, you can find it here: https://github.com/jsf0/rpfload

What most state of the art fighting games nowadays implement is rollback netcode (an implementation on top of lockstep based p2p netcode). This works when the amount of concurrent players in a game is low (2-4). Although I don't see a reason why there couldn't be an authoritative server solution like many other games have it, but then you also had to simulate the authoritative logic on the server instance. The upside is that you can realistically support more concurrent players. Comig back to rollback netcode, for this to work you need a determinisitc simulation. Each simulation on any hardware you support has to play out the same if the same input is provided over the duration of the simulation. Depending on which set of hardware you want to support, this can mean to completely throw out all relevant game systems that use floating point math and replace them with fixed point number types, since different processors might yield different float calculation results, or there are some differences in how compilers choose to optimize calculations. One additional problem for p2p networking is actually to connect with the other player. I recommend having a matchmaking server for this, that just pairs up players. More often than not, every player is in their own internal network and it's hard to connect to the PC over the network then. It would be possible to open map a port from your public IP of your router and re-route incoming messages to your PC in the internal network using port forwarding. This however requires manual setup and can leave you open to some attacks from outside. Having a public external server for matchmaking/pairing up can try to bypass those issues with punch-through). GGPO is popular transport library for rollback based netcode, It has gone open source a while ago too. If you look for an implementation for Unity/C#, I recommend checking out Backroll. Even if you use it, there will be a lot of things you still have to implmenet yourself to actually support rollback. Like making sure that input data representation is the same for every client, having a deterministic simulation, being able to serialize or temporary store a whole copy of your dynamic game state, applying such a stored game state back to the game simulation, and fully running several logical game frames with the call of a method, where input might be provided from historical records of real or predicted inputs of the players. For this reason, a lot of fighting games run the actual logical simulation completely outside of the rendering step. This all sounds pretty complex, but there are also benefits that naturally emerge from a rollback netcode or lockstep implementation: Network bandwidth requirements are very low since the most data you will need to send are inputs, and state hashes to make sure that the game simulations stayed in sync. When you store the history of inputs for a game in a file, and various other inputs you might have (seed for deterministic random generators etc.), you basically have all you need for a replay file, and just can run the simulation on those inputs (a problem is that this will break if you make changes to the simulation though).