[shooly]

It sounds like you're talking about making an equivalent of Super Mario from the 80s, but modern games are in fact much more complex.

And no, just because people in the 80s enjoyed Super Mario doesn't mean it's the pinnacle of game design, and that there's no need to create anything more complex.

> It took less than a month of work for me to get a polished cross-platform system working on five platforms.

You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet. That is especially true regarding consoles with their custom hardware and mobile devices with their abundance of cheap, often not well engineered hardware and sketchy drivers.

[anonymous908213]

"Modern games" span a wide range of things. I develop solely 2D games, because I prefer 2D games over 3D games. I think that even today 2D games are more enjoyable than 3D games. That doesn't mean Super Mario Bros. That can mean Europa Universalis IV, it can mean Stardew Valley, it can mean Magic the Gathering Online, it can mean Hollow Knight, it can mean Slay the Spire, it can mean a huge variety of interesting and engaging games, none of which require 3D graphics. 2D games can be as complex as you'd like them to be, far more complex in game logic than a 3D shooter even. The more complex you'd like them to be, the easier it gets to implement them if you understand the primitives you're implementing them with. Imagine trying to optimize your data structures when you don't even know what an int32 is? There are real game developers in the world who don't know even that much. It is a great thing that off-the-shelf game engines provide a level of accessibility to allow anyone to develop games, but they do not represent the pinnacle of what can be achieved in software engineering. They are the exact opposite of it, in fact.

> You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet.

What is your point? I profile my games and have detailed logging systems. If I or my users run into performance issues, I address them as I come across them. Understanding my codebase at a low level makes it significantly easier to dig into problems and investigate underlying root causes than anyone on Unity will ever be able to. If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level. If they haven't, and you run into that issue in your game, you are completely fucked. I love being solely responsible for the defects in my games. That means I can fix them myself. The worst thing in the world in software development is when somebody else's fuck-up becomes your problem, and you can't fix it, so you have to implement some hacky workaround, if you can even figure out why the closed-source engine code you didn't write and can't read is behaving incorrectly to work around it in the first place. Sometimes that still happens anyways -- our hardware-OS stacks are built with tens or hundreds of millions of line of dogshit code, and you can't get around it if you want to create software for platforms people use, but you can at least remove as many dependencies on bad code you have no understanding of as possible.

[shooly]

> I address them as I come across them

You're already too late at that point, and you probably lost some players, that wanted to try your game and maybe would've even liked it.

And I'm not talking about gameplay logic bugs - I'm talking about issues caused by bad drivers or by not having intimate knowledge about the hardware.

> If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level

Most major engines allow to bypass high-level abstractions either through scripts that access low-level systems (Unity) or by directly letting people modify the source code (Unreal Engine, Godot).

> I love being solely responsible for the defects in my games.

Players do not care about that.

[anonymous908213]

> by directly letting people modify the source code (Unreal Engine, Godot).

Unreal is not open source, and while Godot is, I would wager 90% of its users never even look at the source code. It very specifically attracts people who want an easy way to make games without prior expertise.

> Players do not care about that.

Users don't care about much when it comes to software quality, honestly. They accept 20 FPS, slow loading, bug-riddled games that consume +20gb ram and +100gb more disk space than necessary. They may complain about a game if it gets bad enough, but they still buy and play those games. My games are significantly more optimized than most. They aren't perfect, but they don't need to be. They don't even need to be as optimized as I have made them, it's mostly just a point of pride and making the kind of software I want to see in the world. I think the only way you lose a player on technical points is if they literally cannot boot your game, but those issues plague engine games too. I had driver issues myself crashing on boot with an UE5 game two weeks ago.