So You Want to Make Games in 2026?

Here’s the thing about becoming a game developer in 2026: the path is simultaneously clearer than ever and more intimidating than a Cuphead boss on your first try. You’ve got engines like Unity and Unreal doing half the work for you, but the baseline of “what you need to know” has exploded like a poorly optimized particle system.

So let’s talk about what it actually takes. Not the LinkedIn version. The real version.

The Map Is Not the Territory (But You Still Need the Map)

I looked up a game developer roadmap the other day. You know, one of those technical skill maps that’s supposed to guide you from “I want to make games” to “I am making games professionally.”

It was terrifying.

Boxes and arrows everywhere. Mathematics sections with terms like quaternions and Euler angles. Physics concepts including something called “EPA” which sounds like a government agency but is actually an algorithm. Graphics programming with acronyms stacked on acronyms. AI systems. Engine architecture. Collision detection methods named like they’re trying to win at Scrabble.

Looking at something like that, your brain does this thing where it goes: “Okay, so I need to master ALL of this before I can make anything.”

Wrong. So wrong. Dangerously wrong.

You don’t need to learn everything before you start making games.

The roadmap isn’t a prerequisite checklist. It’s more like a map of a massive city where you only need to visit a few neighborhoods to get what you need. You don’t master the whole city before you go to the grocery store.

Start With the Engine, Not the Math

Pick an engine first, make something terrible second, learn the theory third.

Notice the order.

Most tutorials and courses want to teach you from the ground up. They start with vectors and matrices, building your mathematical foundation like you’re about to construct a skyscraper. And sure, eventually you’ll need that foundation. But you know what gets people to quit before they’ve made a single game?

Spending six months learning linear algebra without once seeing a character move across a screen.

The Big Three (and One Dark Horse)

Your engine choices in 2026 basically come down to this:

Unity is like that reliable friend who always shows up but sometimes drinks too much at parties and makes questionable decisions (looking at you, Runtime Fee debacle of 2023). It’s C#, which means if you’ve done any programming before, you’ll feel at home. The asset store is massive. The community support is everywhere. But the company keeps making moves that make developers nervous.

Unreal Engine is the film student’s choice. Gorgeous out of the box. AAA-level graphics without selling your soul to a shader optimization demon. Blueprint visual scripting means you can prototype without code. But here’s the catch: when you need to drop into C++ (and you will), you’re entering a world of complexity that makes Dark Souls look like a tutorial level.

Godot is the scrappy open-source underdog that’s been having a moment. It’s free (actually free, not “free until you make money” free). It’s lightweight. GDScript is basically Python’s cooler younger sibling. But the ecosystem is smaller, the documentation has gaps, and you’ll spend time on forums asking questions that would take five seconds to Google in Unity.

And then there’s writing your own engine from scratch, which I mention only so I can tell you: don’t. Not yet. Not unless you want to spend two years building a renderer and never actually making a game. Every programmer thinks they want to do this. Every programmer who does this regrets it. (Except the ones who don’t regret it, but they’re lying.)

Pick Unity or Godot. Flip a coin if you have to. You can always switch later.

The Math Will Make Sense Eventually (I Promise)

Okay, let’s talk about the elephant in the room. The big scary one with “Linear Algebra” written on its side in threatening letters.

If you look at what game developers are supposed to know mathematically, it’s… a lot. Vectors and matrices. Transformations and projections. Curves and splines with names like Bezier, Catmull-Rom, and Hermite. Something called quaternions that prevents “gimbal lock” (which sounds like a disease you’d catch at a gym).

You need some of that. Eventually.

But not all at once. And not in a classroom.

Here’s how math actually works in game development: you’ll be trying to make something rotate smoothly, and it’ll snap weirdly at certain angles. You’ll Google it. Someone will say “gimbal lock” and “quaternions.” You’ll watch three YouTube videos, understand nothing, watch three more, understand slightly less than nothing, and then on video number seven, something will click.

