So far I have been very happy with all the updates of Gdevelop but since the last one, 5.0.126, there is something that feels limiting. It is the way timers have to be initialized from now on. In the release notes it is said
“Timers have been modified to be more intuitive.”
I would argue that this is not necessarily the case. I understand that it is better for a project, the readability of the events etc. to have everything set up neatly at the beginning, but that was already possible before. Forcing the user now to use the timer in just one way which may or may not be intuitive for the individual user feels like an unnecessary limitation.
Aside from that there is no warning or message if I use a timer in the events that is not initialized at the beginning of the scene. I can set up everything like before but it just will not run.
So for the sake of being able to do things in many different ways, even though they are not best practice, I would suggest allowing the user again to create timers freely in the events (maybe with a remark that it is better to initialize the timer at the beginning).
Thanks for letting me know. Since I am not contributing to the development of Gdevelop I guess my opinion has not much value in this discussion. Sadly it also seems that 4ian and D8H are quite determined to keep it as it is now.
Of course it is not a huge problem to initialize the timer at the beginning, but as I wrote it is a limitation which is imposed on the users although the previous system worked perfectly fine and everyone was free to initialize the timer at the beginning if they considered it to be necessary/better etc.
What I really dislike is that just one way is considered to be appropriate and more intuitive and other options are purposefully blocked just because some design pattern is declared as the only acceptable way. I think the user should have the choice to do things the way they like, even if it is considered wrong, bad habbit or whatever from a specific perspective.
I’m with you in concept (and you can see me in the Github thread with alternatives), but I will call out that after looking through tons of user threads that I’ve worked on, and some of the issues on the github, 4ian and Davy are correct that a lot (including myself) of users thought timers worked differently than they did.
(i.e. thinking scene timers start at the beginning of the scene, whereas they start the first time an event with the timer conditions (or actions) evaluated true, or thinking object timers start as soon as the object is created, which was also incorrect.)
This led to a lot of user issues where they couldn’t figure out why the timer wouldn’t activate the first time, or happened “later” than they thought it should.
This change does bring timers in GDevelop closer to how all other engines work, and makes them standard and repeatable, so I get the dev’s desire. I also think it was communicated poorly (as in not at all) and users were not properly prepared for the change. They’re connected with that at this point.
They’re going to be updating the conditions about needing to start the time before the conditions will function going forward.
I would definitely prefer if they would implement your suggestion. I agree that it is a good idea to make things more intuitive and straightforward.
I am not against setting the timer at the beginning per se, I just would like to have also the other option. Whether this leads to bad code or is more prone to bugs is ultimately my problem and not the developer’s.
I was not aware of this change due to lack of time for game dev. I totally agree. One of the key reason that got me stick with GDevelop years ago as a complete beginner is that, GDevelop taken care of initialisations and declarations for me and everything just worked while other game dev tools was throwing runtime and compile errors into my face. With GDevelop everything just worked, It was such a nice experience.
Since I got more experience with programming in other engines and frameworks I can understand why such limitation helps with keeping everything organised and why is it more efficient, I am not against it as an experienced user but as a beginner the very reason I choose GDevelop 3 over Construct 2 many years ago was the fact Construct 2 did put such limitations on me while GDevelop did not.
Wondering how many of my examples are also broken now that I won’t have time to go back and fix due to lack of time and other interests I have
Pushing game breaking updates out without warning BEFORE the update released maybe also something the dev team should consider going forward especially if we have tons of broken examples now that need to be fixed.
As the dev team designing GDevelop from a commercial and professional perspective maybe they should also carefully consider it from a beginner point of view how important it is to break backward compatibility and to force people in to a certain frame going forward.
The release note states that the change “does not affect existing conditions”, so I guess your examples might still work. For tutorials this is of course a bigger issue.
That means the way existing conditions work and behave has not changed so Reset timer still does the same like before but from now you have to “Reset the timer” at least once before you can use a timer.
But in some examples I can imagine it was not necessary to explicitly reset the timer before I use it, maybe after I used it I did reset to repeat a certain event but not before.
So 1 or 2 examples of mine I expect it to be broken at this point.
Yes, just the other day I was thinking how weird they did invest so much time and effort in to making official video tutorials and now they moved the controls in to the middle making the official tutorials look obsolete just weeks after they were released
But an internal change like this can literally make video tutorials obsolete indeed.
Huge amount of work going down the drain with each game breaking update which at times need to be done in order to improve the software and the user experience, I am not against it, my biggest issue with this really is that changes like this should come with a warning ahead of time and not overnight and must be justified.
Let’s say if I spend the next few days, weeks checking, fixing my examples, what is the guarantee they won’t introduce an other game breaking update the next day or the day after that?
Of course the same apply to tutorial makers, creating, editing videos is a lot of work but even just to go back and edit a blog post can be cumbersome if it was not scheduled and you had to do it on dozens of pages.
So there is a lot to consider here.
If the team plan to make sudden changes like this without warning I think GDevelop should introduce stable and beta branches similar to so many other projects.
For example Unity did the same before, did introduce breaking changes very often and they have forced developers to deal with it if they want the latest bug fixes. They have realised the mistake finally and now they have 2 branches.
-LTS: which get bug fixes only but no new features and no game breaking updates and released only once in a while, supported for years so creators, developers, educators can put their trust in to this release for their long term goals and projects.
-Pre-release/beta: which include the latest and greatest updated daily and breaks daily, no support, no guarantees, not recommended for any mission critical project.
I had some additional discussions with the devs and contributors on this, and you can read my giant mountain of text over here with more details: Announcement around Timer Changes in 5.0.126
I know I repeat myself here but my main problem was not only the lack of information, so I just would like to add one last time that I keep sticking to my perspective: limiting the options to do something is not an improvement. The idea to fix allegedly bad habbits of the users (see the GitHub discussion) by imposing them to do something that one or two (or more) developers consider best practice is quite patronizing.
If we use the same arguments (most people don’t understand it, bad habbits, confusion etc.), other features of Gdevelop should also be removed, for instance using javascript in the events. Personally I don’t use javascript and it would not affect me but I think it is a great feature that might convince some users to try and use the engine.
Anyway, I am sure everyone got my point. I don’t want to make this a big issue, it was merely the request to give a feature back that I and probably others consider as convenient and useful.
I haven’t read all the posts here and on github. But I also think the new solution is better.
With the old one you had to pause all the timers you want to use at the beginning of the scene and unpause if you want them to start. The new solution needs one less action. Most timers are meant to be started manually and not run automatically from begin, so it should be useful. And there is less confusion as described by Silver-Streak.
It was not intuitive that all timer conditions are true without being started a timer. Maybe you have a different use case in mind than I do, for me it’s definitely easier without any disadvantages.
So my problem is only the change comes 3+ years too late, but well.
I honestly have been doing it this way already. Every time I use timers I start them at the beginning of the scene or whenever I needed them. That is how I understood them to work from reading the wiki. It doesn’t seem like much has changed really.
The only thing that is different in my use cases so far is that now I have more options for comparing value to timer instead of only timer is greater than.
No, that was not the case. You could create the timer on the fly, just when you needed it (in the action start/reset and in the condition column of the same block comparing the time), there was no need to create or pause one at the beginning of the scene. Now you have to do that and thus it requires more actions than before.
As mentioned above, I have no problem that initializing the timer at the beginning is strongly recommended in tutorials, the wiki etc. and I fully understand that this is much better for a project. There are seemingly good reasons as Silver-Streak mentioned in the other post plus the idea to enforce what is considered to be good habbits.
I just dislike that this is now forced on the users. Both methods worked before and everyone could choose what they liked. I think it is a strength of an engine to allow users to do things in different and maybe even “wrong” ways. So my request is not to add something or to make impossible stuff, I just would like to have the old functionality back (if necessary behind a toggle in the settings).
Hm okay. I don’t want to say you see it wrong. I’ve always used it that way. Because the third event would be executed after 5 seconds in the scene without pressing the button.
I don’t know if both solutions are possible at the same time. I also thought of a switch in the settings. But as far as I know the devs don’t like to make things more complicated and error prone. Glad it’s not my decision.
I have always used “reset the timer” when I wanted it to start, and I still don’t have to start it at the beginning of the scene for it to work: it is still created when needed. I was also very confused by the update, and I agree that it was badly explained, but I have realised that nothing has really changed for me.
