Engines

TUI games

I'll probably write out my whole game development history at some point (involves a very old version of GameMaker studio, and the Starcraft II Map Editor), but the most fully-featured game I've made to date is a weird turn-based discrete strategy (think Chess meets Advance Wars meets Magic: The Gathering). I did it in raw Rust, with no formal game engine of any sort (until the end, when I started porting it to ggez). All graphics were terminal-based (don't forget to fill out your Jaxter bingo cards), and the save states were stored in a text-based format so you could store and distribute them with a git forge (another one for the bingo card).

Bevy

Learning from my mistakes, a few months ago when I felt the urge to make another game, I used Bevy. I was feeling like a 3D Magicka type of game, but I was fresh off the heels of playing Pikmin 4, so I know I wanted to incorporate dandori somehow. I didn't get too much further than a basic tech demo with this particular game, but it made me understand better why people use game engines in the first place. Which, in retrospect, probably seems a bit obvious from an outside perspective, but I really did think that, to some extent, feeling the need to depend on a game engine was a dandori issue (which is a bit ironic because Pikmin 4 was the first Pikmin game to use an externally developed engine).

Using an ECS was pretty fun, and I got the hang of it pretty quick. The plugin system is really flexible, and the ECS allows for them to interact pretty seamlessly. Bevy's biggest shortcoming in this experience is the lack of a map editor.

Godot

Which brings us to this month, when I tried one more time to develop a game. After coming to learn about the wonders of using a game engine (and seeing what a bumpy ride Unity's management was dragging their engine through, and their involvement with malware developer ironSource), I decided to try out Godot. And, once again, this might seem obvious, but wow, there are a lot of features that Godot has that makes game development significantly easier. Whereas with Bevy, I had to find a plugin to use for my player character's physics, with Godot, I simply add a CharacterBody3D node, drag a scene into it, and drag in a few lines of code from the internet, and I had a character on the screen that I could control, who would run up ramps and fall off edges. Not just that, but building the map was also much easier. With Bevy, I made my map in Blender, and exported it as a GLTF. And the amount of troubleshooting I had to go through to get it to actually work correctly was quite the ordeal. While the general capabilities of each engine seem to be roughly similar, the workflows are night and day.

That is, until I tried to implement online multiplayer. To give credit where it's due, online multiplayer is very complicated and difficult, and it's a wonder that it even works at all in Godot. But my experience with it was extremely different from my experience with the rest of Godot. While the implementation was relatively straightforward and clever, it was much more difficult to debug, and there aren't as many online resources explaining how to use it because it's a relatively new feature (though this guide was extremely helpful). Not only that, but having to deal with multiplayer also made other parts of the engine similarly difficult to develop and debug. And if I have to do all this sort of tomfoolery anyway, why not do it in a language that I like (3 guesses which one) with a more robust plugin system?

Back to Bevy

While I haven't actually done any online multiplayer in Bevy yet (the previous tech demo only had local multiplayer), I've done some perusing, and it seems like I have a few options. I've chronicled my evaluation of all these plugins in this article.

All pages

• Bevy multiplayer
• Replicon