Making games is hard!

It’s really hard!

…just kidding. I’m not going to start this post the same way as the last one.

Not kidding about the whole “making games is hard” part,

That’s true.

You can trust me, I’ve been doing it for about four years.

Although due to my horrible consistency when it comes to doing it, claiming I’ve been doing it for “Four years” is quite misleading.

If you asked to see all the games I’ve made, you’d be left with a handful of high school projects and a few half-baked prototypes. Certainly not the kind of collection you’d expect for someone who’s been doing it as long as I claim.

But let me take you on a passingly related tangent of my history with code, game development, and how I got where I am today.

Reading Music:

My origin story.

I got started with coding with khan academy java-script tutorials in the 8th grade.

I was making shapes with lines and filling them. using a drawing library for java-script. (processing js if you’re curious.)

I was hooked.

I vividly remember showing off a line drawing program in my grade 8 class, you could change the colour and size of the dot, and it would be placed wherever your mouse was.

The entire class was disinterested.

But with the perspective of the event 5 years later, I can also agree that from their side it looked really lame.

Like MS Paint,

but it only had one function and it sucked.

But from that day I knew I wanted to make things with code.

Jump to grade 10, I took computer science as an elective, and instead of using scratch, python, or some other beginner language we used gamemaker 8

not gamemaker studio 2,

gamemaker 8

an 8-year-old engine in 2019.

…and I was hooked.

Sprites, Objects, Rooms, Scripts, they all spoke to me.

It felt super intuitive, I quickly went from the drag n drop interface we were taught to the text-based scripting language that was also available.

The possibilities felt limitless!

My team and I represented our school in a game development competition at Sheridan college for the years of grades 10-12.

After the course was over, I wanted to keep making games.

But gamemaker 8 was antiquated, I wanted something that people were using.

Gamemaker studio costs money, so that was a no. I looked around for the best free tools that were available. Unity was a clear choice, but everyone was discussing how beginner-friendly this new engine named Godot was for beginners.

So I downloaded it, looked up some tutorials, got started…

and was hooked!

…is what I wished happened.

It made no sense, everything was confusing, where are my objects, my maps, my sprites?

I had no idea how I’d go about making anything using this “Node Tree” structure.

but I dedicated myself to learning this foreign technology, everyone on the internet speaks on how intuitive and powerful it is, so I’ll do it!

I’ll get good with Godot!

As of the writing of this article, I am still not good with Godot.

But I know why I haven’t gotten good.

How did I spend 3 years trying to learn the Godot engine and not make any substantial progress to speak of?

Well, I’ve realized exactly how that happened (or at least have a few solid ideas as to why). I’ve thought about it and I’ve compiled tips and advice I wish I had started out that would’ve saved me lots of time and frustration in my lack of progress.

The Advice. How to avoid using Godot (or any game engine) for 3 years and not learn anything.

Forewarning:

“Some advice can be a vice”

All advice is autobiographical. I wrote these tips from my perspective and for the issues, I was running into. However, I think these tips can be beneficial to anyone, hence why I’m sharing them.

Please consider what I have to say,

take what works,

leave what doesn’t.

Also, most of this advice isn’t really specific to Godot, and only vaguely specific to learning game development. These tips can be adapted and used to help learn a lot of different things, so there’s still value in these even if you’re using a different engine or learning something unrelated.

with that out of the way, we can finally get to the actual content!

1. You’re doing Tutorials.

“Yeah of course I am, I have no idea what I’m doing!”

I’m not telling you to not do tutorials (sure sounds like I am) and like, read the documentation to get started (although for Godot specifically, the documentation is really good and you should use it.)

What I mean is that you’re doing nothing but tutorials.

Tutorials are nice. They teach you common design patterns and how things are done in the engine.

They’re nice, safe, and you have something to show at the end.

But the problem is, you aren’t actually learning

It’s like being inspired by the 2020 FOX TV show LEGO Masters. You decide that you want to become a proficient Lego builder, but you spend all your practice time building pre-made LEGO sets.

You’d have a lot of nice LEGO to show, but put yourself in front of a bin of LEGOs without instructions and you’re unable to make anything.

This is actually a state of learning known as Tutorial Hell. When you’re too reliant on tutorials and explicit instructions to be able to make anything on your own.

Tutorials take away a fundamental part of not only game development, but programming in general: It doesn’t let you practice solving problems on your own.

Making games is just problem-solving. There are (generally) two types of problems to solve in game development: Design Problems and Technical Problems.

Design problems come from designing the game’s features and mechanics. Most people don’t have entire games in their heads when they start working on a project, they have a few ideas or concepts to start off of. This leads to certain parts of your game not working as intended, or not knowing how to fit your game into a cohesive and fun gameplay loop. It’s your job as the game designer to solve these design problems and try to make everything fit.

Technical problems are with the actual code and implementation of your ideas. These are solved through an understanding of the tools available to you from the engine and knowing which ones you can use to solve the problem you’re encountering.

Following Tutorials let you practice neither of these skills.

Design problems are already all solved for you, and you’re getting the answers for any technical implementation problems you’d have.

