Please don’t ping me about this, I am not on the GDevelop team, nor I am not a decision maker, nor do I have any influence or input of any kind on the decisions of the team. I learn about changes the same way as everyone else as they release and have no decision power over any of this.
Now that’s a rant!
I understand the problem and there’s little hope that things will change…
Why did they do it? Because it’s part of the “don’t scare the beginner” craze, so they hide as much as possible, the buttons, the options, the information.
That’s why there’s no instance number, no buttons on the interface and so many drop-down lists. GD5’s interface is just awful and it’s the same problem: it’s being imposed on us when before it was fine and it’s a shame to waste so much time redoing something that’s fine.
But instead of having both, it deletes… One day they’ll delete the software to stop scaring beginners… 
The problem is that they want to be taken seriously but when I see GD5 it looks like a toy and so the question that comes up every time is: Can GD do that? And that’s normal, it casts doubt, you can’t see anything, not to mention that it lacks a real user manual, which is the big black spot for beginners, but instead of doing that they cut up the software to make it “simple”.
They would have saved so much time over so many years by producing a complete manual to avoid all this mess.
2 Likes
Im sorry man, i was annoyed, my bad.
I get what your saying and i agree with some of it.
Not the user manual thing tho, GDevelop team is actually pretty good when it comes to giving instructions, wiki guides, examples, video guides, technical documentation and even the source code and how to use it.
In that respect they are pretty awesome and cover all the bases, from beginner to advanced users, even making material for people who want to contribute.
…as far as the beginner thing…
Thats true, considering 4ians new post, the change was for the sake of beginners and thats a shame.
…but hey, 4ian did start GDevelop to help less knowledgeable people be able to make games, so that pretty on brand for his character… and considering thats such a good cause… im having a hard time being annoyed at the man, even tho im trying really hard to lol
My message wasn’t positive about GD but it’s good that you took it that way too.
Just a reminder, at one time in the GDevelop IDE, when you created a new variable via events, you could also choose it later by a drop down box or autocomplete. So to showcase the convenience of setting up a variable once and then being able to pick the name from autocomplete as an example of how nice the new system is - literally depends on no one remembering that you used to be able to do that with undeclared variables too. I can still do that with undeclared variables on v5.1.160. If you can’t do that now on an updated version, it is because that convenient feature was removed.
3 Likes
I know, there was also autocomplete in the variable setup screen using undeclared variables as well. I think that’s what people want. It should be more dynamic and automatic. If you use an undeclared variable it could automatically be added to the setup screen either completely in the background or as a popup.
It does seem like we’re doing twice the work by having to define it and then type the name in the action. Although, IMO, the time spent setting it up is recovered and then some later. When you type a name, GD tells you it’s not defined. Instead of just bringing up the variable screen it could give you the option to create an new entry with the current name either from the box or in reference to the cursor.
The opposite could be try. When you add the action and bring up the variable screen it could give you the option to add the variable name to the active field or cursor point.
When I imagined a single action for variables, I imagined properties for
scope, name, type, modifier and value.
It would show what type each variable was and you could change it in the event sheet without opening the event to full screen.
Example:
Set Scene var named player.stat as number = 42
I said from the start. I’ve been using the setup screen for some time. I’m a bit biased. So, while I’m not as bothered by this and see it as a good thing . It doesn’t mean that I’m dismissing anyone’s opinion or dissatisfaction. We need to find a happy medium.
1 Like
I am not a fan of declaring all variables. Back when they first started talking about it and said it was for “better performance” I could stomach it more than now to see that it makes variables “safer” - which just makes me feel like I’m being grounded because someone else made a mistake typing their variable name and had a hard time debugging their game.
I think the team will continue to evolve and improve GDevelop based on feedback. They have always done well at that in the past. It doesn’t look too difficult to me from what people are describing because for every project, I have a list of information the game will need to run no matter who is playing it, and I open the global, scene or object variable panes and get to work adding it before I worry about things like events. I only use variables created during events for things that not every game will need depending on player actions. I don’t want to refactor anything though because I do like to overwrite variables to change their type, use the exact same name for global/scene/object variables that are related to each other, have logic that depends on a child variable not existing unless it was created in events so that something is/n’t done unless it’s there, and probably other unsavory practices that I’m not thinking of. I’ll update later on a clean pc when I am about to start a new project and I doubt it will affect me too much. Except if we lost the ability to change type of variable mid game that’s a bit annoying, and obviously I am not a fan of having to declare TempVar and then not being able to reuse him as a different type later. But pretty minor and nothing my natural laziness can’t devise an effortless solution for.
2 Likes
Unless the variable is an array or structure, I don’t think you can change the type after declaring it.
You can use the new local variables. Though I’m wondering if there’s an efficiency cost to adding and removing local variables instead of using say a scene variable. I tested using local variables with repeat or for each child. It’s nice having the declaration right above the event.
I haven’t used the function variables much. I don’t see a way to modify the function variables other than within a condition or action or with an event on the event sheet. IDK if there’s a button somewhere.
I wonder how the changes affect Javascript. I don’t know how you use local or function variables in Javascript.
On a plus, global variables work with for each child.
Edit: I checked the Javascript documentation there’s a method called get getVariablesForExtension I haven’t tried it yet.
IDK, that says extension not function. IDK if it’s the same.
100% agree.
The new UX in this update is bullshit and I would’ve already been out of here by now if it wasn’t for the fact I’ve been working on a massive game for multiple years now within the engine.
I had to spend ages fixing all the new bugs that arose in my game because of this update, and after I had done that, I found that my workflow had been slowed greatly.
Thank you for sheading light on this matter!
1 Like
I don’t agree with a lot of things related to that update and with how the new variable system was implemented, and I even made a somewhat harsh post exposing my point of view (I’ve revised my text since then). I was angry too, and I still hold strong feelings about the change… but please don’t start throwing hate on the wonderful engine we love.
A lot of new users can learn to use the new variable system and take advantage of it. I hope it gets refined with the passing of time.
I don’t think the change was properly managed (and I think we have made our point already), but I understand now it was completely necessary at some point.
If you feel affected by this change as I do, I propose you this: lets give time to GDevelop and return if we feel it had corrected what is important for us, but let no ruin the experience for new users.
5 Likes
Let me add another thing, but it concerns the online multiplayer game. I created a project that was going well, and suddenly the update appeared. I opened the project, and lo and behold, elements disappeared, and the whole project became completely broken. I don’t know if this is due to variables or something else. But I linked this to the update because things got worse after it… And really, the innovation of making a collective online game needs more attention, this is for information and addition.
1 Like
Just adding another vote that this change is a huge step back for advanced users. GD team chose to cater to very beginners (but now it’s even less straightforward if you ask me) and sacrifice UX of users with big projects in progress and users who need to prototype fast (so basically all advanced users)
Is this a good idea? Imo the entry point for GD was already really low and the engine is already on the verge of non-serious educational engine for kids and a serious engine for game developers. The second thing is that these beginners will someday become advanced users and then their workflow will be slowed just as now our workflow became slowed. Does that mean they and other advanced users are meant to jump to the other engine at that point?
3 Likes
I mean, low entry point is kinda the mission of GD and other “does-it-all” and “no-code” platforms.
I can’t imagine why an advanced user would have such a hard time declaring a few variables. Even a beginner should be able to handle typing in a list of names and values.
Really, you should have been declaring your variables already since they introduced the object.variable syntax, well before this update.
And i agree with everything you said…
but…it was a feature… of GD.
i have upgraded cos i need the prefabs…and i had to declare a hundred of variables…while i can still develop without issue …i miss a feature.
I can’t imagine why an advanced user would have such a hard time declaring a few variables
the advanced won’t declare a few variables but a lot of them and many many other temp variables used for prototyping and testing. adding another step in this process means worse workflow.
Really, you should have been declaring your variables already
no, I could.