HOW TO START GAME DEVELOPMENT (THE FIRST 30 DAYS)

Three years ago I watched someone on Reddit post their first game. It was a top-down shooter where you played as a triangle fighting circles. The art was programmer art. The sound effects were clearly made with their mouth and run through Audacity. It had one level. It was on itch.io and had maybe four downloads. But it was finished. It was a real game that a real person could play, and the dev had gone from knowing nothing to shipping it in about a month. That stuck with me more than any GDC talk or YouTube tutorial series ever has.

Most people who want to make games never make a game. Not because they lack talent or intelligence, but because they spend months researching engines, watching tutorials, planning their dream RPG in a Google Doc, and never actually building anything. The gap between "I want to make games" and "I made a game" is not skill. It's willingness to make something small and bad and finish it anyway.

So here's a 30-day plan. It's opinionated. It's based on what I've seen work for beginners and what I've done myself. If you follow it, you'll have a published game in a month. It won't be good. That's fine. The first one isn't supposed to be good.

Pick an engine (day 1)

You need a game engine. You don't need to spend a week picking one. Here's the decision tree: if you want to make 2D games or smaller 3D games, use Godot. If you think you might want to work in the game industry someday, use Unity. That's it. That's the whole decision.

Don't use Unreal Engine. It's a fantastic engine for experienced developers making high-fidelity 3D games. It's a terrible first engine. The editor is overwhelming, the project templates assume knowledge you don't have yet, and C++ will eat you alive if you're just learning to program. Unreal is the deep end of the pool. You want the shallow end right now.

Godot is free, open source, lightweight, and its scripting language (GDScript) was designed to be easy to pick up. Unity has a bigger ecosystem, more tutorials, and uses C# which is a broadly useful language. Both are solid picks. Neither is wrong. Just pick one and download it today. Not tomorrow. Today.

You also need a text editor for when you want to write code outside the engine's built-in editor. VS Code is free and works great with both Godot and Unity. Download that too.

That's your entire tool setup. An engine and a text editor. You don't need Blender, Photoshop, FL Studio, or a second monitor. You need an engine and a text editor and the willingness to open them.

Week 1: one tutorial, one clone

Install your engine. Open it. Spend an hour clicking around and getting familiar with the interface. Don't try to make anything yet. Just look at how projects are structured, where the buttons are, what happens when you hit play on an empty project.

Then pick one beginner tutorial and do it start to finish. For Godot, the official "Your First 2D Game" tutorial on the Godot docs is good. For Unity, the "Ruby's Adventure" or "John Lemon's Haunted Jaunt" tutorials on Unity Learn are solid starting points. Do the whole thing. Don't skip steps because you think you understand. Type the code instead of copying and pasting it. Typing forces your brain to actually process what each line does.

One tutorial. Not five. Not a 40-hour Udemy course. One.

After the tutorial, make Pong. I'm serious. Pong. Two paddles, a ball, a score counter. Pong has been the first game project for developers since the 1970s and there's a reason for that. It's simple enough that you can finish it in a few days, but it touches almost every fundamental concept: input handling, collision detection, game state, score tracking, win conditions, and rendering objects on screen. You'll get stuck. You'll Google things. That's the process. Getting stuck and figuring it out is how you learn. The tutorial gave you a foundation. Pong forces you to use that foundation to solve problems on your own.

Here's the important part: finish it. It doesn't need to be pretty. It doesn't need menus. It doesn't need AI for the second paddle (just make it two-player or have the paddle follow the ball). But it needs to be playable. When two paddles can hit a ball back and forth and a score goes up, you're done.

Week 2: make something original

This is where most beginners stall. Week 1 felt guided and safe. Week 2 is the open ocean. You're making something that isn't a tutorial project and isn't a clone. It's your game. Your idea.

Keep it absurdly small. I mean that. The game should be something you can describe in one sentence. "You're a cat dodging falling furniture." "You click on mushrooms before they disappear." "You're a square trying to reach the right side of the screen while spikes move toward you." One mechanic. One screen. No menus, no levels, no progression systems. Something you can build in five to seven days.

The temptation here is to start designing your dream game. The metroidvania with 15 bosses and a crafting system and a branching narrative. Resist this with everything you have. Your dream game requires skills you don't have yet. You'll spend two weeks on the inventory system, realize you don't know how to save and load data, get frustrated, and quit. I've watched this happen to dozens of people. The dream game isn't going anywhere. It'll still be in your head in six months when you actually have the skills to attempt it.

Make something tiny. Make something you can finish.

I think people underestimate how hard "tiny" is when you're starting out. A game with one mechanic still needs that mechanic to feel responsive. It still needs to handle edge cases. What happens when the player goes off screen? What happens when two things collide at the same time? What happens when the game ends? These are all problems you need to solve, and solving them is where the real learning happens.

Tutorial hell is real

I need to talk about this because it kills more aspiring game developers than any technical challenge. Tutorial hell is when you watch tutorial after tutorial, following along step by step, and feel like you're learning, but you can't build anything without a tutorial in front of you. You become really good at following instructions and really bad at making decisions.

