Open Source Game Engine
A game engine is the foundation a project sits on for years, which makes its terms as consequential as its renderer: a per-install fee or a revised royalty can quietly reclaim the economics of a game after it has already shipped. That risk is exactly what the open source engines here remove. There is no seat tax, no revenue share, and no upstream company that can change the deal once you depend on it, so the full toolchain, editor, and runtime stay yours to fork, retarget, and ship. What remains is the ordinary work of matching an engine to the game you actually intend to build.
Godot Engine
Free, open source 2D and 3D game engine with one-click exports to desktop, mobile, web, and consoles
Bevy
Data-driven 2D and 3D game engine built in Rust around the Entity Component System
Phaser
Open source HTML5 game framework for building 2D games with WebGL and Canvas rendering
libGDX
Cross-platform Java game development framework for Windows, Linux, macOS, Android, web browsers, and iOS
OpenRA
Libre real-time strategy game engine for classic Westwood games, with modernized play and mod support
MonoGame
Open-source .NET framework for building cross-platform games in C#
Luanti
Open source voxel game engine for easy modding and game creation
Open 3D Engine
Open-source, real-time 3D engine for building games, worlds, and high-fidelity simulations
Stride
Open-source C# game engine for 2D and 3D games, with realistic rendering, VR, and a visual editor
Our picks
Best all-round starting point: Godot Engine Godot builds both 2D and 3D games from a single visual editor and exports to desktop, mobile, web, and consoles with one click. It is MIT licensed with no royalties and run by the not-for-profit Godot Foundation, so the terms cannot change under a project. The class reference is built into the editor.
Code-first engine in Rust: Bevy Bevy defines a game entirely in Rust around an Entity Component System, letting logic run in parallel across CPU cores. It is modular through Cargo features, so you pull in only the parts you need, and it is dual-licensed under MIT and Apache 2.0. Expect an evolving API, with breaking changes every few months and migration guides.
2D games for the browser: Phaser Phaser is an HTML5 framework for 2D games that run in desktop and mobile browsers, using WebGL or Canvas. You write in JavaScript or TypeScript with built-in Arcade and Matter.js physics, scenes, tilemaps, and tweens. Beyond the open web it can also target YouTube Playables, Discord Activities, and Twitch Overlays.
Proven cross-platform C# framework: MonoGame MonoGame is a code-first C# framework and an open source continuation of Microsoft's XNA, used to ship games including Celeste and Stardew Valley. It targets desktop, mobile, and, for registered developers, PlayStation, Xbox, and Switch. Choose it when you want C# and full control in code rather than a scene editor.
Matching an engine to the game you are building
The engine demo reel is the wrong place to start; the game you actually intend to ship is. A 2D game with tilemaps and sprite batching may be better served by a focused 2D framework than by a 3D-first stack with a 2D mode bolted on, and a browser game has different constraints again. Godot covers both 2D and 3D from one visual editor, Phaser targets the web with WebGL and Canvas, and Open 3D Engine aims at high-fidelity 3D worlds. Name your hardest requirement first, then judge engines against it.
The bigger structural choice is whether you want a visual editor or a code-first framework, because it shapes every day of work. Godot, Stride, Defold, and Open 3D Engine give you a scene editor and asset pipeline; Bevy, libGDX, Phaser, and MonoGame expect you to define the game in code, in Rust, Java, JavaScript, or C# respectively. Editors help artists and designers work without an engineer for every change; code-first engines give programmers tighter control and cleaner version control. Match that to who is on your team.
Finally, let your release targets narrow the list. Desktop is the easy case; web export adds memory and packaging limits, mobile brings input and store rules, and consoles usually mean proprietary SDKs even on an open engine. Godot and Defold advertise one workflow that exports to desktop, web, mobile, and consoles, while MonoGame reaches consoles for registered developers. Whatever you pick, keep source art, audio, and scripts in standard formats so the project can move if the engine stops fitting.
Related categories
Frequently asked questions
Do I need a full 3D engine or a 2D framework?+
Let the game decide. A 2D game built on a dedicated 2D framework like Phaser or libGDX often gets more predictable sprite handling and lighter builds than the same game forced into a 3D-first engine's 2D mode. If you need 3D, or expect to move between 2D and 3D, Godot handles both from one editor and Open 3D Engine targets high-fidelity 3D specifically. Prototype your hardest scene before deciding.
Should I choose an engine with a visual editor or a code-first one?+
It depends on your team. Visual editors in Godot, Stride, Defold, and Open 3D Engine let designers and artists build scenes without an engineer for every change. Code-first engines like Bevy, libGDX, Phaser, and MonoGame keep the whole game in source, which programmers often prefer for version control and precise control. A code-only engine can slow down art-heavy teams; an editor can feel like overhead to a solo programmer.
What languages do these game engines use?+
They vary widely, which is often the deciding factor. Godot uses its own GDScript plus C#, Bevy is Rust, Phaser is JavaScript or TypeScript, libGDX is Java, Stride and MonoGame are C#, and Defold and Luanti script in Lua. Pick an engine whose language your team already knows or wants to learn, since you will write gameplay in it every day and hire around it later.
Can open source engines export to mobile and consoles?+
Several do. Godot and Defold advertise a single workflow that exports to desktop, web, mobile, and consoles, and MonoGame reaches PlayStation, Xbox, and Switch for registered developers. Console support usually still involves proprietary platform SDKs and developer registration even when the engine is open source. Mobile export is more open, but test memory, touch input, and store packaging on real devices rather than trusting an export button.
Are these engines really free for commercial games?+
Yes, with no royalties or seat fees, which is the main reason studios adopt them. Godot, Bevy, Phaser, libGDX, Stride, and MonoGame use permissive MIT or Apache licenses that do not require sharing your game code. A few engines and reimplementations use copyleft GPL licenses, which carry conditions worth a legal read if you modify the engine. Always check the license of bundled libraries and sample assets too.
How do teams keep scenes and prefabs from causing merge conflicts?+
Favor engines that store scenes and resources as text you can diff and merge, split large levels into smaller owned chunks, and keep generated import caches out of review. Godot's text scene format, for instance, merges far better than an opaque binary. Binary assets like textures still need file locking or clear ownership. Run a deliberate two-person conflict on a real scene before production to find the pain early.
What is an engine reimplementation like OpenRA or OpenMW?+
Some entries here are not general-purpose engines but open source reimplementations of a specific game's engine. OpenRA modernizes the classic Command and Conquer real-time strategy games, and OpenMW re-creates the engine behind Morrowind, which you still need the original game files to play. They are excellent for modding or reviving those titles, and their scripting can host new games, but they are not where you would start a fresh unrelated project.