Re: Game data editor

Hm I'm not sure what you are trying to say here, perhaps it is "I don't know 
of any such middleware", you seem to want to tell me to build it from 
scratch using MFC or .NET when I'm asking for middleware?

I agree that tool development is a large part of the development time, which 
is again why I am interested in finding someone who has done part of the job 
already. You seem to be saying that people in my past don't take tools 
seriously enough (agree there!) but at the same time suggest that I "just" 
embed my "engine" in MFC or .NET. It doesn't make sense, there is no "just" 
about writing an IDE for your game.

Integration with a 3D renderer (doesn't neccesarily have to be the same as 
used in game) was just an example of something I want to be able to _do_ 
with it, not have provided out of the box.

Just to clear another thing up: I'm interested in editing the source data, 
which may or may not resemble the data at run-time, some things do some 
don't, but it doesn't matter. So to stress the point I want the editor to 
have NOTHING to do with ingame data representation, that should be prepared 
from source data by the pipeline, much like we don't usually edit object 
files as programmers, thats what compilers are for.

I've whipped up with a short list of desirable features (fairly random):
* Interface to supply/get data base (.csv or XML or SQL or whatever)
* Interface to supply/get meta data (for example constraints, tool tips, 
whatever).
* Commands with Undo/Redo (preferably with a transaction mechanism, grouping 
commands that should be undone/redone together).
* Ability to connect version control system.
* Extensible menus.
* Extensible views of the data (this includes 3D views).
* Message pipe or other convenient way to communicate between different 
views/components/things.
* Ability to script both GUI and behaviour (preferably C# or something 
sensible like that).
* Docking windows framework.
* Typed ID/Reference support, for linking  data fields to other things, bit 
special case perhaps, but it keeps cropping up.
* Modular design, e.g. a set of libraries that can be used more or less 
independently.
* Library of nifty widgets.

There is probably a lot more that a well-designed Api can provide, and I was 
hoping that there was some 3rdparty ppl out there who have such a thing up 
their sleeve, and some developers out here that have used it in their 
productions. So far the only thing like it seems to be fluxfoundry (or 
spielwerke or whatever it is really called), but I don't know of anyone 
who's used it.

Anything else out there?

cheers.
.ola

----- Original Message ----- 
From: "Jon Watte" <[email protected]>
To: <[email protected]>
Sent: Sunday, September 02, 2007 12:12 PM
Subject: Re: [GD-General] Game data editor


>
>
> 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.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Gamedevlists-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557