Does anyone have any advice or strategies for moving away from tutorial learning? I have messed around with Godot 3.5 for about a year a so. Even bought a couple tutorial videos series on Udemy and pirated some e-books. I have worked through most all the resources I have acquired but I still feel like if you asked me to make a breakout or asteroids game in Godot I would not know where to start.

I experience this feeling when I first started learning computer science in college but luckily I had a coursework framework laid out for me. For Godot (and game development in general) I feel like I don’t have that sort of structure or confidence to learn.

Does anyone have suggestions as to how to progress without having to watch a video or read yet another tutorial. Ideally I would like to more naturally grow my skills and knowledge without it being laid out before me. I recently finished reading the “Game programming patterns” book (https://gameprogrammingpatterns.com) and it gave me I think a step in the right direction on “how to think” rather than just “what to do”.

I don’t expect to be a Godot superstar or anything like that of course. However I want to be able to think of a thing small and be able to implement it without looking for an existing resource unless I have a very specific concern rather than the general “how to”. I want to improve as a novice hobbyist but don’t even know where to begin that improvement.

Any suggestions or feedback would be appreciated.

  • I've been programming for 25 years and I still do tutorials. I know how to code games, but every API and framework is different, and platforms evolve. So even after 25 years I still have to do research all day, but more on the reading documentation and looking at open source code than doing video tutorials. But it really never ends, unless you are just doing the same thing as you've done before. It's unlikely even a God-level programmer like John Carmack could write a game without using Google.

Practice makes perfect. No amount of tutorials are going to get you there alone. You have to actually start putting together your own prototypes. And while you can I'd avoid making just yet another asteroids clone. If you do at least try and add something new to it.

    Make little demo projects focused on learning 1 feature.

    Then start putting smaller games together.

    Reading the documents is essential.

    There's also the possibility you have a superior skill in another aspect of gamedev? Art? Sound? etc? Not everyone is inclined to programming, I know I can't do art and you sound like me when I try to learn art. But, you also sound like me when I first started programming, so who knows. Could be motivation. Is there a way you can FORCE yourself to make progress?

    I've been recently learning how to do some things via tutorials and the thing I sit and ask myself as I watch them is "can I organize this better than the tutorial did?" A lot of tutorials will organize things a little sloppy so they can focus on the thing they're actually teaching. I find that reorganizing the thing they taught forces me to not just follow but understand what they made and how they did it, almost like homework. It also has the lovely side effect of making my project well-organized for painless development in the future.

      GMTK did a video pretty much about this, in his case it was Unity rather than Godot but I think the same principles apply.

        Thanks for the replys everyone. I think the general step forward should be experiment with small stuff and move upward and outward from there.

        soundgnome - An insightful video. It very much covers my general plight. I'll take the heart of the message and just start small. Thanks!

        Megalomaniak - I think I just need to buckle down and accept there is no real "quick" or "easy" path to where I want to go as a game development hobbyist. I think it's just going to be a long (hopefully fun and interesting) path of small projects and protoypes to learn small concepts and then applying that learning to a slightly larger concept.

        JSchrepp - I have been doing that a little bit actually. I have added a few smaller features or slightly better code organization but nothing too profound. It's good to know that's probably something worth doing going forward.

        One thing I do is watch the video for quite a few steps, then see how much I can do without looking at the video from memory. Another thing is check other resources when doing something, especially the docs instead of just following along. Truth is though, it helps to have some tutorial code to build off when doing a project. Maybe there are some people that can remember that much but I'm not one of them. Another thing is try making some changes to the code to do something else, even something small.

        I've been programming for 25 years and I still do tutorials. I know how to code games, but every API and framework is different, and platforms evolve. So even after 25 years I still have to do research all day, but more on the reading documentation and looking at open source code than doing video tutorials. But it really never ends, unless you are just doing the same thing as you've done before. It's unlikely even a God-level programmer like John Carmack could write a game without using Google.

        I am also an old-fart with pretty long history of programming, but I still find modern softwares are hard to learn w/o watching tutorial or tutorial videos, especialy the game dev tools such as unity, unreal or godot or whatever. The game dev tools/IDE is much more complicated and feature-rich compare to a single-purpose program like a video player, a compression GUI, read the f**king manual is just too inefficient since you only need to understand/use a very small portion of the game dev tools to achieve your goal(To make certain genre/type of game).

        Just my 2 cents tho.

          When I was in school, I spent a lot of time reading about lectureship and experimenting with techniques to make my learning more efficient (cause I hated school and wanted to spend as little time studying as possible). What I came up with is a 3-step process. Ideally, you'd have both the docs and a solution on-hand.

          If not, then you can go back to the scientific method: formulate a theory, test that theory and nothing else, formulate a new theory, repeat. In the context of game dev, this would usually mean putting print statements everywhere or watching vars in the debugger. It helps to have some sort of automated testing system for your game. This method is more general but also slower.

          Anyway, if I have ideal conditions, then here's what I do:

          1. Solve the problem, while following the solution to a T.
          2. Solve the problem, only looking at the solution for hints.
          3. Solve the problem on my own without any help.
          4. If at any point, you see something you don't understand, look it up in the docs.

          Also, spam asserts everywhere. Every time you make any assumption about your code, assert. You have no idea how often I've had things crash and burn because I've had values that weren't what I've thought. In the same vein, only develop one feature at a time and pay close attention to your APIs, e.g. Instead of trying to make 'enemy AI', make a path finding algorithm first, and then a state machine that responds to the path finding. And lastly, regularly rebuild small portions of your game from scratch. You'll get better over time, and better code is easier to maintain.

            MagickPanda - I will keep reading the documentation for sure but i maybe I should be less hard on myself for doing so. Thanks!

            10 days later

            I have the same feeling as you do, I have ideas of games I want to make, and yet off put by the lack of confidence in my skills haha. but I definietly do feel better that I am not alone in this and will just as many others here have suggested, one feature at a time, practice with it, play with it, learn and then try add another feature, practice, play with it , test it out 🙂

            TwoFox Also, spam asserts everywhere. Every time you make any assumption about your code, assert.

            The only caveat is that assert is ignored in non-debug builds.
            https://docs.godotengine.org/en/3.5/tutorials/scripting/gdscript/gdscript_basics.html?#assert-keyword

            So this would be a problem, because in a non-debug build, the file.open() would not be executed:
            assert(file.open("user://save_game.dat", File.WRITE) == OK)

            Instead, you could do this:

            var err: int = file.open("user://save_game.dat", File.WRITE)
            assert(err == OK)

            I've never used assert before, but I probably should.

            Most of the time what I do is sanitize the data that comes into functions. Such as using normalize min max clamp % (modulus) etc. so I know it's within the valid range.

            And of course checking for null, array out of bounds, etc. I guess there is an argument for catching mistakes early with assert but I would prefer to never trust anything and still have the game work and not fail even with bugs.

            10 months later

            You need something called "Intellectual bravery".
            It's when someone starts putting effort into what they think MIGHT work.
            It is when you think that your thoughts can solve a problem.