Jump to content
  • Advertisement
Sign in to follow this  
simpler

Inspector GUI

This topic is 2836 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need some advices regarding the inspector GUI in the level editor for a 2D game I'm working on.
With inspector GUI I mean on the left side all attributes of the selected object should be displayed and editable. Like position, width, texture, rotation etc... I got everything up and working but as I'm going to add more objects to the game I need to display different "attribute windows".

Like if I got a platform selected I want to display stuff like


X, Y, Width, Height, Texture
etc..


on the inspector gui, but if I got a lightning source selected I want to display

X, Y, Color, Diffusion, Contrast
etc..


Here's a screenie on how my inspector gui looks if I have a normal platform selected: http://i.imgur.com/CyFTN.png

Up until now I've just been checking with if-statement what type the current object is and then display the according gui elements. The code for that is ugly and it looks like this:



// moving platforms and enemies share the same controls for now, later enemy needs to have health and damage ...
if((activeObject->mObject->getType() == MOVING_PLATFORM || activeObject->mObject->getType() == NORMAL_ENEMY)
{
tStartX->setVisibility(true);
tStartY->setVisibility(true);
tEndX->setVisibility(true);
tEndY->setVisibility(true);
tSpeed->setVisibility(true);
iStartX->setVisibility(true);
iStartY->setVisibility(true);
iEndX->setVisibility(true);
iEndY->setVisibility(true);
iSpeed->setVisibility(true);
}
else if(activeObject->mObject->getType() == STATIC_PLATFORMA)
{
tStartX->setVisibility(false);
tStartY->setVisibility(false);
tEndX->setVisibility(false);
tEndY->setVisibility(false);
tSpeed->setVisibility(false);
iStartX->setVisibility(false);
iStartY->setVisibility(false);
iEndX->setVisibility(false);
iEndY->setVisibility(false);
iSpeed->setVisibility(false);
}


In the long run that won't work and I don't understand how I should solve this problem. It don't feel like the editors responsibilty nor the objects themself. Should I make some kind of interface for the gui elements? If so, then how would I design it ?

Anything is helpful :)

Share this post


Link to post
Share on other sites
Advertisement
Interesting question. I want to implement a similar "inspector GUI" in my game editor. I'm thinking of the following approach:

  • Have a property container class that can hold different types of data (for example like boost's PropertyTree)
  • Every game object (in my case every game component) has a method to load data from a property container (and one to store). Something like
    void MyObject::loadFromPropertyTree(const PropertyTree& ptree) {
    name = ptree.get<string>("name");
    energy = ptree.get<int>("energy", 50); // 50 is the default value
    }

    • Create a schema for the property tree (which could be a property tree by itself) so that the GUI knows what property is of what type. Example:

      #schema for MyObject property tree#
      {
      name =
      {
      type = "string"
      optional = "false"
      }
      energy =
      {
      type = "int"
      optional = "true"
      }
      }

      • The GUI loads the schema and creates corresponding widgets
      • When you change the properties in the GUI. The loadFromPropertyTree() method gets called.
        Here a code example


        // node: the code is not complete, just to illustrate
        Gui::onSelectObject(GameObject* object)
        {
        PropertyTree schema = getSchemaOfObject(object.getType());
        for(each entity node in schema)
        {
        addLabelWidget(node.get_name());
        string data_type = node.get<string>("type");
        bool optional = node.get<bool>("optional");
        TextEditMode mode = TEXT;
        if (data_type=="int")
        mode = INTEGER;
        else(data_type=="float")
        mode = REAL;
        addTextEditWidget(mode);
        }
        }

        Gui::onSubmitText()
        {
        if (!checkInputMatchesSchema())
        // error, do something
        PropertyTree ptree = buildPropertyTree();
        getSelectedObject().loadFromPropertyTree(PropertyTree ptree);
        }


        This is my idea. It would be nice to hear the opinion of others about this approach and other ideas.

Share this post


Link to post
Share on other sites
Interesting idea. I've never touched the boost library before (should i?) so I didn't grasp everything. But what you basicly do is that you write and read from a "virtual" XML, [font="sans-serif"]INI or JSON file?[/font]
[font="sans-serif"] [/font]
[font="sans-serif"]How would you handle the widgets if one changes the selected object? Will you delete all widgets that the last active object used and then create the new one as needed? It seems like the easiest way of doing it but if the last active object and the currently active object shares some widgets then it feels a bit unnecessary, but it mightn't be worth the effort to care about.[/font]
[font="sans-serif"] [/font]
[font="sans-serif"]
[/font][color="#1C2837"]Have a property container class that can hold different types of data (for example like boost's PropertyTree)[/quote]
[color="#1C2837"]It's that one that stores all the attributes, right?
[color="#1C2837"]
[color="#1C2837"]
[color="#1C2837"]
[font="sans-serif"] [/font]
[font="sans-serif"] [/font]

Share this post


Link to post
Share on other sites

I've never touched the boost library before (should i?) so I didn't grasp everything.

There are a lot of nice things in the boost library that help you with many tasks in C++, like smart pointers, function objects, signals, foreach. I use it quite often.
The boost PropertyTree is something like

struct ptree
{
data_type data; // data associated with the node
list< pair<key_type, ptree> > children; // ordered list of named children
};

If some part of the code is not clear because I'm using boost, just post the corresponding lines.



But what you basicaly do is that you write and read from a "virtual" XML, [font="sans-serif"]INI or JSON file?[/font]
[/quote]
Yes I think I would do that, but you can also hardcode it, since the schema cannot be changed without changing the code. (Except you want to add something like a "display_name" entry for the GUI that you could change without breaking the code)



[font="sans-serif"]How would you handle the widgets if one changes the selected object? Will you delete all widgets that the last active object used and then create the new one as needed? It seems like the easiest way of doing it but if the last active object and the currently active object shares some widgets then it feels a bit unnecessary, but it mightn't be worth the effort to care about.[/font]
[/quote]
In my case I would use some sort of tree view widget because my properties can have children. Every time the selected object changes I delete all entries in the tree and add the entries for the new object. I think you don't need to optimize things here, it should be fast enough... (But if you want you can for example pre-create some text edit widgets and label widgets and hide/show/edit them corresponding to the number and type of options you have)


[font="sans-serif"]
[/font][color="#1c2837"]
Have a property container class that can hold different types of data (for example like boost's PropertyTree)[/quote]
[color="#1c2837"]It's that one that stores all the attributes, right?
[/quote]
I don't know what you mean by attributes. If you mean the attributes of the different object classes, then yes, more or less (you only need to store the attributes that need to be stored...).
The property list for my physics component would be something like


damping = {
linear=0
angular=0
}
shape = {
comp_name="shape1"
density=5
friction=0.3
restitution=0
}
shape = {
comp_name="shape2"
density=1
friction=0.6
restitution=0.1
}

Share this post


Link to post
Share on other sites
[color=#1C2837][font=sans-serif][size=2]I don't know what you mean by attributes. If you mean the attributes of the different object classes, then yes, more or less (you only need to store the attributes that need to be stored...).[/font][/quote]

I mean the the variables that will get displayed on the gui. Like x, y, width, height, rotation etc..

I think I know what I have to do now, will certainly check out boost a bit more. Thanks alot :)

Share this post


Link to post
Share on other sites
You are welcome.
I think I don't really need a tree. A list of properties should be enough (with support for arrays).
But Boost.PropertyTree is already there, and it is easy to use. I will think about it...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!