New unified variables and variables declaration in GDevelop 5.4

[4ian]

Hi all,

GDevelop 5.4 rolled out an update to variables, which we can call “unified variables”, as well as support for local variables and variables restricted to extensions. We had seen a lot of different questions here and on the discord, so we wanted to put out a unified post rather than one-off responses.

tl;dr:

• Games are not breaking. They will work as before. Don’t panic!
• Still, you must declare variables, but can do this progressively as you work.
• This is not always convenient so we’ll make a UX improvement to address this/speed up declarations.
• The new system is safer, simpler, more flexible and not mistake prone and will save you minutes if not hours of debugging and yelling at your screen. We’ll update tutorials, the documentation and almost all examples soon (in a few days).

Long version:

As with all updates since years, the update in the variables is not breaking any existing game. The new system requires you to declare variables though, which is a change in most people workflow (despite recommending to declare variables since many months, I understand many creators have been avoiding this).

I’ve seen a few people complain because of this new requirement.
This is understandable as it requires a bit more work rather than being just able to write the name of the variable and go ahead (though this is not without risk. Did you ever mistyped a variable name? Keep reading!). Groups also require all their objects to have the same variables so that they can be used.

This can be “flow breaking” but I think this is totally fixable from a UX point of view by having, when you write a variable name in a field requiring a variable, something displayed like “Declare a new Xxx variable…”. When clicked, this will ask you where to put the variable (scene or global, scene by default) and the type (number by default).

This being said, the new system is here to stay as it provides many advantages:

• This is simpler: there is now a single action to change a variable. The action adapts to the variable type and works for all variables: global, scene, local.

  • This means you don’t have to choose between scene, global (or local) actions/conditions, and then between number, string or boolean.
  • This means the search is now returning a unique action instead of 6 before (or 9 with local variables!) (or even more with extension variables).
  • This is akin to most programming languages where you can just do myVariable = 3 (after declaring it earlier). There is a single symbol to affect a variable (=), whatever its type.

• This avoids mistakes and long debugging times:

  • This avoids beginner mistake to declare a variable somewhere, like a global variable, and then use an action to change or a condition to check a scene variable. Now, it will just works (and you can move it later if you did a wrong choice).
  • This avoids you to use a wrong type with a variable. GDevelop will show you an expression editor that is adapted to the variable type. This is good for beginners to understand that a variable is not supposed to go from a string to a number (which is not performant) (but GDevelop will support this in case your force it to do so).
  • This is safer as a mistake like putting a letter with a wrong case (Health vs health) is not possible anymore. GDevelop will tell you that the variable does not exist.
    This was a mistake observed for every single new user and a very frustrating one.

  This is akin to most programming languages that errors when using an undeclared variable (or even prevent you from running your script/compilation) or when affecting a wrong type to a variable (example: TypeScript and most typed languages).

• This is more flexible:

  • If you move a variable from a scene to a global variable, or to a local variable, or vice versa, your events will… just continue to work as before.
    Previously, you had to rework all the actions and conditions and expressions using it.
  • This is even more flexible: extensions can now take “variable” parameters. Which variable though, global, scene or local? Any of them will work.
  • Same for expressions. An expression taking a variable as a parameter will work with any of them. Tell good bye to GlobalVarToJSON, say hello to ToJSON(anyVariable) and it just works.

  This is akin to most programming languages where a variable can be moved from one scope to another.

• This is more concise in expressions (this was introduced before GDevelop 5.4):

  • You can now write "Your score is" + Score instead of "Your score is" + VariableString(Score).
  • Better, you can now write MyVariable[index + 3] instead of GlobalVariable(MyVariable[Variable(index) + 3]). I let you imagine the result if we had to support local variables.

  This is also akin to most programming languages where variables can be be written and it just works.

All of this allowed us to roll out local variables, but also scene/global variables scoped to an extension (useful for extension builders). In the future, all extensions actions/conditions/expressions will work with any variable. No more duplication. We might even think of things like scene folders that contain variables (so, “semi global” variables ;)).

I understand declaring variables might seems like a pain (though this is required in every programming language and other no-code tools), but I think this is actually a “sounds worse, but actually is better” solution (as it teaches beginners that variables are really “something that exists” in memory, with an initial value you can choose). If it was like this since the beginning, nobody would question this Still, we’ll work on:

• How to declare in ~2 clicks a variable from the action/condition editor. Remember you can open scene and global variable editor from here already. Prototyping fast is important.
• See if we can we make it easier to declare a variable for all the objects of a group.

---

I’m leaving this thread opened but remember to stay civil/polite in your feedback.

