I'm not sure why you say it's a "quite safe" assumption that most games are written in C#. Unity's beginner-friendliness gives it a disproportionate presence online, while the vast majority of AAA games are still solidly C++.

If we eliminate all games with less than 1000 sales or something, I think it would be a very low confidence estimate.

I think perhaps they meant "most Unity games", where Unity was supposed to be implied by the context. It probably is safe to say most Unity games are C#, if we ignore the portion of the engine runtime that is written in C++, which makes sense for some metrics and not others.

> You'll have to search very long to find a C++ game code-base that uses boost, game devs are not that stupid ;)

Don't need to search, factorio used to use boost: https://factorio.com/blog/post/fff-223

The context here, from the top level comment, is AAA game companies and the developers working for them though. In that context, that and indie developer came to the same conclusion after a while is probably just more evidence for the original point.

In a larger studio, even if code sharing isn't common as is expressed here, at a minimum having someone around that sees boost and says "don't do that" is probably a given.

> You'll have to search very long to find a C++ game code-base that uses boost, game devs are not that stupid ;)

Boost has over 160 libraries and counting. I wouldn't recommend every one of them (some have wacky interfaces, slow compile times, and/or experimental designs), but many of them are excellent, and I don't think it's very difficult to tell them apart.

Regardless, I find your insinuation that Boost users are "stupid" to be extraordinarily uncharitable to library users and developers.

> Unity games are usually written in C#

That is true in the most literal sense, but Unity have adopted a programming model that makes much of the normal tooling around .NET useless, and abhors automated testing.

Adopting good testing practices in Unity still largely revolves around developing parts of your game as .NET libraries that get tested before being built and integrated into the game, and it's not too surprising that many developers don't go down this route.

I'm blaming C++ because :

- there is very little information in the community on how to do this kind of engineering efficiently (at least I haven't encountered it nearly as much as I have when I transitioned to application development in higher level languages) - there is very little code sharing in the community and zero standardisation - everyone reinvents shit from standard library, coding conventions, what subset of the language is "allowed", etc. etc. - this means developing good tooling, practices and patterns across large projects is hard

Unity is written in C++, C# is scripting layer and more importantly I doubt Unity developers doing C++ are C# engineers with C# application development background where stuff like automated testing is pretty standard.

> there is very little information in the community on how to do this kind of engineering efficiently

If you aren't a huge studio writing a AAA game or thereabouts in complexity you probably can't write a game engine efficiently.

The number of places that do have that scale and need help on how to be efficient is probably vanishingly small so not a lot of self help pops up.

> (at least I haven't encountered it nearly as much as I have when I transitioned to application development in higher level languages

Pick an engine and use its language whatever that is. Unity gives you C#. Unreal gives you a C++ dialet with some nice features and a blackboard system for scripting that is quite powerful.

> there is very little code sharing in the community and zero standardisation

From my experience there is little code sharing within a studio so expecting there to be code sharing across the entire community is hard.

Assuming you are looking for high performance (AAA) you basically have to write a bespoke engine for your gameplay. And there are a lot of different ways of doing gameplay. Heck whether you have loading zones or continuous loading makes a huge impact on how some fundamental things work (again if you aren't huge there are workarounds that make it easier to generalize in exchange for performance)

> everyone reinvents shit from standard library, coding conventions, what subset of the language is "allowed"

The standard library has some huge performance problems for video games. Mostly around allocation rules. Unsurprisingly algorithms for millions of things can have bad performance side effects on tens of things (and visa versa).

> this means developing good tooling, practices and patterns across large projects is hard

To be fair I think this is generally true. Games just tend to build up their codebases super fast but maintaining any huge code base is a pain in the best cases and it is never the best case.

>I think it's quite safe to say that - overall - most games are not written in C++ but in C#)

Not even close.