This guide is for anyone who is coming to indie development from a non-games related field, or anyone who feels intimidated by traditional gamedev guides. This one is for you.
What is coding?
I’ve been in the tech industry for long enough to realize that “coding” is an arbitrary goalpost that younger engineers move around in order to make themselves look more attractive on the job market. You’re telling a computer what to do. Full stop, that is coding.
If you’ve ever put italics brackets around some text in a blog, then congratulations. You have coded. The people who tell you that you have to “do XYZ to be a real coder” are either showing off their own skills, they don’t care about what your coding goals are, or they’re hoping to discourage you.
Remove those people from your workflow.
What kind of programming language do I need to learn?
The goal is to understand how computers communicate with each other. You don’t need to know the most ‘efficient’ or ‘up to date’ programming language, especially when you’re just starting out. The point is to learn how to manipulate variables, and to understand cause/effect. Any computer language can help you do that.
Don’t pick your first language based on what’s prestigious, or what your friend said that you should learn. Pick your first language based on what you want to make. What were some of your favorite simple games made in? What tools? What software?
The fact remains that coding is still a difficult (not impossible) skill to learn, and you’re going to encounter a lot of frustrations. You’re going to want to throw your monitor out of a window. That means that you have to pick a software or language that you enjoy, or software/languages that are stepping stones to your game-making goals. You’re going to wear yourself out if you chase the phantoms of “real coders.”
How much skill do I need with a computer language in order to make a game?
Honestly? Not that much at all.
When you start out, you don’t need to make a full on Gameboy game. You just need to learn how to get the program to do the things that you want. Your first projects should not be “play-ready.” Be patient about learning fancy effects. Those will come later, so long as you aren’t frustrated into giving up.
Do not read the wiki documentation in its entirety. That will intimidate you, and it’s not very helpful when you’re just trying to figure out how to change text color. Read coding documentation on a purely “need-to-know” basis. If you’re not currently trying to add a specific mechanic or design to your game, then pretend that trick doesn’t exist.
No really, how do I learn all the different tricks to make [a specific game]?
If you’ve learned enough fundamentals, then you should have a vague idea of what to Google. The hard part is breaking down all the different elements that went into a game.
Here’s how I would approach trying to learn how to make Pong. Full disclosure, I don’t have any experience with programming physics.
- I would define the size parameters of the playing field. Am I making this for a small mobile screen, or desktop? Would I specify the size, or would the game automatically resize to the viewport? What’s the minimum ratio the game needs to be in order to play as intended? Define resolution.
- I would have to tell the ball paddles to be both visually and functionally opaque. If a ball touches the paddle, then it should not fall through the other side. When the ball makes contact, it should bounce to the other side. Define ball behavior when it touches one of the paddles.
- How fast is the ball moving? Is the angle or the speed of the ball affected by whether you are letting it bounce off the paddle versus moving the paddle as the ball makes contact? Define ball physics.
- The ball needs to reset when it travels past the paddles. Set ball to reset in a specific position after it passes the goalposts. What area of the window is defined as the goalpost area? In what range can the player paddles move?
- Is this game played by keyboard, joystick, or neither? How are player commands inputted? Implement player input controls.
I don’t know anything about programming for Pong, but I can start researching how to implement every mechanic into the game. I would think this applies for every game. When you see an interesting game mechanic, try to break it down to commands that you need to implement. Like IF “ball hits paddle” THEN “ball goes in the negative direction.”
Even if you don’t know the word for what a conditional statement is, you can still break down the relationships between objects. Use that as a basis for knowing what questions to ask.
At their core, games are a bunch of rules that define player engagement. Instead of trying to learn every possible rule, you just need to learn the ones that facilitate the kind of interaction that you’re trying to create.
My code is bad! Help!
When you look at a good indie game, you’re not seeing the number of years that the programmer spent making bad code. You have to write bad code, and there’s no way around it. Your syntax will be clunky and twice as long as it needs to be. You should write code that breaks when you run it. Mistakes are good if you learn from them.
If you don’t know what broke, then Google “why is [program/language] [doing the thing]” or “why is [thing] breaking/when I do the [thing]”. This is what engineers making six figures in San Francisco do, I promise.
I still can’t make my code do the things that I want!
Slow down. Make sure that you’re not rushing progress. If you’re hitting a wall because of something like a learning disability, then try to make a list of all the different things that you can do in a game engine. Then design around the skills that you have. If you obsess over the kind of code that you’re not capable of yet, then you’re going to feel too bad to make anything.
At this point, making anything at all is more important than agonizing over what you can’t do yet.
Can I practice game design skills while I’m still working on basic coding skills?
Absolutely! Let me point you to Twine. I’ve also heard good things about Ink and Choicescript. Even though those are known as “code light” tools, they’re still useful in getting you to think about causality.
Design can add interest to games that lack mechanical complexity. If you’re good at making graphics, then you should lean into that in order to make thought provoking experiences. I recently played a game about marrying or killing cat bachelors and it was absolutely hysterical. I mean, the concept itself was funny, but what really sold it was the images. Please play Caturdate.
If you’re good at writing words, then do that. You should focus on your strengths as a gamemaker, and then figure out how to use code to improve how you make games (user interface, text display, etc.). The tools need to serve the vision, and not the other way around. Don’t think of code as something that constrains you. Put off learning tools that don’t contribute anything to the experience of the game that you are currently making.
This has been helpful.