[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: peer-peer syncronization
> > What about the server just 'routing' timed packets?
> > -The player gives a command
> > -The client sends the command to the server
> > -The server adds the time (in game time) of the execution of the command
> > (maybe postponed some ticks in the future) and sends it back to ALL
> > clients. -The clients receive the command and, when the time has come,
> > execute the command, updating the game.
> > Drawback: some lag between the command issued and the command executed.
> > But should fit a RTS game.
> > Or not?
> Yes. There will be. What you do is immediately wake up all the troops
> on the player's screen and have them yell something like "Yes Sir!!!"
> which will nicely fill in that gap...
You are a genious.
> Technically: not at all. Also, technically, there is no such thing as
> a UDP connection -- connection is a TCP level thing.
Yes, ok, but you got the point...
> TCP is **NOT SLOW**
> I wish people would stop bloody well assuming things like this. It
> LOOKS slower over broken links because it sorts the packets into
> order and re-requests the missing ones.
> It's only slower if you don't want a guarantee that data will arrive
> and will be in the right order.
> Look, I'm not saying all these things are solved problems, it's more
> like they're UNSOLVED problems. Not using TCPIP has become a new
> religious statement of the games world. It's held as the same sort of
> unverified truth as using assembler is.
Well, i wrote two versions of sender/receiver and router: one using standard
sockets (SOCK_STREAM), and one using connectionless sockets (SOCK_DGRAM).
Belive me or not, on a local connection (same machine), the difference between
DATAGRAM and STREAM sockets was sensible.
So it was somewhat natural to me not to ignore connectionless networking.
> Lots. Read game gems. Read some books on TCPIP.
Have you got the Gamasutra article URL?