4ian / GDevelop

:video_game: Open-source, cross-platform game engine designed to be used by everyone.
https://gdevelop.io
Other
6.4k stars 717 forks source link

Idea - Automatically show default variables on each instance #477

Closed Jeje2201 closed 5 years ago

Jeje2201 commented 6 years ago

Hi, just had a simple request, from now, creating a variable in an object from the object list, and then use this object in the scene would not show it own variable in the object info panel. This gif may show you what im talking about: ezgif com-video-to-gif 1 It would be much easier to have those variables too when we place the object in the scene than creating them back manually, in this gif exemple, my panel would say the text that is in his own variable, so each panel has different text, so I have to edit the variable for each. Same if I want a lever to open a certain door and each lever got a variable "door" with a different number, etc..

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/57432113-idea-automatically-show-default-variables-on-each-instance?utm_campaign=plugin&utm_content=tracker%2F3677421&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F3677421&utm_medium=issues&utm_source=github).
blurymind commented 6 years ago

That seems like a bug

4ian commented 6 years ago

It's not a bug: instances can have variables that will overwrite the variables declared in the object. It may still be useful to display existing object variables in gray or something like this so that it is clear that object variables already exists and that you're going to add new or overwrite existing ones in the instance variables.

Jeje2201 commented 6 years ago

Yes @4ian that's what @Lizard13 told me. That's the usefull part I'm talking about, might help and would be faster, like if for some reason we have way more default variable on some object, instead than rewrite them one per one.

4ian commented 6 years ago

To be sure that everyone understand: if you redefine one variable in instances variables, all other objects variables will still be available.

If you have Object1 with

Variable1: Hello
Variable2: World

If you have an instance with these instance variables:

Variable2: GDevelop

Then during the game, instance will have:

Variable1: Hello
Variable2: GDevelop
Jeje2201 commented 6 years ago

So the title of my request would more be something like "Automatically show default variables on each instance" ?

blurymind commented 6 years ago

Showing them would indeed be very useful :)

On Wed, 25 Apr 2018 11:09 MrJeje_, notifications@github.com wrote:

So the title of my request would more be something like "Automatically show default variables on each instance" ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/477#issuecomment-384235234, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVQnQCZ6KYWPFa4tY_6eSE1jgZKFDks5tsEthgaJpZM4Te9UN .

zatsme commented 6 years ago

What if you change the object variable1 later, will all instances be updated or ??

I would test this to see but not at pc right now :)

On Wed, 25 Apr 2018, 11:20 am Todor Imreorov, notifications@github.com wrote:

Showing them would indeed be very useful :)

On Wed, 25 Apr 2018 11:09 MrJeje_, notifications@github.com wrote:

So the title of my request would more be something like "Automatically show default variables on each instance" ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/477#issuecomment-384235234, or mute the thread < https://github.com/notifications/unsubscribe-auth/AGMbVQnQCZ6KYWPFa4tY_6eSE1jgZKFDks5tsEthgaJpZM4Te9UN

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/477#issuecomment-384237965, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ8mi4yS2mVqBMoHjtCYCjo_XHRUhIOmks5tsE3RgaJpZM4Te9UN .

Lizard-13 commented 6 years ago

I think the grayed out variables idea is pretty good, your instance custom variables shows at the top, and the grayed ones (which are automatically updated when you modify the base object variables) at the bottom, then you can select one of the grayed variables and edit the value to turn it custom. Is that OK?

Jeje2201 commented 6 years ago

you can select one of the grayed variables and edit the value to turn it custom.

That sound perfect @Lizard-13 exactly what I meant / asked for.

4ian commented 6 years ago

(Closed this by mistake sorry!) What was mentionned by Lizard-13 would indeed be the way to go :)

Jeje2201 commented 6 years ago

Awesome :b

Bouh commented 6 years ago

I added $5 bounty on this issue

Bountysource

4ian commented 5 years ago

Hey 👋 I've put this issue on the roadmap (so that anyone can vote for it!) there: https://trello.com/c/bhz39w4Z/76-automatically-show-default-variables-on-each-instance

I'm not closing it as there is a bounty going on on it.

blurymind commented 5 years ago

I've been thinking of trying to tackle this actually. I wonder if anyone else is interested or has started working on it :)

4ian commented 5 years ago

I've not started worked on this, feel free to try! :) Will be really useful.

What I need you will need to do:

