Hello, On Feb 11, 2008 3:24 AM, Eddy Petrișor <[EMAIL PROTECTED]> wrote: > RCL wrote: > > > There was no problem with synchronizing object positions/states, as > > there was only one piece of code that actually did the calculations... > > all the "clients" (including local one, which shared CPU with server > > part) just received the stream of object positions for a given frame > > and interpolated between two frames to match their own FPS rate. > > This is what should be done in wormux, too
[...skipped...] > I think you managed to point out what I always thought to be a weak > pointin wormux' net code: clients shouldn't be allowed to make > calculations independently. There can be several things that can go > wrong with that: parallel universes (one player sees A dead, another > sees A alive), errors in FP implementation of one processor can cause > desyncs, etc. Well, it would be nice to have real client-server in Wormux. However, I realize that you guys want to finish 0.8 branch as soon as possible, and the above scheme means complete overhaul of the network code... with 0.8 being already in beta stage, that's impossible. But if some "critical mass" of enthusiastic people gathers around this idea, it is possible for 0.9 or later versions. Definitely some senior developer should be overlooking the project. What is the essense of the of the above scheme: 1) Entities should be separated into server and client representations (essentially MVC design pattern, with server entities being models and client entities being their views). 2) Server entities should be able to serialize themselves to some archived form which will be transmitted over the network (and/or saved to file for local demos), and client entities should be able to fully reconstruct their state from this form. 3) Server entities should not make any client-specific calls (shouldn't draw, shouldn't play sounds, etc). Just pure logic (movement, physics etc). World (I mean the map graphics) should have its server entity and client entity as well so holes in the ground is also synchronized. 4) Notion of "server frame snapshot" should be introduced, and networking protocol rewritten so it transmits snapshots, and not separate "action" messages. 5) Ideally, server and client code should be able to compile independently (so that headless servers are possible). There are much more problems to solve... client-side prediction (could be necessary for things like rope), effective serialization of complex entities like world, effective network protocol... I think it really sounds like a full time job :) But it would get us the true client-server architecture, with additional bonus of headless server, replaying demos and ensuring that no "rogue" client is able to cheat by e.g. changing some weapon (which I guess is quite possible, given availability of the source code). I hope some senior developer gets interested... > In the worst case, the client that is the current active one should be > the one dictating and distributing all the information about the > changes, while the others will just update the views accordingly. Since > we don't have a real-time game, there is no problem with the fact that > the active payer is ahead of the others. Such a hybrid scheme is also possible, but I think it's inferior to the above, because you will have the client and server functionality mixed in the entity class (I mean, physic object class and its subclasses), so the logic will get complicated... you'll have to check whether you're running in server or client mode in each single weapon/character and refrain from calling moving/refreshing/etc functions... Probably the code will be messy. Best regards, RCL _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
