Physics over a networks doesn't sound like it would be too hard if you just had each client constantly sending each other the position and rotation and let them handle their own physics individually.
I'm sure there's some flaw to that, but I don't see it yet.
Models look really nice and the concept sounds good too. Good luck..
Major sci-fi racing game project
-
monkeycracks
- Posts: 1029
- Joined: Thu Apr 06, 2006 12:45 am
- Location: Tennesee, USA
- Contact:
I never actually did physics over network myself so far. But I already was part of two projects where it was done. So I can tell a little about the problems which you have in such cases.
First of all doing physics is always getting more difficult if you have to do hard position updates. This is even a problem in singleplayer when you for example move the player object against some physic controlled boxes. Because the playerobject will act like an infinite power unless you handle that with some care. I'm sure you all have seen those physic objects which suddenly fly through the whole level when kicked :)
It gets a little more difficult when you start sending stuff over the network.
First reason your solution would not work is because you have to care about the lag. Each player can kick a box at his computer at the same time. But each other computer will only know about the other players kicking that box some milliseconds later.
So now you could say for example: Let the server handle the physics and he will give position updates. This will actually work. And basically it even is what you will do. The server is always the instance which has to be right. But now you have to fix the next problem. Stuff does no longer react immediately when you do something because of the lag.
To solve that you have once again to calculate it immediately on the client first. At least so much that stuff 'seems' to be correct. And handle boxes which are kicked by other players at the same time later on with some interpolation.
It will still have some problems - and you have to think in each case if it's better to calculate it on the server or on the client - or on both and when you will need to do some interpolation stuff.
Next problem is that even if you calculate the same physic at the the same time on different computers it's not trivial to make sure they do the same stuff. Computers seem sometimes surprisingly non-deterministic. As example we had some problems when we found out that even identical codelines with identical parameters can deliver different result depending on the compiler flags because a floating point optimization did use two different sizes internally in the two runs. And even the smallest difference in numbers an accumulate very fast in physics.
First of all doing physics is always getting more difficult if you have to do hard position updates. This is even a problem in singleplayer when you for example move the player object against some physic controlled boxes. Because the playerobject will act like an infinite power unless you handle that with some care. I'm sure you all have seen those physic objects which suddenly fly through the whole level when kicked :)
It gets a little more difficult when you start sending stuff over the network.
First reason your solution would not work is because you have to care about the lag. Each player can kick a box at his computer at the same time. But each other computer will only know about the other players kicking that box some milliseconds later.
So now you could say for example: Let the server handle the physics and he will give position updates. This will actually work. And basically it even is what you will do. The server is always the instance which has to be right. But now you have to fix the next problem. Stuff does no longer react immediately when you do something because of the lag.
To solve that you have once again to calculate it immediately on the client first. At least so much that stuff 'seems' to be correct. And handle boxes which are kicked by other players at the same time later on with some interpolation.
It will still have some problems - and you have to think in each case if it's better to calculate it on the server or on the client - or on both and when you will need to do some interpolation stuff.
Next problem is that even if you calculate the same physic at the the same time on different computers it's not trivial to make sure they do the same stuff. Computers seem sometimes surprisingly non-deterministic. As example we had some problems when we found out that even identical codelines with identical parameters can deliver different result depending on the compiler flags because a floating point optimization did use two different sizes internally in the two runs. And even the smallest difference in numbers an accumulate very fast in physics.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
-
monkeycracks
- Posts: 1029
- Joined: Thu Apr 06, 2006 12:45 am
- Location: Tennesee, USA
- Contact:
This all depends entirely on the level of physics planned.
As for non deterministic simulations, this can actually come down to the actual code of the physics solver, some such as ode; shoot several "collision" rays per object, then choose one by random to apply the impulse. This is why ode's stacked blocks never fall down the same way each time. even if there are multiple collisions per "cycle" of the algorithm some engines take 1 or two collisions by random and the forces from the other non used collisions are applied the next cycle so even on the same cpu we have the lag problem.
as for hitting the same box problem, well thats a fact of life lag will always play a part. Just make sure the kick isnt so powerful that the box will fly a consideralble distance before the other players kick cancels that movement, Unless we are simulating super heros, boxes getting kicked will travle at say <1m/s with lag being in 300-100's of miliseconds max you would expect a max error of 30 cm.
The flying box problem also originates from objects becommeing embeded with each other resulting in lots of collisions in a short space of time, combined whith hack techniques which apply extra forces to get the objects out of this state, a non network problem.
Things should be going at low velocities for lag not to be noticable and this means setting realistic forces on realitic masses, even bullets at supersonic speeds will not push a hit object much since the mass of a bullet is very small and the mass of the thing its hitting should be relatively large (we arent gonna simulate bullets hitting
each other especially in a net game).
As for non deterministic simulations, this can actually come down to the actual code of the physics solver, some such as ode; shoot several "collision" rays per object, then choose one by random to apply the impulse. This is why ode's stacked blocks never fall down the same way each time. even if there are multiple collisions per "cycle" of the algorithm some engines take 1 or two collisions by random and the forces from the other non used collisions are applied the next cycle so even on the same cpu we have the lag problem.
as for hitting the same box problem, well thats a fact of life lag will always play a part. Just make sure the kick isnt so powerful that the box will fly a consideralble distance before the other players kick cancels that movement, Unless we are simulating super heros, boxes getting kicked will travle at say <1m/s with lag being in 300-100's of miliseconds max you would expect a max error of 30 cm.
The flying box problem also originates from objects becommeing embeded with each other resulting in lots of collisions in a short space of time, combined whith hack techniques which apply extra forces to get the objects out of this state, a non network problem.
Things should be going at low velocities for lag not to be noticable and this means setting realistic forces on realitic masses, even bullets at supersonic speeds will not push a hit object much since the mass of a bullet is very small and the mass of the thing its hitting should be relatively large (we arent gonna simulate bullets hitting
each other especially in a net game)."Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
Yeah thats what I did in the irrNet examples, but theres always the problem in physics if somebody touchs someone else, what will happen and how will it be handled?omaremad wrote:Im thinking of clients sending each other velocities over net then sending a position every now and then to correct errors.
Well the colision detection rays are usually proportional to the velocity of the object, so all you do is send the players ship properties but calculate the physics of other players client side based on the properties they sent.
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
multiplayer is just as easy as one player games
at least thats what i think my first finished game was a multiplayer game it took approximately 2 weaks to finish.
to do physics over net work would not be hat hard to do ether just
send the forces that starts a movement and then let all the computers calculate the same result
but only send the info about the objects that are on the screen or just a bit out side it
at least thats what i think my first finished game was a multiplayer game it took approximately 2 weaks to finish.
to do physics over net work would not be hat hard to do ether just
send the forces that starts a movement and then let all the computers calculate the same result
but only send the info about the objects that are on the screen or just a bit out side it
With a fancy physics engine its not that simple. When you force something 100 milliseconds late it could change its path considerably, especially if it bounces around a lot.kompromis wrote: to do physics over net work would not be hat hard to do ether just
send the forces that starts a movement and then let all the computers calculate the same result
You need to have a server do the calculation and clients simply get position updates and attempt to predict where the object will be.
Then you get lag which is even of a worse type! Input lag, which would make the players own inputs seem laggy even if their frame rate is high. Only critical physics should be server side thing like ray casting for bullets and such, other than that who cares if the box moved a bit more than it should if your inputs translate immediatly to on screen events.
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
After getting an influx of coders who dont have much of anidea on coding or game design, i designed this list which will be a dam to stop the flood.
This will also hopefully get more experinced coders interested since they know they will be working with like minded people.
The criteria required to join are:
Required:
-A good understanding of basic game components.
-Ability to translate problems or challenges to alogrithms.
-Very basic understand of how 3D hardware acclerated graphics work.
.Knowldge of polygons, vertices,normals , texture coordinates.
.understanding of costs involved when rendering primitives.
-Good knowledge of c and c++, this means both a good understanding and practical skills in:
.pointers
.classes
.simple object oriented design
Basic math skills:
-understanding of 3D coordinate systems.
-Vectors, and simple math relating to them.
.basic operations (+,-,*,/)
.normlization
.dot and cross products
.applications of vectors in games (forces, ray casts, etc..)
-Trigonomtery (sine cosine and tangent is suffcient)
.practical applications of trig.
-Have at least completed 1 project with the irrlicht engine, this project may range from a scenenode,demo, or game.
-Knowledge of when and how to use common techniques
.Particles
.Billboards
.Gui
-Can lead their own devlopment.
.maintain old code they have written
.communicate progress
.request and provide help when needed
.activly be involved in the creation of gameplay mechanics (thinking,prototype and implementation stages)
Desirable:
-Knowledge of basic physics
.linear equations of motion
.concepts of forces and momentumn.
-Have completed a small game (doesnt matter how small).
-Specialist in the field of programming that you will do.
-Can implent a super feature they always wanted to include in a game Very Happy
-Expertise wih other api's/ programming concepts.
This will also hopefully get more experinced coders interested since they know they will be working with like minded people.
The criteria required to join are:
Required:
-A good understanding of basic game components.
-Ability to translate problems or challenges to alogrithms.
-Very basic understand of how 3D hardware acclerated graphics work.
.Knowldge of polygons, vertices,normals , texture coordinates.
.understanding of costs involved when rendering primitives.
-Good knowledge of c and c++, this means both a good understanding and practical skills in:
.pointers
.classes
.simple object oriented design
Basic math skills:
-understanding of 3D coordinate systems.
-Vectors, and simple math relating to them.
.basic operations (+,-,*,/)
.normlization
.dot and cross products
.applications of vectors in games (forces, ray casts, etc..)
-Trigonomtery (sine cosine and tangent is suffcient)
.practical applications of trig.
-Have at least completed 1 project with the irrlicht engine, this project may range from a scenenode,demo, or game.
-Knowledge of when and how to use common techniques
.Particles
.Billboards
.Gui
-Can lead their own devlopment.
.maintain old code they have written
.communicate progress
.request and provide help when needed
.activly be involved in the creation of gameplay mechanics (thinking,prototype and implementation stages)
Desirable:
-Knowledge of basic physics
.linear equations of motion
.concepts of forces and momentumn.
-Have completed a small game (doesnt matter how small).
-Specialist in the field of programming that you will do.
-Can implent a super feature they always wanted to include in a game Very Happy
-Expertise wih other api's/ programming concepts.
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
You have movement prediction to guess where they will be. Then lag shouldn't be very noticable, unless you have a really high ping. This is how games like CS work. They don't sit and wait for an update, they predict the character's movements. Obviously the player says I am moving here, his computer lets him move there, and the server says "you can't go there" so he gets kicked back. Same for the other players, if the last message was 'player 13 is moving forward' the computer will guess they are continuing to move forward until the next message.omaremad wrote:Then you get lag which is even of a worse type! Input lag, which would make the players own inputs seem laggy even if their frame rate is high. Only critical physics should be server side thing like ray casting for bullets and such, other than that who cares if the box moved a bit more than it should if your inputs translate immediatly to on screen events.
If you have 30 computers that ALL have to P2P report their position and velocity to 29 other computers you will have FAR more lag.
Thats why a server is necessary.
-
lostclimategames
- Posts: 331
- Joined: Sat Sep 02, 2006 4:11 am
- Location: Michigan
- Contact:
-
raven_coda
- Posts: 89
- Joined: Thu Aug 17, 2006 8:11 pm
- Location: Salt Lake City, UT, USA
- Contact:
Networking physics is a big problem in gaming. One article I read calls it the “Holy Grail” of gaming but for this game you have some things working to your advantage. I'd send velocity updates as well as acceleration and omega updates (rotational velocity). Take real advantage of client side prediction. Your using hovercrafts which, unlike Counter Strike players don't make quick sudden changes in direction and velocity. You can predict where a hovercraft will be in the near future with great accuracy. You'll want however to design it as a server client relationship with one server being the last word on a players position. Just keep in mind networking while you write you code and you fair alright. Remember, the net is designed for sending large amounts of data, so having large but fewer packets is better then smaller packets more often.
Good Luck, and let's us all know how fair you guys are getting.
Good Luck, and let's us all know how fair you guys are getting.
Definition of an Upgrade: Take old bugs out, put new ones in.
-
Dread Knight
- Posts: 12
- Joined: Tue Jun 19, 2007 4:17 am
- Location: Macedonia
- Contact:
As for the servers discussion, i have arranged for a few dedicated servers scattered around so that players from around the world can choose the closest one to them.
As far as the progress, i there is a small demo being prepared with a single track and a single hovercraft, just to give people a rough idea on how the game will look like. And yes, we are still looking for programmers.
As far as the progress, i there is a small demo being prepared with a single track and a single hovercraft, just to give people a rough idea on how the game will look like. And yes, we are still looking for programmers.
I was born with enough middle fingers, I dont need to choose a side!