gamedevlists-general

[GD-General] Game data editor

[Ola O. <ola...@gm...>]

Hi!

It seems that every game I've worked on there is a lot of energy spent =
on getting a GUI editor going for designers and others to handle the =
input data of the game. Seeing as it is fairly similar stuff most of the =
time I was wondering if there are any off-the-shelf products out there =
that can do the job? Of course there are those that come with a game =
engine, but I'm after stand alone tools or frameworks (unless the tools =
associated with a given engine could be used in this way of course).

Any pointers?

cheers
.ola

Re: [GD-General] Game data editor

[Research (GameBrains) <res...@ga...>]

http://omegame.com/english/products/menus_master.php

http://www.anark.com/entertainment/gameface-features.html


On Sep 3, 2007, at 3:07 AM, Ola Olsson wrote:

> Hi!
>
> It seems that every game I've worked on there is a lot of energy  
> spent on getting a GUI editor going for designers and others to  
> handle the input data of the game. Seeing as it is fairly similar  
> stuff most of the time I was wondering if there are any off-the- 
> shelf products out there that can do the job? Of course there are  
> those that come with a game engine, but I'm after stand alone tools  
> or frameworks (unless the tools associated with a given engine  
> could be used in this way of course).
>
> Any pointers?
>
> cheers
> .ola
>
> ---------------------------------------------------------------------- 
> ---
> 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
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

Re: [GD-General] Game data editor

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

You are talking about building GUI tools for the data editing, right?

I would suggest using a database tool of some sort (such as Access) if 
you need fancy forms. What we do is get away with Excel -- you can 
script and macro it to do all kinds of neat things (pop-ups, etc), and 
exporting to CSV is very simple in the end.

There is also Microsoft InfoPath for workflow data capture and 
management, but I think that's overkill for this requirement.

Cheers,

          / h+


Ola Olsson wrote:
> Hi!
>  
> It seems that every game I've worked on there is a lot of energy spent 
> on getting a GUI editor going for designers and others to handle the 
> input data of the game. Seeing as it is fairly similar stuff most of 
> the time I was wondering if there are any off-the-shelf products out 
> there that can do the job? Of course there are those that come with a 
> game engine, but I'm after stand alone tools or frameworks (unless the 
> tools associated with a given engine could be used in this way of course).
>  
> Any pointers?
>  
> cheers
> .ola
>  
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

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

Re: [GD-General] Game data editor

[Ola O. <ola...@gm...>]

Yes, I realize that was a bit unclear, that is indeed what I intended.

Using excel seems all very well, if all you want is data input. However I 
guess my direction is more along that of a data IDE, so if you want to view 
items in a 3D view, perhaps to visually connect items (trigger opens _that_ 
door). There is usually other things that you want to do with this IDE, for 
example we have a remote console, as well as a dialog box for running the 
data conversion tools. I don't suppose this kind of stuff can be achieved 
using excel or axcess?

Will have to have a look at what InfoPath might be, but it sounds like it 
will be, perhaps not overkill, but too much killing on the sides at least... 
im sure it will integrate with outlook (shudder).

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.

cheers
.ola
----- Original Message ----- 
From: "Jon Watte" <hp...@mi...>
To: <gam...@li...>
Sent: Sunday, September 02, 2007 11:04 AM
Subject: Re: [GD-General] Game data editor


> You are talking about building GUI tools for the data editing, right?
>
> I would suggest using a database tool of some sort (such as Access) if
> you need fancy forms. What we do is get away with Excel -- you can
> script and macro it to do all kinds of neat things (pop-ups, etc), and
> exporting to CSV is very simple in the end.
>
> There is also Microsoft InfoPath for workflow data capture and
> management, but I think that's overkill for this requirement.
>
> Cheers,
>
>          / h+
>
>
> Ola Olsson wrote:
>> Hi!
>>
>> It seems that every game I've worked on there is a lot of energy spent
>> on getting a GUI editor going for designers and others to handle the
>> input data of the game. Seeing as it is fairly similar stuff most of
>> the time I was wondering if there are any off-the-shelf products out
>> there that can do the job? Of course there are those that come with a
>> game engine, but I'm after stand alone tools or frameworks (unless the
>> tools associated with a given engine could be used in this way of 
>> course).
>>
>> Any pointers?
>>
>> cheers
>> .ola
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
> -- 
> -- 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
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557 

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.

Re: [GD-General] Game data editor

[Ola O. <ola...@gm...>]

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" <hp...@mi...>
To: <gam...@li...>
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
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557 

Re: [GD-General] Game data editor

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

Ola Olsson wrote:
> 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 guess what I'm saying is "view the .NET framework as middleware, 
because it has lots of the functions you're asking for already."

How much are you willing to pay?

Anyway, I agree that fluxfoundry is the only thing out there (other than 
general application frameworks) that comes close. If you try it, please 
let us know how it goes!

Cheers,

          / h+



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

Re: [GD-General] Game data editor

[Sylvain G. V. <vi...@ii...>]

Hi,

Usually Maya will do quite a good level editor.

Good things with Maya:
 * 80% of the work is already done,
 * quite sable, * artists and designers already know the tool,
 * one call create custom tools and interfaces using MEL,
 * one can have a realtime game-like rendering using CgFx/ColladaFx and
shaders.

The bad points being:
 * no immediate level testing, data has to be exported to game format (I
like using Collada + custom tools there) before being usable.
 * the rendering isn't exactly the same (no shadows for example),

From: Ola Olsson <ola...@gm...>
> [...]
> 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.