I have no experience with unity and this is my first post here. I plan to build a sequal of my game in unity and have a technical hurtle i need some help with.
There is a game out there called iRacing that successfully allows 40+ people to race simultanously on the same track and it somehow stays accurate.
My game will be one-on-one with others only spectating, however, i need both drivers and all audience members to see the same thing. It is a drag racing game where in real racing players may hit the breaks or speed up at the finish line (i know this might not make sense but it is bracket racing and it happens in real life). The question is, if your MAIN goal is to make it so that the drivers of both cars see their car and the other car in the same place on screen, how would you do this?
Server side physics where the clients are only doing predictions and the server is authoritative? Or is there another way?
You cannot do what you ask, it is physically impossible. You can use predictive techniques for moving objects to compensate for lag (all networks have an inherent lag of some value) but if the client changes state then there will be lag between the client action and what an observer receives. On current generation mobile networks that lag will be measured in hundreds of milliseconds at the very least.
Evidence suggests you have much to learn about networking in general as the example link given in the post previous to this one has very little to do specifically with FPS games.
It’s possible, very much so if you use a step physics solution, ie roll your own, so that the master server just gathers inputs only, and pushes the same sim forwards on every device then waits again. Clients will predict for visual response and lerp the best guess to the actual sim. This would be ok if the vehicles aren’t super twitch responsive, ie there’s decent amount of slide to it.
Come to think of it, this is what RTS games do I guess.
The beauty of this design is that you don’t worry much if there’s lots of cars ie 64 or so would probably work since you’re just doing inputs. As it is a driving game, that lag you’d get waiting for inputs would probably be almost acceptable I can’t imagine it working any other way for a driving game with that many cars.
The thing with the step physics engine is, every computer agrees who finished first. The downside is it’s only as fast as your laggiest player
You’d probably need really accurate numbers that are the same regardless of phone used too.
Our next game will be featuring co-op play over wifi and mobile with physics. Co-op is OK: if it breaks a little, or things aren’t so perfect, nobody is going to cry since its just you and him. And cheating is fine too. Just play with someone else. But this? I would be scared
also, why do you have to wait for inputs? Why not just go off of the last input you got until you get more input… All your talking about here is throttle position, steering position and gear changes…
Lock-step physics won’t completely solve your problem. Yes, it is semi-possible to do it with predictive techniques. It is possible to make every player see almost the exact same thing**. It is not possible to do it where every player sees it at the exact same moment unless you also punish all players equally. Actually, even then they won’t see it at the exact same moment because the lag time to me may not be the lag time to you. So even though I sent my “hit the brakes” command to the server, and the server responds to everyone “this player hit the brakes, update accordingly” and we all get the command “hit the brakes” we don’t all receive it at the same time. The issue with this technique is that the player who “hit their brakes” ends up with squishy, unresponsive controls because they must wait for the server to acknowledge what they did before their client is permitted to do it. You can mitigate this issue by having the client execute the action and then wait for a response to verify that the action was accepted and correct if they were not allowed to do that, but then they don’t see the same thing as everyone else.
**Every player won’t see the exact same thing because predictive techniques are just that, predictive. My client predicts that you will be at position X based on your physics, even though my physics model is in lock-step with yours, but there is a delay in receiving commands, so I have one of two options, predict where you will be but then show snap-back when I get a correction from the server or stall my client until I get an update that I can use.
43 cars or 430 cars on a track is not impossible, it’s not trivial, but it is eminently doable. Getting everyone in sync perfectly is not possible. Getting everyone across the finish line within a second or two (the lag of your slowest player) and then tallying up who actually won is easy to do. Stopping arguments because you think you beat the player who had five seconds of network lag is not.
You can mitigate some of these lag issues by placing players in closer physical proximity, changing your network topology, and other known tricks but in a cellular network some of these tricks just plain don’t work unfortunately and are much more susceptible to network congestion than most regular internet based games.
also, what we have is this… people reacting to what the car in the other lane is doing… what the other car is doing won’t affect the physics of my car, but i may hit the brakes based on where the ohter car is in relation to mine… Basically these guys do this because they want to win by just a hair, not by alot… so if they think they are too far ahead, they will hit the brakes to close the gap between the cars…
For your particular style of game, I am not sure the built-in physics system is what you actually want. I would need to understand the problem domain a little more before I could accurately make that judgement call but from what you have said the game entails, I’d shy away from Unity physics for the most part. Unity has built-in networking, and that might be a good start if you are a robust programmer. There are various network packages, such as Photon, and others, that also offer very easy setup. I assume that your cars won’t physically interact with each other, you are racing against the clock effectively, even though your game will probably show two vehicles side by side, so ease of setup and how much tweaking the network solution lets you have is probably the most important aspect of any solution you choose.
Based on your last post I would say your biggest challenge will be reducing the hair’s breadth lag of just a few hundred milliseconds between players. You might be able to fix part of that with some tricks by doing a quick fade to black once the player crosses the finish line, then fading back up to show the “photo finish” of two cars at the finish line which will determine who actually won.
well, í think having server side step physics solved the finishline issue, it’s the 200 feet BEFORE the finishline that poses the problem… they need to see their car in relation to the other car accuratly… so they know if they need to hit the brakes or not… Inbracket racing it is called “racing the stripe”… and my game has live Side-By-Side racing but i do client side physics and that makes racing the stripe impossible… so in my next rendition, i want to fix that… if i can…
I think that 200ft is going to be the hardest part of the problem. You can probably get it working for most cases, if a lag spike doesn’t occur, but nailing the problem in all cases is going to suck up a lot of the R&D time.
I can’t imagine it working any other way for a driving game with that many cars.