Code-First Indie Game Developers and their Tools-of-the-Trade

As I've been getting myself more involved again in building small-to-medium scale 2D games, I've spent some time looking at the tools and technologies that have matured in the indie game development space. I thought I'd discuss some of my discoveries and thoughts on the matter, as we move into 2026...

Editor-First vs. Code-First Developers

Indie Game Developers generally feel more comfortable in either an editor-first, or a code-first environment. Which of these camps you fall under is really just a "you" thing. Do you like working directly with your game assets, seeing where they fit visually, etc.? You'll probably be more comfortable in an editor-first environment like Godot or Unity. Do you like having full control of the game engine and build process, and working in a text editor? You'll probably be more comfortable in a code-first environment.

I firmly fall in the code-first camp myself. Here are some of the tools and technologies that code-first indie game developers might want to look into...

Code-First Tools of the Trade

What seems to have quietly happened over the past decade or so, is that the web itself has become a strong contender as a game development platform. There are plenty of tools that can be used to target the web, and the web is available everywhere. It's on your Windows PC, your Linux PC, your Mac, your iPhone or iPad, your Android device, and increasingly elsewhere.

Recently, Youtube has entered the space as a game platform with its Youtube Playables SDK. I plan to look more into how Youtube Playables works, as it looks like a natural fit for indie game developers looking to find a wider audience for small-to-medium sized games.

I've become quite familiar with some of the technologies I'm about to list. But a handful towards the end of the list are tools I want to learn more about.

• C/C++, CMake, and Conan - For developers who want full control over the build process in the lowest-level development environment that isn't assembly code.
• Emscripten - For C/C++ / CMake developers who also want to target a web-based game.
• SDL - For C/C++ developers who want to build a cross-platform game with the widest possible support.
• Raylib - For C/C++ developers who also want 3D rendering and animation support.
• JavaScript (or TypeScript) and Canvas - For developers who want to build a web-first game.
• Phaser - For web-first JavaScript developers, offering a full-featured framework for game development.
• Tauri - For developers who've built a web-first game, but want to take advantage of the native webview that now exists on all major operating systems in order to target the desktop.
• Electron - Similar to Tauri, with easier setup at the cost of larger binaries.

Raylib, Phaser, and Tauri are all tools I plan to look into more in the future. Raylib seems like an attractive option for C/C++ developers, but it does currently still use OpenGL under the hood. While OpenGL is still a stable choice, Raylib's longer-term viability may depend on future support for Vulkan and Metal.

Honorable Mentions

Here are some additional frameworks that many indie game developers use.

• SFML - For C++ developers who want to build a cross-platform game, and prefer C++ classes over raw C.
• PixiJS - A JavaScript 2D rendering library that uses WebGL or the Canvas API under the hood.
• Three.js - A JavaScript 3D rendering and animation library that uses WebGL under the hood.
• Love2D - A Lua framework for 2D games, with a low barrier for entry.

There are others, of course, but these seem to be the most widely-used and actively-maintained as of January 2026.

If I was planning to build a game today that required 3D rendering, I'd be uncertain whether I wanted to go with the combination of C++, CMake, Emscripten, and Raylib. As much as I love the satisfaction of building something in C++, it feels like the combination of JavaScript (or TypeScript), Three.js, and Tauri might actually be a more viable long-term approach.