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.
> 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 :)
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.
Best regards,
--
Kurosu
_______________________________________________
Wormux-dev mailing list
Wormux-dev@gna.org
https://mail.gna.org/listinfo/wormux-dev
