How To NOT Make A Video Game
Why “build fast and fix later” is both the ultimate cure for tutorial hell and a fast track to project collapse.
Probably somewhere on your hard drive is a folder called “projects” that has quietly become a graveyard. Seven different game ideas live there, none past the prototype stage, all buried at the exact same moment: the instant I decided I needed to “learn the engine properly first.” It took two years of repeating that pattern before the lesson actually landed, and no tutorial ever taught it to me half as well.
Get Unpopular Insight’s stories in your inbox
Join Medium for free to get updates from this writer.
So here is how to NOT make a video game. There’s a persistent strain of advice in the solo dev world that pushes back hard against “learn first, build second.” Who cares if the game crashes every time you go to level 2? Here’s the actual breakdown, step by step, imagine you are the one sitting at the keyboard at 1 AM wondering why your collision detection hates you.
Step 1: Skip the Learning Curve Entirely
Learning how the engine actually works is a waste of time — just speedrun the code and generate 10000000 objects which all move at the same time. Forget months of documentation and tutorials. Open the software and start building the actual game of your dreams. Every hour spent on learning the engine or coding is an hour not spent “finishing” the thing you actually care about. This is essentially a bet against what developer communities call “tutorial hell,” the state of perpetually consuming instructional content instead of shipping anything, in favor of what’s sometimes framed as just-in-time learning. Bonus: don’t even use play mode, you don’t need to test your game at all; it will run perfectly on the first try.
Step 2: Start the Dream Project
Conventional wisdom says build tiny throwaway projects first, a Pong clone, a basic platformer. No, just start the dream game from scratch, no preparation, no research, not even a core loop, just start adding random stuff to the game so people stay confused, also add 1000 cosmetics but 0 game feel. Leave the dream game soulless; it is for the best👍. This way people will give you a lot of “good” feedback. Honestly? This one might be the strongest point in the whole philosophy.
Step 3: Learn the bare minimum on the go
Honestly, just learn as little as possible. This way your brain will have more time to be “creative” instead of doing something productive pffff…No separate “education phase” and “production phase.” Here are the three golden rules:
- Every bug — just leave it there
- Every rendering quirk — just call it an “incidental feature”
- Every mechanic that breaks — it’s by “design”
The reasoning here is that knowledge takes too much space in the brain. The idea that skills are retained more effectively when learned inside the real context is just a myth. Bonus: don’t even think about designing the main menu just leave texts which can be clicked — that is all — perfection.
Step 4: Be Impatient
Patience isn’t a virtue here, it’s a trap, the thing that keeps people endlessly preparing and never shipping. Just publish the game for $1,000 while you are still developing version:
- “0.0.2_beta_alpha_prototype_omega_early_access_test1”
This fixes the problem with “analysis paralysis”, the well-documented pattern where excessive deliberation and preparation substitute for actual output. The advice is blunt: feel uncomfortable not knowing something, push forward anyway. Forward motion over certainty, every time. Bonus: add multiple DLCs which contain a random photos from the internet and push them for $10 each.
Step 5: Don’t Polish Anything Early
Visual polish, animation smoothing, UI work, all this is a scam. Your random code and settings are that polish and smoothing. A rough, ugly, half-working version of the game beats a gorgeous version of one feature that might not even survive to the final build. Bonus: add a sexy character, that surely will fix all of your problems and it will also reduce the complaints from the players to zero.
Step 6: Don’t Optimize Prematurely
Do you remember the classic saying: “If it does not work, do not touch it…” Exactly. Do not touch something that is already broken. There is a certain beauty in it. Same deal with performance, refactoring, revisions and error handling. This one’s not even unique to game dev, it’s a well-worn principle across software engineering generally. Optimizing code before you know what’s actually fast saves time, and can make the code easier to touch later anyway. Bonus: the code needs to look like spaghetti, this way people will not be able to make cheats for your precious perfect video game.
Step 7: Don’t Refactor
Rewriting code to make it cleaner without changing what it does. Gets explicitly discouraged, at least early on. The goal is avoiding a loop where you improve something that already kind of works, which only slows you down while the game gains zero new content or features in the meantime.
Step 8: Accept “Etc.”
Documentation, style guides, unit tests, version control discipline, pfff who needs this stuff. The whole philosophy really boils down to one priority: make the game exist in some form, everything else is secondary.
Where This Falls Apart
Put together, these eight steps describe a philosophy built on momentum instead of method. It’s basically the mirror image of the standard advice given by 100% “professionals”, which usually leans on no version control just push everything in main if you send something “good” you will revert manually using the commit history. Bonus: to be extra sure just do not use any kind of repository just use a pen and paper to write your code in a notebook close to your bed 😄
So Who’s This Actually For
This approach is absolutely universal every AAA game needs to follow it. It guarantees instant 1 million dollars in your bank account.
Rather, it serves as a corrective, aimed squarely at people who get stuck in planning mode forever and never actually start. It trades the relative safety of gradual, foundation-first development for speed, accepting more structural risk later in exchange for something playable sooner. If your problem is starting, this advice might genuinely work for you. If your problem is finishing something that doesn’t collapse under its own weight six months in, once feature creep and unmanaged complexity catch up with an unrefactored codebase, this just moves that problem further down the road. It doesn’t solve it.
Which brings me back to that folder on my hard drive. Maybe the real lesson isn’t “learn first” or “build first,” it’s that I need to pick one dream project and actually be impatient about finishing it, instead of impatient about starting seven different ones and abandoning all of them the second the code gets ugly.
Final Thoughts
Strip away the specifics and this whole debate comes down to a tradeoff between two ways of failing: stalling out before you ever start, or collapsing under the weight of what you built once you finally did. Neither the “learn everything first” crowd nor the “just build it” crowd has a clean answer to that, because the right balance depends on the size of the thing you’re actually trying to make. My guess is that the solo dev community keeps cycling through both extremes precisely because neither one is fully wrong, and the tools available now (better engines, more accessible documentation, AI-assisted debugging) will keep shrinking the cost of learning on the go, which means the “impatient” approach probably gets more forgiving over time, not less.
