Jan Ciger kirjoitti: > On the other hand, if you are building a decentralized system (no > central server), this would be the way to go. However, such system would > be rather inefficient and complex due to the need to vote on almost > everything and all the data replication issues. With today's costs of >
i think i agree. in the arcade thing we are doing now, it is also otherwise ok to just do bounding box / distance checks / sphere scenequeries etc. for damage, so probably can be well done in the server. but am happy that now when making the basic gameplay building blocks, don't have to worry about that yet too much .. easier to come up with the protocol when it is clear what actually needs to be communicated. btw http://www.gaffer.org/game-physics/networked-physics/ seems to be an interesting treatment on the topic: """ *Disadvantages of client side prediction* Client side prediction seems to good to be true. With one simple trick we can eliminate latency when the client character moves. But at what cost? The answer is that whenever two physics simulations on the server interact then snapping will occur on the clients. What happened? In effect, the client predicted the physics ahead using its own approximation of the world but ended up at an entirely different position from the physics on the server. Snap. In our simple run and jump fps, this situation would occur if one player runs into another, tries to stand on another player’s head or gets knocked back by an explosion. The bottom line is that any change to the physics of a character that occurs on the server that is not directly related to a change in input sent from its owner client will cause snapping. In truth there is no way to avoid this. This is simply the cost of using client side prediction. This leads me to an interesting point. The evolution of networked physics games is from first person shooters where characters run around in a static world while shooting each other, towards a dynamic world where players interact with the surroundings and each other. Given this trend I am willing to make the following bold prediction - client side prediction will soon be obsolete. I believe that the next generation of networked games will not use client side prediction because the snapping it would cause will be unacceptable. This generation of games will trade latency for an increased depth of physics interaction. """ will be interesting to see what happens with this game we're making, we might e.g. get such explosion effects that move the ships etc. then again this is now in a static environment with fast movement so it may still make sense to detect wall hits (think terrain, level geom) in the client too. > Jan > ~Toni _______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
