[Twisted-Python] "3D Game Using Twisted?", or: "Ach du lieber..."

Andrew Bennetts andrew-twisted at puzzling.org
Thu Mar 14 18:13:57 EST 2002

On Thu, Mar 14, 2002 at 01:47:26PM -0800, Derek Simkowiak wrote:
> -> Well, on the low level, we were discussing make banana extendable so you
> -> can define custom data types, e.g. a data type for location that is sent 
> -> in 4 bytes. The overhead for you would be one extra byte per message, I 
> -> think.
> 	Not 4 bytes... 4 BITS (for the Z component only).  I don't know
> what they're doing, but that's what their Lead Developer told me.

Yes, but you won't be sending 4 bits as a single packet -- that would have
just as much latency as 4 bytes, in practice.  The TCP/UDP overhead is more
like 40 bytes per packet, after all.

In practice, I suspect you'll be sending more than a single Z component at a
time.  You're more likely to change the X, Y and Z at once; or multiple Zs,
or something.  It all depends on the game, of course.  But my point is that
one byte extra on a X, Y & Z message that you pack into e.g. 4 bytes is
going to be as fast in practice as anything else.

> 	Obviously, the need to fiddle with bitshifting (and other tricks,
> like compressing certain packet types before transmisison) makes me think
> I'll need to write my own network library.

Or extend an existing one...

I really know nothing about the internals of twisted.spread, but extending
it sounds like a better idea than building a new one.

> 	There are also further refinements in the CounterStrike/Half-Life
> version of the Quake2 protocol, although I don't know what those are yet.  
> I'm also dinking around with ideas like using bits to mark the traversal
> of a binary "packet opcode" tree, putting the most common types of packets
> near the top of the tree and the less common (or lower priority) packets
> near the bottom -- this way, the opcode identifier for the most common
> packet would only be one bit (and my networking code would be a nasty mess
> of bitshifting and endian-specific code :).  Given this type of work, I'd
> rather not just "pass it off" to banana.  (Although I'm still going to
> take a close look at what's there.)

Sounds like good ol' Huffman codes to me.  Not a bad idea, though, assuming
that bit-packing gives any genuine advantage -- I'm generally skeptical that
the benefit of being able to squeeze an extra 5% through the network
outweighs the overhead (especially in code complexity) of bit-twiddling at
both ends (yes, I realise CPU is more plentiful than bandwidth).  I'd
personally leave bit twiddling until much later in a project, as I suspect
it could be an unnecessary and premature optimisation compared to the other
techniques mentioned.  Bit-twiddling strikes me as an implementation
optimisation, where algorithmic gains could be much more beneficial... but
then, I've never written a networked game, so I'm just guessing :)


More information about the Twisted-Python mailing list