Online coop: keeping fixed timestep shmups in sync?

[ciox]

This feature gets requested a lot nowadays but there seems to be a serious stumbling block in the way. Basically games with fixed timestep will desync non-stop because of slowdown (however small) being different on each machine. Here's what solutions I thought of:

1. The obvious one: sync everything every frame from server to client, the client waits to receive everything from the server and does not spawn enemies or bullets at all, I don't see this working out because of ping and bandwidth reasons, I think it will take a lot of frames to get the entire game state from one player to the other

2. Make the game run in variable time step just for online multiplayer, making it work like a normal online multiplayer game, this kinda makes you rewrite the whole game though since counting frames does not cut it for timing anything anymore and probably adds a ton of overhead unless you use a different exe for online coop (function pointers can help here maybe if you can use them?). Would fix the issue but at what a grotesque cost, what's worse is I have a slight suspicion this is the professional solution.

3. This is a lighter version of 1, I thought of constantly comparing the FPS/deltatime on each machine and adding the difference to a variable, once it gets high enough forcibly re-sync by copying all entities from the server to the client, this will be very jerky though whenever it happens and there's no guarantee that it won't trigger frequently and annoy players, not to mention it will make the game very jerky for a long time if a player has massive slowdown since you're re-syncing constantly.

There's some examples of online coop working acceptably, like Ikaruga on 360 and Gundeadligne on Steam, but I wasn't able to figure out how it was done, like whether it has anything to do with these ideas or not.

[n0rtygames]

Look at the RTS lockstep model.

Starcraft (and SC2) is a game that requires the top level players to play it at rates of 300+ actions per minute in control of hundreds of units at once, each one able to be controlled and moving individually. That is essentially 5 things a second. When the connection completely deteriorates - the game pops up a "waiting for others" dialog.

- You accept that there will be X number of frames delay
- You accept that there is nothing you can do about this
- You accept that there will be lag.
- You accept that this is beyond your control and you can not personally fix this.

The FPS way (aka authorative client/server)
All games that have multiplayer have some sort of code that helps with the illusion of seamless low latency gaming. FPS games have been doing it with a mix of interpolation/extrapolation and rollbacks for years. You don't notice it anymore because the days of being able to enter a console command in a game and set interp to 0 are completely gone, however if you were to do this on any modern game - what you'd see would be a slideshow.

The games basically use interpolation to smooth movements, what you see on screen is actually not an accurate representation of what's happening on the authorative server. It's just mostly okay.. Your client is essentially just a way of conveying information received from the server, to the player. It is your renderer, it just obeys commands that the server gives it.

When you shoot a bullet in an FPS, you're actually requesting that the server allows you to shoot a bullet. You never tell the server "Yo, I want to shoot a bullet at (32,25,91) at rotation (180,92,207)" - well, you might.. but the server will probably ignore your current position and only care about your rotation, then it will create your bullet and process its behaviour. If it then hits another player - the server broadcasts to all clients that this player has been hit. It also tracks their health and broadcasts when they should be dead or not. But there's a lot of shit this does - it's not suitable for you.. but it's kind of important to understand the concept of sending 'requests' to another machine in terms of wanting to perform in game actions

Back to the RTS way..
Read this - you might find it insightful

http://www.gamasutra.com/view/feature/3094/

Just remember that network coding does mean accepting that conditions will not be perfect and yes - it does add a lot of development time and things to consider, when you're doing it properly.

[Kaleidogames]

I have been thinking *almost everyday* how to implement online multiplayer for 'Vortex Attack'. But there will be some lag , and that, for me, would kill the whole experience, specially when players have to be precise between bullets.
But also technically :
- I would have to implement a some kind of random number generator that i already have programmed.
- Create some lag checker and compensator for computers that might have slow connection or poor CPU/GPU
- Create some interpolation system for all objects in screen

But I don't like the idea of playing an arcade online, I think the old feeling of playing with a friend next by is better than the modern online experience.

Nevertheless if enough people ask me to create an online mode I might do to make them happy.

By the way, the game which has already local multiplayers with 3 ships at once and Is a lot of fun.

[S20-TBL]

But I don't like the idea of playing an arcade online, I think the old feeling of playing with a friend next by is better than the modern online experience.

Quite true, in more ways than one.

For one, concerning games with some form of real time communication, you don't have to deal with the G.I.F.T. which is one of the biggest factors killing online experiences (just ask any former WoW player--heck, just ask any former LoL player, or DkS player, or...).

Also, the biggest draw of the arcade experience is social and tactile: you have friends coming together to play games in person. That's why the FGC is a major draw for people who like to congregate and play fighting games. It's basically a party scene.

Also this:

But also technically :
- I would have to implement a some kind of random number generator that i already have programmed.
- Create some lag checker and compensator for computers that might have slow connection or poor CPU/GPU
- Create some interpolation system for all objects in screen

