Aug '24 (edited) • VALUE
How I actually make games
People keep asking me about my process. It's surprisingly not special. But, in case anyone wants to know what it looks like to ship a game to Steam starting from zero, here is what I actually do.
- Have gameplay idea. Write it down somewhere or draw some sketches to work through a few ideas. I write down everything that comes to my mind the moment I think of it, and then I curate the list later. Oftentimes, ideas I kill end up coming back in some way later.
2.Make some sprites to communicate the basic gameplay idea. The shapes need to be readable, and they need to relate to the gameplay. The player needs to have the perception that they are looking at something interactable. There should be no decorative art this early. Art should only relate to gameplay.
3. Get the sprites/UI into the game, just making sure I can draw them in the game where they are supposed to be. Whatever rendering logic you need to write to make this happen, write it. Don't support anything more than what you need to draw the art. There is no generic "renderer." There's just specific things you need to draw. Don't plan for a future which doesn't exist yet.
4. Once things can be drawn, I then make them interactable by doing things like click areas, movement, etc. This is specific to your game idea. You actually have to make the game playable as a game, using the prototype art. Gameplay doesn't come later once you have the "engine." The "engine" gets developed as a *consequence* of making the game work. There is no separation between the two. The engine is the game and vice versa.
5. As I make more and more similar things, I just extract to a function to reuse bits and pieces of what I have to do the next thing. I'm not particularly obsessive about this, trying to remove every bit of duplication. It's more like I casually notice some repeated patterns and then clean it up. Remember you are making a *game*, not raking a zen garden for personal satisfaction.
6. Over a long period of time, a "game engine" starts to emerge. But that's nothing special. It's just leftover code. The more you do this, your skill and knowledge base grows. Even if you don't have the code lying around, you will remember how you approached certain kinds of problems. Half of the "engine" is inside your head. It's your experience solving real problems.
7. Playtest, redesign, and ruthlessly cut what isn't working. When you cut, commit to the cut. Don't keep it halfway in the game, thinking it might come back some day. Just get it out of the way so you can focus on the new direction. Expect your game to go through *several* redesigns. This is totally normal as you figure out how the game is supposed to play. The ideas you had early on won't be as good as the ideas you will have later in development. Expect to cut 80% of what you dream up. Be vicious and emotionless about killing your babies.
8. I NEVER PLAN A SINGLE FUCKING STEP AHEAD OF THE THING I AM DOING RIGHT NOW. PLANNING IS DEATH AND THE END OF YOUR GAME DEVELOPMENT CAREER. IT'S HOW YOU END LIFE AS A SENIOR SOFTWARE ENGINEER 14 AT A BIG CORPORATION DOING ENTERPRISE OBJECT ORIENTED JAVA BULLSHIT AND TAKING RAISES THAT ONLY ACCOUNT FOR INFLATION WHILE LEAVING NO FUCKING DENT IN THE UNIVERSE.
27
9 comments
How I actually make games
powered by
skool.com/game-dev-grinders-8513
A group for game devs who want to ship great games from scratch in C, while mastering the ancient art of Caveman Programming
Suggested communities
Powered by