This is more in-depth look at the question “Should I write my own game engine or should I use Unity?“ which I previously answered in this post. To recapitulate: The answer is neither. It’s a false dichotomy. You can use a different engine. You can use no engine. You have many choices. But what are these choices?
1. Genre-Specific Game Development Tools
Examples: Bitsy, RPG Maker, Adventure Game Studio, PuzzleScript, Twine, Inform 7, Ren’Py
These tools are limited to one genre, certain kinds of controls, and a certain gameplay structure. If you want to experiment with game mechanics and presentation styles from different genres thrown together, these tools will make your life difficult.
On the other hand, if you only want to make a text adventure in the style of Zork without any three-dimensional interludes, then Inform 7 will have many features and you need in a text adventure and tools specific to text adventure games that you won’t find in a general-purpose game engine like Unity3D. Unity3D doesn’t know anything about common verbs text adventure players expect to be in your game. If you want to make a point-and-click adventure, Adventure Game Studio is similarly well-suited to putting_ content_ into your adventure game, and gives you the basics of point-and-click adventure games for free.
Some tools, like Twine and Ren’Py, are made in widely used programming languages, so that you can drop “below” the level of the engine and write plain code (in JavaScript and Python, respectively for these examples) if you want to do something out of the usual.
If you are an experienced programmer, you can probably implement a 2D walking simulator, a point-and-click adventure, a Sokoban-like game, a multiple-choice game, or a visual novel easily enough, either from scratch or in an engine, but these tools still have their usefulness for prototyping.
If the thing you want to make cannot be made easily with one of these tools, you might as well try one of the more general-purpose tools listed below. If you want to make an RPG-rhythm game hybrid, it might be easier to implement character sheets in Unity than to implement rhythm-based combat in RPG maker.
2. Simple, Graphical Game IDEs
Examples: GameMaker Studio, Construct, ClickTeam Fusion
These tools are halfway between the first category of tools and “real“ game engines. They advertise their “simple graphical tools“ (i.e. a level editor that lets you attach code to in-game entities), “no code“ game design (i.e. visual scripting) aimed at people who cannot program, and templates for game genres like “platformer“ or “shoot-em-up“.
If you are an experienced programmer, you may want to stick with a programming language you already know, instead of using visual scripting system. These systems make it easy to write simple logic without wrestling with the compiler all the time, but they make it very cumbersome to implement more complex algorithms or organise large code bases. Especially the graphical programming system of ClickTeam Fusion makes simple game logic very simple, and somewhat more complex game logic disproportionally and prohibitively difficult.
If you aren’t a programmer, but more of an artist, you can use these tools to get graphics moving on the screen and create something playable quickly. Successful games like Undertale,_ Spelunky Classic, Risk of Rain and _Hotline Miami were made in GameMaker. Knytt and Baba is You were made in ClickTeam Fusion.
Warning: These commercial games sometimes rely on extensions written in a “real“ programming language, or on scripting with a different programming language than the “easy” system the editor uses by default. Don’t be fooled into thinking that every one of these games has been made with simple templates and drag-and-drop tools. You can make a complete commercial game with these tools, but it will still be work. It’s the same as having to write JavaScript in order to make Twine do something completely different.
3. Big Game Engines
Examples: Unity3D, Unreal Engine, Godot, Amazon Lumberyard, Source Engine
These have everything, and by everything I mean a 3D level editor that lets you attach code to game objects, a visual scripting system, writing code in a “real” programming language, APIs that let you interact with the game engine, an asset pipeline, collision detection, a physics engine, networking, skeletal animation, path finding, a particle system, an abstract, cross-platform input system, UI widgets, a build system that packages your game complete with all levels and assets for multiple platforms, and so on.
Although you can find templates for many game genres, open source libraries, and all kinds of code assets from the asset store, for things like minimaps, inventory systems, spellcasting, dialogue trees, you will probably need to write some code to tie it all together.
This is the “safest“ option. This is how big studios do it. There are many resources, tutorials, and experienced game developers out there who you can hire or ask for advice.
If you don’t need these features, you can always work around them, by keeping your own state in your own data structures - you are working in a real programming language after all, and can implement whatever you need - and by writing your own rendering based on these structures. There’s a catch, though: If you don’t use the engine’s asset pipeline, scene graph and component architecture, you will lose interoperability with third-party scripts and tools that assume your game follows the software architecture commonly used with this engine. If you write custom code to load level files from disk in Unity3D, you lose the integration of third-party scripts from the asset store with the Unity level editor.
Some people use the same big engine as their go-to tool for every game genre, even if a specialised tool like Twine or PuzzleScript is available, because they have so much experience, they are more productive in this way.
4. Small Game Engines
Examples: HaxeFlixel, Ursina, OGRE, Wasabi2D
These don’t have everything. There is no level editor, you have to use an existing level editor and write code to load the files to populate the scene graph, or you’ll have to write code that creates game objects and level geometry with procedural generation. In any case, you will need to write code to set everything up. The code looks a lot like the code you would write in a “big“ game engine, everything is organised in terms of scenes and game objects and particle systems and so on.
If there are third-party libraries, they are not integrated with the engine by default. Either you have to write your own glue code integrating the physics library with your game engine, or there is a wrapper for your engine that is not always up to date with the newest release of the library.
Small game engines are often based on OOP, instead of a component-based architecture that lets you attach multiple behaviours to one game object. In order to make your game object behave a certain way, you create a class that inherits from the engine’s entity class, and implement the behaviour in there.
5. Cross-Platform Game Libraries
Examples: libGDX, SDL, SFML, OpenFL, XNA(FNA/MonoGame), PyGame, Löve2D
These libraries have all the tedious things like “talking to the operating system to open a window“ or “opening and loading mp3/jpg files from disk“ or “polling the gamepad buttons“ implemented for you, but they are not game engines. You need to write your own game loop, and you need to keep your game state in your own data structures. If you’re using a physics engine, you need to make sure to keep the state of your gameplay objects in sync with the physics simulation.
Some libraries, for example libGDX, come with a vast array of official add-on tools and modules for different use cases, while PyGame is meant to be a low-level library you can use with different OpenGL rendering systems, GUI widget toolkits, and input systems.
If you use a low-level library, you need to write your own game loop, with event handling, updating data structures for game state, and rendering. You have full control over everything, you can decide which code to execute in main() before the game starts. You have to see this as a feature. If you don’t want to write your own game loop, you should just use an engine. These libraries are useful when you don’t want to write low-level code, but want to write a new game engine, or when you want to write a simple game, but need precise control over the game state and control flow, or when you want to make a simple game and know a big engine would just get in your way.
6. Niche Open-Source Game Engines
Examples: Anura, Spring, darkplaces, FTEQW, FIFE, Flare, Wintermute Engine
These are kind of difficult to talk about. I am listing these separately from open source engines like Godot or HaxeFlixel because they are not developed as general-purpose engines for commercial games (or indie games and game jams). These were either developed as special-purpose engines in tandem with an open-source game, or refactored/extracted from a finished game. That often makes these engines comparable in their feature set and focus with the tools in the first category, but without the beginner-friendliness. If you want to make something - anything - that isn’t a real-time strategy game with hundreds of units, spring might not be a good fit.
7. Everything From Scratch
Examples: The Witness, Super Meat Boy* *
Blender, Tiled, Ogmo Editor, LEd, Overlap2D, Ink, Bosca Ceoil, sfxr, ArmorPaint, pixelorama, ASEPrite, CrocoTile3D, Spriter, GTKRadiant, TrenchBroom, Sculptris
Your Own Libraries
Writing libraries: A*, particle system, networking, UI widgets, physics and collision detection
Your Own Tools
Writing tools: Sprite Packer, Level Editor, Dialogue Editor, Content Editors
Your Own Engine