Re: [GD-General] Game data editor

[Jon W. <hp...@mi...>]

Ola Olsson wrote:
> So having seen this kind of system grow (often painfully) at a number of 
> companies and projects now I was wondering if there are any useful 
> middleware out there. I did get a pointer to 
> http://www.fluxfoundry.com/fluxfoundry.html from a reply off-list, which 
> seems like it could be that kind of thing, I've only had a very quick look 
> at it yet though.
>   

If you want integration with a 3D scene renderer, then it is generally 
hard to make that generic, because your 3D renderer or scene graph 
likely looks different from any other 3D package out there. That's why 
those kinds of links typically are edited in the "world editor" that 
comes with the specific 3D package or game engine. Unreal has UnrealEd, 
Gamebryo has their editor, C4 has World Editor, Source has Hammer, etc.

Fluxfoundry seems to appreciate this, too -- it's not an editor, it's a 
collection of libraries to build an editor. However, given that your 
game probably has special kinds of geometry and special kinds of 
properties, and hopefully your game package already supports ray casts 
and the like, it's unclear how much that would help, compared to just 
embedding your own engine in a GUI host. C#/.NET is great for this, 
although MFC or something similar would work well, too. Just make sure 
to plan for things like undo (by doing all operations through command 
objects) or property exposure (by building enumeration into your entity 
interfaces) up front.

In my estimation, 60% of "building a game engine" is actually building 
the tools to allow building good games without too much friction. On top 
of that, you then have to build the game itself. If your previous 
studios have not taken this to heart, but instead just throw the junior 
engineer at "the tool," then of course it will be painful -- the process 
doesn't match the requirements.

Cheers,

             / h+

-- 
-- Revenge is the most pointless and damaging of human desires.