For variables in gray/disabled state, don't show the "+" icon or the icon to remove them, but instead show an icon that makes clear that you're going to "overwrite" the variable in the instance.

Most of the work should be in VariablesList/index.js. I think you have to add a props parentVariablesContainer, in addition to variablesContainer. Starting from this you can do what I've written (compute the difference between variables that are in parentVariablesContainer and not in variablesContainer, then see how to display this properly). For display, you'll either want to duplicate/refactor VariableRow into a ParentVariableRow or have new props to tell that this variable should be grayed.

Bouh commented 5 years ago

To go further with variables I have this idea :

Variables can be defined by actions of the type: "Modify" for a Scene, Object, and Global variable. But when they are declared this way they are not in the list of variables (Scene, Objects, Global) Because of the way they are defined. I know that : Modified is not a good way to add a variable. And added a variable in this way makes it not visible at all by the normal means where it is created. I think we need add the variables like this to the list.

blurymind commented 5 years ago

What about variables on object groups? Should an object group have a variable? Should that variable be visible in the inspector?

zatsme commented 5 years ago

Group variables would be useful 😁

4ian commented 5 years ago

Should that variable be visible in the inspector?

Groups does not exist anymore when the game is running, variables are always attached for the scene.

Should an object group have a variable? Group variables would be useful 😁

Please be a bit more precise :) What for? What would be the use case, how it will be used? I'm asking because there are tons of things that could be created for GDevelop, so we don't want to creep the software of unnecessarily or unadapted complex features. Everything needs to be carefully balanced :)

I see one use case of having a common variables shared between objects of the group. But in this case, what will take precedence, the group variable or the object variable? Also how should this be displayed in the editor so that it's obvious at the first glance what the variable is from?

Lizard-13 commented 5 years ago

I think there is an easy solution that doesn't modify the engine: What do you think if groups lets you edit variables, but it will just show variables common for all the objects in the group, and adding/modifying variables here would add/modify the variable in every object in the group. This way it would be just an IDE feature.

4ian commented 5 years ago

This is a great idea! 🙌 This is also similar to the way the "type" of a group is deduced (the type of all objects is checked, and the type of the group is the same as objects if all objects are same type (Sprite for example), otherwise the group is considered as a base object).

So this would need, when opening the "variables editor" for a group, to get the intersection of all variables of all objects of the group. The variables should be exactly the same (same name and same default value) to be displayed there. If values are not the same, or if a variable is not declared in all objects, then it should not be shown.

I wonder though if it will be confusing or not for the users that could not understand why a variable they added to the "group" disappeared after adding an object or modifying the variable of another. ðŸĪ”

Lizard-13 commented 5 years ago

Haha, I though exactly the same, that's a big downside :/

blurymind commented 5 years ago

When I put game objects in a group, its like putting them inside a shared class with shared logic. That logic needs some sort of shared variables to operate :) The idea is similar to construct2's family instance variables: https://www.scirra.com/manual/142/families

Once you add a variable to a group, all of the members of that group have it and can use it

In any case, the problem imo is that all the variables are not visible in the inspector, but are scattered in different sub windows. The left side inspector should be showing all of the variables of a game object. This is consistent in all game engines btw, so gdevelop is kind of going against a common UI design

The group variable thing is something we can do without, by just manually adding a variable to each member of the group. It would just be convenient.

4ian commented 5 years ago

Note that groups in GDevelop are more akin to "interface" or "abstract classes" in programming languages. They do not provide features per se, but allow to manipulate their content in the same way.

In any case, the biggest problem imo is that all the variables are not visible in the inspector, but are scattered in different sub windows.

Yes the main problem for users here is that variables in the instance variables are not showing the variables that are "inherited" from the object, and this can be confusing. A solution would be to display these object variables "grayed out" in the instance variables, to make it obvious that they will be here during the game :)

Also to answer to @Bouh remark:

Variables can be defined by actions of the type: "Modify" for a Scene, Object, and Global variable. But when they are declared this way they are not in the list of variables (Scene, Objects, Global) Because of the way they are defined.

Indeed, GDevelop support dynamically creating variables on the fly using events, but it may be source of errors (if you enter the name of a variable incorrectly) or confusion (people don't understand why the can use any variable name). (It's a good example of a design that is too flexible for users and backfire against them ;)). I don't think we should remove this anyway but in GD4 I made a feature that analyzed the variables used in events and added them to the list => this could be reused in GD5 to have a similar feature.

