I'm reminded of the story of Randy, that I watched unfold over quite a few months - he couldn't help himself but to work on new features, rewriting existing features, hacking to make his workflow better, but really struggled to release anything, like a form of bikeshedding where you are actually still productive, except what you produce doesn't seem to meaningfully get you closer to shipping at all.
The videos that document the journey probably haven't gone anywhere:
If you want to make an engine and learn about making engines - make an engine.
If you want to ship a game - think long and hard about whether an off-the-shelf engine wouldn't be a better investment of your time (because you wouldn't invest hundreds or thousands of hours making something bespoke and could actually make the features you need within an existing engine).
I suspect that with the great FOSS and source available engines we have, like Godot, there will be plugins for msot things and folks will be able to make their own without having to start from scratch (unless they really want to), like the most competent terrain implementation for Godot so far is a plugin - https://tokisan.com/terrain3d/
Hell, maybe also contribute to lesser known engines if you feel like it: like jMonkeyEngine, Flax (it's great, like a lightweight and 3D oriented Unity / Unreal with a footprint closer to Godot and a nice C# integration), Stride and others.
I’ve been working in the games industry as a programmer for 21 years and I’ve seen this so many times. I also used to see it on gamedev.net and flipcode.com. Very technical people, engine programmers, think they can make a game and seem to think that all it takes is an engine and don’t even think about the game part. They tinker endlessly with file formats, memory allocators, vector math libraries, pooled string classes, etc and never finish anything when they could have just used json and png files and actually shipped something. On PC for the scale of game most indie developers will make all of that stuff isn’t really necessary. And if you find it is necessary then you can refactor later.
The idea that the layer above your own is trivial to build (e.g. biology is just chemistry, or chemistry is just applied physics)
At some point I built a little 2d game engine, but the same amount of time would have been better served actually building a game in Unity. Eventually I solo developed a full 3d VR app for the MetaQuest.
I'm out of the industry now, but I kept doing this for a while. I would want to "scratch an itch" and build a game out of hours. After a few attempts I realised I don't actually want to build a game, I want to build an engine
A few months ago he posted a video where he realized his motivation behind the curse of the Eternal Enginedev: "I thought if I could just make a really good engine, making a game would be the easy part."
I had a related realization recently... I realized I had taken my "prototyping mindset" into a production project, and that was a very bad idea. (Wasted an enormous amount of time, could have finished way sooner.)
So, first of all, I need an outlet for creative and experimental stuff (R&D Division), to get it out of my system! And second, the production project isn't the right place for that. (At least, not on the level of tech and infra.)
I think that's basically what John Cleese was getting at with the Open/Closed Mode thing:
For many people sure. There is also the path of “just build a game” with no distinction between the game and the engine. Super Mario 64 doesn’t have a game engine. For the first few months it was just “catch the bunny”.
There's a game version of the Whorf hypothesis; the engine limits the kinds of games that are thinkable. Unless you are the kind of person that has shipped your own engine, you probably don't even realize the thousands of little decisions that are forced on you. Which is why so many games look and play exactly the same.
According to my research, Steam success is somewhat correlated with making your own engine. Novelty and standing out from the crowd are the things that sell your game. It's a lot harder to do new things if what you can think is limited by your infrastructure.
Still, don't build your own engine. Build your game; the engine comes out of that.
> the engine limits the kinds of games that are thinkable.
Does anyone actually do that?
Most people just sit around thinking things up, and only later are they sobered to the fact of how much work it would be to implement a niche feature that isn't a substantial part of the game.
> Which is why so many games look and play exactly the same.
I'd argue that 90% of that is caused by default shaders.
It's why people complain about "unreal engine sheen" it's how most of the materials get set up for you if you don't care to change it.
The other 9% is default character controllers for the same reasons.
1% or less is going to be caused by some unalienable quirk of the engine that can never change.
> Steam success is somewhat correlated with making your own engine. Novelty and standing out from the crowd are the things that sell your game.
Successful games often have novelty and stand out.
But there's an aspect of survivor bias.
Probably plenty of games that are novel or stand out in all the wrong ways.
It's also not clear that making your own engine causes novelty or you to stand out.
> It's a lot harder to do new things if what you can think is limited by your infrastructure.
Again, not convinced that's the way people go.
Maybe they try to implement it and it's clunky, or doesn't scale, or trashes performance.
So they scale it back, rework it, or write some custom code.
An engine isn't magic, any amount of code you have to write to implement a feature is less than a whole new engine.
Would Balatro have been a better game if it had a completely bespoke rendering pipeline?
I'd say probably not.
> the engine limits the kinds of games that are thinkable. [...] You probably don't even realize the thousands of little decisions that are forced on you
Well, if Im not aware of those decisions forced upon me. I doubt they are affecting what I think is possible to do in the engine, as I'm not aware of the limitations in the first place.
I understand that making a game engine is often at odds with actually making a game, but does anyone know of good literature on building one from scratch? Ideally something like crafting interpreters but for an engine. It’s been on my list for quite a while.
As a hobbyist, I also dislike how standardized the notion of a “game” has become. The big name engines feed into this with the biases built into them to help facilitate making these sorts of games, and then the notion of an “engine” gets similarly restricted. But a game can be any sort of joyous program.
Where do you put modular engine/framework hybrids like Bevy? It owns the game loop so it's technically an engine but you can swap out just about every part of it, even rendering and window management. Tiny Glade only used the core ECS with every other part being custom.
The thing about game engines is that 80%+ of engine developers time is spent on designing tools and a checkbox/slider for you to click. Another 15% is spent on conflits when combining featured. Less than 5% of the time is invested in actual engine features. In raw homegrown engines, you call a function to enable the feature you want. Your 5% time matches commercial engine 5% time. You dont gain much if you know what you are doing. If you dont know what you are doing, well …
Yes but to be fair the vast majority of custom game engines I've seen never even as far as to have a single working game written with them, even by the author. Having a game engine and a "demo" is an accomplishment in and of itself.
That graph isn't 13% "make their own game engine." It is 13% as "other." There are a LOT of other game engines out there. Very, very few games roll their own.
These categories add up to 100%. Where do the engines that are not "custom" (e.g. by the developer who made the game), or the major ones listed fit in?
There is a valuable point in what you are saying, but I don't think it is as strong as you are making it. Game engines do have a certain 'style' that is recognizable, especially if you use default settings and cookie cutter stuff from the asset store. The most successful indie games often have their own unique aesthetic, and rolling their own game engine, while not strictly necessary, does make that uniqueness the default outcome rather than something you have to strive hard to achieve.
But most indie games do not roll their own engine. Even this widely shared post aiming to show off games with custom engines, ends up listing a ton of games with notes like "OGRE-based" or "MonoGame-based." I'm sorry, but that's not a custom engine. That's an atypical engine choice (OGRE or MonoGame) with tweaks. Maybe I'm being a pedant, but I think the difference matters.
Unfortunately I don't think there are good numbers on how many truly original / custom / no-engine games are out there, in absolute or market terms. 13% is the ceiling, but I wouldn't be surprised if it was much smaller (e.g. <5%).
You compared a full-on 3D renderer to something that's basically the same as SDL or Raylib. Ogre could be considered a game engine but XNA/Monogame definitely isn't (nor is SDL or Raylib).
> But most indie games do not roll their own engine.
Most indie games are slop that are barely more than a template with pre-purchased assets and sell zero copies. There's no point talking about most of something when 99% gets thrown straight into the garbage.
> The most successful indie games often have their own unique aesthetic, and rolling their own game engine, while not strictly necessary, does make that uniqueness the default outcome rather than something you have to strive hard to achieve.
Yup and that's the point. Code is art as much as art is art. Sure, you can get a basic game made in a couple hours with Godot, but what's the value or uniqueness when anyone can do the same?
How is MonoGame not a game engine? It handles graphics, input, main loop, etc. You can write simple games in a few hundred lines of code, just loading and game logic. Perhaps we're taking past each other.
Game engines typically provide a LOT more than Monogame. For example, an editor, 3D renderer, scenegraph, etc... Monogame and Raylib do a tiny bit more than, say, SDL, but neither does anywhere close to as much as Unity, Unreal, Ogre, Filament, JMonkey, etc...
Seems like the industry is redefining terms since I was last involved in the 00's. Game engine used to mean the runtime that manages game state, the framework that you code your game against that handles common things that aren't specific to a single game. Editors used to be surrounding infrastructure.
> Game engine used to mean the runtime that manages game state,
Yeah Monogame doesn't do that.
Pretty much every definition of framework vs game engine puts Monogame, SDL, Raylib, SFML, libGDX, LÖVE2D, etc... in the framework category. Engines are Unity, Unreal, Godot, Defold, O3DE, etc...
It really depends on your needs I guess. Not to undermine them in any fashion but If you just need some generic features and get something out quick, a pre-built engine can take a lot of the head ache out of it. I'm thinking stuff like last years 'Skate Story', built by one guy over a few years and it looks great, all done in Unity. If they were building their own engine it probably would still be another few years back and probably for not much gain.
But then things like Fez as you mentioned, back in 2012 when it came out, it would have been a real struggle to put together with off the shelf engines. I could see it being much easier now but still a product of its time.
One studio I am endlessly impressed with is Enhance games. Tetris Effect (UE4),Rez Infinite (UE4), Humanity (Unity) and Lumines Arise (Unity). When you fire them up, you would be really hard pressed to know what engine they are running as they have made the end results so unique that the base engines traits are almost completely gone. That is a real talent.
But if you have some unique tech that just needs to see the light of day or a work p=flow that just doesn't fit what everyone else is providing, go with your own engine. There will never be a one size fits all.
> It really depends on your needs I guess. Not to undermine them in any fashion but If you just need some generic features and get something out quick, a pre-built engine can take a lot of the head ache out of it. I'm thinking stuff like last years 'Skate Story', built by one guy over a few years and it looks great, all done in Unity. If they were building their own engine it probably would still be another few years back and probably for not much gain.
I'm not necessarily making any judgement about what someone should do. Rolling your own engine for a story based game is probably a bad use of time. But the idea that few successful indies have rolled their own is false.
I agree - if you're just doing something that needs some assets placed, some interactions, rendering, some physics, use an off the shelf engine. But the idea that it's impossible or not worthwhile to roll your own is repeated too much.
Isn't this survivorship bias? How many were successful in contrast that just used an off the shelf engine?
Regarding Source, Unreal, etc, that was back in the day when making an engine was much easier than today, due to lower player and graphics demands, which they then iterated on.
> that was back in the day when making an engine was much easier than today
I don't know specifically about how creating game engines was back in the day with lower level languages, but I can hardly imagine it was easier than today. I don't know of many things that are harder today than ~30 years ago when I first touched a computer, everything seemingly is getting easier and easier. Especially creating games, and for sure creating game engines. I'm not complaining, I'm loving the Cambrian explosion of games and especially indie games, but I do think we're seeing more and more games and game engines being made because it is easier today, not harder.
> How many were successful in contrast that just used an off the shelf engine?
Yeah there's successful games that used an off the shelf engine but saying very few roll there own is plainly wrong when a bunch have. And that's without mentioning the whole flash era...
Around 18k indie games are released on steam per year.
Around 300 of those are successful, making over $1 million [1]. VERY few of those successes are using custom engines. Your list is probably close to complete, being far less than 1%.
I have a whole theory on this I call design innovation through technical innovation.
If you want to do something no one has done artistically, it helps if you're also doing something no one has done technically.
And novel designs stand out. It's no coincidence how many of those wildly successful games introduce totally new game designs, only made possible through their totally new game engines.
A lot of those games definitely get some of their unique game feel from their engine, but The Witness in particular is a type of game that really wouldn't need it in 2026. It's a product of both it's time and it's creator's unique strong feelings for programming languages, game engines, and game development.
Well, to be pedantic, Stardew Valley + others used MonoGame which is technically a framework but realistically does a huge amount of the work needed to develop a game engine.
> Except a ton of successful indie games, including some of the best of all time
True. A lot of successful indie games are built in a custom engine. But that doesn't imply that all successful indie games need to be built on a custom engine or that someone is going to have more success by going the custom engine route.
The best of all time is a bar quite high. Success is already a few rungs down the ladder.
The simple reason that a lot of the games made without a custom engine don't sell is because they're simply turds. Games don't sell based on what engine they were made in. Games sell because they're good games.
Still bitterly disappointed that the upcoming sequel to Cyberpunk 2077 will no longer be on their in-house engine. There's something innately charming about the unique brand of jank that comes with doing it all in-house. See also: Skyrim/Creation Engine in general.
Yes a custom engine gives the game a unique look and feel, but it's also expensive. In fact, if Cyberpunk 2077 had used an off the shelf engine, it probably wouldn't have had such a buggy launch.
> it probably wouldn't have had such a buggy launch.
Things like that don't happen because of merely technical problems, "buggy launches" happen because of organizational issues, and those happen regardless of what engine you base your game on.
I agree. But the engine is a complex part of the game, and if you outsource it to a different organization you reduce the effect of your own organizational issues on the game.
The Bethesda Morrowind-onward RPGs had their engine roots in Gamebyro, which was fairly widely used by other developers as well. That said I think there's a question about where the value comes from, as their customization to it 25+ years ago and what it enables their game/toolkit to do has clearly given them a 'special sauce' that hasn't been replicated.
Also upthread Source was mentioned which has id's Quakeworld/Q2 engine as an ancestor, via HL1 GoldSrc.
I'm reminded of the story of Randy, that I watched unfold over quite a few months - he couldn't help himself but to work on new features, rewriting existing features, hacking to make his workflow better, but really struggled to release anything, like a form of bikeshedding where you are actually still productive, except what you produce doesn't seem to meaningfully get you closer to shipping at all.
The videos that document the journey probably haven't gone anywhere:
https://www.youtube.com/@randyprime/videos
https://www.youtube.com/@randyprime2/videos
If you want to make an engine and learn about making engines - make an engine.
If you want to ship a game - think long and hard about whether an off-the-shelf engine wouldn't be a better investment of your time (because you wouldn't invest hundreds or thousands of hours making something bespoke and could actually make the features you need within an existing engine).
I suspect that with the great FOSS and source available engines we have, like Godot, there will be plugins for msot things and folks will be able to make their own without having to start from scratch (unless they really want to), like the most competent terrain implementation for Godot so far is a plugin - https://tokisan.com/terrain3d/
Hell, maybe also contribute to lesser known engines if you feel like it: like jMonkeyEngine, Flax (it's great, like a lightweight and 3D oriented Unity / Unreal with a footprint closer to Godot and a nice C# integration), Stride and others.
I’ve been working in the games industry as a programmer for 21 years and I’ve seen this so many times. I also used to see it on gamedev.net and flipcode.com. Very technical people, engine programmers, think they can make a game and seem to think that all it takes is an engine and don’t even think about the game part. They tinker endlessly with file formats, memory allocators, vector math libraries, pooled string classes, etc and never finish anything when they could have just used json and png files and actually shipped something. On PC for the scale of game most indie developers will make all of that stuff isn’t really necessary. And if you find it is necessary then you can refactor later.
This is the infamous "stack fallacy" https://techcrunch.com/2016/01/18/why-big-companies-keep-fai...
The idea that the layer above your own is trivial to build (e.g. biology is just chemistry, or chemistry is just applied physics)
At some point I built a little 2d game engine, but the same amount of time would have been better served actually building a game in Unity. Eventually I solo developed a full 3d VR app for the MetaQuest.
I'm out of the industry now, but I kept doing this for a while. I would want to "scratch an itch" and build a game out of hours. After a few attempts I realised I don't actually want to build a game, I want to build an engine
A few months ago he posted a video where he realized his motivation behind the curse of the Eternal Enginedev: "I thought if I could just make a really good engine, making a game would be the easy part."
Edit: Found it!
https://www.youtube.com/watch?v=3kzNiMMnT4U
---
I had a related realization recently... I realized I had taken my "prototyping mindset" into a production project, and that was a very bad idea. (Wasted an enormous amount of time, could have finished way sooner.)
So, first of all, I need an outlet for creative and experimental stuff (R&D Division), to get it out of my system! And second, the production project isn't the right place for that. (At least, not on the level of tech and infra.)
I think that's basically what John Cleese was getting at with the Open/Closed Mode thing:
https://www.youtube.com/watch?v=Pb5oIIPO62g
For many people sure. There is also the path of “just build a game” with no distinction between the game and the engine. Super Mario 64 doesn’t have a game engine. For the first few months it was just “catch the bunny”.
There's a game version of the Whorf hypothesis; the engine limits the kinds of games that are thinkable. Unless you are the kind of person that has shipped your own engine, you probably don't even realize the thousands of little decisions that are forced on you. Which is why so many games look and play exactly the same.
According to my research, Steam success is somewhat correlated with making your own engine. Novelty and standing out from the crowd are the things that sell your game. It's a lot harder to do new things if what you can think is limited by your infrastructure.
Still, don't build your own engine. Build your game; the engine comes out of that.
> the engine limits the kinds of games that are thinkable.
Does anyone actually do that? Most people just sit around thinking things up, and only later are they sobered to the fact of how much work it would be to implement a niche feature that isn't a substantial part of the game.
> Which is why so many games look and play exactly the same.
I'd argue that 90% of that is caused by default shaders. It's why people complain about "unreal engine sheen" it's how most of the materials get set up for you if you don't care to change it. The other 9% is default character controllers for the same reasons. 1% or less is going to be caused by some unalienable quirk of the engine that can never change.
> Steam success is somewhat correlated with making your own engine. Novelty and standing out from the crowd are the things that sell your game.
Successful games often have novelty and stand out. But there's an aspect of survivor bias. Probably plenty of games that are novel or stand out in all the wrong ways. It's also not clear that making your own engine causes novelty or you to stand out.
> It's a lot harder to do new things if what you can think is limited by your infrastructure.
Again, not convinced that's the way people go. Maybe they try to implement it and it's clunky, or doesn't scale, or trashes performance. So they scale it back, rework it, or write some custom code. An engine isn't magic, any amount of code you have to write to implement a feature is less than a whole new engine. Would Balatro have been a better game if it had a completely bespoke rendering pipeline? I'd say probably not.
> the engine limits the kinds of games that are thinkable. [...] You probably don't even realize the thousands of little decisions that are forced on you
Well, if Im not aware of those decisions forced upon me. I doubt they are affecting what I think is possible to do in the engine, as I'm not aware of the limitations in the first place.
The lack of awareness is the whole point of the argument.
I understand that making a game engine is often at odds with actually making a game, but does anyone know of good literature on building one from scratch? Ideally something like crafting interpreters but for an engine. It’s been on my list for quite a while.
As a hobbyist, I also dislike how standardized the notion of a “game” has become. The big name engines feed into this with the biases built into them to help facilitate making these sorts of games, and then the notion of an “engine” gets similarly restricted. But a game can be any sort of joyous program.
Where do you put modular engine/framework hybrids like Bevy? It owns the game loop so it's technically an engine but you can swap out just about every part of it, even rendering and window management. Tiny Glade only used the core ECS with every other part being custom.
Framework, Bevy is definitely not an engine.
Does it do one thing? It's probably a library.
Is it a collection of libraries that work together focusing on primitives with callbacks? It's probably a framework.
Does it load levels? Have its own schema for an entity? Provide a multiplayer server protocol, and build on primitives? It's probably an engine.
Libraries -> frameworks -> engines -> games.
Bevy is very much an engine. It's an just an engine without an editor.
A really, really well designed engine is just going to be a library of highly modular components with a nice editor or two thrown in.
As the old adage goes "Build libraries not frameworks"
Bevy is definitely an engine. An extremely modular one. I'm currently building a game with it right now and having a blast.
The thing about game engines is that 80%+ of engine developers time is spent on designing tools and a checkbox/slider for you to click. Another 15% is spent on conflits when combining featured. Less than 5% of the time is invested in actual engine features. In raw homegrown engines, you call a function to enable the feature you want. Your 5% time matches commercial engine 5% time. You dont gain much if you know what you are doing. If you dont know what you are doing, well …
Game developers who find themselves writing a game engine are no longer writing a game, they are writing a demo for their game engine.
Yes but to be fair the vast majority of custom game engines I've seen never even as far as to have a single working game written with them, even by the author. Having a game engine and a "demo" is an accomplishment in and of itself.
That graph isn't 13% "make their own game engine." It is 13% as "other." There are a LOT of other game engines out there. Very, very few games roll their own.
If you look at the actual source linked in the article it contridicts you.
"Other" in that document means custom game engines.
From the source: 'Vast majority of “other” engines are custom game engines'. They don't justify that claim. They just assert other ~= custom.
These categories add up to 100%. Where do the engines that are not "custom" (e.g. by the developer who made the game), or the major ones listed fit in?
> Very, very few games roll their own
Except a ton of successful indie games, including some of the best of all time:
Minecraft, Braid, the Witness, Dwarf Fortress, Stardew Valley, Terraria, Fez, Animal Well, and probably a bunch I haven't heard of or forgot.
Also most AAA studios and a lot of AA studios.
Most game engines were also born out of a game. Source, Unreal, IDTech all were games first, then the engine was extracted.
There is a valuable point in what you are saying, but I don't think it is as strong as you are making it. Game engines do have a certain 'style' that is recognizable, especially if you use default settings and cookie cutter stuff from the asset store. The most successful indie games often have their own unique aesthetic, and rolling their own game engine, while not strictly necessary, does make that uniqueness the default outcome rather than something you have to strive hard to achieve.
But most indie games do not roll their own engine. Even this widely shared post aiming to show off games with custom engines, ends up listing a ton of games with notes like "OGRE-based" or "MonoGame-based." I'm sorry, but that's not a custom engine. That's an atypical engine choice (OGRE or MonoGame) with tweaks. Maybe I'm being a pedant, but I think the difference matters.
https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0...
Unfortunately I don't think there are good numbers on how many truly original / custom / no-engine games are out there, in absolute or market terms. 13% is the ceiling, but I wouldn't be surprised if it was much smaller (e.g. <5%).
> "OGRE-based" or "MonoGame-based."
You compared a full-on 3D renderer to something that's basically the same as SDL or Raylib. Ogre could be considered a game engine but XNA/Monogame definitely isn't (nor is SDL or Raylib).
> But most indie games do not roll their own engine.
Most indie games are slop that are barely more than a template with pre-purchased assets and sell zero copies. There's no point talking about most of something when 99% gets thrown straight into the garbage.
> The most successful indie games often have their own unique aesthetic, and rolling their own game engine, while not strictly necessary, does make that uniqueness the default outcome rather than something you have to strive hard to achieve.
Yup and that's the point. Code is art as much as art is art. Sure, you can get a basic game made in a couple hours with Godot, but what's the value or uniqueness when anyone can do the same?
How is MonoGame not a game engine? It handles graphics, input, main loop, etc. You can write simple games in a few hundred lines of code, just loading and game logic. Perhaps we're taking past each other.
> It handles graphics, input, main loop, etc
It kinda doesn't though
What it provides is the tools to build on top of to make those things yourself
Game engines typically provide a LOT more than Monogame. For example, an editor, 3D renderer, scenegraph, etc... Monogame and Raylib do a tiny bit more than, say, SDL, but neither does anywhere close to as much as Unity, Unreal, Ogre, Filament, JMonkey, etc...
Seems like the industry is redefining terms since I was last involved in the 00's. Game engine used to mean the runtime that manages game state, the framework that you code your game against that handles common things that aren't specific to a single game. Editors used to be surrounding infrastructure.
> Game engine used to mean the runtime that manages game state,
Yeah Monogame doesn't do that.
Pretty much every definition of framework vs game engine puts Monogame, SDL, Raylib, SFML, libGDX, LÖVE2D, etc... in the framework category. Engines are Unity, Unreal, Godot, Defold, O3DE, etc...
> most are slop
Is there any chance they meant most "real" indie games? If they did, does the observation about chances of rolling one's own engine change?
It really depends on your needs I guess. Not to undermine them in any fashion but If you just need some generic features and get something out quick, a pre-built engine can take a lot of the head ache out of it. I'm thinking stuff like last years 'Skate Story', built by one guy over a few years and it looks great, all done in Unity. If they were building their own engine it probably would still be another few years back and probably for not much gain.
But then things like Fez as you mentioned, back in 2012 when it came out, it would have been a real struggle to put together with off the shelf engines. I could see it being much easier now but still a product of its time.
One studio I am endlessly impressed with is Enhance games. Tetris Effect (UE4),Rez Infinite (UE4), Humanity (Unity) and Lumines Arise (Unity). When you fire them up, you would be really hard pressed to know what engine they are running as they have made the end results so unique that the base engines traits are almost completely gone. That is a real talent.
But if you have some unique tech that just needs to see the light of day or a work p=flow that just doesn't fit what everyone else is providing, go with your own engine. There will never be a one size fits all.
> It really depends on your needs I guess. Not to undermine them in any fashion but If you just need some generic features and get something out quick, a pre-built engine can take a lot of the head ache out of it. I'm thinking stuff like last years 'Skate Story', built by one guy over a few years and it looks great, all done in Unity. If they were building their own engine it probably would still be another few years back and probably for not much gain.
I'm not necessarily making any judgement about what someone should do. Rolling your own engine for a story based game is probably a bad use of time. But the idea that few successful indies have rolled their own is false.
I agree - if you're just doing something that needs some assets placed, some interactions, rendering, some physics, use an off the shelf engine. But the idea that it's impossible or not worthwhile to roll your own is repeated too much.
Isn't this survivorship bias? How many were successful in contrast that just used an off the shelf engine?
Regarding Source, Unreal, etc, that was back in the day when making an engine was much easier than today, due to lower player and graphics demands, which they then iterated on.
> that was back in the day when making an engine was much easier than today
I don't know specifically about how creating game engines was back in the day with lower level languages, but I can hardly imagine it was easier than today. I don't know of many things that are harder today than ~30 years ago when I first touched a computer, everything seemingly is getting easier and easier. Especially creating games, and for sure creating game engines. I'm not complaining, I'm loving the Cambrian explosion of games and especially indie games, but I do think we're seeing more and more games and game engines being made because it is easier today, not harder.
> How many were successful in contrast that just used an off the shelf engine?
Yeah there's successful games that used an off the shelf engine but saying very few roll there own is plainly wrong when a bunch have. And that's without mentioning the whole flash era...
Around 18k indie games are released on steam per year.
Around 300 of those are successful, making over $1 million [1]. VERY few of those successes are using custom engines. Your list is probably close to complete, being far less than 1%.
[1] https://www.shanethegamer.com/research/indie-games-statistic...
I have a whole theory on this I call design innovation through technical innovation.
If you want to do something no one has done artistically, it helps if you're also doing something no one has done technically.
And novel designs stand out. It's no coincidence how many of those wildly successful games introduce totally new game designs, only made possible through their totally new game engines.
Factorio is a good example of a game that probably wouldn't exist in the form that it does without a custom engine.
A lot of those games definitely get some of their unique game feel from their engine, but The Witness in particular is a type of game that really wouldn't need it in 2026. It's a product of both it's time and it's creator's unique strong feelings for programming languages, game engines, and game development.
Yeah it's kind of ironic that the Witness and his new Sokoban game don't really need custom technology.
Well, to be pedantic, Stardew Valley + others used MonoGame which is technically a framework but realistically does a huge amount of the work needed to develop a game engine.
Source is based on the Quake engine. A lot of those AAA games you're thinking probably are.
> Except a ton of successful indie games, including some of the best of all time
True. A lot of successful indie games are built in a custom engine. But that doesn't imply that all successful indie games need to be built on a custom engine or that someone is going to have more success by going the custom engine route.
The best of all time is a bar quite high. Success is already a few rungs down the ladder.
The simple reason that a lot of the games made without a custom engine don't sell is because they're simply turds. Games don't sell based on what engine they were made in. Games sell because they're good games.
This is why the custom engine over the last 6 years I've contribute to `godot engine` is more widely used and I haven't finished my game.
I reject this theme, I gained but I also lost.
Still bitterly disappointed that the upcoming sequel to Cyberpunk 2077 will no longer be on their in-house engine. There's something innately charming about the unique brand of jank that comes with doing it all in-house. See also: Skyrim/Creation Engine in general.
Yes a custom engine gives the game a unique look and feel, but it's also expensive. In fact, if Cyberpunk 2077 had used an off the shelf engine, it probably wouldn't have had such a buggy launch.
> it probably wouldn't have had such a buggy launch.
Things like that don't happen because of merely technical problems, "buggy launches" happen because of organizational issues, and those happen regardless of what engine you base your game on.
I agree. But the engine is a complex part of the game, and if you outsource it to a different organization you reduce the effect of your own organizational issues on the game.
Bollocks.
Probably is doing heavy lifting here
The Bethesda Morrowind-onward RPGs had their engine roots in Gamebyro, which was fairly widely used by other developers as well. That said I think there's a question about where the value comes from, as their customization to it 25+ years ago and what it enables their game/toolkit to do has clearly given them a 'special sauce' that hasn't been replicated.
Also upthread Source was mentioned which has id's Quakeworld/Q2 engine as an ancestor, via HL1 GoldSrc.
You do it because it's fun. Then you win, even if you lose!
This also applies to everything else in life.