nakama VS ggpo

nakama: https://github.com/heroiclabs/nakama

To add more detail on the recent work on the ZHeap storage engine. We (Heroic Labs) sponsored work for the Cybertec team to bring it up to date with latest improvements and changes with Postgres' pluggable storage engine:

you can do that, but for what platform? html5? windows? android?, the most easiest way is use firestore a service from firebase (offer a free tier), it is the easiest way not the better, other way is use a service like nakama that is more professional and something in the middle can be mmm pocketbase or supabase.

I recommend the backend solution called Nakama since you’re using Godot: https://heroiclabs.com/

You could create all this yourself, or you can use existing solutions which handle all this (and much more I didn't mention). One that I'm aware of that works with Godot is Nakama. They have a paid hosting option, or you can host the application yourself.

I read using nakama server for this is convinient. https://heroiclabs.com/

Does anyone have recommendations on what to use? I've done a bit of research and found https://heroiclabs.com/. It's a bit unclear to me if it actually supports server side state because it talks about 'hosts' a bit, but I think it does...and it seems like you can host it yourself to avoid the $600 a MONTH! pricetag. But any other recommendations? Has anyone used heroic before?

You might be interested in Nakama server from https://heroiclabs.com/

Depending on how much effort you want to put in to this, you might consider something like Nakama: https://github.com/heroiclabs/nakama

There have been mentions of Normcore, Fish-Net, and Nakama as well.

As mentioned in the top comment, rollback and client side prediction is key. One of the more robust and popular libraries that do this specifically for fighting games is GGPO. When it was opened sourced a few years ago it was a fairly big deal as games that used it felt great. Larger studios have their own libraries but the concept is the same. Its worth a look through if you want to implement something on your own.

I just did a quick Google so I don't know the exact details, but I think Max said Idol Shodown is running GGPO which, as far as I can tell, is open source.

will reply here also in case anyone else wanted an answer. You could use the original C++ library with C++ or any language that interops with C++ (e.g. C#), so that's there for ya if you need

Sure thing bud. I guess we'll just keep pretending like Code Mystics, the same people that did the KI netcode, haven't partnered with SNK because SNK realized their shit sucks and they needed external assistance. We'll pretend like the source code for GGPO is hidden away in the recesses of Tony Cannon's mind or that it isn't open and free for anyone to use or that it doesn't have Japanese documentation. We'll pretend like MikeZ didn't implement a version of GGPO in Skullgirls in 2012.

GGPO is a common implementation and it's all open source if anyone wants to get into the nitty-gritty: https://github.com/pond3r/ggpo

Backroll-rs is a brand new networking library based on GGPO dedicated to peer-to-peer Rollback Netcode, for use in fighting games, platform fighters, and other games with less than 8 players that require low latency. We are looking for programmers familiar with Rust to help finish this project. We are 80% of the way completed with this project, but we need more unit tests and debugging to fully finish it.

This doesn't work in the comparison to shooters. Shooters operate through a server, while fighting games are peer-to-peer. They only require a server for matchmaking purposes. Doing the peer-to-peer part actually puts fighting game devs at an advantage compared to other genres, as there's libraries and documentation for those libraries to either plug and play a rollback solution or build one buy looking at existing source code complete with solid documentation.

GGPO doesn't really solve the biggest problem with SFV's netcode, which is client timesync. It does have code in there to handle it by slowing down the client that's ahead and allowing the client that's behind to catch up, but that doesn't fix the fact that one client consistently gets ahead in the first place, and also means the faster client will see more stuttering or slowdown.