Re: [pygame] Networking?

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

I don't have twisted experience so I don't have an opinion on it
specifically, but I completely agree with all the other stuff Patrick
said. In particular, the hard part is not the underlying network layer
(unless the net layer adds complexity), the hard part is figuring out
how to send small useful packets, so in my opinion simple net layers
are always better.

I've also had a good experience python sockets, although I haven't
seen a need to toss the code that manages them in a thread at all. The
TCP stack is already running in a different OS thread (on windows at
least) and it's doing acks and resends and all that without me giving
it a timeslice so there's nothing for a thread to do, I just select to
find out if I've got any data I should care when I'm ready to deal
with it and deal with it then.

I can see threads would be useful if you were building your own
protocol over UDP that did reliable and/or ordered transmission, so
you could have the thread manage acks and resends. Such features can
be kinda nice for optimizing network latency on bad connections based
on traffic type (you can't do reliable unordered with raw TCP or UDP)
but TCP can work perfectly well for high-performance network games.

I also agree about games being specialized so much it's hard for the
library to be useful for all games -in particular action/real-time/low
latency games over the internet are hard to generalize with (I imagine
some simple net layer could make all puzzle games trivial to implement
networked, and most action games on the LAN as well). There's some
basic tricks it could help with though - like if you are doing
delta-encoding of game state, having a reliable & ordered transport
that also does adaptable/progressive compression (I think python can
do this over tcp sockets with zlib with some extra work) can be very
useful, but on the other hand it's hard to make a useful generic delta
encoding module for game state...

On Nov 20, 2007 1:34 PM, Patrick Mullen <saluk64007@xxxxxxxxx> wrote:
> I tried the twisted as separate process thing for a while when i was
> working with Blender's game engine.  At the time it was the only way I
> knew how to do it, but it was very unwieldy to work with and deploy,
> just not a good system at all.  You are already introducing issues
> with network communication, why introduce issues with local
> communication as well.
>
> Currently I am using sockets with threads, it works pretty well I
> think.  It seems extremely stable, and fast enough, if I could get my
> higher level constructs in order.  The hard part with network
> programming in my opinion is the higher level stuff rather than the
> protocol.  How to serialize the data, what data to send, and how to
> interpret it, is very difficult if you want a smooth game.  No
> networking library I have seen handles this for you.  I'd like to see
> someone write a game network library that handles things like moving
> characters around and sending chat messages - 95% of networked games
> need these two things.  But most games are so specialized and
> integrated that it's hard to modularize this functionality to make it
> general enough for a library.  If I ever completely solve my netcode,
> I don't see myself being up to that task.
>
> I used to really like twisted, but it's sort of a hard nut to crack
> sometimes.  When using basically the raw tcp or udp protocols, twisted
> seems like massive overkill to me, and none of it's constructs seem
> all that well tailored to games.  That might have changed in the few
> years I've been away though.  What things like raknet, hawkNL, etc
> give you, is the ability for reliable udp sockets, which does make
> some things a bit easier and smoother.
>
> But really, the socket module IS everything you need.  It's just a lot
> of work to set up and learn to use it.
>