This is how i would solve current problem
It would not penalize ones that do not want to declare their variables
While it would help ones that are into declaring their variables
If we want convince users they should declare their vars i say this is right path
Where we do all of this in same exact window we start to use new var
No one gets harmed everyone benefits from it
Nothing is taken away something is given to everyone
You have no idea how wrong you are
Soon what will happen is that ppl will come here and on discord asking where is THAT option
Because they see something else on screenshot/video on how to set up variable from what they have in the engine
I am not fortune teller i cannot see into future
So how i can be so sure?
Cause every week i answer at least one question like
Where is action to change animation / fire bullet
And we get that there cause over course of updates naming changed and i say it is a good thing
Since now names make more sense
Yet it create confusion among users who do not take into consideration that something could get an update
And just wait will same thing will start happening to every single tutorial that included setting up vars
I already said it somewhere but i as dyslectic should be all in for new change
Yet i am not i never had any big problem with previous system
Neither i ever seen any1 ask for variable system to be updated changed in a way that we need to declare all variables
I do not want to take away declaring variables i want choice of not declaring them not being taken away from us
In fact i want better system i made post about it which is in my above message
Which would streamline the process for all of us not penalizing any1
To give everyone the context on the technical reason why we can’t just say “undeclared variables can still be used with the new system” is because, when you use the unified, single action to change a variable, we can’t know where the undeclared variable should be created (do you want GDevelop to make a global variable? A scene variable? Is it a local variable to your event?) nor the type (but this is less of a problem, but still - allowing this kind of dynamic stuff reduce the margin we have to do performance improvement, by accessing for example directly the variable in memory rather than relying on its name).
Of course, we could do something “in between”. When the variable is declared, you use it and when it’s not declared, then GDevelop could assume it has to create a scene variable… which can create all sort of problems:
1 + DeclaredVariable but not 1 + UndeclaredVariable.This will create in our view more issues than solving this. Especially once we’ve polished the UX and declaring a variable is ~2 clicks, this could be seen as a net negative to allow you to use undeclared variables. This is why we decided against this extra complexity (because yes, this will be more complexity - in addition to still supporting all existing games with undeclared variables, as we would never break compatibility with previous versions).
Another note, I’ve read some arguing that “GDevelop tries to be too beginner friendly” and this could be seen as “dumbing things down”. I think this is the contrary: most professional game developers would be worried to see that undeclared variables in GDevelop are possible. It’s almost an heresy 
They develop large scale games, where they must ensure their code is robust: variables are properly used with their right type, there is no obvious mistake, and GDevelop can create the most efficient code because it knows about what variables you’re using.
So this is actually moving toward more professional usage because this make GDevelop closer to good programming conventions (your game designer won’t break your level because they mistyped a variable. In a team this is really important.).
Note that if you don’t like all of this… you can use a structure 
Create a scene variable called “SceneVariable” and use it as a structure where you store any variable with any name.
This is perfect for dynamic situations. But in most cases, declaring a variable is the way to go and hopefully won’t take long, and will even be faster in the future.
Is the “about 2 clicks” still to come? Currently we need to click on the “Add or edit variables…” option, select the correct tab, and then enter the variable name and select type. I would have thought with the changes that the initial drop down (under the “Add or edit…”) would have options like “Add as scene boolean”, “Add as scene number” etc. This would be quicker still.
Be honest and ill shut up about this for good…
How many complaints did you actually get about this? Not the update, i mean complaints that lead you to change variables?
I dont remember seeing anything on the forums or any mention of it, did people really mess up that much and complain directly about the engine?
What happened?
Or is this a “just in case”?
Thats the part i really dont get… i
Tell me wouldn’t that solve the issue?
Man i wish i could explain what i have to say about this way better… but check this out.
GDevelop did not support you using undeclared variable in expressions, this makes sense, and as far as i recall, that was my experience, but…
If you add an undeclared variable in an event, GDevelop now handles that variable as if its declared and does allow me to add it inot an expression.
THIS RIGHT HERE!!
This is why its always felt natural to work with undclared variables in the event sheet, once i add it onto the events, that variable feels declared, in fact even the fact of writting the variable down, feels like your declaring it and since the engine then acknowledges that variable in expressions afterwards, it just feels right.
All that without ever seeing the variable page, this is what i ment about how it felt like the way forward.
It does seem like your doing the “professional” step.
…and when i have a reason to declare variables, i still do it with no issues, their usually globals, like when i need a coin counter, or an item counter, or player level, stuff like that.
But simple scene variables that are used to lock key presses or open menus, like booleans, i have no need for all taht, i just “declare” them on the events.
I did still learn the importance of “declaring” the variable, and making it show on my “code” in the events, i just didnt do it the proper way…
I really hope you read that and that it made sense…
Yes (still to come), there’s been a few mentions of the need for (and desire) to add a simplified UX/UI for rapid creation of declared variables by 4ian and the devs. It is not available yet.
I’m not a fan of this decision. I feel like I’m being punished because other people are stupid. Curiosity about one of the comments requires me to ask, if I update I can no longer have a global, scene and object variable with the same name?
I just said what the founder and the other full-time devs say, so…
And ya I helped many beginners on and offline to get started with GD, years before you were here🙃
Yes they will, because there has been a change. What I said is that there are technical advantages to declaring them. And they are working on making them easier to declare. With just one click on undeclared ones, I think.
But we’ll see, there is a hint and the variable editor button is only 1 centimeter away from the field, 99% will find it on their own. 
It is normal that years old screenshots may no longer be up-to-date, but that shouldn’t prevent any innovation. Examples and official videos will be updated.
But hey it fully doesn’t matter what I think about it, I didn’t want it too but I don’t think the world is going to end because of that, other changes and the lack of the option to turn it off optionally were more annoying for me.
Sometimes I wish there was more discussion and voting before things are finally implemented, but in the end it is the decision of those who do the work.
I have been using Gdevelop for a long time, and in my particular case, it is a very big job to declare each variable. Added to that, I have many variables with the same name but for scene, object, global, etc. I prefer the previous system (I feel like I have more control over what I do). I really don’t like having to spend a ton of time “fixing” things that aren’t “broken” in my game, with the result being simply the same thing I had before, but I imagine that the idea is not to return to the previous system, so I propose some intermediate to make it easier for those who have larger projects to migrate to the new system. I suggest implementing some quick way to detect all the variables present in a scene (or external event), such as a scan, to be able to declare them with few “clicks”. Also, find out which ones have the same name, to suggest changing them.
I’m interested in understanding this. Would there really be a difference in the performance of Gdevelop games with this system?
Hey there,
I think the new system is a BIG improvement to GDevelop. Here’s why…
Having all the variables declared in the project means having total control over these variables. This links the events with the declared variables so that any change is universally updated anywhere the variables are referenced. Similar to how objects work.
YES it takes few extra seconds to declare each variable.
BUT it eliminates having to type the long expressions and saves a lot of typos in the code. Fixing one simple error in the code can take much more time than the time it takes to declare or edit a variable.
Having the “Freedom” to be able to use undeclared variables made me work the wrong way. It’s a NIGHTMARE to change a variable in a big project with lots of scenes and external events, by going through each events sheet and Search / Replace expressions.
But having this “Limitation” makes for simpler and more streamlined workflow using variables. This forces the use of variables in a more responsible way. Which in the end makes the code easier to read and navigate through, and the project will be more organized.
I had different feelings about this change at first, because I was used to a certain workflow for a long time and the change caught me off guard. And I think a lot of developers are feeling the same way right now.
But after trying the system more and going through the discussions, I understand now the importance of declaring variables and that this is the correct way of doing things!
I’ve been using the engine since GDevelop 4, and I learned a lot and I will continue to learn from the experts in the team and from the community. I also saw how GDevelop evolved since then with every major update.
This variables system is intuitive and will only get better over time. It makes understanding variables simpler, faster and more fun to use.
This is just my opinion and sorry for the long post.
I believe the GDevelop team made the perfect decision!
Many thanks to everyone involved in continuing to make GDevelop more and more awesome!
Perhaps. I myself am still not sold on the idea. Possibly because I already listed important variables in their appropriate variable pane so any benefit of doing so now is no more benefit than I had already but with the added ability to take an undeclared variable, say TempVar, and use it as a place to put a json, convert it back into the same TempVar as a structure, erase the structure by turning it to a number etc. I didn’t gain a thing.
Also I liked the long expressions. I made an impressively long expression once when I had first been using GDevelop a few months and I was so proud of its ungainly size I rushed to the forum to share it. I remember Keith I think pointed out that I could have shortened it by doing some of the calculations independently and then using the resulting variables in the expression instead of my verbose and masterful precious.
I am all for people dictating how I do my workflow to make it simpler and more streamlined for them, when they pay me. On my dime, I prefer to do things my way and trust me, when something is quicker and easier I latch on to it because I am lazy and my brain just looks for things like that.
So I for one am pretty disgusted with the change, but it is actually not the first change I have been disgusted with. It really doesn’t matter to me because I love GDevelop and will continue to support it. There is no game engine in the world that is not going to make some change that disgruntles some users but in the end you have to look at majority benefit and the future of the engine. I think they’re being great about the gentle timeline of this whole thing so that people can get migrated over, not just creating a new system and breaking everyone’s old projects outright without ever giving anyone a hint.
I sit on discord trying to solve other ppl problems
Sometimes it is way easier to me to just set up events send screenshot and link to preview of my project to ilustrate+prove it works
This already happened to me but it will be same story for every user for which i try to solve their problem
2 days ago user on discord ask how to make something happen on increments of a number
For sake of simplicity lets say each 5 so at 5,10,15,20,25,30 and so go on
My best idea is to use modulo expression on some variable
(Modulo loops around some number so imagine you have variable seconds and if you mod seconds to 60 then when it should hit 61 it will not go to 61 but instead start counting again from beginning)
So he had variable called Combo
Using compare two numbers condition he could simply go with
mod(Variable(Combo),5)=5
And now in action he could do whatever he wants
And it did not work and it was because my mistake
I forgot module accounts for 0 so when i told him to put there ,5 what it did was go 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 since that’s 5 digits including 0
I did not realize that so i went to test it in my project and show him it is working
And then i found i forgot about that 0
So proper expression would be mod(Variable(Combo),6)=5
Now it would go 0 1 2 3 4 5 6 0 1 2 3 4 5 6 0 1 2 3 4 5 6 since that’s 6 digits including 0 and it will hit 5
To do that i needed to declare variable just to test it out in my project in which i do not need that variable
I did say sorry for my mistake and showed him how it should be done
Now i needed to go back to my project and delete manually that declared var which my project won’t use / don’t need
Just so i do not litter my project with random vars
Variable update added me 2 tasks which takes up time if i want to provide that kind of help
There is no argument how long it takes it is few secs to declare and delete vars
BUT each time i gonna help someone this way i gonna need to take 2 additional steps
And i cannot say that my workflow because of this update got better the same way you can
Declaring variable in above scenario did not give me anything and only made me need to delete declared variable in addition to deleting events after i did make visual presentation for someone
And i or any1 here is not asking “please remove declaring variables”
Far from it
Cause you see old system still works so projects using old system do not break
I can copy or pre made variable of each type put it into disabled event group and just copy paste them when i need them
Either way i need now take additional steps each time when i try to solve problem for someone on discord or even here on forums
I won’t die from it but my workflow did not got better
So me or other users are not in need of taking away declaring
We ask for streamlined way declare vars or a easier way to use not declared variables
If new system did make your workflow better then good for you
But consider not all of us do what you do and use gdevelop in same exact way as you do
So for some of us new system can cause more problems than it solves
Where in most cases we did not have problems with old system
I agree with ddabrahim, Lucky-j and ZeroX4 here. Declaring the variables in advance is apparently the best way, but I believe that the user should have the freedom to decide whether they want to do it this or another way, even if the latter is not considered to be ‘good practice’.
It is not only easier for beginners, it also makes it faster to stitch something together for testing or sharing. I see it as a strength that you could do something unoptimized in Gdevelop and it would still run.
Reading through the posts in this topic gave me a flashback to this one 2 years ago, when timers suddenly had to be declared in advance.
Obviously everyone gets used to a new system after spending some time with it, I just don’t believe that those changes make Gdevelop necessarily user-friendlier or faster to use - which is one of the hooks on the webpage to try the engine.
I went into topic you linked i did read all of it
Pure luck but imagine in my games NOWHERE i am using timers
Just because i found out i can use TimeDelta() in vars
Or even go straight up with adding/subtracting some value like 1 or 5
To variables and use that instead of timers
JUST because this way i am not need to start something first
I only add action for it to run and check if value is below or above something and im done
With this method i do not get perfect timing i need to check if something is lasting long enough or not too long for my project
Yet i am able to measure it as i please
To be fair and clear with timers i know how much 3 seconds is
Yet i still need to check if 3 seconds as a cooldown is what i want for my project
Isnt it too much or not enough of a delay
So when i simply go add 1 to variable then check if that variable is above let’s say 100 i do not know how much time it will take for it to get it to 100
But i need to go trough exact same process
Where i do not need to know if 3 secs is enough
I need to know if delay i set is enough or not and adjust it anyway
So in conclusion seems i always avoid methods that required extra steps from me
So it is not about if i start using gdevelop from moment declaring was obligatory i would not have problem with it
I would still look for a way to have easier manage system for my vars
But right now we are running circles
Most of us just try to prove why one system is better over another
And that will prove nothing
I wish we sit and think for a better system for everyone
Throw ideas and eventually we find compromise or a solution that will make everyone happy or at least won’t be penalizing in some scenarios
Here is some actual, live, user experience dealing with the variable change.
This is honest feedback, im not trying to trash the new update, its literally just me working and having to deal with this.
I also find pretty quick some issues that need to be adressed, and honestly, amazed that it even works like this in the first place…
Like pressing “Enter” on the variable page just closes the whole thing and dosent save anything… almost feels like im being pranked every time i press it lol
just quoting what i said (not here) in this thread for other ppl
but i was thinking …
isn’t possible to restore the old conditions without using the old system…?
i mean
we may restore old conditions just as a “bridge” to declare vars in new system.
eg: if i have a undeclared var in – change the scene variable “my var” set to “1”
it will just bridge to the new system automatically declaring it in the scene properties…a scene var with the same name…so old and new sentences can be used and swapped depending on dev choice
They gonna works as a fake undeclared vars…just miming the old method…
it will just fake you thinking that ure using the old method
It will be just a matter on what you believe to read on the screen
ps : we may even have an option in game properties to see or not the full sentence.
if on it will show the kind of var edited (like old method) Eg: change the “scene” var myvar set to 1.
if not it will show the new sentrence change variable my var set to 1
We all have different experiences and opinions, but one thing we all have in common is that we use GDevelop. A no-code game development engine, and it’s VERY good at it. This change brings GDevelop a step closer to it’s purpose.
The team made this decision for a reason, or many reasons, and they know very well what the advantages / disadvantages are. GDevelop now is lightyears ahead of GDevelop few years ago thanks to the people involved in keeping the engine getting better with every update.
I can say that I know a lot about the engine and I also help people here on the forum. But I’m NOT a GDevelop expert, no way near it actually! I don’t know everything about how the engine works in the background, but there are people who do know. So I learn from them and adjust my workflow to how the engine is designed to work.
Now, we can keep on debating which is a better system, and that this change removed a feature that is supposed to make development faster and added unnecessary friction, or that there are many issues now. But we would be missing the whole point.
For beginners or people getting into the engine, this change makes understanding and working with variables so much easier.
For advanced users, this makes projects more organized, easier to navigate and less prone to errors. Which in return saves a lot of time and effort later.
Variables are one of the most important aspects of development. So if the purpose of using undeclared variables is to prototype and test out ideas faster, then these ideas and prototypes are being built on a more shaky foundation. I prefer spending a little extra time planning and setting up variables to build better prototypes and more solid ideas.
4ian explained it perfectly here:
Sure there are still improvements to be made, and the team is working on them atm. But I found that the new system works pretty well at this stage. Remember that it’s still in its early stages, and with future updates, declaring and editing variables will be much much improved.
You can still use older versions of GDevelop or copy existing older events. But my advice would be to start using this new system from now on.
Take a look on my posts above andv tell me what u think