game dev

HOW TO BECOME A COMPUTER GAME DEVELOPER

The computer sitting on your desk right now has more raw power than every machine that shipped games for the first twenty years of the industry combined. The only thing standing between you and being a computer game developer is the willingness to start, the patience to fail, and some idea of what to actually install. I can help with the last part. The first two are on you.

I want to be specific here because the internet keeps smashing "game developer" into one word when there are actually a bunch of different flavors. Console developers deal with dev kits and cert processes and platform holders. Mobile developers fight with device fragmentation and ad SDKs. Web game developers chase browser compatibility and canvas performance. Computer game developers, which is what we're talking about today, build games for Windows, Mac, and Linux. That's a specific world, and it's honestly the friendliest one for beginners.

Why PC is the best starting point

There's no gatekeeper. That's the real answer. If you want to make an Xbox game, you need to get into Microsoft's ID program or work at a licensed studio. If you want to make an iPhone game, you need a developer account and you need to jump through Apple's review hoops. If you want to make a PC game, you open your computer, install an engine, and make a PC game. When you're done, you can upload it to itch.io in about four clicks. You own the entire pipeline from day one.

The tooling is also free. Every major engine has a free tier that covers you until you're making actual money, and most of them don't start charging until you've crossed a revenue threshold that ninety percent of hobbyists will never hit. The barrier is not cost. The barrier is attention.

PC also has the most mature set of learning resources. Twenty years of people making PC games means there are twenty years of tutorials, open source projects, forum threads, and Stack Overflow answers. Whatever weird problem you hit at two in the morning, someone else hit it in 2017 and wrote a post about it. That compounds in ways that the newer platforms can't match.

The programming foundation

You can't skip this. I've seen people try. The ones who try to become game developers without learning to program end up as designers or artists with side skills, which is a real career but it's not what we're talking about here. If you want to make computer games as the person who builds them, you have to learn to code.

The good news is that you don't need a computer science degree. You need maybe six months of consistent practice to become dangerous. Variables, loops, conditionals, functions, classes, and basic data structures like arrays and dictionaries. That's the vocabulary. Once you have that, you can read and write the kind of scripts that actually ship in games.

Which language? It depends on the engine you pick, which I'll get to in a second. But the honest truth is that the first language you learn is the hardest. The second language takes a quarter of the time. The third feels like a translation exercise. Don't agonize over the choice. Pick one, stick with it for a year, and you'll be bilingual soon enough.

If you want a generic starting point before committing to an engine, C# is probably the best bet. It's what Unity uses, it's what a big chunk of Godot users are picking now, and it's a clean modern language that teaches you good habits. Python is friendlier for absolute beginners, but nothing major runs on it in the game world, so you'd be learning it just to throw it away.

Picking your engine

This is where people get stuck for way too long. They watch engine comparison videos for a month and never actually install anything. I'm going to cut through it. There are three engines worth seriously considering in 2026 if you're a beginner on PC.

Unity is the one I always start beginners on. The tutorial library is absurdly deep. The asset store has a workable free model or low-cost solution for every problem you're going to hit in your first two years. C# is a great first language. The editor feels like a real professional tool, and the workflow of dragging prefabs around and tweaking values in the inspector gives you fast feedback in a way that code-only engines don't. The downside is that Unity has had some corporate drama and pricing scares in recent years, and some of the community has migrated elsewhere. But for actually learning how to build a PC game, it's still the path of least resistance.

Unreal Engine is what I'd pick if I wanted to build something that looks photoreal out of the box. Unreal is overkill for a beginner's first project, but it's not a bad choice if you know you want to end up at a AAA studio eventually, because more of them run Unreal than Unity at this point. Blueprints, the visual scripting system, let you build a surprising amount without writing C++. Eventually you'll want to learn C++ to squeeze performance out of anything real, and C++ is a harder language to start with than C#. Unreal projects also install enormous. You'll want a fast SSD with a hundred gigs free before you even open the editor.

Godot has become my recommendation for anyone who doesn't want to touch corporate tooling. It's completely free and open source, which means no licensing, no revenue share, no company that could change the deal on you next year. GDScript is ridiculously easy to learn, because it was designed for games from scratch rather than bolted onto a general purpose language. The 2D tooling is genuinely the best in the business, and the 3D side has caught up hard in the last two years. The community is small compared to Unity, so you'll occasionally hit problems where the answer isn't on the internet yet, but the engine itself is a joy to use once you're past the first week.

