How to practice game development effectively

A lot of aspiring developers spend months following tutorials and still feel like they are not capable of coding on their own. The problem is usually not effort: it is the expectations and the kind of practice that are at fault.

The sections below explain why this works and how to get the most out of it.

Why unfocused practice fails

You can spend long hours watching tutorials and courses, but on its own that does not make you a better programmer. Without real practice, your progress is slow. If you ask "how do I get better?", most people will tell you to just code more.

"Just build things and don't overthink it."

That advice is too vague to be really useful. If you stay in your comfort zone and build the same kinds of things you already know how to build, if you keep working on the same kinds of problems, you will not move forward much.

The fastest progress happens when you are working on something just outside what you can already do. When code feels unfamiliar and you have to think hard to solve the problem, that is when you train core skills the most.

There is also the opposite trap: picking something way too hard and getting stuck with no way forward. As a beginner, it is easy to underestimate how much work a project takes. When you do not know better, a 3D MMORPG seems like no big deal. Focused practice is the way out of both traps.

The practice method

Pick one area of game programming where you need the most improvement. It should be a real weakness, and ideally something relevant to the kind of games you want to make, to motivate you. Then decide on one specific mechanic or module to implement:

• A platformer character that can climb walls
• A homemade collision system based on the SAT algorithm
• An inventory UI with drag-and-drop and stackable items
• A pathfinding algorithm using A on a grid-based map

Every day, code that from scratch for at least 30 minutes. The point is not to copy what you did the previous day: you want to solve the problem fresh, find things you missed, and do it a little better each time. Keep doing this for 3 to 7 days until it stops being a challenge, then move on to your next weakness.

The repetition is part of what makes this work. You want to do targeted and intentional work on one specific thing until it stops being as hard.

Delete your code after each session

In this exercise routine, I recommend deleting your practice code at the end of every session. This removes the temptation to build on yesterday's work, and makes sure you are solving the problem again each day.

If you are new to coding though, I would suggest keeping your project for one day before deleting it. After your session ends, read through the previous day's code and compare it to what you just wrote. Then delete the old files.

This helps in two ways:

1. You practice reading code, which is a core skill. The ability to read code and make sense of it without needing comments or explanations will save you a lot of time, so it's well worth training early.
2. You can see exactly how you improved from one day to the next, which makes the progress concrete.

Read the old code after your session, not before. If you read it first, it will influence how you approach the problem that day, and you're more likely to end up repeating yourself.

Making the most of your practice sessions

Prepare a template project ahead of time with the assets and scenes you need so you can get straight to coding each day. If you are practicing character movement and wall mechanics, set up a small level with walls, collisions, and an empty character scene and script in advance. Anything not directly related to the thing you are practicing, you can prepare beforehand.

Every day, copy that template project, open it in Godot, start your timer, and code.

Your questions

If I do not finish the system I planned in 30 minutes, do I start from scratch the next day?

Yes! This idea of deliberate practice shows up in many fields. To get good at drawing hands, you draw a dozen hands every day until it clicks. You are focusing on one specific weakness until you get past it.

That is exactly where the practice happens: you are working on something specific that you can tackle in one sitting. If you find yourself never finishing in 30 minutes, the thing you picked is perhaps too large. Consider breaking it down further or extending your practice session.

If I solved the problem yesterday, do I not already have the solution for the next day?

The idea is not to repeat what you did from memory, but to keep finding ways to improve. Between sessions, take a minute to think about what worked and what did not, and write down ideas to try or things to look up.

In games, so much of your code affects how the game feels, so once you have found a solid solution you can shift focus to improving the controls or the overall design. There are almost always multiple valid solutions to a problem too, so you can try to find different ones.

What if I have no idea how to make the thing I want to practice? Should I start with a tutorial?

If you are completely new to a domain, like networking, then yes, read a guide or textbook to get started first. You cannot practice online multiplayer techniques if you have no idea what a server is or how computers communicate over a network.

But for the practice itself, try to work alone and figure things out by yourself. Working through that struggle is how you build the skill of solving problems on your own, which is one of the most important differences between a strong developer and a weak one.

If you are stuck after a full session with no progress at all, however, then you should look for learning resources and return to practicing later.

When I need to learn something new, I generally start with a textbook and a small structured project, read about the underlying concepts, look at how other games or programs handle the problem, and work from there.

updates / code patches

• This guide was rewritten to be more nuanced and to update our practice recommendations.
• Suggest an update.
• No errors reported. Report an error.