[Twisted-Python] "3D Game Using Twisted?", or: "Ach du lieber..."
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