There’s a way to get a leg up in the game dev job market. No matter your title – artist, narrative designer, QA – you will always impress your prospective studio if you know your way around a game engine. It’s like applying for a film gig and knowing your way around a set, even if you’re an editor. The knowledge is smart to have. You don’t need to be a full-on programmer to get a game dev gig, unless you’re applying to be a programmer, lol. (To my knowledge, no one is vibe coding their way into Activision’s programming staff.)
Most games today are made in one of three engines: Unreal is used by big studios making AAA games. Unity is targeted at mid-sized indie and mobile games. Godot is the open source engine for the indiest indies. Unreal is a suit and tie. Unity is a work shirt and khakis. Godot is a bootleg Bart Simpson shirt from the thrift store. (In reality, the majority of people using these programs wear hoodies.)
My current studio, Doborog, uses Unity extensively. The more familiar I am with Unity, the easier it is for me to communicate with my colleagues and understand what’s happening with our games. Unity knowledge also helps me as a game designer, because I have a better idea of what’s difficult to achieve in engine. If I know my way around Unity, I won’t design gameplay elements on paper that would put us way behind schedule if we implemented them. Again, to use a film analogy, it would be like being the screenwriter for a small budget romantic comedy and writing a scene with multiple car crashes. The more familiar the writer is with the mechanics of film and genre, the easier it is for them to write useable material.
There’s another good reason I should learn Unity. My friend Spencer runs his own studio, YYT Games. He has access to the magical dev kits that transform Unity projects into console games. He’s offered to help me convert my games and get them onto Nintendo Switch, which is the kind of thing porting houses charge considerable bucks for. Spencer’s a very good friend!
The only problem? I hate Unity.
I’ve been using Unity on-and-off-again to make game prototypes for years. The most ambitious of which was Motion Picture, a puzzle game that required dragging and dropping pieces. As I wrote about last year, you would think any game engine would make drag-and-drop simple. It’s such a basic user interface component. But the code is surprisingly complex. I had to copy and paste it from a YouTube tutorial, which I couldn’t even understand!
And this was using Playmaker, a visual scripting add-on for Unity to make coding easier! Even the tool designed to make Unity simpler just wasn’t simple enough for me, because Unity itself is so complex. There’s always some hidden setting or weird quirk that rubbed me the wrong way. Like, say you want to place a block in the top left corner of the scene. You drag the block object into the scene. The object isn’t visible. Where did it go? Oh, are your camera settings right? What about your canvas settings? Is your object in the visible layer? What are the object’s coordinates? What’s the object’s size? You finally fix it after a half hour, so you can see the object, then you preview the game and it disappears again! What happened? Why am I reading a forum post from four years ago about raycasting? Do I really have to know what raycasting means? I just want to make a little jigsaw puzzle!
Playmaker is well intentioned, but even that tool has a fatal flaw for me. You create visual diagrams with pre-written code within game objects. So if you make a pause button, you create a little flowchart inside the pause button object with blocks of code that do stuff like, “Pause all animations,” “Pause timer,” and “Play the sickass pause menu beat.” The problem is this: If your scene has many objects with flowcharts in them, their actions might contradict each other in unexpected ways that create bugs. When a bug happens, you have to revisit the flow charts in every game object to figure out what’s wrong. Sometimes the code is basically right on all the objects, it’s just that one game object is doing their action a micro-second before another game object, which creates a very difficult bug to detect!
I am on a quest to make game design fun, particularly the soul-enriching game dev projects I’ve been taking on in my spare time. In my perfect world, I wouldn’t be my own programmer. I’d be the keyboard player in a band, not a rapper-producer putting out tracks on Soundcloud in his bedroom. But I have weird taste and no desire to start a commercial studio, so it’d be difficult to put together a dev team.
What’s a non-programmer to do if they want to make games for fun? The answer I came to is that I was using the wrong tool. Yes, Unity proficiency would be helpful. But helpful ain’t fun. If I’m making a game for fun, the process itself needs to be fun.
I needed a new game engine.
I did a lot of research. I’m already familiar with Ink and have made dozens of text-based games with it. But not every game I want to make is a choice-based text game. I wanted an engine with more capabilities. A lot of the popular no-code options, like Bitsy and Twine, felt limiting to me. I spent four and a half years developing 100 text games. I want to grow and challenge myself. Unreal looked even more complicated than Unity. Godot seemed a smidge easier than Unity, but didn’t strike me as particularly fun.
Then I found a YouTube video running down the no-code options and they spotlighted an engine I’d never heard of before. It was called GDevelop. Like Godot, GDevelop is open source. Like Ink, it’s designed to be no-code. And like both of them, it’s free to use! But GDevelop is a visual engine that has built-in templates for making all kinds of games: platformers, RPGs, card games, even 3D FPS. They have an intuitive system where all the logic for the scene is on a single sheet divided into two sides. There’s an “If” side (ex. “If the FART BUTTON is pressed…”) and a “Then” side (ex. “Play sound file WETFART_3.wav”). So when there’s a bug, because there will always be bugs, all the logic you coded is in one place. Best of all, the code is written like sentences a person could theoretically say.
There are pre-built behaviors for objects, which you can just click to make them do something. For example, to make a game object draggable, I just hit a check box for draggable. When I previewed it, the object was instantly draggable. No YouTube tutorial required. It just worked. There are lots of other behaviors, too. You can check that an object is a platformer character to give it instant gravity and movability (all customizable), or check that an object is a platform itself, so the object can be solid ground for your platformer character.
The on-boarding to use GDevelop was a series of short, easy to understand mini-game tutorials. You start a game and see something is broken. The tutorial walks you through how to fix it, thereby teaching you the main principles of the engine. Unity has a version of these tutorials, but they’re bigger and more bloated, because they have a lot more to cover.
GDevelop has some drawbacks. There’s a built-in AI coding tool you can pay money to use. Blech. I just closed the tab and ignored it. It’s highly ignorable. If you want to use their cloud service to make Mac and PC builds, they charge you for that, too. You can also make builds on your own hard drive using a $20 tool on Itch. Or export as HTML5 on the web for free. (I had no issues exporting to HTML5 in GDevelop, whereas my Unity web builds were always unmitigated disasters.) Porting to console requires a studio with special dev kits, aka money, but I’m far from making a game for consoles at this point.
GDevelop’s logic has its own peculiarities, which I’ll go into more next week. But because the language it uses is so clear, at least I can understand what those peculiarities are, so I can work around them. GDevelop is like a challenging puzzle game, but everything I need to know to solve the puzzle is there or easily looked up. I just need to figure out the solution. Unity is a maddening puzzle game to me, where many of the clues are buried in hidden windows written in a foreign language.
After my recent game jam with GDevelop, the two of us are making a go of it. So far, so good. We moved in together. We’re splitting the utilities. We’re thinking about getting a cat. I’m sure I’ll be reminded of Unity all the time. I might even regret the break-up on a professional level, but I want to make video games and have fun doing it. Now I think that’s actually possible.
🎲 Your Turn: What’s your favorite tool for making creative stuff? A game engine? A pottery wheel? A watercolor brush? What do you like about it? Have you ever abandoned a tool that wasn’t working for you anymore? I’d love to know what you’re making. Reply to this email or leave a comment using the orange button below.
Leave a Reply