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

Derek Simkowiak dereks at realloc.net
Wed Mar 13 20:32:01 MST 2002


-> > 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





More information about the Twisted-Python mailing list