I'm thinking of something like, at the opening of an object/scene/global variables list editor, analyze the events and if any variable is used without being declared, add a warning or show the variable grayed out with an explanation :)

Both of these features would make more obvious were variables are coming from :)

4ian commented 5 years ago

I've created a card for the second issue (variables declared in events): https://trello.com/c/hTlS55Mg/156-automatically-show-in-the-variable-editors-the-variables-that-have-been-used-in-events-but-not-declared-in-the-variable-list and the first issue is here: https://trello.com/c/bhz39w4Z/76-automatically-show-default-variables-on-each-instance

Jeje2201 commented 5 years ago

Never thought posting idea would move that much of people and other ideas haha 😄

4ian commented 5 years ago

It's often the case ahah - but it's great to foster discussions like this 😉

blurymind commented 5 years ago

as a side note- it would be great if the Objects 'Properties' editor just showed all the variables without requiring to do an extra click for them to appear. That extra step to just view the values of an instance - when you have to do it very often - it really adds up to a lot of clicks. I dont mind having to scroll down a little more to see variables.

So to sum it up - it would be great to have access to all of the selected object's variables and instance variables in one place in the scene editor- without requiring an extra click to show them. Just select an object in the scene and they become instantly visible in the Properties window - No blocking pop ups that break the flow

Godot is a great example of doing that right, but most engines Ides do that as well

Bouh commented 5 years ago

Remember i put on this issue a bounty of $5

Bouh commented 5 years ago

I'va added $6.39 to $5, now it's $11.39USD for this issue ðŸĪŠ Link on bounty source

blurymind commented 5 years ago

Guess I could look into it if nobody else wants to tackle it

4ian commented 5 years ago

I think that's a super interesting feature :) And would help a lot people to understand what's going on with instance variables (as they will see the object variable grayed out, and hopefully understand better than they can "override" them or declare new one for the specific selected instance)

blurymind commented 5 years ago

Ok so just to summarize, we need to:

blurymind commented 5 years ago

The advantage of having the variables list inside the instance properties panel is that it is much easier to compare values of instances. Its instant access and key information is not hidden by default in a popup. This is how Unity3d, Godot and most other game engines do it. When you create new variables, they are accessible directly in the properties panel gdevelop-easyaccess What I want to hear before going further with this is- is it a welcome change? Having them all in one place and that place is instantly visible upon selecting any instance

blurymind commented 5 years ago

instead of popping them out, we could optionally collapse them with something like https://github.com/glennflanagan/react-collapsible

that would add a new dependency to gd5, so I want to see if there is something we can already use

Edit: Will need @4ian 's advice on that. Being able to collapse things will be useful here, although not essential at this point

blurymind commented 5 years ago

some update on this: gdevelop-compact-er

I moved the copy/paste/delete buttons to the add variable row - its more compact that way. Also I think the location is more intuitive there- as editing variables is not split into two rows that way

Wend1go commented 5 years ago

Is this only for instance variables or can we also edit object variables this way? (without having to open the right click menu on an object) Marking an object in the right panel could also show its object variables in the left panel. But I don't know how much work that would be. ^^

blurymind commented 5 years ago

not yet, but the goal is to also be able to edit object variable values when editing instance variables. I am working on it :)

Bouh commented 5 years ago

In this pannel if we have 1 sub-variable the space is tiny, imagine with 3 sub level ? (I prefer open a new windows than resize the panel at each time for see all my variables or idealy a new shortcut on keyboard) Maybe we need compact the previous settings mockup

blurymind commented 5 years ago

We can keep the pop out option if you want to. I don't think that many people will create variables with alot of nesting

On Sun, Jan 27, 2019, 12:22 PM Bouh <notifications@github.com wrote:

In this pannel if we have 1 sub-variable the space is tiny, imagine with 3 sub level ? I prefer open a new windows than resize the panel at eatch time for see all my variables.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/4ian/GDevelop/issues/477#issuecomment-457913227, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVWvamEVv6TadND-cbC3f9Drt3MCpks5vHZn8gaJpZM4Te9UN .

4ian commented 5 years ago

instead of popping them out, we could optionally collapse them with something like

I'm pretty sure we could do it ourselves without a new dependency :) (store collapsed: true or false in the state, render the children or not according to it). But yeah that would be super useful to be able to collapse. Also would improve performance when having a lot of nested variables on large games.

not yet, but the goal is to also be able to edit object variable values when editing instance variables. I am working on it :)

I wonder if it's not too risky, would create a lot of confusion maybe?

