Not too long. I started with Godot 3 a couple years ago, got distracted, and I’m only now getting back into Godot 4. So far I’ve only done like a handful of tutorials and made a few basic template games from that so maybe 4 or 5 weeks total. I’m also not very experienced with coding so it’s been a struggle. I have a vague idea of what needs to happen to make my game ideas work, like on a high level, but I have a really hard time figuring out how to piece it together and the tuts didn’t really help with that.
At least I’m much more confident in creating assets when I get to that part.
One small step at a time. I find that there are dozens of individual problems I need to solve to finish the project I’m working on, so when I get stuck on one I’ll jump to another for a bit. I don’t have anything groundbreaking yet, but even the smallest amount of progress each day keeps me from giving up.
I’ve got about the same background with Godot. Dabbled with it in the past, but never committed to anything. Just started messing around with it again about a month ago. While I do have amateur programming experience, It took me a long time to wrap my head around how different components should interact with one another in Godot (and I am STILL figuring this out). I was fighting with the Godot scene tree quite a bit, trying to create my own data structures and beating the Godot scene tree into submission. I have come to realize that it is better to just treat the Godot scene tree as the word of God.
Find ways to inscribe meaningful relationships between nodes in the tree. Find ways to structure things so logic can be performed with built-in Godot functions like get_parent() or is_ancestor_of() instead of re-inventing the wheel or trying to implement an Entity-Component-System pattern. If one node is a child of another, you are free to add on any additional implications beyond the nuts and bolts built-in to the engine. You could create an inventory system where items from the world are simply reparent()ed to an invisible Node inside the player, for instance, instead of getting bogged down trying to encode the whole thing in a dictionary and implementing the Factory pattern in GDScript. Then you can simply do something like $Inventory.get_children() to get a list of items your character is carrying. A lot less code is required if you can think of a way to represent things like this in the scene tree, and it will work regardless of what unique characteristics each item possesses.
The ability to break up complex scenes and test things in isolation is also huge. One giant scene with one giant script can be a nightmare to rework (and you will need to rework it over and over again as you gain new insights about how things can/should work). I read some advice recently that a good pattern to embrace is “Call down, Signal up.” A node should almost never have dependencies on its parent. A node should be able to manipulate its children however it sees fit without unrelated things breaking. When you think a node needs to interact with its parent, what you really want to do is give that node a custom signal that the parent can subscribe to. Out of everything I have read so far, I think this was probably the most important piece of advice I have ever stumbled across.
Working like this in general really helps to make it so you can work on independent parts of a project without getting stuck on some big complex show-stopping system. You can break things without it stopping you from making progress elsewhere. You can also build rudimentary unit tests for some of the more complex logic.
Anyway, good luck, and feel welcome to ask Godot questions in the future. Apparently there are a handful of us.
The issue you talk about with tutorials, and not being able to piece a game together on your own, is actually quite common in my experience. I strongly recommend checking out the video How I learned Unity without following tutorials. The process he describes can be applied to any game engine.
Not too long. I started with Godot 3 a couple years ago, got distracted, and I’m only now getting back into Godot 4. So far I’ve only done like a handful of tutorials and made a few basic template games from that so maybe 4 or 5 weeks total. I’m also not very experienced with coding so it’s been a struggle. I have a vague idea of what needs to happen to make my game ideas work, like on a high level, but I have a really hard time figuring out how to piece it together and the tuts didn’t really help with that.
At least I’m much more confident in creating assets when I get to that part.
One small step at a time. I find that there are dozens of individual problems I need to solve to finish the project I’m working on, so when I get stuck on one I’ll jump to another for a bit. I don’t have anything groundbreaking yet, but even the smallest amount of progress each day keeps me from giving up.
I’ve got about the same background with Godot. Dabbled with it in the past, but never committed to anything. Just started messing around with it again about a month ago. While I do have amateur programming experience, It took me a long time to wrap my head around how different components should interact with one another in Godot (and I am STILL figuring this out). I was fighting with the Godot scene tree quite a bit, trying to create my own data structures and beating the Godot scene tree into submission. I have come to realize that it is better to just treat the Godot scene tree as the word of God.
Find ways to inscribe meaningful relationships between nodes in the tree. Find ways to structure things so logic can be performed with built-in Godot functions like
get_parent()oris_ancestor_of()instead of re-inventing the wheel or trying to implement an Entity-Component-System pattern. If one node is a child of another, you are free to add on any additional implications beyond the nuts and bolts built-in to the engine. You could create an inventory system where items from the world are simplyreparent()ed to an invisible Node inside the player, for instance, instead of getting bogged down trying to encode the whole thing in a dictionary and implementing the Factory pattern in GDScript. Then you can simply do something like$Inventory.get_children()to get a list of items your character is carrying. A lot less code is required if you can think of a way to represent things like this in the scene tree, and it will work regardless of what unique characteristics each item possesses.The ability to break up complex scenes and test things in isolation is also huge. One giant scene with one giant script can be a nightmare to rework (and you will need to rework it over and over again as you gain new insights about how things can/should work). I read some advice recently that a good pattern to embrace is “Call down, Signal up.” A node should almost never have dependencies on its parent. A node should be able to manipulate its children however it sees fit without unrelated things breaking. When you think a node needs to interact with its parent, what you really want to do is give that node a custom signal that the parent can subscribe to. Out of everything I have read so far, I think this was probably the most important piece of advice I have ever stumbled across.
Working like this in general really helps to make it so you can work on independent parts of a project without getting stuck on some big complex show-stopping system. You can break things without it stopping you from making progress elsewhere. You can also build rudimentary unit tests for some of the more complex logic.
Anyway, good luck, and feel welcome to ask Godot questions in the future. Apparently there are a handful of us.
Also: 122? That’s NOTHING! :)
The issue you talk about with tutorials, and not being able to piece a game together on your own, is actually quite common in my experience. I strongly recommend checking out the video How I learned Unity without following tutorials. The process he describes can be applied to any game engine.
I’ll check it out, thanks!