I encourage you to give it a try for a few days to fell how “good” it feels to just declare your variable once and be using it anywhere without any risk. It’s very pleasant!

[RMDB]

I understand the usefulness of unifying variables so that can be used and swapped when needed.
But that’s the only positive thing I see in the update.

There are worst thing to fix than typos when developing a game.
the old method was much more straightforward in choosing the variable type and imo easy to read.
I’m happy with what i have for now and i’m not going to update. But it doesnt mean that i’m not gonna do it in future if things will improves

[4ian]

@RMDB

There are worst thing to fix than typos when developing a game.

As I explained, this was not the only issue. But I don’t agree This is probably the worst as it’s a very preventable mistake that can takes you hours to find.
It’s making you build on “shaky grounds” and was a reason why people were often complaining of “GDevelop is buggy”.

the old method was much more straightforward in choosing the variable type and imo easy to read.

Sure, but you had to choose the variable type every single time you were using an action. That’s like doing the choice every single time you want to modify it. As for “Easier to read”, I’m not sure as this was forcing us to show “the boolean value of scene variable […]” everywhere. This was very verbose

Not to mention when searching “variable”, you had to choose between so many combination. Is it global or not, is it a number or not… GDevelop already knows this and does the job for you.

Anyway, I won’t reply every time but I think you will get quickly used to it - I won’t rephrase all the advantages but this is something that will help a lot to make robust games. You can of course stay on the old version, but this should be frankly not a hard update once you get used to it, I hope I’m right!

[MagicBiscuit]

Im not gonna question to flexibility part about moving variables since iv never had a need to do it and have no idea about it.

I dont get the rest… mostly the beginner part or the saving mistakes.

If you make a mistake its because you didnt notice it, and then if you hit the what ever easier way to declare a variable youll add, then that variable is declared, but with the wrong name.

What about a string? What if a beginner is writing a text and miss spells something? Gonna add orthographic checks too?

I know its a silly argument but mistakes just happen…

I have poor eye sight and do makes those mistakes where i spell a variable wrong, but the amount of time that i spend looking for it was never that long, and the time i save but just typing in my undeclared is massive in comparisson.

I get the whole, other programming languages do it, in fact i brought that up, but regret saying it, because i find the old GDevelop way that allowed me to just quickly make variables and complex events in seconds, far superior, and i wish it would of stayed.

Lastly, there quite a lot of “beginner” reasons on there…

I was under the impression GDevelop aspired to be more than just a beginner tool or a learning program, that it wanted to be taken seriously as an engine, so making such a big change in favor of “beginner friendly” seems… off in my perspective.

Beginners should learn to double check their stuff instead of just having bells and whistles going off…

Just recently i learned that, was having an issue with an objects collision shape because i made it into an angle… it was bugging out and i had no idea why… as it turns out, it was because instead of removing one of the points from te square hit box, i simply moved one of the edges to be on top of another to make the ramp, no bells or whistles, the thing didnt go red, it broke… but i figured it out, fixed it and learned from it, that was a good experience.

The change is here to stay so no point wasting breath, but it does suck.

Specially since i was sorta hoping that the reason for it was that it had to happen to implement something cool, a new feature that we wanted or something… but no, its just cause it had to happen… thats disappointing.

[ZeroX4]

IDK how it is in other parts of the world but in my country politics set sugar tax for Cola Pepsi Fanta Sprite and all that kind of drinks
Now because of that price of these drinks went up but to keep up price at possible minimum manufacturers did start to include less sugar in these drinks
NO ONE can argue it is better for health of ppl who drink them
YET choice between drink what we used to drink and drink what we have now was taken away and now we have no choice at all
Tax was introduced few years ago and young kinds do not even know how pepsi used to taste and for them something that taste like glass of water with bubbles and sugar is perfectly normal
Where i do know what i should feel when i drink pepsi and it is not what is inside pepsi bottle right now

We could take away 1 click online exports from users and there would be rage over why it was taken away
Yet we could agree if it was never there then no one would complain since it never existed
IF from the start you would need to manually export your game no one would even argue over one click exports

And that pretty much is same with variables now
I am dyslectic i should be all in for that change
I will writhe THEN instead of THAN and i will not see anything wrong with it yet i know exactly the difference since this update takes away something that was available for us before rather THAN giving us choice between wat we hand back THEN and what we have now

I am biased against this change not because declaring is bad but because it took choice away from me do i want to declare var or not
Not all variables i use should be declared or to be precise i should not be forced to declare them