So throw away tutorials and start making your own stuff right!?

…not necessarily.

Despite how I made it sound, tutorials can actually be useful, as long as you’re using them “properly”.

Well how do you use them “properly”?

Expand off them!

After you finish following a tutorial, use what you learned to make something on top of the finished project.

This helps you practice both types of problem-solving in an environment that is a lot less intimidating than a blank project.

Make a second type of enemy/projectile/collectible/mechanic based on the knowledge you gained from making the first, you can even start to use what you learned from a different tutorial (you can refer to the code you wrote) to add a new feature to another tutorial.

Once you get comfortable enough, start trying to re-create tutorials without following them.

This will help your technical skills improve tremendously, and if you get stuck you can always refer to the solutions within the tutorial.

You just want to make sure you’re able to do things on your own.

Because nobody is going to make a tutorial for the game you want to make.

2. Consistency is far more important than length

Practicing 30 minutes a day for 6 days a week is much better than practicing for 3 hours a day once a week.

To paraphrase A Mind for Numbers, a book everyone who’s trying to learn/improve at anything should read:

As we learn things, neural connections are made. those connections start off weak, but are strengthened by recalling the information used to make them, sort of like going to the gym to train your muscles. And just like your muscles, you’ll need to spend time letting them rest and build in strength, becoming easier to recall.

There were a lot of times I’d quit using the engine for extended periods and come back feeling like I knew nothing, reverted back to a beginner.

In those cases, I essentially had been. All the connections my brain had made faded away due to lack of use, and any progress I had made was gone.

Two of the things that would frequently cause me to stop using the engine were:

I got stumped/ran into an error I couldn’t solve.

Getting stumped is normal, if you’re doing things right, you’ll be stumped many times over. Learning how to make your own solutions to things is going to leave you with a bunch of problems you aren’t going to immediately know the answer to. Understand that it happens to everyone, you aren’t uniquely un-gifted or something.

First, read the error. consider what it’s saying. Godot gives you a readout on all relevant variables, uses print statements, breakpoints, the documentation, try to figure out what’s going on.

You can also look-up the error. Other people are likely not running into the exact same situation as you, but it can give you some much-needed insight into what’s going wrong in your case.

you can also reach out for help. Notice how I put this option last? It’s because when you’re coding you should always try to solve things on your own before seeking help from others. Not only because you don’t want to be reliant on others to get your stuff done, but because getting things wrong and then finding the correct answer yourself makes it much more impactful to you, and easier to commit to your toolbox for future problems solving.

I have No Ideas

Not having ideas for projects is completely normal. Thinking up ideas is a skill just like making video games is. and just like any other skill, you need to practice it to improve.

So practice coming up with game ideas! this can just be a scratch file you keep that has concepts and ideas. You don’t need to have the entire gameplay loop figured out, just practice making a starting point for you to begin prototyping.

3. You Aren’t Doing Game Jams

Game jams are probably the most efficient way to get good at game development.

They’re great because they let you practice so many essential skills like:

• Thinking of an idea based on a theme
• Deciding a scope for the project to fit the span of the game jam
• Making you practice and discover ways of solving technical issues that arise. It might now always be the best or cleanest solution, but it was what you came up with
• It lets you rapidly iterate, so you know if that Idea you had in your head really works or if it falls apart in execution.

They happen all the time, some of the big ones are the GMTK game jam once a year and Ludum Dare which happens bi-annually.

You can look on Itch.io, you’ll find one coming up.

4. Join a community

One reason as to why I was so inconsistent with game development after my grade 10 class that I hadn’t considered up until recently was the lack of community I had.

Back in high school, I had a mandated time and place to sit with a community of students in a room and all do the same thing: make games.

This helped me stay consistent and improve quickly.

But on my own, I have nobody to hold me accountable or guide me in what I should do. in and that lead to me taking breaks and being inconsistent.

So I made myself a new community.

I started the game development club at my University! It’s doing great, two months in and I already have 100+ people on the discord server

join my server

Conclusion

You’ve reached the end of the post!

I still don’t know how to end these things.

You now have a wealth of information that I wish I had when I started.

You’re welcome

Hopefully, it helps you as much as it’s helped me.

Extra Resources

Please please please read A Mind For Numbers by Professor Barbara Oakley. It isn’t actually about math and science, it’s just about understanding how our brains learn and improve at things, and optimal strategies for learning. I’ll probably make a whole blog post about it so I won’t go into too much detail right now but read it.

If you’re struggling to be creative and think of Ideas, please read Steal like an Artist by Austin Kleon. It teaches you that ideas aren’t created from thin air, they’re adapted, modified, and fused together forms of existing ideas. You learn how to “steal” your inspirations from existing art to make your art new and original. The book is tiny and can be read in like 40 minutes, very worth it. The entire trilogy is some of my favorite books, but like AMFN, I’ll probably talk about them in a future post.

As for actual resources on learning Godot, some of my favorite Youtube channels are GDQuest, NADLABS, Miziziziz, Goodgis, and Heartbeast.