I have to second n0rty. It's actually good you're considering all these factors early on. A major question is, will you have the time and manpower to invest in having to set up those extra resources and parameters?

[qmish]

But I don't like the idea of playing an arcade online, I think the old feeling of playing with a friend next by is better than the modern online experience.

You become older, apply for a job, your friends do the same, your workflows are different or even they move to another city or smth... it's complicated. And it's often u dont have anymore people to play these exact games in local while u have old friends in online sometimes

[Squire Grooktook]

^^^Qmish is absolutely correct.

Plus, you have no idea how much these kind of things matter to the more casual peeps. I was amazed by how interested my non-shmupping/arcade/hardcore friends got in Metal Slug just by playing a few rounds of it online. The appeal of online play should not be underestimated, IMO it's the factor that single-handedly made fighting games commercially viable to a mass market again. The vast majority of players don't have friends who happen to also be into such a genre, don't have any arcades nearby, and don't want to drive to tournaments just to play against humans.

I'd be willing to bet 1 million internet bucks that Blazblue, Marvel Vs Capcom 3, Skullgirls, Xrd, etc. wouldn't have been made (or just wouldn't have sold) if online play wasn't viable for them. It's also the reason why nobody gives a flying fuck about doujin fighting games, even though some of them are quite interesting. You just can't play them unless you also have a close IRL friend who's into doujin stuff (HA HA HA).

Sadly, it seems online play will always be fundamentally flawed till we have flying cars and such. GGPO style rollback netcode seems to work close enough though, as the shmups I've played on Fightcade played pretty smooth.

[qmish]

And i forgot to mention when people marry and have children... though that remeinds me how users say that they move to portable consoles because of that

[Xyga]

I remember online coop shmupping with kaillera-equipped mame builds, that was about a decade ago.
Awful delay and therefore impossible serious play, but the fun was there for some time at least.
Only a much, MUCH faster solution would allow decent coop and therefore continued fun, I think GGPO came shortly after and did a bit better but I never went to it because my ISP at the time was beyond hope anyway (yay living countryside).
Never tried Fightcade...

[ciox]

You know, I always intended to come back to this thread with some results, using Nortygames suggestion for 'deterministic lockstep' multiplayer, I thought it would be a cakewalk since I already had working input replays that didn't desync, but with my average coding skills it took forever to implement and never worked right, so I forgot about it until this got bumped.

I got most of the functionality in, where two players stay in sync just by sending their inputs to each other, and some speed optimizations like using UDP instead of TCP/IP for higher speed and dealing with lost packets by always sending all inputs that haven't been confirmed as received, and small stuff like sending an input when it starts/stops being pressed instead of constantly. (based on this http://gafferongames.com/networked-phys ... -lockstep/ )
Where I choked was the "playback delay buffer" that introduces just enough input lag to keep things smooth, I never got that working and the input lag either snowballed until it made controls unusable or it didn't do anything, so without input lag the game runs choppily if your ping is higher than 16ms, I remember trying to make it less dynamic and just locked at 3 frames of input lag so it would run well if you are at 48ms or less, but even then you need some proper code to recover after lag spikes and manage the input lag properly.
I'm probably going to make a few more attempts at this feature at some point since it's theoretically close to being done but I'm pretty burned out on it.

Sadly, it seems online play will always be fundamentally flawed till we have flying cars and such. GGPO style rollback netcode seems to work close enough though, as the shmups I've played on Fightcade played pretty smooth.

Honestly that's pretty interesting that shmups had good performance on Fightcade, I figured saving a ton of bullets every frame to have rollback states would create performance issues, still pretty complex to implement I'm sure.

[Squire Grooktook]

Sadly, it seems online play will always be fundamentally flawed till we have flying cars and such. GGPO style rollback netcode seems to work close enough though, as the shmups I've played on Fightcade played pretty smooth.

Honestly that's pretty interesting that shmups had good performance on Fightcade, I figured saving a ton of bullets every frame to have rollback states would create performance issues, still pretty complex to implement I'm sure.

Yes. I was really surprised by how playable Mars Matrix felt on it. I seem to recall it was choppy at some points, but it felt like the kind of thing that I wouldn't be against putting some time in with a partner for a 2cc. I should really put more time into that to see if it was as "ok" as my memory made it out to be.

[Zaarock]

I've had fairly positive experience with shmups on fightcade/GGPO. A lot of people play Twinkle Star Sprites for example so it's definitely playable. I remember Ikaruga XBLA having significant input lag. For rollback, wouldn't there be less 'conflicts' between players in a shmup than a fighting game?

Strania XBLA version by G.Rev has the best netplay I've seen for a shmup. It doesn't implement input delay but keeps the players in sync somehow otherwise (FPS model norty mentioned or rollback?) at high pings it could desync but for the most part is very smooth. Since it had the possibility of desync maybe it prioritized not having input lag over everything else? In that case it could have just felt good instead of being really accurate (though still fun for survival coop)