No subject


Tue Nov 15 16:38:34 MST 2005


> I think the first question to ask and answer is what our specific
> goals are with this format.  Is this only for Juice, or for other
> authoring tools too? Is it to be loaded directly by games?  Is it an
> issue to be able to read and tweak the format in a text editor, or
> not?  Is it only for rigid body dynamics and collision detection, or
> also for other physics effects, like cloth, etc?  Do we want to
> describe entire game levels, or just separate 'machines'?  Would we
> like to script the behavior of these machines?  Is the graphical and
> audio rendition of the scene to look exactly like what we will see in
> the game, or only an approximation?

Good questions!

I'm looking for a file format to use with my next project.  I could re-use
the Juice format, as it does most of what I care about, but since there's
been talk of a standard file format I would rather explore that, and the
go back and retrofit Juice to use whatever standard comes together.

Basically what I want to create is a multi-user world containing dynamic
system created with Juice or other authoring tools.  There is no
particular purpose for this, it just seems like an interesting project.  
(I do hope that Anselm can finally realize his dream of tripping a Juice
creature with one of his cars, though.)

I would like it to be human-readable, partly because I think that makes
debugging easier, and partly because it makes it easier to generate files
using perl and such tools.

Rigid body dynamics and collision detection are the main things that
interest me, but it seems reasonable to ensure that the syntax allows for
expansion to cover related technologies.

I think of an "entire game level" as a collection of "machines," but that
might be because I'm not a game programmer.

I'd rather treat behavior and scripting as a separate problem - this file
format should cover the "hardware" on which behavior "software" runs.  
That's basically because there are so many approaches, and new approaches
being cooked up daily... I don't think it makes sense to try to specify a
single file format for all of them.  I'd rather just use a pointer (URI,
whatever) to reference behavior specifed in other files.

So now the question is, is anyone else working on a project that has (or
could use), a file format similar to what I've described?  And of the
raised hands, who's interested in creating and/or using a common format?

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com





More information about the ODE mailing list