On Wed, Feb 25, 2009 at 8:41 AM, Boris <[email protected]> wrote: > > Hellow again, thank you for such quick reply... > > Please elaborate your first statement. > >> / Because of our fixed time step, we wait every client to send its input >> to > > />/ every one. When data arrives, we update next frame. > / > that is a bad idea, > > Why do you think this is a bad idea, do you have any other idea. I know that > our idea is not cheat safe. But we see only this, as a major problem in our > idea. And ofcoarse our code is for LAN only. Internet is another story.
For LAN it's ok, it makes things simpler and you usually have very low ping values on a LAN, but it's a bad idea because you can't use it on the internet. Also, if your LAN is either wireless or crowded, packet loss could occur, causing delays. You mentioned Halo, so I assume this is an FPS game or at least a fast action game (as opposed to turn-based strategy game). The alternative I suggest is to use a fixed timestep on the server and the clients, but not demand everything be fully synchronized before incrementing the time. This introduces a lot of new challenges in regards to consistency. The site Erik Beran links to in another email talks about this, and there are a lot of other resources about this on the web. It's not my field, but I believe John Carmack has written some good stuff about this, he wrote most of the engines for the Doom and Quake games, and pioneered multiplayer FPS games. Espen Overaae _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
