Hi!
On Feb 10, 2008 2:15 PM, Kurosu <[EMAIL PROTECTED]> wrote:
> Hi!
>
> RCL a écrit :
> >> - things that don't need it (every thing else like wind particles, camera
> >> shake ;) ).
> >>
> >> So, a camera shake is obvously falling in the 2nd type.
> >
> > Yes, I felt that I'm doing something wrong, because it shouldn't stay
> > in sync, but because of my internal laziness I failed to search for
> > more suitable random function :>
> >
> > But my guilty conscience made me warn you about that here on the list :)
>
> I think you should use static functions from tool/random.{cpp,h}
> Basically, replace all randomSync.Get* by Random::Get*
>
> You modified camera.cpp at least, but I'd prefer that you are the one to
> check that only this needs modification, and that it doesn't break what
> you achieve currently with randomSync.
Drayan already fixed that :) And Random::GetDouble behaves the same
way, I assume, so nothing should change in experience.
> > Could you tell me more about the logic of network play? Am I right
> > that it's just relying on the fact that both parties run the same code
> > and syncronizes only occasional data like random seed and player's
> > initial positions?
>
> I'm not very much more knowledgeable, but most events are processed
> through the generation of "Action"s, whether they come from network
> packets or are internally generated.
>
> To see what travels through the network, there is a wealth of means:
> - grep for SendAction (mostly in include/action_handler.cpp) and see
> which actions are sent to the clients
> - edit network/network.h and uncomment LOG_NETWORK define (may need to
> be built as debug); this will cause a file to be generated with packets
> when playing online; I wrote a very rudimentary (which needs to be
> updated, probably) parse for this file, located in tool/netparse
> - if you configured wormux with --enable-debug or --enable-logging, run
> wormux with parameter "-d action_handler"; this will generate debug
> output for everything occurring in the action handler that was deemed
> interesting
>
> Probably more to find, but this should get you started :)
Thank you for the guide :) I feel I'm a bit too fresh to dive into
networking code details, but I'm glad that my assumption (about two
copies running the same code and using stream of events to syncronize
them) was right.
> This shall show you that a lot of data is sent to set characters' info
> on the clients: position, health, ... When you move a character, around
> 112bytes are generated for each event (which can be a lot in a second,
> in the tens).
>
>
> > I haven't noticed traditional quake-like separation into "server" and
> > "client" code (even when running singleplayer) with server entities
> > being just "replayed" on each client (including local one). Or am I
> > wrong?
>
> The network design is in my (humble) opinion not the best around, mostly
> because nobody really has any previous experience with such feature in a
> game. But it's working good, and changing it would probably be very
> painful (debug-wise), and I certainly can't come up with a better design.
>
> Anyway, the code improves, as causes of desynchronizations are discovered.
>
> This topic interests me, because I have a pet peeve which is to record a
> game, and be able to replay it, not for debug purpose but for the fun
> part in watching some games. I have a newer version, but nowhere as
> functional, and probably missing a lot of recorded info.
>
> I'm not an expert on wormux' code, maybe like you with 6 months more
> experience (or 2 months if you keep on at this speed ;) but I hope it'll
> give you a start, possibly completed by other senior developers.
>
Thanks again. Actually, I have once worked in gamedev company and
wrote networking code for the game that was commercially released...
though that was not a big success with thousands of servers online,
the network was mostly LAN-oriented :) It was a 3D shooter and we had
the following design (I guess it's pretty common for such games):
"Server" part, which is the only part of code that evaluates (moves,
applies logic/collisions etc) the actual objects.
"Client" part, that is basically a player of (serialized) object
states, no matter whether they came from network (multiplayer), shared
memory (single player) or file (replaying demos).
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.
In that design, server is always one frame "ahead" from its clients
(including local client, so the situation is fair for every player),
so while the rocket hit the ground in frame N, clients are still
showing it flying in frame N-1 (last one they received).
This also makes game highly dependant on network latency... you can't
use TCP with that, as you don't need stale frames from seconds ago, so
you're stuck with UDP and you have to provide your own scheme for
sending something reliably (if there's a need).
But it has positive sides - you don't have to use multiple threads as
you can just use non-blocking network API.
I guess the biggest difference between the above scheme and one
implemented in Wormux, is that Wormux server communicates not the
object states, but the "actions", that are used to drive the client
code the same way as usual keyboard input would.
But the actions seem to be able to come at any time and there's no
notion of "server frame" in the Wormux code (e.g. a complete set of
object states for a given time on server), so if some "rogue" or
buggy/outdated client interprets some particular action differently,
there's no way for the server to fix object position for him, or to
even know about that, right?
> Best regards,
> --
> Kurosu
>
Best regards,
Dmitry 'RCL' Rekman
_______________________________________________
Wormux-dev mailing list
Wormux-dev@gna.org
https://mail.gna.org/listinfo/wormux-dev
