I’m looking for tips beyond the official GDevelop tutorials and some of the online guides (like Helper Bros). I’m trying to break out of “tutorial hell” — I’m fairly comfortable with GDevelop but still have a lot to learn. Any recommendations for tutorials, practice projects, learning paths, or resources to build practical skills would be greatly appreciated.
My advice would be to just start making a game that interests you. When you have a problem, and you will have a problem, take zGameCreator’s advice and look for answers here on the forum. Yes, you could just ask a question first but there’s really a lot to be learned here by reading. If you don’t find an answer then yeah, ask your own question.
What I’m looking for is probably a bit vague. One of the things I really like about GDevelop is that even when I don’t know how to do something, I can read through the events and they still make sense to me, which I genuinely love. That said, I usually don’t know what to do unless I’ve seen it before or someone points me in the right direction.
I guess I was wondering if there’s something like a comprehensive “learn these first” list for events and actions. My sense is that the real process is more about running into a wall, searching, asking for help, figuring it out, and then running into the next wall until, over time, you’ve learned what you need. That’s totally fine by me. I’m not complaining at all, just trying to be efficient about how I learn.
Hey!
Personally, I just grabbed a template and expanded on it to make my first GDevelop game. I loved it so much and learned so much from it that I ended up making a sequel for it!
The template that I originally used was the Duck Game template.
Also, I am a template designer myself! I’ve released a couple paid templates, and 2 free templates. If you could (totally fine if not!) try out my free Trivia Match Template and let me know what you think, that would be awesome! I’m currently working on an update for it (including a new tutorial) and not sure what to add, so all feedback is appreciated
(Sorry if this post comes across as advertising, that isn’t what I meant at all!)
I did try it and the first 10 seconds I was like …huh? But then I realisedoh this is just math and it worked perfect so you get a strong 9 out of 10 haha!
Hey, thanks!
Sorry if I wasn’t clear earlier, but you can actually download the template and open it in GDevelop! (If you want to!)
If you do end up downloading it, let me know what you think of the tutorial, and if there was anything that was unclear. Also, if you get any ideas for what I could add, let me know as well!
Again, no pressure, just explaining it a bit because I’m not sure you understood
You need to develop so called “programmer mindset” and get familiar with core concepts to be able to solve problems on your own.
In general I would recommend to avoid behaviors, extensions and templates as much as you can and instead focus on core concepts such as variables, arrays, loops, timers, expressions, object linking and generic translation events to rotate, change position and create interactions. It is the fundamental building blocks of all behaviors and extensions. Once you understand these fundamental building blocks, then you can make anything on your own and you can speed things up using behaviors and extensions once you understand how they really works.
Regarding what projects to work on, once again I would recommend to avoid templates because they are using behaviors and extensions heavily and provide very little explanation how they work. Often include no comments at all. They are useful to speed things up but to learn and understand how something works exactly they are counterproductive.
Instead I recommend to work on small mechanics, anything you find interesting. For example the very first mechanic I developed was a car that I was able to drive around and improved it to the point it felt like a proper vehicle with acceleration, drifting…etc. Then extended it with a canon to shoot bullets and created a tank. Then I added multiple targets to destory and enemies that also shoot and follow me. No physics, no behaviors, no extensions, only pure logic and generic events. But first, before anything you really need to get familiar and understand core concepts like variables, arrays, loops, timers, linking, expressions, forces…etc Try them all, play around with them until you understand how they work.
I have created tons of examples demonstrating these core concepts with tons of comments explaining everything but unfortunately they are out of date, was not updated for a long time and considered obsolete now. Focus heavily shifted toward behaviors and extensions. But if you look at these old examples maybe you can still learn something from them.
By the way and it’s funny, i had me too in mind the example of the car in reparation.
If the mechanic man press a button for serviving a car, he’ll know nothing on the manner to service a car.
However, if the mechanic man by himself has experience in service a car , he’ll be expert at a certain time because he will have a lot of experience with mechanic.
This is exactly the kind of advice I was looking for. What you mentioned really clicks with me, and I think it mostly comes down to taking the time to familiarize myself with the engine’s different conditions and actions. There’s no real shortcut for that. It’s just experience.
My goal is to get to a point where I don’t need to stop and hunt down a video every time, but instead can think through things logically and figure out what needs to happen. I feel like GDevelop makes that possible for me. It might not be fast, but I do think I can get there, which hasn’t always felt true with some of the other engines I’ve tried.
I know you mentioned they are out of date but any chance you can link or point me twords some of those examples you mentioned?
The examples are included in the examples repository. When you create a new project, you can search the examples by typing the name of the feature you looking for for example “pathfinding” “collision” “inventory”…etc But I can imagine they are going to be removed, replaced very soon as they are obsolete and show you ways to do things that no longer works nor considered practical.
You can also find them on my itch.io page, but as I mentioned many of them are out of date and may demonstrate things that no longer can be done in a new project.
I was considering to update them recently but unfortunately I don’t have time and also the way I have done things considered not practical and would not be accepted in the repository anymore. The use of behaviors and extensions is the primary way to do things and mandatory to use them in new examples now. For example if I used a math expression to tween the position of something, it would be considered bad practice and I would be told to use the tween behavior which is not my focus to show how to use behaviors and extensions. But maybe one day I’ll find the time to update them on itch.
Yes, it can be a good advice to do like that.
It’s a little like in classic programming where it is encouraged to use Libs (on PC devices of course) rather than employ formulas in the body of the main programs.
So, of course, this can be discuted a little because that is today important in my opinion, is to solve the problems globally and with abstraction in informatic, and not to point to a solution efficient certainly but difficult to maintain.
In generally I agree with that behaviors and extensions are more practical and can simplify maintenance in a large project, however at times it can also generate unnecessary bloat and add extra layer of complexity and noise that can be also complicated to debug and maintain especially for beginners. This is why personally I think it is important to get familiar with the core mechanics and fundamentals first instead of hiding it inside abstractions and then everyone can make the decision how they intend to package and distribute their logic.
A template intended to be a starting point for new projects certainly need practical implementations included, but small examples intended only to demonstrate the implementations of features and mechanics not necessairly benefit from being wrapped in to abstractions.