Almost exactly one year ago, I started learning to make games.
Really, I started learning how to learn to make games; those first weeks and months were less about creating anything functional than they were about figuring out how, over a decade after leaving school, my brain retains and metabolizes material, and where to start looking in the first place. I had never done any sort of coding, beyond some light web design (yes I mean MySpace), and had decided a long time ago that I was perfectly content to never be a Math Person.
I began completely in the dark, fumbling toward promising pinpricks of light, and now, twelve months later, I’m just starting to see the outlines of something pathlike forming. Honestly, I don’t know if what I’m working on can be called “games,” precisely, anymore, although every other descriptor I’ve come up with has been wildly pretentious (“It’s really more of a poem-dollhouse?” I heard myself say to an innocent bystander, aka my fiancé, the other week). Whatever they are, and whatever all this is, I’ve learned a lot to get here: the fundamentals of programming and digital art, interactive design principles, even some remedial algebra and physics. Mostly it’s made me realize how much more I have to learn.
One question I’ve gotten a lot over the past year is how, specifically, I’m doing this, particularly what resources I’m using. I put this little guide together to document my own process, and ideally begin a dynamic list of useful tips for anyone — especially folks with a non-STEM background like me — interested in exploring this space.
I have to imagine that there are as many ways to learn these tools as there are people. What I want to stress is that’s exactly what they are: tools. They’re for making the thing you want to make, whether that’s a game or an interactive essay or a virtual pet or some heretofore undiscovered combination of adjectives and nouns. Once I’d acknowledged that — that the real work of it all was in the creating, which didn’t have to and in fact shouldn’t wait for me to achieve some far-off level of mastery — it became so much easier to find an entry point, and to play around, and, paradoxically, to pursue topics that might have daunted me in a vacuum.
Choosing an art style, coding approach, and game engine
You could probably research how to start getting into game development forever; there are SO many YouTube channels and guides and well-meaning suggestions about which engines and languages and art styles are the best for beginners. I don’t think it’s a mistake to consume some of this material, but I do think it’s important to remember that doing so isn’t the same as actually doing the work, and that the best tools for making anything are the ones you’ll actually use.
For me, this meant deciding pretty quickly that I was going to stick to making 2D games to start, and would create my own game assets using pixel art. There’s plenty of free and placeholder art available online and no shame in using it, but much of my desire to make games in the first place had to do with getting my hands on all parts of the process; in the same vein, I also decided that I’d have to get some familiarity with code in order to achieve the level of control I wanted.
These factors helped me decide which game engine I’d start out with. I landed on GameMaker Studio 2 after a week or so of research and fiddling around with a couple of options. Its base version is available for free, and it’s the engine behind some 2D games I’ve loved, like Undertale and Hyper Light Drifter. I understand that it’s less commercially popular than more complex engines like Unreal and Unity because of its relative lack of facility with 3D games, but above all I wanted a tool with a gentle learning curve that didn’t come with a million options I wouldn’t need as an absolute beginner. GameMaker, which uses its own proprietary coding language called GML, has been great for that purpose despite its limitations, and I’ve made the majority of my projects in the past year with it; I’ve also found that learning GML set me up well when it comes to learning more widely applicable languages.
Some other options to consider besides the three I’ve already mentioned include Godot, an open-source engine that’s fairly agile with regard to both 2D and 3D games and which I’m considering learning next; Bitsy, which requires no coding knowledge and can be used to make small narrative games with a gentle, retro aesthetic; Pico-8, a similarly intentionally limited engine with more of a coding basis and arcade feel; and RPG Maker, which I’ve never used but I’ve heard has a fairly intuitive drag-and-drop approach for, you guessed it, making RPGs.
There are many, many other engines, plus plenty of game-oriented frameworks and libraries for languages like Python and JavaScript that I’m just starting to dip my toe into. If you want to start with an entirely text-based engine, there are tools like Twine that operate as essentially choose-your-own-adventure writing software — an excellent way to conceptualize branching dialogue and player choice as an absolute beginner, and especially as a writer. I just went to a class last weekend about how to make a game in Google Sheets, so really, truly anything can be a game engine (including good old-fashioned pen and paper).
Finding helpful tutorials and teachers
Once I’d chosen my engine, I began the tutorials. Game Maker comes with a number of built-in how-tos with assets provided, intended to leave you with a full, small game at the end; my understanding is that all of the other major engines do too. The one I followed first was Little Town, which was great for getting a basic handle on how the engine and programming in general worked.
After that, I began to seek out more specific tutorials on YouTube while starting to build some small projects of my own. Peyton Burnham’s intro RPG tutorials provided the basis for some of my first exploratory attempts, and I also got a lot out of his branching dialogue tutorial; Shaun Spalding and Friendly Cosmonaut have extremely helpful beginner tutorials to help get basic features like player movement, inventory management, and textboxes up and running. Each teacher goes through each line of code in order to make it clear why they’re making certain choices, and I found that following along — not copy and pasting code even when that was an option — went a long way toward helping me get the feeling of programming in my hands and head. I began to cautiously improvise, tweaking the techniques I was learning so they’d fit my little wisps of vision.
At this point I started to reach out to other people with questions. A programmer friend sat with me for an entire evening, helping debug my code; I joined a couple of Patreons for tutorial creators I really liked, as well as a handful of Discord channels. I did a creative coding program at NYU and spent the month asking much more advanced programmers than I how they’d approach a given problem. Knowing enough to know how to ask for help, after the months I’d spent working alone at that point, felt like in itself a small triumph.
These online spaces aren’t meant to be dumping grounds for every little bug you encounter, but they are where you can find folks who are delighted to help out a beginner, especially if you can provide clear documentation of the issue and what you’ve already tried to fix it. I’ve been genuinely moved by the helpfulness on display in these communities, the sheer desire to help others make more stuff, and highly recommend finding the ones that relate to your tools and interests as you progress. It’s such a relief to have actual humans to turn to when something inevitably goes wrong, and a joy to have a place where you can find inspiration and show off your accomplishments when everyone else you know is sick of hearing about data structures.
Where to go from there
A year in, I feel like I’ve just finished the pre-requisites for a class I haven’t yet begun to take. I’ve published a handful of small projects, all of which I still consider works in progress, and begun tinkering with a handful of others, which I’d like to continue to release somewhat regularly; I’ve found that just getting something out into the open air, and certainly into the hands of people who can interact with it, is the absolute best way to learn what to do the next time around. It runs counter to my instinct to sit on something forever, tinkering and tweaking until it’s perfect, but that’s a really good way to never finish anything.
Now that I have some basics down, I’ve tried to structure my learning somewhat topically. For the past three months, for example, I’ve been focusing mostly on randomness and procedural generation, learning how to create game levels as well as little pieces of interactive art. I followed Jeremiah Reid’s beginner JavaScript tutorial to make a small roguelike, and have been playing around with the p5.js JavaScript library, a beginner-friendly way to get comfortable with creative programming if you’d rather not take the game development approach in the first place. The Coding Train on YouTube is an excellent resource for getting started with p5.js, and with programming fundamentals generally.
I wrote this years ago, in a book about knitting, but I think it applies here too: “The important thing is to start, even if it’s ugly, even if it’s hard. Even (especially) if you are the sort of person who is used to having everything exactly the way you want it, who worries that the world will end if one stitch is out of place.” I’ve found it so thrilling and so terrifying to decide to learn something new this past year. I hope, truly, that you do too, and I’d love to see what you make.
Beautiful essay. It's been wonderful to get these dispatches from your game making journey. This one also hits at a really perfect time, personally. I'm going through a little career shift of my own, and today was particularly tough. Your sign off reminded me that I can't be perfect all at once, or ever at all. P.S. "Dollhouse Poem" would be a great video game title.