Does anyone have experience sending physics information across the network successfully?
In the ideal situation I would like a server to calculate the physics (or at least all the collisions, including with the ground) and send position/transform/collision information out to the clients. I know in small cases that this wouldn’t be too taxing, but I would like it to be for an rts.
If the above method wouldn’t work, would it be better to have all of the computers calc the physics on their machines and then occasionally synchronize with the server?
This is the best manner to impl. networking by sending new primitive values and no binaries like pictures etc.
I had made a game with the networking feature, the game was a Pong-like. Users could open a server-host instance or connect to a server-host instance over the usual IP network. We sent the status at every ticktime, this was the only serialized binary among the usual positioning/movements values. ;D.
I think part of that might be so that if a host leaves, things can be picked up gracefully and the game isn’t lost, but I’m not sure. I’ll have to do some more research on rts networking before I decide my model.
the host is not the same as the server. rts games are p2p because servers would be either unaffordable for the company, or make the game price very high
You really really need to provide more details - number of collidables, number of collisions, effects on gameplay (how deterministic does the outcome have to be?) etc.
The normal approach (using e.g. Havok) is to do it on all clients and the server, and the server sends out official messages and the clients continually predict the future - but to increase performance you decide what is “essential” what is “important” and what is “cosmetic”, and have three different code paths so that the essential messages are not competing for resources with anything else.
Better is to go with a fully deterministic physics engine, and get clever about doing rewinds and replays on the client, so that when they mis-guess what happens next, they can take a corrections from the server.
Depends on the questions I posed above, but you would normally do both.
The numbers of collidables would be upwards of 1000, collisions would between each soldier, etc. would be sparse except for with the ground (which will amount for most of the collisions).
I get most of this and was an option I was considering. When you say different code paths, do you mean different threads to handle the different categories of messages, each with an appropriate priority, or do you mean just having a queue and you won’t get to the lower priority messages until all of the essential or important ones have been dealt with?
Potentially use entirely different ways of keeping the logic in synch.
For cosmetic, for instance, you can afford to have every client simulate locally with no fix-up.
For middle-ground styff, you can have client simulation with fix-up only when the predicted client story is more than a certain amount of threshold out of synch.
etc.
It is not an approach I favour, I’d rather go for more deterministic solutions, but hey - it works.
I finally got around to reading those links you guys posted, it had good information. I have definitely run into the same thought problems as darkprophet. I’ll look into the source of the physics api, but since I’m making an rts game, I think I’ll use the P2P pattern instead of the server-client used in that api (but it’ll be good reference).
