Physics based multiplayer (networked game)
BlitzMax Forums/BlitzMax Programming/Physics based multiplayer (networked game)
| ||
| well I planned to make my game Flood an online multiplayer game but I am not exactly sure if it is possible or has ever been done. For one, I have never seen a realtime (not turn based) physics game online. Not even with simple physics... so my question is how would I go about transferring the position and velocities of 2500 active fluid particles every couple of frames and still make it look realistic with no jerking or lag when players are interacting with eachother and the water. I have thought of a few ok ideas... 1. send all of the keypresses to the server and it will do the physics then send all positions and velocities back while the game tweens. 2. Have each game run a normal physics simulation and send particle/player positions and velocities to the server... the server will then send the particle positions and velocities averaged to the players just wondering what yall think about this.. and if its even possible. |
| ||
| I don't think you can send position of all the particles. Way too much data. Not just too much to send, but also too much to process. You might be able to get away with each client running the simulation, and only send player data and particle data that is affected by the player. |
| ||
| You might be able to get away with each client running the simulation, and only send player data and particle data that is affected by the player. thats when things, to underexagerate it, get complicated. say a player touches a particle one frame and this 'touch' is sent to the server. Then within a couple of frames the server will tell both clients this particle was touched at this frame... now what.. the physics simulation has already gone ahead a few frames and it would be rediculous to go back in time and process the sim for a few frames again with that one particle changed what does the engine do? well lets say it just ignores it and moves the particle forward, multiplying the timestep by however many frames it has been since it was collided with. well by this time, on the player's coputer that touched the particle, the particle would be interacting with every particle around it, completely throwing off the simulation... pretty soon the butterfly effect would have every client with a completely different game :p and sending all of the particle positions between every player in order to hopefully balance out the simulation wouldnt work because they would all lag for about a minute while the clients all caught up... |
| ||
| What about if you try something like a .. symbolic sending of the particles.. kinda: - take the particles in packs of 8 - 128 - u got a collection of "standard" position configurations for the particles, lets say, about 65536 (a Short). - when sending information, u wont send each part.s position, but just figure out which standard configuration figures best for this "pack" atm, and send over the symblic data, plus .. the current w&h the pack is spread over - all clients take the received "standard configuration" as a movement keyframe for the particles This idea sprang to my mind. Its 5 am here in ger, no idea whether this might be realistic. Now, you would need an ingenous algorithm to check out the standard patterns, but ... |
| ||
| I've never put it into practice but it might work along the lines of; Server collects all player positions at frame[0], every client is sync'd (your particles are deterministic right?, so all physics calcs are done on the clients). For frames[1] to [9] you continue running the sim on each client based on the data from frame[0] At frame[10] you re-sync from the server, in your case re-running the sim from frame[0] to [10] interpolating the position of each player between their frame[0] and frame[10] positions. The server should also be at least one step ahead of the clients, where a client tells server 'at frame[14] I want to be at [x,y,r]', another client at the same time might have said 'at frame[18] I want to be..', Then the server can provide all clients with all positions at frame[10] with no lag. Insert your own numbers :) Remember you've got 1000's of particles running at many 100's of frames per second, so limit the game to 40fps or so and you can use all the extra processing power to re-step through the sim behind the scenes. |
| ||
| In all likelihood this would be hard to achieve given the number of particles and complexity of the interactions... that being said... The server would have to control the simulation there is no doubt there...otherwise you have fuzzy logic going on. Basically I think you would have to send the players a "snapshot" of all the particles at a game tick including positions, forces, velocities, connections, etc...(so long as you don't exceed 65540 (or so) bytes (after header). When clients (players) receive them, the positions of the vertlets would be calculated from that tick to the current one (past to now). The engine would have to play out the future as well as it can predict and then update again when it receives the next packet from the server. At least the vertlet static data only needs to be sent once :) The player actions (per tick) would be sent to the server, that would then influence the game but with constraints set to minimize game tampering. Those influences would then be included in the next game state packet. thoughts... If you could include the "fluid" nature of network play (force with influence) into the physics simulation itself you might have something really interesting. |
| ||
| ok thanks for the ideas... I think after reading over the ideas, I have come up with one of my own that should work perfectly. ok each client is lagged 5 frames or so. (depending on how long it takes to get player info across) So after 5 starter black frames the physics sim starts at the same time as the info was sent for the players position and rotation 0 to 5 frames ago. This would lag all players by approximately 5 to 10 frames (not too much right?) well the server could then send the info about all of the ships positions and rotations to the clients and at what frame they would be there... the client would then be able to predict where the player would be if there is major lag. All of the clients however would have to use this prediction though so the client that sent the info about there ship wouldnt get a different simulation. hmmm Im still thinkin this out... ill post back when I do |
| ||
| You gotta make sure your physics are deterministic - that they will always give the same results having started at the same position on several machines. Then you have to run the simulation with fixed rate logic. Then you have to get the server to run the simulation also and send little updates on player input to each machine so that it can a) predict the position of particles, and b) update them to their new positions using tweening, etc. |
| ||
| yes it is deterministic IH. I thought I had said that but I guess not :p |
| ||
| why you need to be doing this: "transferring the position and velocities of 2500 active fluid particles"? |
| ||
| @ImaginaryHuman that's what Multiwinia developers introversion did here |
| ||
| Article on networked physics by Glenn Fiedler: http://gafferongames.com/game-physics/networked-physics/ |
| ||
| thanks muttley, that was very helpful but I am afraid my game is an extreme of his stacked boxes example. There is simply no known method to update and keep all clients in sync with stacked boxes (in this case water particles) that every player can interact with.. :( and in the comments, someone mentioned the physics could be different on different processors no matter how fool proof you tried to make your code... maybe I could resort to using string maths for all of my physics .... NOT! lol |
   |