The Worst Game Engine: Electron
Some comparative talk about various game engines, and the worst possible way to make a video game.
Let’s imagine that you’re an indie video game creator - what’s the tool you turn to, first, to assemble your game?
Well, a game engine. I mean, technically all anybody needs to make an impressive video game is a programming language that can write colorful pixels to the screen and emit noises upon command, but in the decades since game programming became a thing, some companies have been out there writing code that takes the ability to write colorful pixels to the screen and comes with pre-written libraries to handle common use-cases like “accepting input”, “3D rendering”, “model rigging” and “shadows”. You want shadows in your game? Well, there’s the hard way (learning an awful lot of math and an awful lot about computers) and the easy way (five minutes of reading the documentation about light sources).
The software that currently sits at the top of the heap when it comes to indie video game development is Unity. I mean - there are lots of alternatives, but I think it’s fair to say that Unity enjoys near market-dominance over the indie space right now - for lots of reasons.
Let’s look at some of those reasons:
It’s a widely accepted standard, so art and tooling teams already know how to work with it.
You can’t walk five feet without tripping face-over-butt on to a Unity tutorial
There’s an absolutely huge ecosystem of (mostly-paid) add-ons that can provide functionality and assets to your game.
It supports 3d workflows extremely well
It supports 2d workflows kinda well
It works cross-platform - with some flexin’, Unity apps can run on Windows, Linux, Mac, iOs, Android, and some of the more expensive toasters
It’s powerful and performant, generally
It’s not too expensive to use, and you don’t have to start paying until your revenue or funding exceeds $200,000/yr (this is subject to change, visit their website for up-to-date details on their pricing model) - at which point the $150/seat/mo licensing is not too cumbersome.
C# may be one of the most well-designed and comprehensive languages in common use today.
There are also some concrete downsides to Unity - I’m familiar with some of these because of my day job.
Thanks to its utter and absolutely complete market saturation, indie developers have really explored the space of what’s easy to accomplish with Unity.
The asset market is like… npm, but if everything cost $30 and probably doesn’t work. Or, you could turn to NuGet, a hive of scum and villainy.
The 2D feels really tacked on compared to the 3D. Unity is a 3D game development tool that treats 2D games as “3D games with a fixed camera” - which can be a good model for 2D game development.
Unity UI tools can be frustrating and extremely limiting.
Unity is currently in the process of rewriting some of their most core systems (I think one of which might be UI?) and so the environment can be a bit of a moving target.
Loading webpages from within Unity is a nightmarish hellscape from which there is no escape.
I think “visual scripting” is a silly goal that language creators keep chasing and I wish they would stop trying to represent complicated code relationships through wierd nodular structures.
just because C# is good doesn’t mean I like it, and the .NET ecosystem is (I want to use a well-reasoned, scientific argument here) fart rock city.
Especially when it comes to websockets.
There are lots of viable and vibrant competitors, too - for example, Unreal Engine, which is probably more powerful, but, in my opinion, too complex for smaller development teams.
There’s Yoyo Games’ Gamemaker, which seems like a great tool for getting started with 2D game development.
There’s Godot, which is fully-open-source, entirely free, and surprisingly powerful.
There’s … RPG Maker and Visual Novel Maker - wierd, idiosyncratic little programs that are designed to make development of an extremely specific kind of game accessible to even the most amateur developer.
There’s the Pico-8, which, uh, is what it would be like if someone made the Nintendo Entertainment System but included a comprehensive and easy-to-use set of charming lo-fi game development tools right in the box. When I retire I might just make Pico-8 games recreationally.
All of those are products designed to make games - but at their most basic, all anybody actually needs to make a game is the ability to draw pixels on the screen, accept input, and play noises. One can do this on just about any computer with the SDL, or in just about any browser, with the Canvas element.
So that brings us to our bargain basement of game engines - thin wrappers around the SDL or Canvas. For a lot of developers, Python is the first programming language that they ever learn, and PyGame - a thin wrapper around the SDL that provides minimum-but-helpful abstractions like “sprites” and “animation” - is a powerful way to go from zero to pong. Aside from learning tools for students, like Scratch, PyGame is probably the easiest way to get a basic working game together in a weekend.
If Ruby is your jam instead of Python, there’s now Dragonruby.
And then, there’s browser tools.
Nobody outside of Mozilla takes browser gaming capabilities particularly seriously. Every couple of years they’ll pop their heads out and mention that they’ve got WASM compiling native Rust into a cross-platform virtual machine and that the browser can run an entire Linux kernel and the whole world looks at them, bleary-eyed, and goes “uh, cool, I guess” at which point we all collectively go back to playing Fortnite and exchanging cat pictures and ignoring Rust and WASM, as is the natural order of things.
It’s possible to build games in the browser with JavaScript, working with the Canvas API largely the way one would work with the SDL in PyGame - just drawing pixels here and there. And, like PyGame, helpful libraries like CreateJS and PixiJS have appeared to turn the Canvas and a handful of browser capabilities into a basic game engine.
These games are browser only. Everything in the game needs to be downloaded when you hit a webpage, run in a pretty fixed sandbox, and that game has to keep all of its stuff stashed in local storage.
One way to overcome those limitations is Electron, which is a portable browser wrapper that allows developers to take the browser environment and use it as a deployable application framework. If, for example, you had 300 megabytes of game assets and you wanted to ship them packaged with your game rather than having your players re-download them every time, you could build your browser game as an Electron application.
This guy, Ramsey Nasser, did just that. He built a whole little game engine in Electron, with the canvas element, and as far as I can tell he isn’t even employed by Mozilla.
Electron, too, has a lot of advantages and disadvantages. For people building a UI-heavy game with lots of menus and text, the web toolkit is leagues better than anything in the game engine space. Want to do some network communication over HTTP, or some database work? Electron’s got your back. When it comes to smoothly playing clean-sounding music and pushing pixels at a steady framerate with modern tooling, though? Total tire fire.
Here’s the thing, though. I’m pretty good at dealing with JS. Not great, mind you - but I already know how to develop entire applications, no matter how janky, end-to-end with this nightmare stack. I understand a lot of the tooling. I’m not building a game - no, that’s too imposing, I’m just building an application that also happens to have some game features.
Anyways, record scratch, that’s how I ended up working on an isometric MMO engine in Pixi.js.
It’s not going terribly, so far.