[Twisted-Python] "3D Game Using Twisted?", or: "Ach du lieber..."
Hello. My name is Derek Simkowiak, I've just been introduced to Twisted by Sean Riley (sean at twistedmatrix dot com). I'm using (and now contributing to) his PyUI widget set for my 3D game engine. When I told him I still needed to write the networking code, he pointed me here. I wanted to introduce myself, ask for some general guidance about a network protocol, and point out that the documentation titled "The Basics" at http://twistedmatrix.com/page.epy/docs/basics.html results in "no such page", which really sucks for somebody just getting started (like me). First, a little bit about my game engine, because it's the type of thing you twisted Twisted people might be interested in: o OpenGL for rendering o SDL for event management o Quake2 BSP map rendering (many more model formats to come soon) - includes almost all of the Id BSP culling tricks - includes fully-functional collision detection using the Q2 "bloated planes" algorithm, as figured out by Kekoa Proudfoot o Complete in-game GUI over the top of the 3D world, including transulency, using the PyUI widget set. Screenshot at: http://www.realloc.net/~dereks/targa_pyui1.jpg Also see the older shots at: http://www.realloc.net/~dereks/commputers/my_code/targa/ Also, the big piece that you may like: I've recently refactored the whole damn thing, and with a little help from SWIG my "engine" is now nothing more than some Python C extensions. My "main event loop" is just a simple Python script, and because all the [bottlenecking] rendering code is still C, I get the ~70 FPS I was getting when the entire engine was pure C. But now I have Python at my disposal, mua ha ha. (Also, note that all the libraries are cross-platform. I'm developing under Linux, but eventually this thing should run under MS-Windows, Mac OS X, AmigaOS, and even PlayStation2.) The big pieces I have left are the enemy A.I. and the networking code. This is a client-server engine. The light at the end of the tunnel is load-balanced Linux cluster (using LVS) serving up a persistent, 3D world (ala' PlanetSide), and maybe even me making some $$$ from a few hundred subscribers paying $5/month. Now you see where Twisted fits in -- I'm basically shooting for twisted.reality in real-time 3D. My concern is regarding bandwidth. My game protocol will be similar to the Quake2 protocol, meaning huge lists of 'entities' are updated with position and orientation data as often as possible. Such generic position updates will be done with UDP, and 'critical' packets (such as damage, explosions, jumps, messages, etc.) will be done with TCP. In summary, every single byte of network overhead matters -- nay, every BIT matters (npi). So I've browsed through the API docs, but I don't have any context to know what I'm looking at. I'll be downloading and installing the source soon, but in the meantime... any advice? Is there any particular package I should be looking at (other than twisted.internet)? Does Twisted's networking code cater to somebody who needs to, for example, do bitshifting and compression to absolutely minimize the bandwidth requirements? What approach would you take? Note that, using PyUI for the GUI and [possibly] Twisted for the server, I want to have things like in-game "IRC/ICQ", in-game "emails", and also in-game "voice chat" ala CounterStrike 1.3. Other wild ideas include in-game video conferencing, and dynamically-downloaded bits of Python code that would act as all-new, not-previously-imagined entities. (Note that by "in-game" I mean the 3D world is rendered, and the email/IRC/video client application is rendered on top of the 3D world with some translucency. The idea is to keep the player immersed.) Any advice is greatly appreciated. If anybody else is using Twisted for something similar, I'd love to hear about it. Thanks, Derek Simkowiak dereks at realloc dot net
On Wed, Mar 13, 2002 at 06:14:34PM -0800, Derek Simkowiak wrote:
Hmm. You've asked a lot of questions, which I can't answer at the moment, but you might prefer this URL: http://twistedmatrix.com/documents/servers -Andrew.
Derek Simkowiak wrote:
The site was re-done. This should be useful: http://twistedmatrix.com/documents/servers The next version of Twisted will include all written docs in the tarball, such as they are. I'll let more qualified people answer the rest.
-> > http://twistedmatrix.com/page.epy/docs/basics.html -> -> The site was re-done. This should be useful: -> -> http://twistedmatrix.com/documents/servers In that case, please note that (a) Google returned the [broken] URL I gave, not the new one (b) The URL I gave is referenced from (at least) one article online It would be nice if there were some kind of link to the new documentation. --Derek
Derek Simkowiak wrote:
(a) Google returned the [broken] URL I gave, not the new one
Not our problem.
(b) The URL I gave is referenced from (at least) one article online
Maybe we should deal with this. Chris?
It would be nice if there were some kind of link to the new documentation.
It's reachable if you go to http://twistedmatrix.com and then follow links from there.
On Wed, Mar 13, 2002 at 08:54:55PM -0500, Itamar Shtull-Trauring wrote:
Yeah. Google will correct itself eventually; in the mean time, it probably offers a cached copy.
It might be nice if the 404 page offered a link back to the homepage, instead of just a "No Such Resource" error message. -Andrew.
Hey, Darek!
That looks great!
Also see the older shots at:
This link didn't come up for me, though...
Very cool.
Welcome to the club. :-)
Any advice is greatly appreciated. If anybody else is using Twisted for something similar, I'd love to hear about it.
I'm working on a similar goal -- Persistent worlds hosted in Twisted with various 3D clients. Currently, I'm working with the Nebula Device (http://www.radonlabs.de), which is a multi-platform general scenegraph-oriented library. I'm working on putting together a demo, but until then, check out the papers which describe the approach I'm taking: http://www.asbahr.com/papers.html It would be useful to identify the common features between the various game projects so we can collaborate effectively. Does the fact that you are using Quake-style approach mean that you will want to consider the world in terms of "levels", versus terrain chunks or "rooms"? Cheers, Jason
On Wed, Mar 13, 2002 at 07:52:42PM -0600, Jason Asbahr wrote:
I'm interested in contributing to something like this.
The big pieces I have left are the enemy A.I. and the networking code. This is a client-server engine. The light at the end of the
I have AI experience in a totaly different field (OCR), and do embeded real-time systems programming in the real world (including some autopilot programming). I once upon a time did some low-level 3D programming (rendering algo's), but that was ages ago. I'm interested in contributing to A.I, update + lag-compensation algo's, progressive detail algo's, and random environment generation. I also have some ideas on using RPG style skills and skill advancement in a FPS.
radeonlabs.... If there is demand, I'd also be interested in trying my hand at tweaking radeon drivers for linux. Although I really like Python programming, I've actually had heaps more experience with low level assembler and C.
Oh yeah, I'm also very keen on helping facilitate common-code usage. -- ---------------------------------------------------------------------- ABO: finger abo@minkirri.apana.org.au for more info, including pgp key ----------------------------------------------------------------------
On Wed, 2002-03-13 at 21:32, Donovan Baarda wrote:
Deus Ex did this very nicely. I wish every day that there was a Deus Ex MMRPG :-) -- Chris Armstrong << radix@twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/
-> > http://www.realloc.net/~dereks/commputers/my_code/targa/ -> -> This link didn't come up for me, though... Sorry... typo. Too many 'm's in 'commputer'. Try: http://www.realloc.net/~dereks/computers/my_code/targa/ (That page is a bit dated, but has a link to more screenshots.) -> I'm working on a similar goal -- Persistent worlds hosted in Twisted -> with various 3D clients. Currently, I'm working with the Nebula Device -> (http://www.radonlabs.de), which is a multi-platform general -> scenegraph-oriented library. I need to take a look at Nomads again... (unfortunately, I have a sharp distaste for C++). But it would be good to look at their architecture, now that mine is fully designed. -> I'm working on putting together a demo, but until then, check out -> the papers which describe the approach I'm taking: -> http://www.asbahr.com/papers.html I will take a look. Thanks! -> It would be useful to identify the common features between the various -> game projects so we can collaborate effectively. I don't want to spam this list with off-topic 3D game mails. Perhaps a "twisted-3d" list is called for? Until then, please follow-up with me privately. -> Does the fact that you are using Quake-style approach mean that you -> will want to consider the world in terms of "levels", versus terrain -> chunks or "rooms"? No, I consider the world in terms of generic "Entities". Renderable entities have a "model" member, which is itself a C extension class. Then when the entity goes to render itself, it calls the C 'render' function of the model. This is because many model types (i.e. BSPs and Quadtrees) have culling information intrinsically built into the model format, and it makes sense to use C to do that. My engine will (eventually) allow for several BSPs within either a landscape, or in outer space. Imagine a game like HomeWorld, except that you can crash-land your small fighter in the landing bay of an enemy frigate, jump out of your fighter (First Person Shooter ala Quake), and now -- within the BSP of the ship -- run around hallways and corridors until you reach the control room, kill the command crew, and take over the frigate. That is the kind of flexibility I am aiming for; the "frigate" entity would detect if the camera (i.e., viewer perspective) is within the ship. If not, it would render a mesh model. If yes, then it renders its BSP tree. What's really cool is that my BSP code, unlike any other BSP-based engine I've seen, allows sharing of the static data, including OpenGL texture names. So you'd have the BSP in memory once only, but be able to have 50 frigates (any one of which you can crashland into). The same theory would apply to buildings, underwater settlements, etc. I hope to soon support meshes, particle systems, landscapes (dynamically loaded lists triangle strips), and later on streaming media. All I need to do to add those is write a C struct to hold the data, and then implement the render() and collide() APIs for those structs. The rest is handled in Python. I will read your papers soon. Thanks again. --Derek
well, the piece of Twisted that is immediately relvant for this type of application is twisted.spread - comprised of "pb", "jelly" and "banana". these provide a distributed object system with marshalling, serialization, networked observation and reference counting. All things that are useful for building on-line games! This technology is not optimized at the level of Quake or Tribes style protocols, but it is infinitely more flexible and provide a much higher level of functionality. I have some (incomplete) code for a primative "sub-space" clone that I wrote using Twisted a while ago. It probably doesn't even work with the latest Twisted build - but maybe it could be a starting point for some pb examples? I could post it somewhere if anyone is interested. -----Original Message----- From: twisted-python-admin@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Derek Simkowiak Sent: Wednesday, March 13, 2002 8:15 PM To: twisted-python@twistedmatrix.com Subject: [Twisted-Python] "3D Game Using Twisted?", or: "Ach du lieber..." Hello. My name is Derek Simkowiak, I've just been introduced to Twisted by Sean Riley (sean at twistedmatrix dot com). I'm using (and now contributing to) his PyUI widget set for my 3D game engine. When I told him I still needed to write the networking code, he pointed me here. I wanted to introduce myself, ask for some general guidance about a network protocol, and point out that the documentation titled "The Basics" at http://twistedmatrix.com/page.epy/docs/basics.html results in "no such page", which really sucks for somebody just getting started (like me). First, a little bit about my game engine, because it's the type of thing you twisted Twisted people might be interested in: o OpenGL for rendering o SDL for event management o Quake2 BSP map rendering (many more model formats to come soon) - includes almost all of the Id BSP culling tricks - includes fully-functional collision detection using the Q2 "bloated planes" algorithm, as figured out by Kekoa Proudfoot o Complete in-game GUI over the top of the 3D world, including transulency, using the PyUI widget set. Screenshot at: http://www.realloc.net/~dereks/targa_pyui1.jpg Also see the older shots at: http://www.realloc.net/~dereks/commputers/my_code/targa/ Also, the big piece that you may like: I've recently refactored the whole damn thing, and with a little help from SWIG my "engine" is now nothing more than some Python C extensions. My "main event loop" is just a simple Python script, and because all the [bottlenecking] rendering code is still C, I get the ~70 FPS I was getting when the entire engine was pure C. But now I have Python at my disposal, mua ha ha. (Also, note that all the libraries are cross-platform. I'm developing under Linux, but eventually this thing should run under MS-Windows, Mac OS X, AmigaOS, and even PlayStation2.) The big pieces I have left are the enemy A.I. and the networking code. This is a client-server engine. The light at the end of the tunnel is load-balanced Linux cluster (using LVS) serving up a persistent, 3D world (ala' PlanetSide), and maybe even me making some $$$ from a few hundred subscribers paying $5/month. Now you see where Twisted fits in -- I'm basically shooting for twisted.reality in real-time 3D. My concern is regarding bandwidth. My game protocol will be similar to the Quake2 protocol, meaning huge lists of 'entities' are updated with position and orientation data as often as possible. Such generic position updates will be done with UDP, and 'critical' packets (such as damage, explosions, jumps, messages, etc.) will be done with TCP. In summary, every single byte of network overhead matters -- nay, every BIT matters (npi). So I've browsed through the API docs, but I don't have any context to know what I'm looking at. I'll be downloading and installing the source soon, but in the meantime... any advice? Is there any particular package I should be looking at (other than twisted.internet)? Does Twisted's networking code cater to somebody who needs to, for example, do bitshifting and compression to absolutely minimize the bandwidth requirements? What approach would you take? Note that, using PyUI for the GUI and [possibly] Twisted for the server, I want to have things like in-game "IRC/ICQ", in-game "emails", and also in-game "voice chat" ala CounterStrike 1.3. Other wild ideas include in-game video conferencing, and dynamically-downloaded bits of Python code that would act as all-new, not-previously-imagined entities. (Note that by "in-game" I mean the 3D world is rendered, and the email/IRC/video client application is rendered on top of the 3D world with some translucency. The idea is to keep the player immersed.) Any advice is greatly appreciated. If anybody else is using Twisted for something similar, I'd love to hear about it. Thanks, Derek Simkowiak dereks at realloc dot net _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-> well, the piece of Twisted that is immediately relvant for this type of -> application is twisted.spread - comprised of "pb", "jelly" and "banana". -> these provide a distributed object system with marshalling, serialization, -> networked observation and reference counting. All things that are useful for -> building on-line games! Very cool (although, I have to say it, I'm not really a fan of 'cute' API names. I much prefer clarity and conciseness.) Also, twisted.spread could easily be confused with the "Spread" C library, which is also designed for use in distributed systems. It has a somewhat different purpose, but my first thought was that twisted.spread was a Python interface to the Spread library (which would be really useful for Twisted, by the way). See http://www.spread.org/. -> This technology is not optimized at the level of Quake or Tribes style -> protocols, but it is infinitely more flexible and provide a much higher -> level of functionality. Unfortunately, most people _HATE_ a laggy gaming experience (i.e., see the "Damn Lag" T-Shirt at ThinkGeek.com). For my application, the need for efficiency outweighs the other features of twisted.spread. However, I could probably use twisted.spread for "administrative" networking. That would be things like text messages, download of resource files (meshes, textures, etc.), changing levels, etc. -- things that don't need to be updated at ~70 FPS. -> Twisted build - but maybe it could be a starting point for some pb examples? -> I could post it somewhere if anyone is interested. "More examples" is always better than "fewer examples" :) Thanks for the help! --Derek
In the spectrum of protocols ranging from generic but bandwidth heavy protocols like SOAP to highly compressed and specific protocols like Quake, "pb" falls somewhere in the middle - but much closer to the Quake end. It has been optimized for use in games, while still providing generic functionality. "Lag" is much more of an issue than just protocol design. Tricks such as client-side prediction, intelligent weapon design, distance based attenuation and aggressive visibility calculation make a huge difference. With the right game design and the optimizations that are planned for pb i think it could be used for FPS type applications. There could even be an extension to banana (the protocol packer) specifically for these application that knows about 3d co-ordinates, movement packets and other common packet types. This banana extension could do bit-shifting, low-precision floats and compression, or any other tricks learned from the FPS crowd. I am definately planning on using it for all in-game traffic within the 3D virtual spaces I am building. I'd encourage you to do the same - at very least consider using extensions to pb rather than writing your own protocol framework. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-> "Lag" is much more of an issue than just protocol design. Of course, and I have been studying heavily all of the things you mentioned (prediction, et. al.). But just to give you an idea of how optimized the 3D protocols are, Sony's PlanetSide only uses 4 bits for the Z component of it's entity origin update packets (because they are using tricks to get around the loss in granularity). Also, as the guy who going to have to write the code, I'm kind of looking forward to playing with different optimizations and "tricks". If I'm just calling somebody else's library, I lose all that fun :) -> I am definately planning on using it for all in-game traffic within the 3D -> virtual spaces I am building. I'm highly interested in this work; I would love to see what kind of response times you get with twisted.spread (and which 'tricks' you employ :). -> least consider using extensions to pb rather than writing your own protocol -> framework. Because you are so persistent in this recommendation, I will take a very close look at pb. But presently my intuition says I'll be writing my own. --Derek
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. This depends on adding "profiles" to the banana protocol, which is on our TODO list.
-> 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. 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. 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.) Thanks, Derek
On Thu, Mar 14, 2002 at 01:47:26PM -0800, Derek Simkowiak wrote:
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.
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.
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 :) -Andrew.
On Thu, 2002-03-14 at 17:13, Andrew Bennetts wrote:
And yes, this is where a lot of often-neglected network trickiness happens -- actually getting more data into each packet. Balancing latency against keeping a full packet payload is hard.
And, while pb is designed to be extended to do just this, the amount of application-specific optimization necessary for a first-person shooter is really phenomenal. You'll need to optimize PB down quite a bit further than it's already been (although PB is built to be optimized, so it's not really a problem) even to be adequate for the control stream. The biggest problem I can see you having with the protocol itself is the fact that it only operates over TCP. A UDP extension for doing things like movement packets would be really handy!
I really know nothing about the internals of twisted.spread, but extending it sounds like a better idea than building a new one.
twisted.spread, and Perspective Broker, are both designed to be highly extensible. Itamar is currently working on the final iteration of banana, which will define some mechanisms for backwards-compatibility, as well as enabling us to write an RFC. Consider ancillary services that are going to interoperate with your game, too; if you are extending PB in order to do your game protocol, then applications like game browsers, high-score charts on webpages (and so on) will come together in a snap. Other folks are also writing games that use Twisted for networking, and it would be neat if they could all talk to each other!
Networked games are tough, and Derek's concerns are valid. My point of view on this is that PB cannot handle such a game by itself, but it defines mechanisms for extensibility that are designed to solve exactly this sort of problem. PB's purpose is twofold. It does provide a useful, generic, high level protocol that one can use out-of-the-box in lots of different kinds of applications. However, I also hope to provide a sort of meta-standard for protocols that have domain-specific optimization requirements, so that real systems that solve hard problems can communicate lower-priority (e.g. "the ones that don't have to be as close to real time as possible") messages using a mechanism less abusive to their performance requirements (either on the network in CPU) than XML-RPC, and easier to add new messages to than something like CORBA. For most systems, this should really be good enough. Ideally I'd like to replace HTTP with it, but that's obviously a bit more work than has been done :) (Smash the web!) Despite the fact that I want to provide a reasonably efficient network layer, my own humble opinion is that systems that are so latency-sensitive that PB doesn't work for them out of the box are probably kidding themselves about the latency issues that arise just by using the internet... but I think that John Carmack disagrees. At the very least, PB should help one get off the ground and start prototyping game functionality really early, before one worries about seriously packing the network protocol; if one's game is just a 3D shooter this is probably not that interesting.
On Thu, Mar 14, 2002 at 01:13:51PM -0800, Derek Simkowiak wrote:
My advice with "tricks" is avoid them until the last moment of implementation. Too many designs get complicated beyond redemption by "clever tricks" too early in the piece. You end up with a tangled mess that breaks every time you look at it, and usualy turns out slower than a "trick-free" clean implementation of a good design.
My advice would be to prototype using Twisted, then optimise to C later if it is needed. Python will allow you to easily re-factor the whole design again and again untill you get it right. If you start in C, the re-factoring will hurt enough that you will avoid it and employ "tricks" instead :-) My gut feeling is that a good twisted implementation will be fast enough at throwing bytes over a wire. Optimising to C will only buy you CPU, not reduced latency and/or bandwidth. The really critical thing will be the design, ie what data you send, and how it is used to present a consistant world view. Be prepared to think "outside the box" when at the design stage, and prototype and experiment extensively. There are some potentialy groovy ideas floating around based on "distributed data fusion", where all the nodes maintain their own view of the world, which is used to correct and is corrected by the other nodes "world views", using karmen (spel?) filter techniques. This is a generic approach to resolving a concensus world view between multiple distributed sources of information. -- ---------------------------------------------------------------------- ABO: finger abo@minkirri.apana.org.au for more info, including pgp key ----------------------------------------------------------------------
(note, this message is a bit stale. I composed it yesterday, but my mail server (twistedmatrix.com) went down for a bit.) On Thu, 2002-03-14 at 01:31, Derek Simkowiak wrote:
At least 'spread' and 'pb' are sane names -- spread is a toolkit for spreadable computing (as opposed to distributed computing, which we make the dinction with because spreadable is translucent as opposed to transparent), and we have PerspectiveBroker which is.. a broker for Perspectives (which were named with the rule of clarity and conciseness in mind -- in fact, Glyph spent an obscene amount of time coming up with this name). :-) I'm only saying all this because I think disliking the name is pretty irrelevant when it comes to code ;-) Anyway, see below, not *all* of this message is a troll ;-)
Well, there's not much we can do about this but try to make it clear that it's not in the documentation/website (which we do).
You might want to take a closer look at the banana protocol. It was definitely implemented with efficiency and extensibility in mind. My point is, a UDP alternative for it would be very cool, especially if we could integrate it higher-level abstraction, like a subset of/something similar to PB, for example (this would an interesting challenge to think about). The biggest problem here is CPU-time that banana/jelly take up -- but this problem is being targetted, especially with dash's work on twisted.eco. :-) -- Chris Armstrong << radix@twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/
On Wed, Mar 13, 2002 at 06:14:34PM -0800, Derek Simkowiak wrote:
Hmm. You've asked a lot of questions, which I can't answer at the moment, but you might prefer this URL: http://twistedmatrix.com/documents/servers -Andrew.
Derek Simkowiak wrote:
The site was re-done. This should be useful: http://twistedmatrix.com/documents/servers The next version of Twisted will include all written docs in the tarball, such as they are. I'll let more qualified people answer the rest.
-> > http://twistedmatrix.com/page.epy/docs/basics.html -> -> The site was re-done. This should be useful: -> -> http://twistedmatrix.com/documents/servers In that case, please note that (a) Google returned the [broken] URL I gave, not the new one (b) The URL I gave is referenced from (at least) one article online It would be nice if there were some kind of link to the new documentation. --Derek
Derek Simkowiak wrote:
(a) Google returned the [broken] URL I gave, not the new one
Not our problem.
(b) The URL I gave is referenced from (at least) one article online
Maybe we should deal with this. Chris?
It would be nice if there were some kind of link to the new documentation.
It's reachable if you go to http://twistedmatrix.com and then follow links from there.
On Wed, Mar 13, 2002 at 08:54:55PM -0500, Itamar Shtull-Trauring wrote:
Yeah. Google will correct itself eventually; in the mean time, it probably offers a cached copy.
It might be nice if the 404 page offered a link back to the homepage, instead of just a "No Such Resource" error message. -Andrew.
Hey, Darek!
That looks great!
Also see the older shots at:
This link didn't come up for me, though...
Very cool.
Welcome to the club. :-)
Any advice is greatly appreciated. If anybody else is using Twisted for something similar, I'd love to hear about it.
I'm working on a similar goal -- Persistent worlds hosted in Twisted with various 3D clients. Currently, I'm working with the Nebula Device (http://www.radonlabs.de), which is a multi-platform general scenegraph-oriented library. I'm working on putting together a demo, but until then, check out the papers which describe the approach I'm taking: http://www.asbahr.com/papers.html It would be useful to identify the common features between the various game projects so we can collaborate effectively. Does the fact that you are using Quake-style approach mean that you will want to consider the world in terms of "levels", versus terrain chunks or "rooms"? Cheers, Jason
On Wed, Mar 13, 2002 at 07:52:42PM -0600, Jason Asbahr wrote:
I'm interested in contributing to something like this.
The big pieces I have left are the enemy A.I. and the networking code. This is a client-server engine. The light at the end of the
I have AI experience in a totaly different field (OCR), and do embeded real-time systems programming in the real world (including some autopilot programming). I once upon a time did some low-level 3D programming (rendering algo's), but that was ages ago. I'm interested in contributing to A.I, update + lag-compensation algo's, progressive detail algo's, and random environment generation. I also have some ideas on using RPG style skills and skill advancement in a FPS.
radeonlabs.... If there is demand, I'd also be interested in trying my hand at tweaking radeon drivers for linux. Although I really like Python programming, I've actually had heaps more experience with low level assembler and C.
Oh yeah, I'm also very keen on helping facilitate common-code usage. -- ---------------------------------------------------------------------- ABO: finger abo@minkirri.apana.org.au for more info, including pgp key ----------------------------------------------------------------------
On Wed, 2002-03-13 at 21:32, Donovan Baarda wrote:
Deus Ex did this very nicely. I wish every day that there was a Deus Ex MMRPG :-) -- Chris Armstrong << radix@twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/
-> > http://www.realloc.net/~dereks/commputers/my_code/targa/ -> -> This link didn't come up for me, though... Sorry... typo. Too many 'm's in 'commputer'. Try: http://www.realloc.net/~dereks/computers/my_code/targa/ (That page is a bit dated, but has a link to more screenshots.) -> I'm working on a similar goal -- Persistent worlds hosted in Twisted -> with various 3D clients. Currently, I'm working with the Nebula Device -> (http://www.radonlabs.de), which is a multi-platform general -> scenegraph-oriented library. I need to take a look at Nomads again... (unfortunately, I have a sharp distaste for C++). But it would be good to look at their architecture, now that mine is fully designed. -> I'm working on putting together a demo, but until then, check out -> the papers which describe the approach I'm taking: -> http://www.asbahr.com/papers.html I will take a look. Thanks! -> It would be useful to identify the common features between the various -> game projects so we can collaborate effectively. I don't want to spam this list with off-topic 3D game mails. Perhaps a "twisted-3d" list is called for? Until then, please follow-up with me privately. -> Does the fact that you are using Quake-style approach mean that you -> will want to consider the world in terms of "levels", versus terrain -> chunks or "rooms"? No, I consider the world in terms of generic "Entities". Renderable entities have a "model" member, which is itself a C extension class. Then when the entity goes to render itself, it calls the C 'render' function of the model. This is because many model types (i.e. BSPs and Quadtrees) have culling information intrinsically built into the model format, and it makes sense to use C to do that. My engine will (eventually) allow for several BSPs within either a landscape, or in outer space. Imagine a game like HomeWorld, except that you can crash-land your small fighter in the landing bay of an enemy frigate, jump out of your fighter (First Person Shooter ala Quake), and now -- within the BSP of the ship -- run around hallways and corridors until you reach the control room, kill the command crew, and take over the frigate. That is the kind of flexibility I am aiming for; the "frigate" entity would detect if the camera (i.e., viewer perspective) is within the ship. If not, it would render a mesh model. If yes, then it renders its BSP tree. What's really cool is that my BSP code, unlike any other BSP-based engine I've seen, allows sharing of the static data, including OpenGL texture names. So you'd have the BSP in memory once only, but be able to have 50 frigates (any one of which you can crashland into). The same theory would apply to buildings, underwater settlements, etc. I hope to soon support meshes, particle systems, landscapes (dynamically loaded lists triangle strips), and later on streaming media. All I need to do to add those is write a C struct to hold the data, and then implement the render() and collide() APIs for those structs. The rest is handled in Python. I will read your papers soon. Thanks again. --Derek
well, the piece of Twisted that is immediately relvant for this type of application is twisted.spread - comprised of "pb", "jelly" and "banana". these provide a distributed object system with marshalling, serialization, networked observation and reference counting. All things that are useful for building on-line games! This technology is not optimized at the level of Quake or Tribes style protocols, but it is infinitely more flexible and provide a much higher level of functionality. I have some (incomplete) code for a primative "sub-space" clone that I wrote using Twisted a while ago. It probably doesn't even work with the latest Twisted build - but maybe it could be a starting point for some pb examples? I could post it somewhere if anyone is interested. -----Original Message----- From: twisted-python-admin@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Derek Simkowiak Sent: Wednesday, March 13, 2002 8:15 PM To: twisted-python@twistedmatrix.com Subject: [Twisted-Python] "3D Game Using Twisted?", or: "Ach du lieber..." Hello. My name is Derek Simkowiak, I've just been introduced to Twisted by Sean Riley (sean at twistedmatrix dot com). I'm using (and now contributing to) his PyUI widget set for my 3D game engine. When I told him I still needed to write the networking code, he pointed me here. I wanted to introduce myself, ask for some general guidance about a network protocol, and point out that the documentation titled "The Basics" at http://twistedmatrix.com/page.epy/docs/basics.html results in "no such page", which really sucks for somebody just getting started (like me). First, a little bit about my game engine, because it's the type of thing you twisted Twisted people might be interested in: o OpenGL for rendering o SDL for event management o Quake2 BSP map rendering (many more model formats to come soon) - includes almost all of the Id BSP culling tricks - includes fully-functional collision detection using the Q2 "bloated planes" algorithm, as figured out by Kekoa Proudfoot o Complete in-game GUI over the top of the 3D world, including transulency, using the PyUI widget set. Screenshot at: http://www.realloc.net/~dereks/targa_pyui1.jpg Also see the older shots at: http://www.realloc.net/~dereks/commputers/my_code/targa/ Also, the big piece that you may like: I've recently refactored the whole damn thing, and with a little help from SWIG my "engine" is now nothing more than some Python C extensions. My "main event loop" is just a simple Python script, and because all the [bottlenecking] rendering code is still C, I get the ~70 FPS I was getting when the entire engine was pure C. But now I have Python at my disposal, mua ha ha. (Also, note that all the libraries are cross-platform. I'm developing under Linux, but eventually this thing should run under MS-Windows, Mac OS X, AmigaOS, and even PlayStation2.) The big pieces I have left are the enemy A.I. and the networking code. This is a client-server engine. The light at the end of the tunnel is load-balanced Linux cluster (using LVS) serving up a persistent, 3D world (ala' PlanetSide), and maybe even me making some $$$ from a few hundred subscribers paying $5/month. Now you see where Twisted fits in -- I'm basically shooting for twisted.reality in real-time 3D. My concern is regarding bandwidth. My game protocol will be similar to the Quake2 protocol, meaning huge lists of 'entities' are updated with position and orientation data as often as possible. Such generic position updates will be done with UDP, and 'critical' packets (such as damage, explosions, jumps, messages, etc.) will be done with TCP. In summary, every single byte of network overhead matters -- nay, every BIT matters (npi). So I've browsed through the API docs, but I don't have any context to know what I'm looking at. I'll be downloading and installing the source soon, but in the meantime... any advice? Is there any particular package I should be looking at (other than twisted.internet)? Does Twisted's networking code cater to somebody who needs to, for example, do bitshifting and compression to absolutely minimize the bandwidth requirements? What approach would you take? Note that, using PyUI for the GUI and [possibly] Twisted for the server, I want to have things like in-game "IRC/ICQ", in-game "emails", and also in-game "voice chat" ala CounterStrike 1.3. Other wild ideas include in-game video conferencing, and dynamically-downloaded bits of Python code that would act as all-new, not-previously-imagined entities. (Note that by "in-game" I mean the 3D world is rendered, and the email/IRC/video client application is rendered on top of the 3D world with some translucency. The idea is to keep the player immersed.) Any advice is greatly appreciated. If anybody else is using Twisted for something similar, I'd love to hear about it. Thanks, Derek Simkowiak dereks at realloc dot net _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-> well, the piece of Twisted that is immediately relvant for this type of -> application is twisted.spread - comprised of "pb", "jelly" and "banana". -> these provide a distributed object system with marshalling, serialization, -> networked observation and reference counting. All things that are useful for -> building on-line games! Very cool (although, I have to say it, I'm not really a fan of 'cute' API names. I much prefer clarity and conciseness.) Also, twisted.spread could easily be confused with the "Spread" C library, which is also designed for use in distributed systems. It has a somewhat different purpose, but my first thought was that twisted.spread was a Python interface to the Spread library (which would be really useful for Twisted, by the way). See http://www.spread.org/. -> This technology is not optimized at the level of Quake or Tribes style -> protocols, but it is infinitely more flexible and provide a much higher -> level of functionality. Unfortunately, most people _HATE_ a laggy gaming experience (i.e., see the "Damn Lag" T-Shirt at ThinkGeek.com). For my application, the need for efficiency outweighs the other features of twisted.spread. However, I could probably use twisted.spread for "administrative" networking. That would be things like text messages, download of resource files (meshes, textures, etc.), changing levels, etc. -- things that don't need to be updated at ~70 FPS. -> Twisted build - but maybe it could be a starting point for some pb examples? -> I could post it somewhere if anyone is interested. "More examples" is always better than "fewer examples" :) Thanks for the help! --Derek
In the spectrum of protocols ranging from generic but bandwidth heavy protocols like SOAP to highly compressed and specific protocols like Quake, "pb" falls somewhere in the middle - but much closer to the Quake end. It has been optimized for use in games, while still providing generic functionality. "Lag" is much more of an issue than just protocol design. Tricks such as client-side prediction, intelligent weapon design, distance based attenuation and aggressive visibility calculation make a huge difference. With the right game design and the optimizations that are planned for pb i think it could be used for FPS type applications. There could even be an extension to banana (the protocol packer) specifically for these application that knows about 3d co-ordinates, movement packets and other common packet types. This banana extension could do bit-shifting, low-precision floats and compression, or any other tricks learned from the FPS crowd. I am definately planning on using it for all in-game traffic within the 3D virtual spaces I am building. I'd encourage you to do the same - at very least consider using extensions to pb rather than writing your own protocol framework. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-> "Lag" is much more of an issue than just protocol design. Of course, and I have been studying heavily all of the things you mentioned (prediction, et. al.). But just to give you an idea of how optimized the 3D protocols are, Sony's PlanetSide only uses 4 bits for the Z component of it's entity origin update packets (because they are using tricks to get around the loss in granularity). Also, as the guy who going to have to write the code, I'm kind of looking forward to playing with different optimizations and "tricks". If I'm just calling somebody else's library, I lose all that fun :) -> I am definately planning on using it for all in-game traffic within the 3D -> virtual spaces I am building. I'm highly interested in this work; I would love to see what kind of response times you get with twisted.spread (and which 'tricks' you employ :). -> least consider using extensions to pb rather than writing your own protocol -> framework. Because you are so persistent in this recommendation, I will take a very close look at pb. But presently my intuition says I'll be writing my own. --Derek
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. This depends on adding "profiles" to the banana protocol, which is on our TODO list.
-> 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. 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. 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.) Thanks, Derek
On Thu, Mar 14, 2002 at 01:47:26PM -0800, Derek Simkowiak wrote:
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.
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.
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 :) -Andrew.
On Thu, 2002-03-14 at 17:13, Andrew Bennetts wrote:
And yes, this is where a lot of often-neglected network trickiness happens -- actually getting more data into each packet. Balancing latency against keeping a full packet payload is hard.
And, while pb is designed to be extended to do just this, the amount of application-specific optimization necessary for a first-person shooter is really phenomenal. You'll need to optimize PB down quite a bit further than it's already been (although PB is built to be optimized, so it's not really a problem) even to be adequate for the control stream. The biggest problem I can see you having with the protocol itself is the fact that it only operates over TCP. A UDP extension for doing things like movement packets would be really handy!
I really know nothing about the internals of twisted.spread, but extending it sounds like a better idea than building a new one.
twisted.spread, and Perspective Broker, are both designed to be highly extensible. Itamar is currently working on the final iteration of banana, which will define some mechanisms for backwards-compatibility, as well as enabling us to write an RFC. Consider ancillary services that are going to interoperate with your game, too; if you are extending PB in order to do your game protocol, then applications like game browsers, high-score charts on webpages (and so on) will come together in a snap. Other folks are also writing games that use Twisted for networking, and it would be neat if they could all talk to each other!
Networked games are tough, and Derek's concerns are valid. My point of view on this is that PB cannot handle such a game by itself, but it defines mechanisms for extensibility that are designed to solve exactly this sort of problem. PB's purpose is twofold. It does provide a useful, generic, high level protocol that one can use out-of-the-box in lots of different kinds of applications. However, I also hope to provide a sort of meta-standard for protocols that have domain-specific optimization requirements, so that real systems that solve hard problems can communicate lower-priority (e.g. "the ones that don't have to be as close to real time as possible") messages using a mechanism less abusive to their performance requirements (either on the network in CPU) than XML-RPC, and easier to add new messages to than something like CORBA. For most systems, this should really be good enough. Ideally I'd like to replace HTTP with it, but that's obviously a bit more work than has been done :) (Smash the web!) Despite the fact that I want to provide a reasonably efficient network layer, my own humble opinion is that systems that are so latency-sensitive that PB doesn't work for them out of the box are probably kidding themselves about the latency issues that arise just by using the internet... but I think that John Carmack disagrees. At the very least, PB should help one get off the ground and start prototyping game functionality really early, before one worries about seriously packing the network protocol; if one's game is just a 3D shooter this is probably not that interesting.
On Thu, Mar 14, 2002 at 01:13:51PM -0800, Derek Simkowiak wrote:
My advice with "tricks" is avoid them until the last moment of implementation. Too many designs get complicated beyond redemption by "clever tricks" too early in the piece. You end up with a tangled mess that breaks every time you look at it, and usualy turns out slower than a "trick-free" clean implementation of a good design.
My advice would be to prototype using Twisted, then optimise to C later if it is needed. Python will allow you to easily re-factor the whole design again and again untill you get it right. If you start in C, the re-factoring will hurt enough that you will avoid it and employ "tricks" instead :-) My gut feeling is that a good twisted implementation will be fast enough at throwing bytes over a wire. Optimising to C will only buy you CPU, not reduced latency and/or bandwidth. The really critical thing will be the design, ie what data you send, and how it is used to present a consistant world view. Be prepared to think "outside the box" when at the design stage, and prototype and experiment extensively. There are some potentialy groovy ideas floating around based on "distributed data fusion", where all the nodes maintain their own view of the world, which is used to correct and is corrected by the other nodes "world views", using karmen (spel?) filter techniques. This is a generic approach to resolving a concensus world view between multiple distributed sources of information. -- ---------------------------------------------------------------------- ABO: finger abo@minkirri.apana.org.au for more info, including pgp key ----------------------------------------------------------------------
(note, this message is a bit stale. I composed it yesterday, but my mail server (twistedmatrix.com) went down for a bit.) On Thu, 2002-03-14 at 01:31, Derek Simkowiak wrote:
At least 'spread' and 'pb' are sane names -- spread is a toolkit for spreadable computing (as opposed to distributed computing, which we make the dinction with because spreadable is translucent as opposed to transparent), and we have PerspectiveBroker which is.. a broker for Perspectives (which were named with the rule of clarity and conciseness in mind -- in fact, Glyph spent an obscene amount of time coming up with this name). :-) I'm only saying all this because I think disliking the name is pretty irrelevant when it comes to code ;-) Anyway, see below, not *all* of this message is a troll ;-)
Well, there's not much we can do about this but try to make it clear that it's not in the documentation/website (which we do).
You might want to take a closer look at the banana protocol. It was definitely implemented with efficiency and extensibility in mind. My point is, a UDP alternative for it would be very cool, especially if we could integrate it higher-level abstraction, like a subset of/something similar to PB, for example (this would an interesting challenge to think about). The biggest problem here is CPU-time that banana/jelly take up -- but this problem is being targetted, especially with dash's work on twisted.eco. :-) -- Chris Armstrong << radix@twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/
participants (9)
-
abo＠minkirri.apana.org.au -
Andrew Bennetts -
Andrew Bennetts -
Christopher Armstrong -
Derek Simkowiak -
Glyph Lefkowitz -
Itamar Shtull-Trauring -
Jason Asbahr -
Sean Riley