We can keep the pop out option if you want to. I don't think that many people will create variables with alot of nesting

Yes a button to open the full editor in a separate dialog sounds a good idea to me.

blurymind commented 5 years ago

@4ian I think that since if one creates an instance variable with the same name as an object variable, that overwrites the object variable - it will make a lot of sense to include the object variables listed as instance variables too. I think I worded it wrong before-

the idea is not to edit object variables (create/remove) in the instance variable editor- but to automatically create an instance variable for each object variable and communicate the user that it is overwriting the default object variable - even show to the user the object variable itself as a placeholder when the field is empty: gdevelop-objectvarplaceholder

I think people who want to create variation in their game will be doing that a lot with instances- giving some of them more HP or attack, etc. So making them manually create overwrite instance variables could become a pain in the neck

4ian commented 5 years ago

Ah yeah, I mean showing the existing object variables as placeholder like you did and with some other visual hints (maybe make the name of the variable also "grayed", to represent that it's "behind", not hidden but still there) is the way to go :)

Lizard-13 commented 5 years ago

It sound like you were trying to add the ability to edit the default object variables from the panel, as 4ian says it would be risky and not related to the instance actually. What Wendigo was asking is to be able to edit object properties from the panel, in GD4 it was possible but in GD5 selecting an object doesn't show attributes in the panel at all.

4ian commented 5 years ago

So it's indeed two different concerns :)

Wend1go commented 5 years ago

I don't think that many people will create variables with alot of nesting

I wouldn't count on that :yum: My Sakawochi game has 5 languages. My GUI variables looked like this:

GUI
  TutorialFrame
      TitleText
          Languages
              EN
                  'Welcome'
              DE
                  'Willkommen'
              ...

You can imagine the length of the list. Especially not being able to collapse anything was a real pain. I went up exporting the languages into JSON files and manually added them to the resources of the project JSON (in a "hacky" way via text editor) to make the game more manageable. Luckily they were just scene variables, not object variables. This is why I don't think it would be a good idea to remove the variables editor dialog altogether. Just a small anecdote. :wink:

4ian commented 5 years ago

Yes, I think this is especially the case for scene/global variables - I have a large game with lots of nested global/scene variables too. So it's both valuable to be able to open the dialog separately with a button (even if instance variables will surely have much less nested variables) and to work at some point on being able to collapse nested variables. Adding the ability to collapse variables can be done separately to showing object variables values inside instance variables. I've created a card for it: https://trello.com/c/ZtiM98XI/241-add-button-to-collapse-show-nested-variables-in-the-dialog-to-edit-variables

If someone want to try, this seems actually not too hard to implement.

blurymind commented 5 years ago

Here is a little progress. I implemented a reset to default button. It shows up only when an instance variable is inherited from an object variable and when their values differ. It works exactly as is done in Godot and unity- you click it and the instance value is reseted to whats in the object it is inheriting from: gdevelop-resettodefault

And also as you can see, the button to open the instance variable editor as a modular pop up is back too. :)

The ability to collapse editors should be for another pull imo - as other parts of the editor can benefit from being collapsible

@4ian any idea why the animation value is showing up below the instance variables button like that? It seems a bit out of place there. I think that it should be above the button

blurymind commented 5 years ago

Another progress report: @4ian asked to add some limitations to this,so now any object variable names can not be renamed from the instance editor, or removed - they are only shown. If their value is changed- in the background what happens is that an instance variable with the same name gets created and listed - we call that an inherited variable, as it overwrites the object one. We can also not create any structured inherited variables automatically - as there is currently a limitation in gdevelop, noted here: https://github.com/4ian/GDevelop/pull/908#issuecomment-459776939 I managed to move down the instance variable button below animations as @Bouh requested and yes it's back as @Wend1go requested

Screenshot here (edited now) :) gdevelop-limtations

its not as pretty as before, but it works better, as it is dynamic and instance variables overwriting the object one get created only when the field is edited, not on mount. Only when required.

I wonder if adding a button+ counter for object variables next to the one for instance variables will make this more intuitive. Right now that command is hidden in a menu on the right hand side objects list

blurymind commented 5 years ago

I now have something working in the pull request. Another thing I did was in adding a button to edit object variables at the bottom: capture That will make it easier to access/discover than having it just in the object list menu imo, but will change/remove it if you guys think it shouldn't be available there

Would appreciate any feedback/review. :) please let me know if you find corner cases where it breaks