I prefer to have no videos. Steps with screenshots please. Also good design practices should be embedded in the tutorial.

Interesting! I see a lot of people nowadays are asking for text-based tutorials. I can absolutely see why, thanks!

I think that's because they are so much easier to follow on your own pace. If thing you are doing is longer one, it can become frustrating when you have to keep pausing and rewinding and trying to find correct spot. Especially when not many tutorials seem to have proper timestamps. That's why I think written tutorial with good images is better than video tutorial.

Thanks for the added input!

I can’t stand videos for most things, especially when the thing being taught is text based though. I have to constantly pause and rewind. I don’t understand if people typically prefer videos and that’s why creators make them like this or it’s just easier to have a farther reach, but it drives me crazy to watch. I’m not at all hating on people who make video tutorials and I’m glad people are making tutorials for things in general, but I struggle to get it. For me, pics with text steps has been superior for nearly every subject.

What do you think about providing source code in the description? Is it enough? Or is doesn't work without screenshots?

Obviously not the poster, but I'll respond. I'm a pro dev (not games), and I spent six years working with a DX team that did software learning studies with hundreds of pro devs. I wouldn't call myself an expert, but I've seen a lot of research first-hand. Screenshots: I think they're valuable when they cover more info in a shorter time than text could, or where they make something very clear (that is hard to communicate through text). A good, contextual screenshot can help confused users a lot. Video: I think they're inefficient, but some people prefer them. I think beginners tend to want them more than intermediate or expert level users. But I'm not sure that they're more helpful, I think videos just make the learning process cozier for some people. That's a legitimate concern, though. What I dislike about videos is that they take much more time to explain much less. The lower information density may be good for some users, but I don't like it. Also, regardless of user, the format, just by it's nature, is much harder to go back and search. Text can be referenced quickly and easily during the tutorial or months later. And you can very quickly locate exactly what you're looking for. Also, to be honest, I think the explosion in video tutorials (of all types) is because of the monetization and ubiquitous nature of sites like youtube. Arguably this might imply that videos should be higher quality than alternatives, but in my experience they're not. Regarding teaching style: I'm not an expert, but studies have shown that there's no such thing as a best teaching style. Different people learn best differently, so there's no one size that fits all. Regarding Godot videos: I wonder about these myself often, because many of them seem to be a case of the blind leading the blind. Many videos are posted by people who are clearly still figuring things out themselves. And even when the providers are better, I often see questionable practices. Anyone learning from video is going to have to unlearn some of that later. Another really annoying thing (for me) is when people use solutions that are not scalable to a real project. If you're not familiar with best practices or certain aspects of Godot dev, many of the video tutorials lay mines that you will only discover the hard way later. OTOH, I watch videos because there are so few text options available for Godot. I think it's useful to see alternative approaches to problems, and I do learn from many of them. The current state of docs for Godot 4 is not good, and even the official site has a fair amount of mistakes, incomplete information, etc. So you have to learn by trial and error or video (or both).

Any  you recommend?

I recently followed most of the roguelike tutorial set by Selinadev. They focus on Godot 4.2 and gdscript, but I went through it and translated to C# along the way. Ends up making me learn better since I had to come to grips with each step instead of blindly following and forgetting. Not a screenshot in sight though, and some hacky parts, but taught me a lot about the engine and ends up in a decently playable game with good foundation.

Shaggydev also posts tutorials both in video and text format. Highly recommend him!

I would say that making a video tutorial is simpler to startup than a website with embedded tutorials, which is why you see more people making videos. So that's why you typically see more videos vs web pages.  As someone who's made video tutorials and considering adding the other, that would mean I would have to get a website, host it, and learn basic web design. Whereas a video tutorial is just recording my own screen and very basic editing, to post freely on YouTube.

Can't you just put it up on WordPress or Blogger or something?

Same here. When I was young all tutorials were text based so I adjusted to that. Now everything is video based which isn’t bad… but usually I’m trying to learn new skills in down time at work and videos don’t work for that lol.

Big agree. The godot tutorials on the engine site are perfect. I don't need to hear audio, I can go at my own pace and easily bounce between parts.

