Depends entirely on what you want to do. Use a bog standard engine, and you get Satisfactory. If you build your own, you can have Factorio. The former will never reach the sort of simulation complexity the latter can even on modest hardware.
> The former will never reach the sort of simulation complexity the latter can even on modest hardware.
You're comparing games rather than engines here. There is no reason at all that you can't write your simulation logic in vanilla bare bones C++ as factorio has done, and still get the benefit of using an existing engine. You get all the neat (and hard) things like serialisation, multiplatform support, networking, asset management, patching, and a bunch of other things. Sure, factorio may not need a 3d renderer, but it definitely needs and uses the rest of what I listed above.
But you'll always be fighting the engine, because these kinds of "one size fits all" engines are complex enough to be essentially another operating system above the one you'd otherwise be dealing with. As long as your desires are well aligned with the abstractions it presents it will probably save you time, but the more you drift from that the less time it will save you and eventually there's a point where dealing with it costs more time than it saves.
For the level of performance the Factorio devs want it makes sense they'd opt for maximum control over everything rather than fighting someone else's implementations.
The problem is you can't deal with the number of entities factorio regularly does on a stock engine. They just aren't made to deal with hundreds of millions of stateful and non-trivially interacting entities. That's not what game engines are built optimized for.
I think you're underestimating what can be done with the industry standard engines. From a rendering perspective modern game engines can handle so much stuff that it will fill your screen entirely. Just look at UE5's Nanite which supports ridiculously massive scenes and splits the frame into roughly pixel-sized triangles to render at interactive frame rates.
If you do end up in a situations where you have more objects than is suitable for even these systems to simulate you don't need to throw the baby out with the bath water. Create your own managers running whatever simulation you wish without tying the units directly to the most obvious game engine entities, with whatever scheduling you need to make the updates work with the compute budget you have. Use the engine entities to represent whatever higher level object makes the code manageable and easy to work with.
Then you can surely leverage the game engine for input handling, rendering, and a lot of your logic, just writing your own code for whatever challenges are unique to your game and where the standard approach for that engine is unsuitable.
Just because you're using unreal doesn't mean you need to have one actor per entity (for example). Using [0] as an example, there's no reason you can't implement a cache optimized simulation algorithm in C++ and pass the results out to UE4 instead of whatever layer factorio is using.
To be fair, factorio is a pretty good example of when the existing options offer limited value (lock step networking, _very_ simplistic rendering, very little in the vein of "gameplay" features), but it's one of very very few. For every factorio, there's 100 2d side scrollin platforms that are written in a custom C++ engine rather than using unity.
Reimplementing all of the features that unity provides for you is time spent on "just" adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations, when you could have been building a game. I can spend a month building a bare bones C++ engine that gives me all of the above and start into my game, or I can download unity, start with all of those features and spend a month working on my game.
Sure, and then deal with leaky abstractions and fighting the engine wherever its abstractions don't give you what you want.
> adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations
None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be. And there's value in having complete control over your product and understanding how every part of it works. You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.
I'm not saying it's the wrong choice to use a bespoke engine, indeed many games that are made with bespoke engines would not have been made otherwise and I'm grateful that such things exist and enable those games to be made, I'm just saying it's not necessarily a bad idea to make your own engine. Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.
> None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be.
I never said they were _hard_, but they take time. Time that can be spent on your game.
> You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.
Every system has bugs. You're always going to have to make tradeoffs when building projects, and building an entire framework from scratch to avoid those bugs is throwing the baby out with the bathwater. You're trading the possibility of at some point in the future being blocked from developing a very specific part of your game for the guarantee of spending time up front yak shaving.
> Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.
Blow has shipped two games in 20 years, and one of those (braid) predates _any_ of the existing engines being free and easily accessible. Another of the "build it from the ground up" camp is Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game. The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.
You say that like it is a bad thing. By (nearly) all accounts Braid and The Witness are lovingly and expertly crafted, unconventional, and brilliant games. He's not making the annual Madden or Call of Battlefield here.
> Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game
Be fair to Casey, Handmade Hero is primarily an educational project and he only devotes a few hours to it each week. Though admittedly he has allowed the scope to creep quite a bit from the original goals.
> The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.
My point is more that I'm kind of sick of people being so down on the concept of building your own engine even for relatively simple 2D games. Yes, I agree that it takes time, but so does learning the ins and outs of an existing engine and the time you invest in the latter nets you less generalizable skills than the former and leaves you with less control over the end product. It is a tradeoff, and like all tradeoffs there are good reasons to go one way or another.