And suddenly you get it. Not in an abstract “I can derive this formula” way. But in a “oh, THAT’S why my spaceship freaks out when it points straight up” way.

The math in games isn’t about passing a test. It’s about solving specific problems that are currently making your game look janky. That’s when you learn it. When you need it. When the pain of not knowing exceeds the pain of learning.

The Math You Actually Need (At First)

Start here:

Vectors: Just three numbers in a trench coat, pretending to represent direction and magnitude
Basic matrix operations: How to move and rotate things in 3D space
Dot products and cross products: The two tricks that solve 80% of spatial relationship problems

That’s it. Seriously. You can make an entire game with just that knowledge.

The rest—splines, projection matrices, quaternion slerping—you’ll pick up when you hit the specific wall that requires them. Trust me, you’ll know when you need to learn about Catmull-Rom splines. Your camera system will tell you by looking absolutely horrible.

Physics: Where Your Dreams Go to Collide

Game physics is a lie. A beautiful, necessary lie.

Real physics is complicated and expensive (computationally speaking). Game physics is a series of clever approximations that look “close enough” while running at 60 frames per second. It’s like comparing instant ramen to actual ramen. One is technically correct, the other is what you actually eat at 3 AM.

Game physics breaks down into two big problems: Dynamics (how things move) and Collision Detection (how things bump into each other without tunneling through the floor like a glitched speedrun).

Dynamics covers the basics: center of mass, acceleration, forces, friction, velocity (both linear and angular), restitution (bounciness). This is the stuff that makes your physics feel right or wrong. Too much friction and everything slides around like it’s on ice. Too little and it’s like playing on a skating rink.

But collision detection? That’s where things get interesting.

Collision Detection

Collision detection has two phases, and understanding why you need both will save you from performance nightmares later:

Broad Phase answers the question: “Which objects are even close to each other?”

Imagine you’re making a game with 10,000 objects. Checking every object against every other object means 100 million collision checks per frame. Your game now runs at 0.3 FPS. Congratulations, you’ve made a slideshow.

Broad phase uses spatial partitioning (fancy words for “don’t check if the bullet in Tokyo hit the player in New York”). Techniques like Bounding Volume Hierarchies or Sort & Sweep narrow down the “maybe colliding” list from thousands to dozens.

Narrow Phase answers: “Okay, these two objects are close. Are they actually touching?”

This is where you pull out algorithms with names like SAT (Separating Axis Theorem), GJK (Gilbert-Johnson-Keerthi), and EPA (Expanding Polytope Algorithm). These sound like government agencies, but they’re actually just different ways to answer one question: “Is object A inside object B?”

You don’t need to implement these from scratch, your engine handles it. But understanding what’s happening under the hood means you’ll know why your collision feels mushy, or why small objects are falling through floors, or why your physics simulation turns into a screaming nightmare when things move too fast.

(The answer to that last one is usually CCD—Continuous Collision Detection. You’re welcome.)

Graphics: Where Art Meets Math and They Have a Complicated Relationship

Let’s get real: graphics programming is where game dev goes from “I can do this” to “I’ve made a terrible mistake.”

Rasterization is how your game engine renders things. It’s fast. It’s what’s running on your GPU right now, turning triangles into pixels at 60+ frames per second. It works by projecting 3D geometry onto your 2D screen through a series of mathematical transformations.

There’s also Ray Tracing, which simulates actual light rays bouncing around and produces gorgeous, physically accurate results. You’ve seen it in AAA games with reflections that actually look real. But here’s the thing: you won’t touch ray tracing for years. It’s expensive, complex, and completely unnecessary for learning. Your engine handles basic rasterization out of the box. That’s what you’ll work with.

What you will care about is making rasterization look good through clever tricks—shadow mapping, normal mapping, lighting models. This is the bread and butter of game graphics.

The Graphics Pipeline

