You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game.
I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But instead of spending time on writing my own containers and memory allocation, I spend time writing game logic. Instead of optimizing game to run from 100 to 150 FPS on my computer, I'd rather spend this productive time making 5 variants of the same game mechanic to find out which is more fun. Even if the game runs in just 30 FPS.
Of course, I sometimes try to research low-level stuff, write my own renderer, or do a small experimental project in pure C, but then my goal is to research, not to write a game. I can hardly imagine a project, where the goal would be to develop a game, and not to research, where using C and having to spend so much time on this matters would be a good trade-off compared to working on actual game mechanics in higher-level language.
Unity is written in C. That the game logic is written in C# is hardly relevant as you explain. In fact this guy might still embed C# at some point if he wishes for his logic to be less painful to write.
The author states at the beginning that his goal is writing an engine and only after that write a game. You are right on all other points though, most people working on game engines simply never get to the making a game part. There's simply too much to do.
I spent a couple years' working together with a friend every now and then on a game+game engine in C#. We did get past the game engine phase because it was kept simple (ECS + box2d and simple monogame 3d renderer) but we eventually gave up because even though game logic was progressing swiftly assets were just a pain in the ass.
Most low level engineers (as we are/were) underestimate the work it requires to get a proper asset pipeline set up. You're never going to build a 3d game if you can't load cheap 3rd party assets with their animations and materials. And then the level designer which is basically just another game in your game.
We went with UE4 as a change of pace and man is it librating not to have to worry about the limitations of your homebrew engine anymore. In UE4 literally anything is possible (you have the full source after all) and its always less work.
I guess, my question to the author should've been: why are you trying to write a game engine? It's a completely different task than writing a good game, and mostly conflicts with it.
Two reasons: Creative interests which make traditional game engines a hard fit. I could make compromises to the design, but as I also have technical interest in making game engines, it's a double win.
The need for high performance meets with my creative interests. (But I also have technical interest in making the engine). I also value the ability of being able to implement extraordinary features to the engine in a whim, which is hard with large general use engines.
I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.
> I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.
This "class of games" includes more or less everything that a single developer without a very costly art department can produce. If your game can not be implemented with a prebuilt engine, it's really something extraordinary.
I think it's pretty clear from the article that using an off-the-shelf engine is not an option for the author, because it doesn't satisfy his interest in building game engines ;-)
That said, I agree with your previous comment about performance. Rarely, if ever, should using one programming language over another limit the performance of any game so much that it would severely affect what you can and can not do gameplay- or feature wise. Unless you use some highly dynamic scripting language that fundamentally doesn't fit the problem domain, of course (I wouldn't write a 3D engine in Python or Ruby, for example).
I can somewhat understand some of the other arguments of choosing C over C++ (primarily build times), but for the most part the problems the author has with C++ appear to be philosophical. You can have almost everything you want in C++, if you're prepared to use it differently depending on your requirements. In terms of performance, it really is true that optimization only pays off for small sections of your code, so it doesn't make any sense to switch languages for that. You can most definitely make an extremely efficient data-oriented entity-component system in C++ without going having to jump through any hoops, for example.
I don't personally think it matters all that much even on AAA games. Unreal has GC. Take a look at the games made in Unity. Plenty of AAA or close to AAA games. Cities Skylines, Firewatch, Ori and the Blind Forest, Pollen, Endless Legend.
I've written several game engines in the past. I hope to never do it again.
>Take a look at the games made in Unity. Plenty of AAA or close to AAA games. Cities Skylines, Firewatch, Ori and the Blind Forest, Pollen, Endless Legend.
I think we may have differing standards. I've only played one of those, Ori, and it had massive problems with long frames. Like, often, and sometimes even half a second long pauses during normal gameplay. I don't know if Unity is to blame for that, but that game is not a good argument in favor of it at least.
I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But instead of spending time on writing my own containers and memory allocation, I spend time writing game logic. Instead of optimizing game to run from 100 to 150 FPS on my computer, I'd rather spend this productive time making 5 variants of the same game mechanic to find out which is more fun. Even if the game runs in just 30 FPS.
Of course, I sometimes try to research low-level stuff, write my own renderer, or do a small experimental project in pure C, but then my goal is to research, not to write a game. I can hardly imagine a project, where the goal would be to develop a game, and not to research, where using C and having to spend so much time on this matters would be a good trade-off compared to working on actual game mechanics in higher-level language.