Tutorials are useful for learning a specific technique. How to set up a tilemap. How to implement a state machine. How to make a character controller. They're terrible for learning how to make a game. Making a game is making hundreds of small decisions about what to build, how it should work, and what to do when something breaks. No tutorial teaches that. Only building your own projects teaches that.

My rule: for every hour of tutorial you watch, spend three hours building something of your own. If you catch yourself opening YouTube when you're stuck on a problem, close it. Sit with the problem. Read the documentation. Try something. Try something else. The struggle is the learning. The tutorial is just the warmup.

Week 3: add juice

Your game works. It's playable. It's also probably boring to look at and boring to play, even if the mechanic is decent. That's because it has no juice.

"Juice" is the game design term for all the little things that make a game feel good. Screen shake when something explodes. Particles when you collect a coin. A sound effect when you jump. A slight pause on impact. The way things ease in and out instead of appearing and disappearing instantly. None of these things change how your game plays, but they transform how it feels.

Spend week 3 adding juice to your game from week 2. Start with sound effects. You can find free ones on freesound.org or generate them with a tool called sfxr (it's free and designed specifically for making retro game sounds). Add a sound for every player action and every significant event. Jump sound. Landing sound. Pickup sound. Death sound. Background music if you can find a Creative Commons track that fits, but sound effects come first.

Then add particles. Every engine has a particle system. When the player dies, spawn some particles. When they collect something, spawn some particles. When they land after a jump, a little puff of dust. Particles are cheap to implement and they make your game look 10 times more polished.

Screen shake is the big one. A tiny amount of camera shake on impacts makes everything feel powerful. There are tutorials for implementing screen shake in every engine (this is one of those cases where a tutorial for a specific technique is appropriate). Add it.

You'll be amazed at how different your game feels after a week of juice. The core game is exactly the same, but it went from feeling like a prototype to feeling like a game. This is why juice matters. It's the difference between a functional thing and a thing people actually want to play.

Use assets and don't feel bad about it

You're going to need art and sound for your game. You have two options: make it yourself or use pre-made assets. If you're a programmer with no art background, use assets. Free ones are everywhere. Kenney.nl has hundreds of free asset packs that are good quality and consistent in style. OpenGameArt.org has thousands more. The Unity Asset Store and Godot's asset library have free packs too.

Some beginners feel like using premade assets is cheating. It's not. AAA studios buy middleware and asset packs constantly. Using a free sprite pack for your first game is no different from using a free font in a document. You're learning game development, not art. You can learn art later if you want to, but right now you're trying to finish a game, and spending three weeks on pixel art for a project that teaches you programming is a bad trade.

The one exception: if you enjoy making art and it doesn't slow you down much, go for it. Simple geometric shapes, basic pixel art, hand-drawn stick figures. Whatever you can produce quickly. The goal is a finished game, not a portfolio piece.

Week 4: ship it

Your game has a mechanic. It has juice. It has sound. It's playable from start to finish. Now publish it.

itch.io is the easiest place to publish a game. Make an account, upload your build, write a short description, add a screenshot, and hit publish. The whole process takes about 30 minutes. Your game is now on the internet where anyone can play it. That's real. You made that.

If your game runs in a browser (Godot can export to HTML5, Unity can export to WebGL), even better. Browser games get more plays because there's no download barrier. People are more willing to click a link than install an executable from a stranger.

Share it. Post it on Reddit in r/itchio or r/indiegaming or r/gamedev's Screenshot Saturday thread. Post it on Twitter or Bluesky with a short GIF of gameplay. Send the link to friends. Some people will play it. Most won't say anything. A few might leave feedback. That feedback, from strangers who have no reason to be polite, is gold.

You will feel vulnerable. Putting something you made in front of strangers is scary. Do it anyway. The first time is the hardest. By the third or fourth game, it's routine.

The real skill is finishing

Here's the thing nobody wants to hear: talent doesn't matter much at this stage. Technical skill doesn't matter much either. You can learn both. What separates people who become game developers from people who just talk about becoming game developers is finishing things.

Most people quit. Not because they can't figure out a coding problem or because their art isn't good enough. They quit because the middle of a project is boring. The exciting part is the beginning, when everything is new and possibilities feel infinite. The exciting part is also the end, when you can see the finish line. The middle is a slog. You're fixing bugs in systems you built two weeks ago. You're playtesting the same 30 seconds of gameplay for the hundredth time. You're adding content that feels repetitive to create even though it won't feel repetitive to play.

Finishing a tiny game in 30 days teaches you what finishing feels like. It teaches you that the boring middle part is temporary. It teaches you that a mediocre finished game is worth infinitely more than a brilliant unfinished one, both as a learning experience and as proof that you can do this.

After your first game, make another one. Then another. Each one will be better. Each one will be easier. You'll start to internalize patterns and solutions. You'll build faster because you've solved these problems before. By your fifth or sixth small game, you'll have the skills and the confidence to attempt something bigger.

But that fifth game starts with the first one. And the first one starts with opening an engine and making Pong.