The pipeline is this multi-stage assembly line that turns your 3D models into the 2D image on your screen. The key stages:

Vertex Processing: Moves the vertices around in space (position, rotation, scale). This is where your object goes from “model space” through “world space” and “view space” to finally land in “clip space.” Each transformation is a matrix multiplication. Linear algebra, baby.
Rasterization: Turns your triangles into potential pixels (technically called fragments). This is where 3D becomes 2D.
Fragment Processing: Colors those pixels based on lighting, textures, and materials. This is where the magic happens—where flat-shaded polygons become surfaces that look like metal, wood, or skin.
Output: Final image goes to screen, you feel briefly like a wizard.

You’ll write custom logic for steps 1 and 3 using shader languages: HLSL (DirectX), GLSL (OpenGL), or Metal Shading Language (Apple’s special snowflake). They’re all similar enough that learning one means you can fake the others. Badly. But you can fake them.

And here’s a secret: most shaders are copied from somewhere else and slightly modified. This is not cheating. This is how it’s done. The shader programming community runs on copy-paste and prayer. Embrace it.

The Rendering Equation

At the heart of realistic rendering is something called the Rendering Equation. It’s this elegant mathematical expression that describes how light bounces around a scene. It accounts for:

Light sources (directional, point, spot lights)
Material properties (diffuse, specular reflection)
How surfaces respond to light hitting them from different angles
How light bounces multiple times before reaching your eye

The equation is beautiful. It’s also impossible to solve exactly in real-time.

So we approximate. We use techniques like shadow mapping for shadows. We fake reflections with cubemaps or screen-space reflections. We use normal mapping and parallax mapping to make flat surfaces look detailed without actually adding geometry.

Modern graphics programming is basically a collection of increasingly sophisticated lies that look close enough to reality that your brain accepts them.

Game AI: Making NPCs Slightly Less Stupid

Game AI isn’t about creating Skynet. It’s about making NPCs that can pathfind around a chair without having an existential crisis.

Game AI splits into two domains: Decision Making (what should I do?) and Movement (how do I do it without walking into walls?).

Decision Making: The Brain

State Machines are the simplest approach. “If player detected, then chase. If health low, then flee. If player not visible, then patrol.” Simple, predictable, and rigid as hell. Your enemies will feel robotic because they literally are robots following a flowchart.

Behavior Trees are more flexible and have become the industry standard. Instead of hardcoded states, you build a tree of conditions and actions. “Check if player visible. If yes, check if health above 50%. If yes, attack. If no, find cover and heal.” They’re modular, reusable, and make your AI feel less like it’s following a script.

Utility AI is for when you want NPCs that feel organic. Instead of “if-then” logic, each possible action has a score based on the current situation. “Attacking has utility of 0.8, fleeing has utility of 0.3, healing has utility of 0.9.” The AI picks the highest-scoring action. The result: enemies that adapt to circumstances in ways that feel almost… smart.

Then there’s Fuzzy Logic and Markov Systems for when you want to get really fancy.

Movement: The Body

Once your AI knows what to do, it needs to get there. Pathfinding is the science of navigating from point A to point B without walking through walls or falling off cliffs.

A* (A-star) is the king here. It’s been the industry standard for decades because it finds the shortest path efficiently. Your game probably uses some variant of A*, whether you know it or not.

But pathfinding alone makes NPCs look like they’re following GPS directions. They turn at 90-degree angles. They bunch up. They walk into each other like drunk robots at a convention.

Steering behaviors add the local layer—the ability to smoothly avoid obstacles, separate from crowds, and generally move like a living thing instead of a shopping cart with broken wheels.

The Special Case: Board Game AI

If you’re making a chess game, or a strategy game with turns and discrete moves, you’re in a different world entirely. Here you need:

Minimax: “I simulate my move, you simulate your best response, I simulate my best counter-response…” It’s game theory implemented as code.
Alpha-Beta Pruning: Minimax but faster, by cutting off branches of the decision tree that obviously won’t matter.
Monte Carlo Tree Search: For games too complex for perfect evaluation (like Go). Instead of calculating everything, run thousands of random simulations and see what works.

