Avara 2 Code Design

So we've been talking about using Panda3D (and Python) instead of jME3 (and Java). Here's my preliminary thoughts on how we could put it together.

import avara

World

Either extend NodePath or include one as a property, to serve as a parent for any and all WorldObjects that appear in map files: the sky and ground, blocks, ramps, domes, celestials, etc. The list of incarnators will also be stored under World, but not as child nodes of the NodePath. Maybe look at storing a "palette" of Material types here as well that WorldObjects can reference, rather than constructing their own. We'll probably need an easy way to create temporary Materials to simulate glow effects when an object is damaged, though. Certain environmental properties will be tracked here, too, like gravity. Hectors will not be bound to the World at all, I think. Once a level is loaded, we'll attach the World's NodePath directly to base.render. We can detach it just as easily, allowing us to switch maps on-the-fly if need be. Or just, you know, unloading the level once the game is over.

WorldLoader

This is the thing that parses XML into a World object. Alternately, just put all that crap under a "load" method for World. Or a hybrid approach. I don't really care!

import avara.mesh

This module just contains tools for generating geometry. Building quads out of tris from four points (given in CCW order), building blocks or other quaddy meshes from doze quadz, building domes, etc.

from avara.world.environment import *

Sky, Ground, Celestials, AmbientSounds, etc.

from avara.world.logical import *

Incarnators, and... other stuff! This is probably where AvaraScripty things will live eventually.

from avara.world.physical import *

WorldObject superclass and its subclasses, including Blocks, Ramps, and Domes. No need for making a distinction between VisibleObjects/PhysicalObjects like before. In Javara, PhysicalObjects could be marked as holograms making them decidedly un-physical, so what's the point?