pygame and socket.recv

[Aaron Brady]

On Apr 1, 10:38 pm, Terry Reedy <tjre... at udel.edu> wrote:
> Aaron Brady wrote:
>
> > My game loop looks like this:
>
> > poll events, get 1 at most
> > send to server
> > wait for server reply
> > render entire frame
>
> I am very sure that commercial 'real-time' (versus turn-based)
> multiplayer games do not operate that way, at least not the ones I have
> played.
>
> I suspect that most do not operate by  frames on the server, but rather
> sent a more or less continuous series of events.  NPC movements come
> from the server (and can be given as vectors), other player movements
> get echoed as sent to the server.  The client uses the most current data
> it has when it renders a frame.  If the scene it too complex relative to
> the client rendering capability, the frames jump and the motion is
> choppy.  If the info stream is interrupted, the scene may freeze a bit
> even as the client continues to re-render to account for player motion.
>   Hope this helps a bit.

I am thinking a couple of things.  Take a branch in the reasoning.  On
arriving at the time to render the next frame, without any
announcement from the other side:

1) Side A continues to model Side B as though no change in motion
occurred.
2) Side A discontinues its model of Side B until next transmission.

In 1, upon receiving the next update from B, it will have to retrace
its steps, "unmodel" the changes, and bring them up to date.  This can
have retroactive cause-and-effect consequences on A as well, including
but not limited to, live-or-dead state, position, and velocity.

In 2, A's view of B looks jumpy-- B is halting, then jumping ten
tiles, then moving smoothly, then halting and jumping.  Retroactive
changes are regardless possible.

This was a the-long-way-'round word search for the word 'retroactive',
which I'm glad is a word, incidentally.  In either case, every time
one player's packets are delayed, every other player's screen will
alter state, more or less like they have been sleepwalking and just
come to.  There is the additional problem of what to do with A's
interim actions.  Reminds me of a diff-merge in source control!  How
about king-of-the-hill precedence for contradiction resolution?

Then, the player whose packets are delayed has an advantage.  B got to
make a change to another player's state, as well as proceed with
exclusive knowledge of it.  B is the only one with an up-to-date model
of the game during the lag.

This could also apply to B instead, if the game structure makes the
others' besides B the valid current model.  B is sleepwalking for the
length of his/er network delay, and his/er actions are discarded.
This may be more what players are accustomed to; the interface goes
dead, and issuing or rescinding orders isn't acknowledged or received.

Any momentary loss of "visibility" could be mitigated in a low-impact
game or simulation of physical motion, since it takes many Gs of
acceleration to avert most-- all but glancing-- collisions that are
destined in just a few frames.  Mine is not such; position and
velocity are subject to arbitrary changes.

<jest> Maybe I just need more clicks per second, to give the user a
feeling of accomplishing something, even though the same percentage of
actions is successfully transmitted.  Is satisfaction a simple
decaying proportion?</jest>

With discontinuities in position and momentum possible, is lockstep
frame-for-frame synchronization my best option?  Or should I fall back
on a sturdier game model, where actions' consequences can't affect
other players for several frames?  Blue... no!  Yellow!