I will give to new system that if i would declare all my vars with my dyslexia I would have easier life with finding them via drop down list
I can’t argue with that that is one superior aspect over not declaring them
Yet i am writing this only because something was taken away from me
Where so far i was working with previous system perfectly fine i had some issues of misspeling some vars yet i never had hours long to solve issue
I say we should have choice between the two and no one would be harmed

[MagicBiscuit]

@4ian

Sure, but you had to choose the variable type every single time you were using an action. That’s like doing the choice every single time you want to modify it.

The heck? Its the same steps now with the update if im not mistaken?

1. Action
2. Type Variable
3. Select Variable
4. Set change
5. Hit apply

Old version

1. Action
2. Type Vari + type
3. Select variable (or simply make a new undeclared one)
4. Set Chage
5. Hit apply

Im not trying to give you a hard time, but this stuff is whats driving me nutts

Its the exact same thing, its not quicker, easier, simpler, what ever, you just have the extra work of declaring the variables first and then managing them

[MagicBiscuit]

Sorry for spamming a little, but i just wanted to add about this whole not having the option thing…

Why not make it into an option?

Training wheels?

If its because of beginners, or wanting to have a safety net, can that be added into options?

You essentially removed a speed work function that was so useful.

The flexibility thing, why not make it only work with declared variables? But if we want to use undeclared, then we can, they just wont do the extra stuff your talking about.

Leave the option for us to quickly work with variables… sorta like an “Advanced Mode” in the options.

If Advanced mode is turned off, they you get the beginner friendly version of GDevelop and do you best to teach them about this stuff, but for us that are ok taking the risk of spelling mistakes gives a mode where we can have way more freedom to do what we want.

[MagicBiscuit]

No one complains about additions (mostly)
People windge at subtle changes
Big changes people arent so fond of

[ddabrahim]

@4ian

The new system requires you to declare variables

I think it is a mistake. As a complete beginner I really liked the fact GDevelop doesn’t force me to do things in a certain order, a certain way and doesn’t throw compile and runtime errors at me just because I forgot something. Instead, GDevelop helped me out and everything “just worked”. It was the primary reason I sticked with GDevelop in the early days and it was a fantastic experience that makes me continue to follow GDevelop and its community to this day.

As a more experienced developer, I do agree with the decision variables must be declared first, it is a good practice, this is what I always do. However, this is what every engine and framework does. It doesn’t help GDevelop stand out in any way. GDevelop is slowly becoming just an other general purpose engine with annoying strict rules to follow.

The old system indeed allowed people to make mistakes, make debugging harder but it is also made GDevelop the most simple entry level option for complete beginners that is taken away now.

I feel sorry about this decision.

What I would have done is consider some automation where as we type in a new variable name that was not declared, instead of displaying a big scary red error message and force people to click through a tree of menus to fix it, just make it work. Declare the variable for us and display only a friendly yellow warning letting the user know the variable was not declared before so if the intention of the user was to use an already declared variable, the user is notified with a friendly warning instead of a scary error message.

[jack]

@4ian

Still, we’ll work on:

• How to declare in ~2 clicks a variable from the action/condition editor. Remember you can open scene and global variable editor from here already.

Good
Yesterday I wanted to make a request for menu buttons to open the scene/global variable editor from the eventsheet, because it takes 5 clicks (or shortcut) for scene variables since it is no longer possible via the expression editor.

Because global variables are overwritten by scene variables in the IDE and their value runtime, maybe we should get a warning when we declare one that already exists?

The “Get a field of a document” (firebase) action should also allow to fill a global not just a scene variable, as exists for Storage.

[jack]

@ddabrahim

As a complete beginner I really liked the fact GDevelop doesn’t force me to do things in a certain order, a certain way and doesn’t throw compile and runtime errors at me just because I forgot something.

I know what you mean but honestly the previous concept forced you to use always the right conditions/actions, which often led to problems, long troubleshooting and confusion with the type.
I think also beginners will understand what creating/declaring variables is. We now have interactive tutorials, very good video instructions and the note directly under the variable field that recognizes when it is not declared.
My biggest problem will be that I often gave global and scene variables the same name.

[ddabrahim]

@jack

think also beginners will understand what creating/declaring variables is.

To teach beginners the correct way of doing things is a valid argument, but for complete beginners there are so many different concepts to learn about, if an engine throw everything at the users at once and expect them to understand all of it before they can run a preview, it could scare beginners away. It did scare me away from many engines and the forgiveness of GDevelop was life saving for me and I learned to navigate around it, never really had much problem with it myself. I really did enjoy the flexibility of GDevelop. It was something no other engine has.

[themitchnz]