Pick one. Install it tonight. Don't read another comparison article. The differences between these three are small compared to the difference between using any engine and using none.

Your first six months

I get asked what to build first all the time. The answer is always the same. Clone something that already exists. Don't invent. Don't innovate. Don't try to make your dream project. Pick a game you played as a kid that was simple enough to explain in one sentence and rebuild it.

Pong. Breakout. Asteroids. Snake. Space Invaders. A vertical shooter. A match-three. These are the training games for a reason. They have a limited scope, a clear win condition, and the mechanics have been solved. You're not fighting the design problem, you're just fighting the implementation problem, which is exactly what you need to be fighting at this stage.

Make one of those, finish it, put it on itch.io. Then do another one. Then a third. By the time you're three projects deep, you will have hit every basic problem a game developer hits. Input handling. Collision detection. Score tracking. Menu states. Audio. Simple AI. Save and load. You'll know how your engine handles all of this, and you'll have a portfolio page that actually exists.

This is where I diverge from a lot of advice online. People say to start with a game jam. Game jams are great, but they're easier when you already know your tools. If you do a jam before you've shipped one small complete project, you're going to spend forty of the forty-eight hours fighting the engine instead of making the game. Ship one thing first. Then jam.

If you want to read more about the broader no-degree route, I wrote about it over at how to become a game developer and that covers some of the general skills side of things. What I'm saying here is specifically about the PC-focused implementation path.

Building a portfolio that Steam takes seriously

The portfolio conversation for computer game developers is different from the one for console or mobile devs because PC developers have two distinct storefronts that actually matter and are visible to the whole industry.

Itch.io is where you ship your first ten projects. It's free. The upload flow is basically dragging a zip file into a form. It takes about ten minutes from having a built game to having a public page. Tags let people find you. The community genuinely plays random free games in a way that no other platform does. If you're doing game jams, your jam games live here. If you're doing prototype experiments, they live here. Treat itch like your sketchbook.

Steam is the grown-up version. It costs a hundred dollars to put a product in Steam's system, which is their filter against total spam. Once you're in, you have access to the largest PC gaming audience on earth. But you don't put your first anything on Steam. You put your first serious commercial project on Steam, after you've shipped enough itch projects that you know what you're doing. Steam reviews are visible to future employers and future customers for the life of your game. A rough first project on Steam can follow you for years. On itch, nobody cares. Use itch as your learning ground and Steam as your proving ground.

The other thing about Steam specifically is that the metadata matters. Capsule art, tags, trailer, screenshots, and Steam page copy make or break your visibility in search. That's a skill on top of the development skill, and it's worth spending real time on when the time comes. Wishlist counts before launch drive the algorithm more than anything else, so you need to announce early and build an audience before the store page even goes public.

Community and networking

Computer game development has a strong online culture that matters more than most people realize. You don't need to live in San Francisco or London. You do need to be plugged into the right places online.

Discord is where the real community lives. Every major engine has a few active servers. The Unity Discord, the Godot Discord, the Unreal Slackers community. These are open. You join, you lurk for a week, you start helping beginners with the dumb questions you used to ask, and after six months of that you know people. Real people who remember your name. That's how networking works in this space. It's not LinkedIn. It's being visible and helpful in communities that matter.

Twitter, or whatever we're calling it this week, still has a gamedev community worth being in. Post screenshots on Screenshot Saturday. Tag your builds with the common hashtags. Reply to other devs' work with actual thoughts, not just emoji spam. People follow people who engage, and the gamedev community is small enough that the same thousand people are tracking each other's projects.

Go to local meetups if your city has any. Most cities with a university have an IGDA chapter or something equivalent. Online-only networking is fine, but one in-person meetup can do more for your career than three months of Discord activity, because the bar for showing up in person is still high enough that the people who do show up tend to be serious.

The thing nobody tells you

Being a computer game developer is mostly about finishing. Not about starting. Not about ideas. Not about skill ceilings. About finishing. The industry is full of people who have eighteen prototypes and zero shipped games. Don't be one of them. Ship small things often. Get the dopamine hit of calling something done. Learn what the last ten percent of a project actually feels like, because it's nothing like the first ninety percent and you have to build the muscle for it.

Once you've shipped three or four small games on itch, you'll stop thinking of yourself as someone trying to become a computer game developer. You'll just be one. The transition is quieter than you'd expect.

← Back to the Sketchbook