Probably.
Most (i.e. the vast majority) aren't going to support a FG just because it has GGPO. If it doesn't interest them, it doesn't interest them. For those that are interested though, GGPO/rollback is extremely welcome.
-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
GGPO (rollback netcode) SDK now Open Source under MIT License
- Thread starter Murlin
- Start date
Most (i.e. the vast majority) aren't going to support a FG just because it has GGPO. If it doesn't interest them, it doesn't interest them. For those that are interested though, GGPO/rollback is extremely welcome.
I was planning on buying samsho till I heard the netcode was trash. Still want to play it even now, but bad online is too frustrating when trying to learn a new game.
Here's the MK devs giving an incredibly detailed explanation of the things they had to go through to get rollback working (which has been posted more than once in this thread before, clears up so many misconceptions, but people are ignoring over and over):
https://www.youtube.com/watch?v=7jb0FOcImdg
Again talk is only dealing with the engine level optimizations, not dealing with other things like implementing a reliability layer.
Are you seriously going to tell me that this:
Have simulation steps that are computational heavy as this:
https://www.youtube.com/watch?v=Z8WnKsEKXv4
Because the cost of serialization was so expensive, the MK devs ended up having to rollback 8 frames every frame. This mean that rollback requires 8 * 60FPS simulation steps per second. Lockstep latency compensation does not require this, which makes lockstep computationally cheaper. Which also means the company not having to spend the expensive time of a senior engineers doing perf work.
Obviously from a quality perspective, rollback blows lockstep out of the water, but it does come at a cost. When your game isn't as computationally expensive, it's not as costly.
It's not a little bit. The expense of handling physics/collision for a 2D fighter is significantly cheaper that have to deal with the expense of having to deal with multiple animation channels (which are not just part of the rendering step of a frame and does affect simulation) required to simulate a 3D scene. Again, look at the MK GDC talk (it's a great talk) and look at all how much work they had to put in to shave fractions of a millisecond of each frame to get it to run at a consistent 60FPS.
You would be surprised. The people who make key decisions are business people and business people love data. When they see data like this:
They're going to assume that means only a fraction of their user base cares about online. I have worked on projects where online was slapped on near the end of development using some framework they found on the unity asset store. They decide not to put money on it because of analytics like the ones above.
If I were guess why Netherrealm sunk at least a million (again, probable underestimate) into upgrading the netcode was because the latest mortal kombat is littered with microtransations and they want to keep those whales (who are a very small but profitable minority) playing.
It's companies making a business decision not to invest in something that does not add to the bottom line. This happens so much. Want to know why the gaming you paid +$60 for is buggy even with the day 1 patch? It's because they wanted to get it out before the deadline because extending the project further would mean they would have to pay people more.
Guys, take a look at these API references:
http://www.cplusplus.com/reference/stl/
https://docs.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-d3d12createdevice
https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html
https://docs.unrealengine.com/en-US/API/Runtime/Engine/GameFramework/AActor/index.html
Notice something? They're all in English. Most programming languages are English based. If Japanese developers can code, they know English or they wouldn't be able to do their jobs.
I've had to work with international developers before. I have yet to meet one who couldn't navigate themselves around an English speaking country. Lack of Japanese translations isn't a significant hurdle.
I think there might be an even better way. As I have mentioned before, when you have a budget and a deadline you would much rather use a netcode framework that's tested and ready to go. Since most off the shelf frameworks are lockstep based, it's what devs are going to use.
As I was typing this post, I thought "It would be great if someone created GGPO based frameworks for Unity and Unreal" and then I realized since the source is literally sitting on GitHub, it's entirely possible. If I had an ounce of spare time (which I spend on only the most important tasks), I would start a branch of GGPO that uses cross platform APIs so you can run it on Mac/iOS/Android/Linux.
Unity and Unreal frameworks made available on GitHub would cut the cost of implementation way down. It would be great if there was GGPO foundation similar to the Blender Foundation so people can support GGPO based frameworks. Part of me wants to add "Start GGPO foundation" as a ticket on the GitHub.
Don't know if someone already replied to this. While what you say is true, the best way to implement GGPO/rollback is to think about it as a priority and then build the rest of the game on top (Like they did with Killer Instinct on the x1). There was this very interesting interview Maximillian did with Keith where they go very in depth about it.
So yeah, it could be added to GG but for best results it must be considered from the very beginning, hopefully they are doing that for GG and KOF XV :D
So... After doing a bit of research, I've realized that GGPO implementation is not exactly the walk in the park that many think of, and I'll fully admit and apologize for my ignorance by thinking that Japanese translations would solve all problems.
Yeah, you definitely should build your whole game from the ground up around GGPO in order for everything to work as it should like the Killer Instinct folks did, so HUGE kudos to the MKX team for going as far as they did to add it after the game being released, it must have been a nightmare and a half to get that done.
For a simpler way to understand, you all should give a look at the sequence of Tweets from user "mauve":
And if you're feeling especially adventurous, here's a more in-depth explanation:
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking.html
I would love if Mike Z (lead developer of Skullgirls) could comment on how it was working on GGPO and how it differs from creating a delay based system, but the poor bastard is drowning in work right now with the release of Indivisible, so I would never get the courage to bother him on Twitter at this moment, dude has enough on his plate for the time being.
MistaTwo, since you're at arms reach, would you mind to sharing a few of your thoughts when it comes to the programming side of things? Might as well turn this into an education thread :P
Yeah, you definitely should build your whole game from the ground up around GGPO in order for everything to work as it should like the Killer Instinct folks did, so HUGE kudos to the MKX team for going as far as they did to add it after the game being released, it must have been a nightmare and a half to get that done.
For a simpler way to understand, you all should give a look at the sequence of Tweets from user "mauve":
And if you're feeling especially adventurous, here's a more in-depth explanation:
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking.html
I would love if Mike Z (lead developer of Skullgirls) could comment on how it was working on GGPO and how it differs from creating a delay based system, but the poor bastard is drowning in work right now with the release of Indivisible, so I would never get the courage to bother him on Twitter at this moment, dude has enough on his plate for the time being.
MistaTwo, since you're at arms reach, would you mind to sharing a few of your thoughts when it comes to the programming side of things? Might as well turn this into an education thread :P
I can understand the emotional response, yes, but the points you bring up are not so small you can just wave them away with "Yeah we know BUT..."
Those points are the reality and why things like the above happened. Those projects aren't even handled by the same department inside the company.
Sorry, I am not a programmer. I work in the game designer/planner department in the studio.