Not sure why people are so grumpy lol. I think the new system is fantastic and less error prone has to be more beginner friendly, not the opposite… especially when we can create the variables in line again.

I’m working on a fairly big game that involves 30+ scenes so being able to loop through global variables now is a game changer for me (and something that should have been there day one).

This must have been a huge effort to get right in the backend and not a gucci feature like multiplayer or 3d so I appreciate the core development experience getting some love.

[MagicBiscuit]

Heres something thats been on my mind about this having to declare variables…

So you strictly have to declare variables, because thats how programming works… then how come you can not declare variable in GDevelop and it will work just fine?

Does GDevelop already declare variables for us? Is that how it works? Because if we have to declare them in order to work, but we didnt before and it worked, what sort of magic was it? (i dont mean this in a bad way)

The point is, maybe GDevelop has found a much better way of working and is now making a big mistake by trying to get rid of it.

Is it traditional? No, is it standard? No, is it better? In my opinion Yes, so why not just embrace it and work around it?

Oh i also figured out this whole changing variables from global to scene thing… i was being slow as usual.

I already do that with undeclared variables when i make save states for my game, and it works just fine, i never had any issues with it, no variables missing or anything of the sort… so i dont get how this is a selling point for the new method.

Given i use a java script to collect all my variables, both declared and undeclared and then make the change… but why not make this feature into GDevelop? I was able to make it, and i dont know jack about squat, im fairly certain you guys could do it better.

I understand the motivation and the reason behind the change now… i just dont think its the way forward in any regards.

[jack]

@ddabrahim

the forgiveness of GDevelop

That wasn’t it, capitalization and all sorts of other things caused problems that are now automatically prevented. It removes complexity and so it will be easier and more accessible for beginners.

Working with things that weren’t created isn’t any easier to understand. A bit like the old scene times that became true even though they were never started.

I wouldn’t have needed a varibale system change either and had continued to use the long expression, but ya now it’s here.

[ddabrahim]

@themitchnz

less error prone has to be more beginner friendly, not the opposite…

I feel like need to take in to consideration, there are 2 type of beginners. The one who wish to learn how to do everything the correct way and don’t mind to take the necessary extra steps and time, and there are those who just want to and need to see results immediately to stay motivated. I was the latter and the old system didn’t stop me from learning to do things the correct way but allowed me to just have fun in the process. No other engine offered this freedom.

[ddabrahim]

@jack

Working with things that weren’t created isn’t any easier to understand.

It is not about being easy to understand but easy to start with. Everyone has different experience and started game dev with different backgrounds. When I started my background was empty completely and I disliked the way other engines forced me to do things in a very specific way forced me to learn concepts before I was able to do anything. I loved the way GDevelop allowed me to just play around it just worked.

[MagicBiscuit]

@jack

Working with things that weren’t created isn’t any easier to understand.

This is subjective and wrong in my personal experience.

When i was learning how to use variables in GDevelop, i thought you had to declare every single variable, and i found this a pain from day one.

It didnt help me understand it any more or any less, if anything, i avoid having to use variables because i just didnt want to constantly have to clean them up since i was just experimenting.

Then i checked out an example about inventories and saw that even tho there was loads of events with variables, there was no variables on the variable sheet, this blew my mind.

I was left wondering how the heck this project had no declared variables but everything worked with event variables…

Thats when i leaned you didnt have to declare them, and simply add them in on events.

This was so freeing, and made me use them more and more, learn more way of how to apply them since i didnt have the extra steps to go trough… and id say that worked pretty well.

Now i have a pretty good grasp of how to work with variables thanks to that.

So again, i dont really get how a beginner in GDevelop will benefit from this.

[MrMen]

@MagicBiscuit

Does GDevelop already declare variables for us? Is that how it works? Because if we have to declare them in order to work, but we didnt before and it worked, what sort of magic was it? (i dont mean this in a bad way)

GDevelop would create the variable and give it a default value of 0. Because variables were loosely typed it could be taken as boolean (false), number (0) or string (“0”).

[MagicBiscuit]

@MrMen

GDevelop would create the variable and give it a default value of 0. Because variables were loosely typed it could be taken as boolean (false), number (0) or string (“0”).

So it does already declare it right? thats what you mean by create?

I know they get created, but not as their proper types until they get used, its sort of like a placeholder,

for example, i made a Scene Boolean called “UNDECLAREDTest”, set to False.

This is what shows up untill i actually do something with that variable

After its used, the type changes into Boolean with a regulard boolean value.

…either way, if this works, why does it need to stop?

Honestly ill just stop asking at this point since i dont think theres any answer other than because thats how its supose to be.