I’ve been learning GDevelop using a bunch of YouTube tutorials, and while they’re great for quick demos (movement, simple events, animations), I keep running into the same issue: most videos show small standalone mechanics without ever explaining how to structure a full game’s event logic, especially as complexity grows.
For example:
Scene transitions and persistent player state across levels
Modular event organization so logic doesn’t become spaghetti
Performance issues once you add UI, variables, and enemy AI together
A lot of YouTubers just build a simple prototype and stop — then the next video shows something else. That leaves me with a bunch of disconnected patterns but no sense of how to design games that scale.
So I’m curious:
Do you use YouTube for GDevelop learning at all, or do you avoid it for anything beyond basics?
Which channels (if any) explain game architecture, event organization, or debugging workflows rather than just isolated mechanics?
How do you take what you learn on YouTube and turn it into a solid structure that survives iterations and complexity?
If you’ve moved from tutorials to real projects, what resources or habits helped most?
Looking for community-tested strategies, not general “watch more videos” advice.
Imagine this
You make clickable button yourself
You use sprite object for that with different animations + text object + play sound action
Do you put it all in one place?
When button is clicked change text to something
When button is clicked change animation to something
When button is pressed and animation = THIS then play some sound
?
Or would you have all play sound actions in one place
All text change action in different place
And so go on
Considering you will have let’s say 4 buttons
You see there is no right or wrong answer here
I would say it like hardly depends on what game you are making
And more important to get experience with which game you should go which approach
You should make few small games you don’t even care to finish
Just something that works and can be played
This way you gonna find what to do in what scenario and what not to do
For example
i am often telling ppl not to make object variable
But to use object opacity
For example you need boolean variable for your object to block something
Well why make object var if you can check and change opacity?
I just check if object opacity = 255
If so i switch it to 254
So whatever was possible when opacity was 255 will not happen now
Most of us don’t even use opacity for anything
So why create new variable when opacity is as good as variable which you can check?
And you cannot tell difference visually between 255 and 254
Need more?
Go with decimal
Check if object opacity = 254.0001
Or 254.0027
And so go on
Then someone is using opacity for object to blink
So my idea will not suit this scenario
But does that make my solution invalid?
Nah it just make not suitable for this scenario
But also does not make it automatically suitable for every other scenario
Most of what you described there is NO right or wrong answer for
There are only multiple ways of achieving it
And i say we should all check them all and pick our poison
Most YouTube tutorials are great at showing what’s possible, but not how everything should live together once the project grows. I’ve run into the same thing where each mechanic works fine in isolation, but once UI, enemies, scene transitions, and variables all coexist, the cracks show.
What helped me was intentionally reusing the same systems across multiple small projects instead of starting clean every time. That forces you to think about event organization, reuse, and whether something belongs in a scene, an external event sheet, or global logic.
Also +1 to the idea that there’s no universal “right way.” A structure that works perfectly for a UI-heavy game might be painful for a physics-based one. Trial, friction, and refactoring seem unavoidable here.
Short, fast-paced tutorials reward “look, it works” moments, not long-term thinking. I’ve found that consuming content from less polished or unofficial sources sometimes forces me to think more critically because things aren’t wrapped up neatly. For example, when reviewing behavior patterns from alternative YouTube clients or modded APK builds (I’ve looked at sources like YTModz for analysis purposes), the lack of consistency makes you more aware of assumptions in your logic.
That mindset carried over into GDevelop: instead of asking “does this work?”, I started asking “what assumptions does this event rely on?” Scene order, variable lifetime, UI state — all of that becomes clearer when you expect things to break.
Once you stop trusting tutorials to give you structure, you start building your own — and that’s when projects actually scale.
