In short: learn by doing, learn to create a deliverable, rather than learn to learn. I do very much also hate the feeling of being completely unable to estimate time needed for x, because ive never done x y or z before. not sure that is avoidable.
Decades of work in software development (and estimating in story points, supposedly not translatable to time) led my to the conclusion that it's not about how much time it takes, it's how much stuff to be done I know of, and how much I'm not sure off.
Unless you're trying to get a "self-taught computer gaming" degree (which isn't a thing), tutorial hell is a form of analysis paralysis.
I tend to collect art and music for my games, but I'm fairly minimalistic at actually using them. I have 7GB of art and music sitting on my flash drive waiting to be used, but my last game used <20MB of both. I see the art and think, "I can see where that would be useful in that type of game. I might want to make one of those someday." Since there is no real cost to downloading free art and storing it on a huge flash drive or SSD HD, I can waste HOURS scrolling free game art sites and collecting BILLIONS of images.
What's the point?
Sitting passively watching "edu-tainment" tutorials have no value unless you are trying to solve a specific problem. So, what game are you right now in the process of making? What problem are you trying to solve?
"If the only tool you have is a hammer, every thing becomes a nail."
If you have no problem to solve, then every solution will work. ... But is it REALLY a solution if you have no problem that needs solving?
Well, given time management I'm still in the phase of familiarizing myself with the engine. After that I will pick an idea I'm capable of implementing and delivering fast. That's why I'm going with Brackey's and tutorials about making games of certain genre's - they're actually solving this problem, not being simple edu-tainment where you don't know where to go next with the knowledge, they're giving you a checklist. If only I got to this conclusion earlier ;-)
When I get a vehicle, I don’t take it apart; I drive it. When I maintain it, it gets me somewhat familiar with the engine and systems. When it breaks down, then I get real familiar with it.
Games start with design. That gives you a goal which you break down into tasks. Obviously when you’re new to the IDE it’ll all take longer and be more frustrating with lots of time spent in research, but since you have a specific task that you’re trying to perform one step at a time you’ll have a focus for your research.
Brackey’s introduced me to a lot of new and interesting concepts that I never heard of, but I was able to filter them through my game and ask, “Where does that help me now?” In most instances, it couldn’t see how it would. In one instance, I thought it might. I tested it and found it worked so I do it that way now.
Well, staying faithful to the vehicle metaphor I would say I have the vehicle now I'm practicing for the driver's licence ;-) By doing typical routes I would do. Like making a platformer ;-)
In short: learn by doing, learn to create a deliverable, rather than learn to learn. I do very much also hate the feeling of being completely unable to estimate time needed for x, because ive never done x y or z before. not sure that is avoidable.
Decades of work in software development (and estimating in story points, supposedly not translatable to time) led my to the conclusion that it's not about how much time it takes, it's how much stuff to be done I know of, and how much I'm not sure off.
What game are you trying to make?
Unless you're trying to get a "self-taught computer gaming" degree (which isn't a thing), tutorial hell is a form of analysis paralysis.
I tend to collect art and music for my games, but I'm fairly minimalistic at actually using them. I have 7GB of art and music sitting on my flash drive waiting to be used, but my last game used <20MB of both. I see the art and think, "I can see where that would be useful in that type of game. I might want to make one of those someday." Since there is no real cost to downloading free art and storing it on a huge flash drive or SSD HD, I can waste HOURS scrolling free game art sites and collecting BILLIONS of images.
What's the point?
Sitting passively watching "edu-tainment" tutorials have no value unless you are trying to solve a specific problem. So, what game are you right now in the process of making? What problem are you trying to solve?
"If the only tool you have is a hammer, every thing becomes a nail."
If you have no problem to solve, then every solution will work. ... But is it REALLY a solution if you have no problem that needs solving?
Well, given time management I'm still in the phase of familiarizing myself with the engine. After that I will pick an idea I'm capable of implementing and delivering fast. That's why I'm going with Brackey's and tutorials about making games of certain genre's - they're actually solving this problem, not being simple edu-tainment where you don't know where to go next with the knowledge, they're giving you a checklist. If only I got to this conclusion earlier ;-)
When I get a vehicle, I don’t take it apart; I drive it. When I maintain it, it gets me somewhat familiar with the engine and systems. When it breaks down, then I get real familiar with it.
Games start with design. That gives you a goal which you break down into tasks. Obviously when you’re new to the IDE it’ll all take longer and be more frustrating with lots of time spent in research, but since you have a specific task that you’re trying to perform one step at a time you’ll have a focus for your research.
Brackey’s introduced me to a lot of new and interesting concepts that I never heard of, but I was able to filter them through my game and ask, “Where does that help me now?” In most instances, it couldn’t see how it would. In one instance, I thought it might. I tested it and found it worked so I do it that way now.
Well, staying faithful to the vehicle metaphor I would say I have the vehicle now I'm practicing for the driver's licence ;-) By doing typical routes I would do. Like making a platformer ;-)
I find that consistency is more useful than motivation. Even if the task is smaller than intended, doing something keeps the momentum going.