This stuff is fascinating if you’re into it. It’s also completely unnecessary for 95% of games.

The Skills You Didn’t See Coming

Here’s what the roadmap doesn’t tell you: the technical stuff is actually the easy part.

The hard parts are:

Finishing things. That burst of motivation that got you to start 47 different game projects? It runs out around 30% completion every single time. Learning to push through the “boring middle” where you’re fixing bugs instead of adding cool features—that’s the real skill.

Cutting features. You will have to kill your darlings. That amazing procedural terrain generation system you spent three weeks on? Doesn’t matter if it makes your game run at 15 FPS. Cut it. Hurt now, ship later.

Playtesting with real humans. Your game makes perfect sense to you. You built it. But watching someone else play it for the first time will reveal that your “intuitive” control scheme is actually “what if we made it as confusing as possible as a joke.”

Dealing with scope creep. Every feature you add multiplies the complexity by a factor of “oh no.” Start small. Finish small. Then make something slightly less small.

Your Actual 2026 Roadmap

Forget the overwhelming skill trees and branching paths for a second. Here’s what you should actually do, in order, as someone starting from zero:

Months 1-3: Make Pong

Seriously. Make Pong. Or a Flappy Bird clone. Or a simple platformer where you jump on boxes. Pick one mechanic. Implement it. Finish it. Put it on itch.io.

Learn:

Basic programming in your engine’s language
Game loop fundamentals
Input handling
Basic collision

You’ll also learn: how to scope a project, how to debug, how to handle that moment when nothing works and you want to quit. These are more important than quaternions.

Months 4-6: Add One New Thing

Take what you built. Make it better. Add procedural generation. Add enemy AI. Just pick ONE thing and go deeper.

Learn:

Whatever math you need for that feature
The relevant section of the roadmap that applies
How to search Stack Overflow effectively (or let’s be honest, how to ask AI the right questions)

Months 7-12: Build Something Weird

Now make the game YOU want to make. It’ll be too ambitious. It won’t work like you planned. You’ll have to cut features. That’s fine. That’s how you learn what’s actually possible in your time budget.

Learn:

Everything that roadmap mentioned, as needed
Project management (the hard way)
When to use middleware vs. building yourself
The specific taste of your own tears

Year 2+: Specialize or Go Broad

By now, you’ll know what you like. Maybe you’re obsessed with rendering and want to go deep on graphics programming. Maybe you love the game design side and technical implementation is just the means to that end. Maybe you discovered you’re really good at tools programming and want to build editor plugins.

The whole landscape of skills stops being a checklist and starts being a reference. “I need to implement vehicle physics? Let me look up what I need to know about dynamics and friction.”

The Things That Actually Matter

You can learn quaternions. You can master physically-based rendering. You can implement an ECS architecture that would make Unity engineers weep with envy.

But if you don’t ship something—anything—you’re not a game developer. You’re someone who knows a lot about game development.

There’s a difference.

The math is important. The graphics knowledge will serve you well. The physics understanding will save you debugging headaches. But none of it matters as much as this:

Start small. Finish something. Ship it. Repeat.

Everything else is details. Beautiful, complex, frustrating details that you’ll learn when you need them.

That’s the real roadmap.

Now stop reading this blog post and go make something. Even if it’s terrible. Especially if it’s terrible.

Your first game should be bad. That means you’re doing it right.

P.S. — If you’re wondering whether you’re “smart enough” or “creative enough” or “mathematical enough” to do this: you are. The people making games professionally aren’t superhuman. They’re just people who started making games and didn’t stop. Be one of those people.

P.P.S. — Yes, you’ll eventually need to understand why quaternions prevent gimbal lock. But that day is not today. Today you just need to make a cube move around a screen. Start there.