Index:
Comment 2
I've had lots of random thoughts about LevML recently. Here are some, laid out in paragraph form as I think better that way.
I'm envisioning four layers of complexity, three of which are universal, while the fourth is engine/genre-specific. The upper layers are built upon the lower. In this manner, designers and tools can have as much complexity at their disposal while not sacrificing higher-layer elements.
The lowest layer are 3-D primitives--planes, polygons (are these synonymous?), etc. Not really having much experience with how 3-D environments look and what elements comprise them, I'm not sure how all-encompassing this layer should be. What, exactly, are skyboxes? They seem to be a common feature of many engines, so would it be best to include them in this lowest layer? What about heightmaps for terrain?
I'm also envisioning a second layer atop this first, perhaps using the lowest-layer primitives to create more common shapes. For instance, this layer could include cubes and other 3-D shapes, whether they're solid or hollow, etc. Would it be better to consider skyboxes and heightmaps on this second layer, defining them in terms of first-layer primitives? Or do most engines consider these as primitives, and would defining them in terms of planes take control from the engine itself?
The third layer would include a plethora of common game objects, most defined in terms of second-layer elements, but with the option of dipping into the first layer for more fine-grained control. For instance, a room might start as a generic cube with openings defined. However, it may contain windows and doors, which fill the open bits on the cube's surface with portal primitives (there's another primitive idea which I'd envision on the first layer.) The third layer might also include some facility for defining entities in terms of their appearance, then attaching other bits of metadata which engines or tools can incorporate in the next layer to add additional functionality. This layer doesn't have any concept of mechanics, though. It only concerns itself with defining appearance and, perhaps, animation characteristics. Also, there is a set entity tag for this, and no new tags are introduced here.
The fourth layer is game-specific. Here we define lightswitches, buttons, gremlins, whatever objects the game needs. They are defined in terms of the previous layers, and are usually done with specific, newly-introduced tags. The idea here is to have one tag be both highly customizable and do lots of work, such that slapping down game locations and entities is a simple, straight-forward process. Ideally, there should be some mechanism for mapping tags to some symbolic representation such that a compiler can either guess at some lower-level equivalence, or introduce some sort of element into the level to represent the unknown tag. For instance, if someone is designing a level for a strategy game, and uses various terrain elements that have yet to be defined in the strategy game engine, the compiler should have some mechanism to map these unknown elements to areas of colored fog or another common visual element to offer some representation of how the level might look once the fog is replaced with trees, marshland, etc. Of course, this would also require designers of fourth-layer elements to share attribute names with the spec, and might produce pseudo-unpredictable results after compilation, but it would at least offer level designers an opportunity to scope out levels visually before the engine for which they are being developed is ready to render them.
The idea of expressing all levels as a series of cubes, while interesting, may be too simplistic and limiting for all designs. Also, designing a room as a series of stacked cubes might make certain tasks rather difficult (I.e. splitting the room into a series of cubes to allow for openings, etc. Most engines (and the .map format, from what little I've read of it) seems to use planes, so it may make better sense for LevML to use this approach as well.
-- NolanDarilek
Comment 1
Here are thoughts on some of the areas that we need to consider when developing the standard
LevML Technical Details
Co-ordinate Systems
Absolute (not recommended but there for completeness)
Relative
Percentage
Alignment values (centre, left, right)
Example tag for aligning an object
"Solid" Elements
Making Rooms, Walls
Room element (creates hollow cube)
Outside areas
...
Entities
Separate namespace allows for extensions
Doors, lights, buttons, are entities
Texturing
Face element? Each "solid" element has a known number of faces.
How to apply another texture on top in a certain place (e.g. logo)
-- MatthewTyleeAtkinson 2004-11-30 00:03:18