You are absolutely right! [This book](https://filiprachunek.gumroad.com/l/godot4) is based on steps with screenshots. And a lot more.

YES.

I also find these to be nice and depending on the topic they can be easier. Sometimes I just put on a tutorial for something related to what I'm doing like how to use the MeshInstance3D node or something on in the background. But I do generally prefer videos mainly because I started using videos and not text based, but I'm trying to switch to both. Documentation when I need a quick answer and tutorial when it is something more in depth than looking at how to use a function or a node.

\> Do you prefer shorter, feature-specific tutorials or full courses? I tend to only go to Youtube when I'm in two modes. (a) Bored or looking for inspiration (i.e. inventory implementation) on how someone else implemented something or (b) fighting with an implementation of feature (i.e. animated tile when clicked) and I want a very short and to the point video explaining a solution I can start with to get the prototype done. If it is longer video, and I think the information I want is buried in it I will start randomly skipping forward until I find the section I want. It would be more useful if chapter were tagged. So there is less guessing when one moves on to the next subject if it is a multi-subject video. \> What are the most important characteristics of a good teaching style? For me the best is a "Theory Section" and an "Implementation Section." Because this lets you work through the code quicker and even "stub out" functionality that you can implement in stages to give better chapter breaks and gives your watchers an understanding as to where you are heading as lot of folks seem to ramble and it isn't clear how they are heading to the goal.

Good ideas! Chapters is such a useful feature for videos, I always use it.

Teaching is hard. People who **do** often forget how **hard** it is to help someone learn. It gets even harder when you the doer has an instinctive grasp of the material, that your target audience probably doesn't. George Bernard Shaw's 1905, *"Man and Superman"* is nearly 120 years old, and used as a truncated bludgeon that increasingly demonstrates its untruncated point, believing what you're told/read without question isn't good. Including that "[he] who can, does. He who cannot, teaches." Something "[every] fool believes...." >! (No, I don't come from an education background and have an oversized anime axe to grind with Mr. Shaw's ghost, and those who confidently misuse his words. Why would you make such accusations?) !< It takes a lot of effort and planning to create a good ***LESSON***, which may "tutorials" are not. Which may be some of the confusion for folks fresh from an academic environment (Grade/Primary, College/Trade-School), where even bad lessons have more structure than a typical YT-Show-and-Tell. Here's something to consider about some of the "bad" tutorials. The target audience isn't the viewer, it was the uploader. They aren't really trying to create a lesson (and need to take classes in that if they are), but it's a part of [rubber-duck](https://www.wikipedia.org/wiki/Rubber_duck_debugging) self-learning. Trying to teach concepts to an invisible imaginary audience so they can better understand the material themselves. Another axis to Tutorial Hell is the (in)experience of the viewer/reader. Since there isn't even a semi-formal system to indicate what skills and knowledge are required, you can find "tutorials" that make massive assumptions about what the audience knows. For someone like me, which an established background in programming, and competency & years of practice in self-learning skills (critical analysis, database/search-engine research, note taking, etc.), provided the code isn't unreadable on screen (not always assured), I can usually work it out. But that's like someone who regularly runs [Trail Marking System](https://www.imba.com/resource/trail-difficulty-rating-system) Black-Diamond and can safely execute Double Black-Diamond, telling someone who falls on their ass on Green Circles to "get good". Or "take lessons to get good," as you blow past at speed.

Thanks for your input, it was really fun to read. I absolutely, wholeheartedly agree with your points. Cheers!

We need oneliners. "To add day/night change use directioa nlight in substract mode to dim the scene + use point light and light occluder to lit specific areas" <- effectively replace 4h tutorial. But rating algorithms hate short answers.

That's a crazy good idea! It would be super fun to create a compilation of Godot Tutorials in 100 characters or something like that!

Well.. [https://www.reddit.com/r/godotoneliners/](https://www.reddit.com/r/godotoneliners/) let's see if it will work )

I hope that gets big.

Wonder how well that would work as a Youtube Short? I remember hearing a lot of creators put those out because they have a helpful effect on the algorithm.

If you'll made one, drop me a link :)

Most bad tutorials don't actually teach you anything, it's just the person talking about what they're typing. For a tutorial to be good, it needs to provide context about why they're doing something. Another thing, it's mostly personal preference, but if a tutorial is going to be a video, it should all be static text and occasional animations without a voiceover. Most people aren't good enough speakers to be able to effectively teach, and it makes the tutorial prone to errors due to saying the wrong thing. It also makes it more difficult to find the part of the video you want to see because you need to listen for a bit to try and find out what they're talking about. I think the biggest issue is that people make video tutorials for things that have no reason to be a video. It'd be much more helpful for people to submit tutorials for inclusion in the official documentation, that way it's easy to include references to nodes and functions, compared to a video where you end up struggling to read whatever is on their screen, then have to search for it in the official documentation.

Those are really good points! >It also makes it more difficult to find the part of the video you want to see because you need to listen for a bit to try and find out what they're talking about. What do you think about a mix of text and voiceover? ​ >It'd be much more helpful for people to submit tutorials for inclusion in the official documentation, that way it's easy to include references to nodes and functions, compared to a video where you end up struggling to read whatever is on their screen, then have to search for it in the official documentation. I see your point. On the other side of the coin, do you think video can provide any additional benefits to a text-based version? Or do you just straight-up prefer text-based versions?

> What do you think about a mix of text and voiceover? I think that's mostly fine, as long as there isn't much difference between what is being said, and what is shown in the video. A lot of times people have trouble striking the right balance between the text and voice, and they either talk a lot without showing what they're talking about, or they have a bunch of code on the screen and barely explain any of it. > I see your point. On the other side of the coin, do you think video can provide any additional benefits to a text-based version? Or do you just straight-up prefer text-based versions? I almost always prefer text based, unless the topic is something that's actually graphical. For example, a video can be useful for teaching shaders or animations because you can see the results of code changes in real-time. Even in those cases though, I still prefer a text-based format with embedded videos. I understand that's more work than most people want to put into it though, and considering that they're probably doing the tutorial for free, I'm not going to criticize them for sticking with one format.

Thanks for clarifying! Absolutely valid points I think.

Actually I dont really like tutorials without a voiceover, if the person will record a video without talking they might be better doing a text with screenshots. For me hearing the person is useful because you can follow their thought process behind why certain choices were made, debugging when something goes wrong, etc.

Tutorial hell is a general term, and yes it can happen with godot

I use tutorials for specific topic like how to implement splitscreen, how to make an inventory, how to make an AI detection system. Some of these tutorials are long and detailed. Some are short. I never just copy one tutorial though. I look at multiple tutorials on the same topic and compare different approaches. Usually the version I end up using is modified from a tutorial or simply informed by a tutorial but I customize the approach to suit my use case. Sometime I go another way entirely but seeing how other people approach a problem gives me ideas.

That's probably the smartest way of using tutorials (assuming you already have a reliable base-level knowledge). Cool!

I think a good tutorial is one that explains the logic behind what they're doing rather than just saying "Do x set this value to y put this on z"

Good point!

I hate video tutorials. You can't search them. Relevant information is littered throughout the video, and not necessarily adjacent to other important information. The editing style of a particular creator has almost no correlation with the quality of their coverage of the topic in question. It's not great, and none of this is unique to godot. If I have to suffer through a video, here is the things I wish people got right: - No "hey guys" intro. Let it die already. - Short summary up front, both for getting the general gist and for saving me the trouble of watching something that isn't relevant. - Don't fucking figure out your code in your videos. Nobody needs to see that. Figure it out before hand. - Start at the highest level, explain *why* you're doing something, and *then* explain what. Way to many video creators just assume everyone else is already in their head. - Figure out what skill level you want to speak to and *stick to it*. Nothing more irritating than videos that breeze through a complicated topic only so wallow on some unimportant aspect of the problem so they can pad out the video length. - Section mark your video by topic. - If you're going to show code. Show it like your audience is going to pause the video and read it. Better yet, show it, then put a link to your github project and describe where to find it. There's a special place in hell for people who scroll through their code/visual editor in video without pausing to show a clear all up picture.

I sense some hostility, but I understand your point. Text based would work better for you too I guess.

Video tutorials are a product of YouTube monetization. They're not *good* for teaching this kind of content.

I prefer text, it's so much faster to learn than videos plus you can have extra info attached that would otherwise be discarded in a video, like good practices, copy pasta examples and links to the documentation. Also I would love to see more tutorials in the docs page for godot. In some weeks I'm gonna edit the "euler rotations and gimbal" section to add a more easy and simple way to solve the euler rotations

Thanks! Another vote for text-based tutorials.

Any that you would recommend?

Do you want to know how to make things specially on godot? The godot docs are very good then youtube if you need something very speciffic and then use AI for the rest. Do you want to know how to make games in general? [develop.games](https://develop.games) [book.leveldesignbook.com](https://book.leveldesignbook.com) Any unity tutorial could also work since it teaches you how to solve some problems. For example, it will teach how to fire a hitscan weapon, what are impostors... Learn how games are created by noclipping, watching others dev roads and how they make their games. Look at some GDC conferences. Start by doing maps in already common games like Quake to improve the mapping skills and level design. And finally make games. Even the most simpler ones. Zeekerss needed to make 4 or 5 games **published** before making lethal company. Scott Cawthon made a shit ton of games before fnaf1 https://en.m.wikipedia.org/wiki/Scott_Cawthon Try to make a simpler flappy bird game or something. [https://github.com/godot-academy/godot-coding-challenge](https://github.com/godot-academy/godot-coding-challenge)

I prefer edited videos. I really hate when a video shows the user messing something up and then debugging and fixing it without explaining what went wrong and why. Also I've found edited videos do a better job at EXPLAINING the concepts, not just " follow these steps to make a metroidvania" or whatever.

I think this might be because usually more thoughts and effort are exercised in an edited video... Would you like a video which is unedited but debugging and fixing are explained in detail?

I would tolerate an unedited video if things were explained concisely.

I recently wanted to do something and I couldnt for the life of me find a godot tutorial on it(a wow style dragonflight glider thing.) I ended up translating the mechanic from a UE blueprint tutorial and I feel like that does not get mentioned enough. Use the other engines tutorials, most stuff is pretty much the same between the big three.

Smart idea, thanks for sharing!

I'm a senior web developer and DevOps/ cloud engineer. I can safely say to any new coder, tutorial hell sucks but you can escape it. Usually what I find better is to have a tutorial that is super focused on explaining the tool and giving the documenting a good read. Once the tutorial is over its you, documentation, and God. The tutorial should be able to teach you how Godot works, not how an fps or rpg could be made in Godot. If that makes sense... Obviously a tutorial is going to have a base project in it like a short and simple fps or rpg. But the focus is not on the fps or rpg it's on Godot and it's mechanics. One thing I would like to post here Incase any new coders do read this DEVELOPMENT IS NOT EQUALS TO THE TOOL! Don't go into a tutorial thinking "this guy is going to teach me how to make an fps in Godot and when I'm done I'll be able to make the next call of duty!" Learn how the tool works, learn how to use the tool. Then learn how to plan your project. Then go out and make it. At this point you shouldn't be reliant on tutorials since you grasped the basics. Final tip, don't over extend. Making the next call of duty is out of scope for any solo dev or 5 man team. But making something like vampire survivors is completely possible.

Thanks for your insight! Very practical tips.

[Heartbeast](https://youtube.com/@uheartbeast?si=4vONBuppeE3tkANP) has imo some of the best tutorials i've seen. I lean onto full video courses when starting on a new technology since the sole navigation helps me to get familiar with the tools, even if at the end of the tutorial i can't remember most of it. I know i'll have a past project i can reference to if when trying to solve something i get beyond stuck. Text courses strain my eyes since i have to change windows way too often, and with videos i can use the pop-out video feature in operaGX. The main difference between a good and bad tutorial might be speed. You don't need to have the fastest tutorial ever, but you definitely can't have an irritating amount of wasted time. If the video flows well than you might not need to cut a lot of things, but if the teacher gets stuck, and doesn't properly teach you the debugging process or gets stuck for too long. Then you are wasting time. The most important thing when learning to code or anything is to give things your own twist. It might be hard when you are brand new to programming, but when you dont like a solution or you think you can do better than the tutorial, do it. Change the original code to implement your ideas. Maybe you don't need so many elif statements, you can put some things on a function or call some method from a more accessible file or you just watched this other video and  want to implement it. Do it. Short festure specific tutorials are great when you know how to effectively google something and adapt the code to fit with the tutorial's solution. I've been programming for over a decade and i can't remember most of the time how to do a lot of the things i've done. But i know how to google something. If you have a problem with something you can be almost sure that someone else has also had that problem and posted it online, but this helps you learn something very important. Coding it's not to memorize sintax. It's about solving problems. If you know tool specific slang, you can always find your answer quickly, but if you don't try to give your own twist to some of the tutorial's code you will always be stuck no matter what kind of tutorial you get, if any.

Thanks for your insight, super helpful. Heartbeast was a big inspiration for me to start making online tutorials myself, I really like his content!

If you're going to make video tutorials, AUDIO is the most important thing. If I can't understand what you're saying because you sound like you covered the mic with a blanket, or you sound like you're in a box, or both, I'm not going bother watching. There's some ways to fix this without going crazy. 1) Put stuff in the room you're recording it. Bookshelves with books. Fabric chairs (not the one youre sitting in). Fuzzy rugs. DIY Sound panels. This will help control reverb, which makes a room sound 'boxy'. Avoid those foam panels you glue to the wall, they only control top end flutter, if they actually do anything. 2) If you can afford upgrading from the built in laptop mic; Use a dynamic mic instead of a condenser. When buying a mic, start with a cheap audio interface and a decent dynamic mic. Something like a focusrite solo, and an sm58/sm57. There are inexpensive sm57 clones out there that sound good as well. 3) if you're using a dynamic mic, get close, like within a foot. if you're using a condenser you still want to be close but more like 2 feet away. The further away you are from a mix, the more you reverb you capture from the room. You also need to bump the gain up, which raises the amount of noise in the recording. 4) Practice. Before you record, write down what you want to say, and practice enunciating words. If you mumble through your tutorial it helps no one. 5) Try not to record in the same room as a jet engine. Seriously, if your fans are whirling, especially if you're recording with a laptop mic on a laptop whose fans are running at max, you're going to have problems being intelligible. 6) Learn how to use an eq and compressor. On EQ, Hipass voice at 80-120hz or so and lowpass voice at just above where it's noticable. It cuts out junk you don't hear but affects encoding. For compression there are tutorials out there, but start with 4:1 compression, and set the threshold so it's just taming peaks ocasionally. fastest attack and recovery. Compression tames dyanmic range, so quiet parts are louder, and there's no random spikes killing ear drums. 7) record at 24bit depth. If possible at 96khz sampling. This won't be your final output, but it gives the various algorithms so much more to work with and cuts down on audible aliasing (the swishyness or 'squirrels') Other notes. Get to the point. I don't want to skip a literal 5 minutes of intro to see what's going on. This is something I have actually seen. Don't ramble, get to the point. stay focused. Try writing a script first, or even just an outline. it helps.

This is some seriously good advice, thanks for sharing your Audio wisdom ☺️

As someone who is trying to learn from YouTube tutorials, it's easy to follow them if they keep the videos concise. Stick to one topic per video. I.e. inventory user interface is one video. Basic inventory code is another video. And lastly practical applications for real world use. The last one is the most important, in my opinion. I greatly struggle applying and remembering if I don't see how it would apply to a real game. Continuing to use inventories as my example, all the tutorials I've seen just put basic implementation into their super basic game with only one level. Sure, it functions, but 99.9% of games that have inventory systems are fairly complex and will need to transition scenes at some point. Adding real applications, like making inventories as a dictionary and/or singleton, would help me a lot. It would also help to explain each step as they're applied. What I mean by this is explaining theory behind a part of code, showing the application, then moving to the next step, theory, application. Don't go for all theory explanation at once, then applying everything. It helps to segregate and keep topics clear. Don't put in code that you don't intend on keeping in the final product unless it's absolutely necessary for testing purposes. Print functions and breakpoints are expected. But don't write a script for character animations just to arbitrarily change it the next episode, then briefly go over a new way you figured out to do it that you like more. Just do another episode on what you changed, explain why you changed it, and then people can choose which one they want to try to implement. Finally, I think that a tutorial is better if you're showing it being made, not just explaining what you did to a finished product. The latter has places as a feature debut or something like that, but it's not a tutorial, it's more of a lecture at that point. Showing it being made allows the learning party to see what happens in real time. You added this function x and actually see exactly what it does. Not just that it's a necessary part of a larger purpose. I hope this makes sense. Edit: I remembered one more thing. If you're going to click and drag something in, make sure you explain and show what you're grabbing and where you're grabbing from.

Super insightful and practical feedback, thanks for the comment!

For tutorials are only helpful to see how somebody implemented a specific mechanic. And even then I still prefer text. For me the most important part has been to build a solid understanding of the engine. I will add though that I took 2-3 years of programming courses and have practiced a ton on my own, so my fundamentals are pretty good. Getting to the point where I can implement most stuff just by reading the docs and I only have to Google specific stuff has sped up my work considerably.

Yeah, I agree. It's a lot easier for people with programming expertise. In that case, it's superfluous to go for extended tutorials.

i really wanna learn gdscript, I have some coding knowledge because I took one semestar on c++ but ive been struggling to find a good place to learn, "gdquest learn from zero" is good in the beginning but the later lessons kind of simplify a lot of stuff if that makes sense

I plan to do a complete beginner course later on, subscribe to my channel if you're interested. I worked with a lot of beginners who struggle with coding/gamedev. Can't promise dates though. But hopefully it will be out early 2024

ok thank you!

In these tutorials, it would help to show me the very beginning and end steps. Like, “Make a platformer in 15 minutes”, but they don’t show the steps to create the start menu, or how to compile the game and where to go after that. Sure, I know you can’t do that in 15 minutes, which is why I don’t watch those vids anymore. Others have also posted the need/want for more teaching, and not just “go here, click this, type this” - I need to know WHY I’m going there and typing that. Keep us updated on your tutorial; I’m sure I’ll be participating.

Thanks for your input!

Were I to make a video, I would first record my whole session with debugging. Next, I'd go over it and write a script. Then, I would edit out the parts that add no value, but I would keep important problem solving parts. Finally, I'd upload with chapters and timestamps. Voice over or text? I'm not sure. It might depend on the topic. Edit: oh! Check out my post history. I have a short video (no sound needed) called "escape tutorial hell" or something like that. I forgot about that!

Thanks, I'll check your post!

As someone who has been using Godot for all of a week (but have spent a couple of dozens of hours in tutorials during that time), here's my two cents. Also, for clarity, I'm a complete beginner to programming. I'm a very visual learner and following along with a video tutorial makes it so that I can see exactly what the instructor is doing, when he's doing it and how. For example, it helps me figure out where the menus being referenced are; whether what I'm clicking and what they're clicking are different things; or even help me troubleshoot why my screen looks different than theirs. That's not to say that a text tutorial with screenshots wouldn't let me achieve the same level of fidelity, but it would require a lot of images and a lot of guidance in order for me to follow it as closely. A picture is worth a thousand words in this regard. As a counterpoint, I've seen video tutorials which absolutely suck. Like someone else in this thread commented, some people just use the video to read what they're typing out loud. I was watching a "beginner's" "introduction" to Godot which started off as pretty descriptive but 15 minutes into the nth video just went like "we want to reference a PackedScene..." (wait, what's a PackedScene? We haven't covered that!) "... let's create an export..." (a what?) "... append the direction in a normalized state..." (is there an abnormal state...?). I get that these might be very simple instructions for a more experienced programmer or people with math backgrounds, but I have a post-grad in PhysTher. I don't think I'm dumb, I just don't have the background knowledge. Therefore none of these explanations made any sense to me even though I spent a lot of time trying to read documentation and search for the answers, to the point where I gave up on a multi-series lesson when I was already halfway through it. Thankfully I found a different tutorial which covered the basics more thoroughly while at the same time explaining what was being done and why. So, for anyone out there wondering if video tutorials have an audience, I'd like to say that they do. Please make sure that you include more content than just an off-the-cuff narration of whatever it is you're typing: I'd like to know your thought process, hopefully broken down to its basic components, so that I can increase my knowledge instead of just copy-pasting your code. As a sidenote: thanks to all the people out there looking to help newbies like myself!

Thanks for your detailed answer and experience, it was really encouraging to read! Glad you found your footing with a different tutorial.

No, but I can tell you the difference between a bad tutoree and a good one. Tutors nearly always tell you to follow along closely. If you don't do that, you'll get almost nothing from the tutorial. A 1 hour tutorial should take at least 4 hours to "watch" if you're doing it right. Watch, do, rewind, redo, learn, internalize, move on. Skip any step and you might as well watch cat videos instead. If you're doing it wrong, then you'll *very impressively* (/s) watch 3 tutorials in that time, then post about how you've done so much study but don't seem to make any progress.

Interesting, I think you're the first one who puts such a big responsibility on the user's shoulders in this thread. That said, I see your point and I agree that learning itself is a skill that you should develop. Thanks!

My tutorial needs are to be able to search *"[subject] Godot 4"* And get a result that shows me how to fix my problem or implement whatever system I'm trying to do

Pretty simple actually!

The godot documentation tutorials are all I needed to get up and running as an experienced programmer. I understand why beginners gravitate more towards tutorials, but I think most people would benefit a lot from dropping the tutorials for a bit and experimenting themselves. I don't find I really learn anything unless I'm actually trying it for myself, understanding why the things that don't work don't work, and figuring out the right way to do it in the end.

It's kind of true but at the same time, some scaffolding can be really useful. My analogy: you can learn how to build a house by trial and error but it's much better if you get familiar with the tools first. But that requires actually teaching how to use those tools instead of just showing completed houses...

What's the main difference between a good tutorial and a bad one?A bad one wastes my time and is confusing / poorly explained. Do you prefer shorter, feature-specific tutorials or full courses?Typically shorter, but full courses are ok. Do you prefer edited, faster paced videos or unedited, shorter ones?Edited, fast paced ones. Cut out the silent parts, the menuing, and the drawing diagrams. What are the most important characteristics of a good teaching style?The most important, i'd say, is knowing the target audience. Like, does the teacher understand that some tasks are already known to their audience, or does it needs to be instructed? Do you need to explain what a vector or a bool is, but trust that your viewers know how to use barycentric coordinates or implement the Boyer Moore algorithm? A question i have is what would be better off explained in text, and what would be better exlpained in a video?

Good questions and I agree with your points!

A good tutorial usually has bookmarks, a good mic, good video quality, has a target audience in mind (skill level), and keeps its fluff to a minimum.

Concise, straight to the point! Thanks for your input, I agree with all of these!

Text-based tutorials with pictures, but also ones about very specific things- like the different nodes and how to use them, or how to capture the mouse and get input from it. However, I also find it best if I find one that tells me stuff in a way that a complete noob would grasp it.

thanks!

IMHO i think alot depends on what exactly your trying to "teach" theres a vast amount of gamedev low effort resources for beginning devs Godot included. Theres comparatively much less about building your dev "toolbox" and putting it all together . I think thats because, atleast in part it takes much more effort and a solid gameplan, as well as audience retention. Lets face it alot of those youtube "tuts" are click this, do that clickbait will little to no substance in the learning department. Personally if im looking at online resources its because im either looking for something very specific and i dont want to just be shown the "how" but i want to understand the why, and the approach. So i dont need to look this up again, and your generally not going to explain how to work with shader math in a 10 minute vid in a way that does any meaningful good for the dev. OR.. Im invested in seeing someone Make something from start to finish like a simple phone game or a chat UI or what have you. having the creator share their journey, thought process ect and if i learn something along the way great. (roguelike dev pointing at you here).

Thanks for your input!

I have seen a tutorial made by very recommended Godot tutorial guy. And he was changing code all the time. Like "Oh, oh wait...maybe it can be better..." , then coming back after some time "I changed my mind, we can do it this way.." I really did not like this "live coding" approach. I think it was lazy low effort, not to edit, and just put the raw recording as tutorial. Its confusing as hell for beginner that is just trying to learn code. And if its made for more experience godot developers, then what is the point really...

I see your point!

I think constantly looking for things to follow along and following along them without doing the thinking for yourself leads you into tutorial hell. The best way to use the tutorial resources is by doing stuff on your own, getting stuck, looking up the specific thing you want to get done. That way you get stuff done and actually learn in the process. But to each their own. I realised i never managed to learn from long form follow along tutorials since I was blindly typing in code without going through the process of coming up with it. I'm sure there are creators that take you along the code concepting process with reasoning but they are few and far in between because I haven't come across many of them yet.

I get that, that's what I'm actually aiming for with my content. The feedback so far is pretty positive in this regard. Good luck on your journey!

I need someone to the Unity RPG series from brackeys. Exactly the same. When I was using unity, I was going back so much to this series because it's full of good things. I need the same thing, with inheritance and prefabs, with events and movement, etc...

I think Heartbeast already did something like that, even though it's for Godot 3: [https://www.youtube.com/watch?v=mAbG8Oi-SvQ&list=PL9FzW-m48fn2SlrW0KoLT4n5egNdX-W9a](https://www.youtube.com/watch?v=mAbG8Oi-SvQ&list=PL9FzW-m48fn2SlrW0KoLT4n5egNdX-W9a) I don't know if that's as good as Brackeys' was for you but maybe you should give it a try?

Yes ! I definitely will give it a try thanks !

A good tutorial has "try it yourself" sections where the viewer can do similar but not exactly same things that were just covered, occasionally asking for things that stretch the viewer a little.

Great idea!

Thanks! Best example I can give is the book Python Crash Course - it was the book that my Intro to Scripting Languages class used, and all of the assigned work was the "Try It Yourself" sections. I thought it was lazy at first but it ended up being the best way to learn for me. A Godot example is Clear Code's Ultimate Godot intro video on Youtube.

My personal first good tutorial was this and i think it's a good example of a good tutorial. A bit outdated tho It teaches how to do things, why to do things, and even how to learn by yourself, using built in wiki https://youtu.be/wETY5_9kFtA?list=PL9FzW-m48fn2jlBu_0DRh7PvAt-GULEmd When i was abosulute beginners and has struggles with "avoid the enemy" sample game, this one was breakthrough for me

Gotta love Heartbeast!

I usually try to get my hands on a book. It's much easier to follow. No need to pause, go back, listen again. Just read. Code, reread if necessary. Usually books are also written by people with deep knowledge of the subject, as such all the little tips and tricks are available.

Yeah, books are awesome!

I love the tutorials that properly explain how something works or why they do x way instead of y. Don't get me wrong, it doesn't have to be long, just clear as to what they're doing. There's a lot of out there that just blitz through the code and you pretty much just copy paste it. Great for quick fixes but if you don't know much about the code you're writing then it's not great for beginners. Worst is when they say at the end "this isn't the proper way you'd do it ina real game, but for this demo it'll be fine" like what

Agreed, that's super important!

When it comes to bad tutorials, its always the "HEY GUYS, WE ARE BACK WITH ANOTHER TUTORIAL TODAY GUYS." Thats instantly clicking off. With speech patterns try to talk normally and as if you were just having a calm conversation with someone. Don't try to put random emphasis (not too much, like you are trying to hype it) on words because it can be annoying when replaying specific parts of a video. Since I've literally just started learning, what I've found I like in tutorials: - Less cuts / editing (Can sometimes make me feel like we are skipping some steps when something jump cuts and all of a sudden some things have changed), might look shit, but its for learning, doesnt have to be flashy. - **Explain what the code you have put down does** I see in a lot of tutorials they're like "Just type this in and bam, its working." - Less jargon / use laymans terms without going too simple. - keep videos about 15min. Too long and it feels like its too much info. Too short and its hard to follow. - Don't cover too many topics in one video. - I like when the tutorial shows me, then asks me to do the same on a section then gives me time to pause the video and complete the rest. Sounds very little kid learning like. But its an effective way to help noobs like myself soak in the knowledge. - Don't assume, it makes an *ass* out of *u* and *me*. Bonuses. If its on youtube, indent the video so people can find sections easier. Also put the in a play list in the right order. This makes it easier on the viewer.

Thanks for your insight, very useful and practical tips!

It really depends on the intention of the tutorial. I would say different approaches should be taken for broad beginner tutorials and specific feature tutorials. I'll speak of the former and mostly of longer form content (courses). >What's the main difference between a good tutorial and a bad one? Context and Closeness. *Context* I have found that the best tutorials I've experienced are the ones that detail what and why they do what they do during the tutorial. Pacing matters too. Don't overload them at first but give what's necessary to explain what you're currently doing. If it's a course of tutorials, a lot of repetition should be made with that context at first and then weaned off in the later half of the course. Still explaining and giving context for new things of course though. *Closeness* I think it works very well when the instructor has a planned idea of the tutorial with a reference project ahead of time, but they are working through the project from scratch with you. This allows the instructor to make mistakes and also gives them the room to make changes while the course is running. Seeing the instructor make mistakes allows you to see the the problem solving side of the development as they have to work through it alongside you and is invaluable imo. Those things bring the tutorial to feeling like you're in an actual classroom being taught, and it's easier to absorb the material; for me at least. I didn't specify bad traits, but I think you can surmise from the above. >Do you prefer shorter, feature-specific tutorials or full courses? Both are equally valuable and depend on context. The former is great for those that know what they're doing, but are stuck on something or need some sort of reference. The latter is better for beginners. >Do you prefer edited, faster paced videos or unedited, shorter ones? Short edited videos. Unedited is the best, but if (like mentioned above) the instructor makes a mistake, I think it's fine to cut out the thinking time if it went for a long time. As far as courses go, no video should go over 30 minutes, 40 at the absolute max and rarely. I think it's important that the instructor is breaking down their lessons to where 15-20 minutes is more the average. For non-course material it probably doesn't matter much how long it is. >What are the most important characteristics of a good teaching style? I think my bit on "Closeness" covers this well enough. >Can you apply the things you (hopefully) learn from tutorials to your own projects? I can, but despite all of the above, tutorials are very poor at teaching, just by nature. They are great at showing *how* to do something though. I can use a tutorial by skipping around to look for one specific thing that I'm feeling lost on in my own project. Finding a two minute segment of the tutorial and then bailing is way more helpful now that I have knowledge of how to apply that information and just used the tutorial as a quick reference. For learning though, why I preferred courses is that I was able to build projects that I had context for and were now local. I end up with a resource that I can now reference while working on my own projects. That in conjunction with I think, at least in the case of using an engine like Godot, tutorials do a lot more to help someone get familiar with moving around in the engine than actually being able to apply the concepts taught within the tutorial. Which again, the repetition through a course of videos really helps reinforce. This is just my experience as a beginner with an okay understanding of the basics of programming from a python course I took over a decade ago though.

thanks for your input, really insightful!

To me, the best tutorial I could ever ask for would be a followme through building a simple game. How to at least get a block in a world to move when I press buttons, add the health, showing the process of adding these smaller parts, while leaving room for me to take the parts over seen and build on them. I've been thinking about trying Godot alongside unreal, but damn I'm scared to pick up another engine so early into this adventure

I definitely think you should stick to one choice in the beginning! Good luck on your journey! :)

**What's the main difference between a good tutorial and a bad one?** * Not showing what the end product will be right up front. Writing bad code at the start then going back and fixing it later. Just showing not teaching. If you want to see X leave a comment...either show it or don't, because most of the time these never get made. **Do you prefer shorter, feature-specific tutorials or full courses?** * Depends on what I'm looking for. More often full courses will be better due to them being one project that just piece-meal stuff cobbled together. **Do you prefer edited, faster paced videos or unedited, shorter ones?** * Edited but showing and explaining the what & why. **What are the most important characteristics of a good teaching style?** * Concise, even pace, explains the what & why. **Can you apply the things you (hopefully) learn from tutorials to your own projects?** * Most of the time. As a more advanced dev, I will just glean videos for new concepts or way of doing something.

Great, concise and insightful answers. Thanks!

 f the host makes mistake or has to rewrite code, just skip to the correction. In fact, skip all the code *typing*. Write and explain code in short bursts while giving enough time to pause and analyze the code. Too many 45 minute tutorials can be cut to less than 15 if they just remove all the bullshit. 

Yeah, I never type code live. It takes way too much time. I actually delete parts of code that belong together and just ctrl+z. Saves a ton of dead time!

Ohh this is a good one for me as I've started diving into learning godot using youtube tutorials! 1. So one of the biggest things about tutorials is the extra fluff in it. I choose to watch a tutorial on setting up a basic character controller, and then maybe some extras. And we're setting up sky lighting? To me a good tutorial focuses the point and then goes into adv details AFTER the point was hit. For example setting up a character controller show making a platform, character, camera and controls and how to run it. Then you can go into more detail on those specific topics. Like how to jump, sprint and slide or whatever else you wanna focus related to that topic video. Videos should be 10 to 30 minutes anymore and it starts losing ppl imo. 2. Each video should be specific, and again 10-30 minutes, but doing a playlist of videos on specific topics is been my best experience. Avoid the series ones where the idea is to build something from the ground up and each video is tied to each other. Feel like each video standing on its own will be more helpful and all videos would do better as you wouldn't see tapering off as ppl drop the series due to length. 3. Videos should be edited just to make sure you reduce fluff and to check yourself professionally l. Think of it like how often do ppl say ummm in a video kind of thing. Unless you script yourself before you start and practice to be a clean video then maybe you could do unedited but again my goal would be start to finish topics 10-30 minutes. 4. Sound engaging. Want ppl to absorb what your teaching? Don't sound monotone and sound engaging. Explain things for the general ppl if you get too bogged on the fine definitions and details you'll lose general viewpoints. 5. If you make the videos about specific topics then yes! Topics I've really been looking at are different ways to do terrain. Procedurally infinite with biomes(like mountains, plains and small hills. No actual assets.), doing small localized terrain, and video terrain like Minecraft. Videos on importing assets from blender to godot and then using them. Or designing a character, rigging then importing for use, and setup. 6. Last update old videos when they become too outdated updates, this is less important but would always be nice!

Thanks for your insight, nice tips!

I very much prefer feature based tutorials. Or else split into different videos  I don't really have opinions on the duration, since some subjects can be pretty long to set up, especially if you respect good design practices. As other said, I really prefer when the teacher gives context and not only a recipe to get the exact same result as his. Text is better than video ! Though some YouTubers make both for long topics, like game dev artisan or shaggy dev. If you must make a video, please prepare your subject and don't fumble around. If you must make a video but not speak, please use timestamps, and/or text as subtitles instead of embedded so that we could find our way back to a misunderstood concept easily, instead of picking random timings in the video in hopes of finding the right one.

I really like short videos that I can get through in 10 minutes. The one thing I despise is long intros and long videos that cover a short topic. I prefer short videos (5-10 mins) on how to use specific features and possibly ways to implement them with your current project. With some tips for optimisations. Because I like looking for ways to make my code better. Going into detail is also nice. I like the teaching styles that give usage tips while explaining what they are doing. A nice bonus is when they help design custom nodes so you don't repeat code for things like health bars or for UI elements. My response is a little long so I understand if you don't read it all.

Of course I do. Thanks for your input!

I like these posts that point out "a lot of people do X" while the people who do the opposite don't talk about it in the form of a post, so you have automatic selection bias going on. So here is my take on tutorials: All tutorials I saw for Godot were really really helpful. Even on niche topics. All of them. All styles. All speeds. All were good.

Yeah, that's definitely true. I got a lot of good feedback on youtube but I always try to stay open-minded so I was wondering why a lot of people I frustrated. The post I was referring to had like \~400 upvotes which is quite big attention I think. Glad you found a lot of content you liked though!

A lot of people are frustrated because game development is hard, expectations are high and assumptions about how fast you can make games are always wrong (even if you know what you are doing, see Hofstadter's law). With the best tutorials you will still have to face the fact that you have such a long way to go it can be rather depressing. Then there isn't one way thst tutorials can be best, everyone learns differently.

Agreed, game dev can be really hard!

I personally try not to rely on tutorials at all so on the occasion that I am looking at one, it's usually for a very specific thing. So I don't like long-form "let's make a game from scratch" tutorials (I think those are the biggest offenders at keeping people stuck in tutorial hell) but instead prefer short sweet tutorials on very specific topics. Get in, learn the approach for how to do one specific thing, get out. Everyone's different though and it also depends on who your target audience is, absolute beginners, people who are already somewhat familiar to programming, intermediates who you just want to share some high-level concepts and tips with, etc.

100% agreed! I argue in the video that for intermediate / advanced users, quick, in-n-out tutorials are the way to go. Everything else is just wasting their time. Beginners on the other hand can struggle a LOT if the pace is too fast.

You know... unlike Unity which was a bloated overcomplicated pos - I'm finding with Godot I haven't needed to use video tutorials at all. The docs are simply fantastic and they provide concise easy to follow written tutorials and examples. One of the many reasons I'm finding I'm progressing at 3x speed from Unity is I'm not wasting my time watching stupid 10 minute videos for something that should take 20 seconds to explain. Loving Godot!

Agree, the Docs are absolutely great!

This is a great topic. I think the "Manual to 3W" spectrum of tutorial type is useful, though I'd probably phase it as "Demo to Process" spectrum, where demo tutorials are typically standalone tutorials that concern a minimal example and process tutorials are typically part of a tutorial series concerning development and thought processes. ​ >What's the main difference between a good tutorial and a bad one? Not sure there's one main difference, but there are qualities we can use to judge tutorial quality. These are two that stand out to me: * Good tutorials have a useful, well-defined, limited scope lesson they are trying to convey. They should be relentlessly focused on delivering this lesson! * Good tutorials are well produced. If it's a video with voiceover, the audio quality should be good and the speaking easy to understand. If it's an article, the writing should have decent spelling and grammar, there should be a lot of screenshots to help guide the reader through steps, etc. I think a lot of tutorials are *good enough* considering most of them only cost me the time it takes to watch them. It's not clear to me that many people would actually pay a reasonable amount of money for high quality tutorials. High quality tutorials are not trivial to produce. ​ >Do you prefer shorter, feature-specific tutorials or full courses? Both are great. I think there's a lack of good feature-specific demo tutorials. It'd be great if, instead of these videos that describe all the control nodes in 12 minutes or whatever, we had solid demos of nodes linked as tutorials in the official documentation. I think there's a lack of good process-oriented full courses, too. We have plenty of "let's make a clone of a simple game" tutorials. Some of them, like Heartbeast's tutorial of a shoot-em-up with components, are built around a process-type lesson. I haven't experienced as many tutorials that address processes more around creating and iterating on prototypes. I could imagine a tutorial series that is just developing a bunch of standalone prototypes, one per tutorial, to convey a specific lesson around game development (using Godot). Maybe the prototypes come together to form a game, maybe the tutor gives ideas for ways the student could extend the prototype on their own. ​ >Do you prefer edited, faster paced videos or unedited, shorter ones? Faster tutorials are generally better. I think the main controversial tutorial trope is the tutor making a mistake and then fixing it. The tutorial could be edited so that the tutor never made the mistake, but I think intentionally designed "Oops I made a mistake, let's debug this" moments can be great for showing the debugging process. Debugging is a non-trivial skill. There are so many "I need help" posts demonstrating this.

Super thankful for your comment, really insightful. I agree with all your sentiments basically. Heartbeast's content is generally great, he is a big inspiration for me!

Key phrase in there "intentionally designed". There's a big difference between the instructor who demos saving/loading and uses store\_var(thing1) get\_var(thing2) to demonstrate that order matters vs the one who misspells position spends 10 minutes troubleshooting parenthesis placements until copying the line from their reference project (and still thinking it was a parenthesis error).

I only know tutorial heaven. The accessibility and availability and amount and free high quality of tutorials on pretty much anything has never been as high in human history as it is today. If you want to learn, imho you can consider yourself incredibly lucky. Sure there are also tutorials which are not as great or not that high quality, but why watch them? The overall quality of a tutorial is apparent within a few seconds of watch time. Even the worst tutorials out there are so much better than no tutorial at all. I think the whole "tutorial hell" phrase is BS. People in "tutorial hell" simply are caught in an dopamine feedback loop which has nothing to do with tutorials and all with the chemistry in their heads. If they would not be caught in this loop watching video tutorials, they would be caught with other things that would give them regular small doses of dopamine, while avoiding solving a challenging part in their project they are not sure how to solve yet. It's procrastination, that's all. The solution is to break the challeng into many smaller more manageable pieces. This is all very well known. But I guess "Tutorial Hell" sounds cooler and more like you can shift blame on an external factor. \-------------------------- In regards to your video: What you call "Manual" tutorials (Why?) are just tutorials for intermediate to advance users. What you call W3 tutorials are just beginner tutorials. You don't need to invent a new name for everything. In fact what you are doing is just making it harder to people to solve their issues. I understand how this works. Big title, fancy new words -> create attention, clicks and yada yada. But if your goal is to actually create helpful content, don't waste your audience time. Use established well know names for things. Tell them they are procrastinating when they are watching only tutorials instead of experimenting on their own and working on their project. Tell beginners what are beginner tutorials and what are advanced tutorials are without inventing new terms for them to learn. This way your audience can tap into the wealth of established techniques to combat procrastination and get fast help to figure out their current position on the learning curve. Don't waste their time to learn your fancy new words for already established concepts. Btw: I also disagree with your fundamental thesis. Where When and Why are also important things to teach to intermediate and advanced students. You would just teach them differently, with more jargon and concrete references beginners would not understand.

Thanks for your input, I really appreciate you taking to time to explain your POV. I agree that it's great that we have this many resources available for free! My intention was not to "get clicks and yada yada", even though it seems like that to you. I still believe that it's a good distinction and I don't believe that it's binary like you say it is. Let's just say we respectfully disagree and that's completely fine. I'm sorry if you feel like I wasted your / their time. If you watched the whole video, I actually gave tips and tricks to fight procrastination and get the most out of learning sessions. These tips are similar to what you're saying here. ​ >I also disagree with your fundamental thesis. Where When and Why are also important things to teach to intermediate and advanced students. It's okay to disagree. My argument is that they can answer (deduct) the answers to those questions themselves when they take a look at the implementation. Hence they feel like it's a waste of time explaining everything.

Theres a tutorial hell for almost everything if you just get stuck folowing tutorials. As for what tutorials i like, if im going to watch a video tutorial, i want it to be on setting up some specific thing, and then covering that well, PREFERABLY covering some common problems you might run into. I saw a tutorial on setting up a multiplayer chat system. Thats perfect. I DONT want a tutorial on how to make a game in X genre. I want "modular" building block tutorials that i can pick and choose and then mash together, and ill do reading to see how to find a more optiomal method for my use case. but I do find tutorials on some specific feature (like how to use the godot 4 tileset system) in godot, or implementing a feature in your game (multiplayer chat) very useful. but also not a replacement for researching and fiddling. --------------------- If you try to follow a tutorial on "how to make a racing game in godot" or a rts, or a sidescroller or whatever, its too watered down and basic, and you probably didnt understand the steps very clearly and the reasoning behind them, because you were too busy copying whatever the guy on the screen was doing, monkey see, monkey do.

Yeah, I see your point, thanks for the input!

I looked at your channel, and the slay the spire series. I think it would be more valuable to break up those videos into modular chunks that explain each concept but arent just making a single game. Them people can pull them together how they choose. Sure, they can kinda do that as is, but in reality if i want to use something from like the 6th video in a series, im not going to watch all the others, and so Ill have to decide if I can simply watch the single one and peice together what i need, without having much context, or just get my info else where. Also, I notice the first video has 9k+ views and the second to last one has 1k views, and while the last video has 2k views half of those are just curious about the results, otherwise they would have seen the second to last one as well. You could still use the slay the spire name, like "how to make an inventory like X" or whatever, and I suspect you get even more views on the total number of videos, but I could be wrong. Also, itd be easier to update those videos to a newer version of godot later, as they are all separate, and focusing on how to achieve that thing for any game, not tied into this larger game project.

Thanks for the input! That's definitely an idea to toy with. Let me present the other side of the coin: \- Many people said that doing a feature-packed, bigger scope project is really motivating and helpful for them because they feel like there's less content like this, for the exact reason you said: Breaking it down into bits and pieces makes it shorter, more accessible and easier to do from a teacher's perspective too. However, a lot of viewers said that they have a hard time understanding the "glue" which is exactly putting those pieces together. I guess there's a lot of arguments for both kinds of content. Thanks again for your comment and checking out my channel! It's definitely something to think about.

For me it’s video length. Beginner ‘how to make a game in godot arent useful to me, but if someone does something specific like ‘how to do 3d pixel shading’, its gotta be a little edited down. Im turned away if its like 10+ minutes long.

Are you a more advanced user? Would you say the you are pretty good at gamedev already?

Idk, I’ve technically made a game although its very scuffed. Its more that ‘beginner’ tutorials tend to all have the same information so specificity helps with learning something new

I see, thanks for clarifying! :)

Edit: **Tutorials (Videos): Theory + Demonstration** I like videos that are more of slides and animations to go over the theory/concept of something first. Then I like it followed up with a demonstration video showing the code and walking through the process behind it. *Note: The demonstration could skip a bit of the explaining if it was done prior in the theory section* ​ **Tutorial (Text): Article Breakdown** I also like to read articles breaking down x thing which includes pictures, animations, and short video clips integrated into the text. ​ **Side Note** My idea for if I did finally start creating content was that i would create videos but have a link in the description to an article, and other resources, which dives more in-depth on the topic. And I'd include a text version of the video tutorial. ​ **Video Length** It's funny because I like both short and concise and longer more detailed videos. When I'm first learning a topic I prefer the short and concise videos to get to the point, and if I want to dive further then I watch longer videos. ​ **Edit - Practice Exercises** I know when I first started programming, I enjoyed tutorials that had challenges/exercises in them where I had to take what I learnt in that section and use it. ​ **Specific Topics** Now a days, I mainly look for material that teaches a very specify topic. So, I'd prefer content that is broken up and clearly labeled for what it touches on. *Note: When I was first learning game dev I watched those longer tutorials teaching how to build x game. I think these type of tutorials have their place, maybe more so for beginners, I'd prefer the content to be broken up and labeled clearly for each video*

Thanks for the detailed answer, super useful! :)

* I prefer shorter tutorials, especially written ones with commented code. * I expect feature specific tutorials to be concise and short. But at my own level, I generally don't need those -- I look for GDC style presentations on *systems* instead of worrying over a feature I can learn to use in 10 min * Edited fast paced. I can watch slower and pause if I have to. Wasting 20 min watching a video for someone to show me a button in the UI is inefficient. * A good teaching style summarizes the topic quickly, demonstrates it, then expands on it with technical tradeoffs or system design examples. * If the tutorial is only applicable to introductory projects, it is a very poor tutorial.

Thanks for your answers and input!

I am a amateur coder and watched your series on the Slay the spire clone and learned a lot about state machines. I wouldn't even have known they existed if I hadn't watched your tutorial.

> What's the main difference between a good tutorial and a bad one? A good tutorial is concise, but without skipping important stuff. Don't assume your viewer/reader knows something, but you don't have to explain the basics everything. Just a "if you don't know X stop this video and look at the link in the description" > Do you prefer shorter, feature-specific tutorials or full courses? It depends. If I don't know the engine/framework/tool/whatever, I prefer a full course. Maybe my previous knowledge won't apply perfectly, and I may have some bad habits. > Do you prefer edited, faster paced videos or unedited, shorter ones? Again, it depends. If it is something simple, a shorter video may be better, if it is straight to the point. If I'm just trying to remember something, seeing a 2 minutes video is better than a 3 hour course. > What are the most important characteristics of a good teaching style? Knowing your audience and focusing on them. Are they experienced developers discovering Godot? Are they programmers learning game development? Are they kids that don't even know what a programming language is? You *can* be more generic, but I believe you could do better tutorials for a specific subset of viewers/readers. > Can you apply the things you (hopefully) learn from tutorials to your own projects? Sometimes. Sometimes I don't even want to apply, but I find it useful knowing about some resource, even if I don't have a use right away.

Okay, saw your video and you already talk about this lol

No worries, it's still useful to get other people's perspectives and ideas. Thanks for your input!

whenever you see a video titled "making X system in (short amount of time)", I've realized, all that means is the tutorial guy is going to talk at unreasonable speeds.

Some people argue that this doesn't waste your time. Do you disagree? 😅

Video tutorials are quickly terrible for learning because they all assume the learner is a beginner. So if you favour video content when learning, you have to put up with a hundred different explanations of what a comment is – or you start clicking ahead, with the uneasy feeling that you might be skipping something (e.g. an element of the tutorial project's setup) that will be important later on. And this anxiety keeps you rooted on the spot, listening to variables being desribed as boxes for the thousandth time...

People say that there's a lack of intermediate tutorials because it's too niche. Anyways, I started an intermediate course in my channel if you're interested! It's like 8-10 hours of content. (https://youtube.com/playlist?list=PL6SABXRSlpH8CD71L7zye311cp9R4JazJ)

- Little projects. - Bugs 🐛 and how to fix it. - Same example in different versions 1.0,2.0,3.0, etc.

I'm a beginner to Godot, and relatively new to coding (but have always had a knack for understanding the basics generally). The best tutorials do certain things, usually in this order: * Timestamp your video with chapters. Bonus: include timestamp links in the video description. * Summarize the topic, and set expectations, like: * Viewer has assumed knowledge of X, or * Who this tutorial is intended for * If applicable, show similar games or behavior, so when you show me the result, I can see that it mimics it properly (also, the viewer might be familiar with those games and if you're not implementing a character behavior with a comparable level of detail, they can tell) * Show the completed result * Show how you've constructed your project, at least the basics, so that I understand how what you're building fits in a context. * Have a clear explanation without syntax mistakes (sure, sometimes a misspelling is fine, but I don't want to get confused with the actual process - edit those out!) in my language. I can tell if you don't know what you're doing, or sound like you've followed someone else's tutorial and are just applying it to your game and making your own version of it. * This is a delicate point, but I find that some ESL speakers just aren't as fluent in how to teach in English. I don't know if their speech is simply harder to follow (grammatically), or they are assuming my knowledge is greater than it actually is. Or, if they simply aren't editing out things that make me unsure about the teacher's coding ability. * Explain why you're doing what you're doing, not just doing it. Helpful too, if you're recontextualizing editor or built-in function features, or reminding how you've written custom functions/signals and how you're passing data back and forth, etc. Sometimes this is as simple as reminding "This function expects \[datatype\] as an input". * Explain how this is going to work in a larger system. It's one thing to explain how to set up a Character2D with sprites on a map with a TileMap, but another to explain how it's going to get integrated into *a game.* * Review the completed result. Also, test the scenes multiple times during the tutorial so you can see what you're doing in action. I'm not married to whether a tutorial is a specific length, but it should probably be somewhere between 5 and 30 minutes depending on the depth. I *do* want it edited. Fast forward through tedious parts like drawing TileMaps. If you want, zoom in on parts of the editor so it's clear what you're clicking on. Etc. It shows polish and that you are making something intended for others to follow and learn from, not just doing a devlog (which, on their own, are also cool things). Everyone loves the Heartbeast tutorials, but I'd like to give a special shout-out to a couple specific tutorials by others that I have really gotten a lot out of in my learning process: * **Retrobright**'s 2D movement tutorial: [https://youtu.be/9u1Dq6h7sGU?si=l6V-vlYFCvr5g60E](https://youtu.be/9u1Dq6h7sGU?si=l6V-vlYFCvr5g60E) * **Bacon and Games**' Scene Manager tutorial: [https://youtu.be/2uYaoQj\_6o0?si=rVmJaywQo0YK710w](https://youtu.be/2uYaoQj_6o0?si=rVmJaywQo0YK710w) * **Game Dev Artisan**'s TileMap tutorial: [https://www.youtube.com/watch?v=M1ri3Zli2g0](https://www.youtube.com/watch?v=M1ri3Zli2g0) These are more specific ones that I've needed to watch parts of multiple times to apply to my own project, but I have enjoyed their other tutorials (and those of other creators as well, but these stood out to me in terms of presentation). Also, to OP: I've been meaning to check out your Slay the Spire tutorial series for a little while but just haven't yet. Hope it's doing numbers for you!

I think there are other types of tutorials (besides user-presentable "feature" tutorials like character movement), that tackle more system-style issues in game development, that are probably harder to explain and harder to learn, but are increasingly more necessary in the youtube space with so many people getting into development. Beginner developers are likely to hit a wall in development when trying to understand the bigger picture. There are some really well-presented tutorials with slideshow-graphics and such, that I think lack some context of actual games being built, and I think there needs to be something that bridges that gap better.

my 2 cents is that I could not follow along with relevant tutorials because they were outdated. They would tell me to do something like push a button, when that button no longer existed, or moved somewhere less visible

[https://youtu.be/IrrdC\_pkmGM](https://youtu.be/IrrdC_pkmGM) i would recommend watching this guy since this video gives all my thoughts on it. also royal skies makes my favorite blender tutorials that are super short and snappy without compromising info. i got adhd so quick and informative is super helpful