C++ is a much better language than c#, what’s your reasoning here?

Better is relative. And it's just a different type of tool. To be honest I know many more better engineers who primarily work with dotnet over CPP. The learning curve for CPP is higher because the ability to shoot yourself in the foot with CPP is higher. It's neither better or worse. Just a different tool in a toolbox.

I think a lot of people find the learning curve of c++ fairly extreme, especially when considering the amount of knowledge to do idiomatic programming in c++ required to “do things elegantly.” C# and related languages tend to have idioms baked in closer to the syntax and grammar. My view of c++ after 30 years of it is it’s great if you’ve got 10 years experience programming it within a team of seasoned c++ programmers who shows you the ropes. Even then I think rust is the language I wished for all these years (albeit not for game dev yet). Finally, for the reasons rust isn’t great for game dev, c# and ilk generally have excellent reflective and dynamic natures making them sort of the sweatpants and old T-shirt language for game programming.

That said, it locks you into using stuff like mono and stuff for cross platform which makes me a sad.

> That said, it locks you into using stuff like mono and stuff for cross platform which makes me a sad.

Microsoft's .Net Core runtime (now just .Net) has supported Linux and MacOS since 2016, so this information has been out of date for 7+ years.

https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...

Oh thanks! I stand corrected. Good to see.

But that does NOT include WinForms.

Define "better language". If you don't need performance then C# can make your life much easier.

The new versions of C# can compile ahead-of-time, and have expanding support for value types and pointer-like semantics, so you're not stuck with the Java-y OOP For Everything paradigm if it doesn't fit your requirements.

The standard libraries are still an allocation party, of course, but that can be supplemented in an engine context.

Famous last words, even with the optimization in the latests net core clr, it's nowhere close to C++.

Citation needed? Raw speed is likely similar; the cost overhead comes from GC cycles and the general approach to managing memory primarily in the heap vs stack, although C# can stackalloc if you're really diligent. Note that this is the same problem that blazing fast alternatives like Go have at competing with C/C++. These languages are mostly equivalent to C/C++ in speed, but lose the benchmark shootouts because of GC.

Calling Go blazing fast would be a stretch at best...the path to performance in C# is same as in Rust or C++: struct generics (aka templates), as short hot paths as possible, static partitioning of the work, sometimes hands on memory management and minimization of locking.

This is a pretty wild generalization to make. It's not hard to contrive scenarios where C++ with its notoriously slow stdlib (despised by game developers) is going to be slower than C# with its JIT doing runtime optimizations like guarded devirtualization.

C++ written by people who really good at writing fast C++ is faster than C#. Naive and readable C++ written by average programmers wanting to solve a problem in the obvious way on the whole isn't faster than C#

Keep in mind that in addition to the "learning curve" arguments, there is also the functional developer ergonomics of things like live reload (where you can maintain memory state) that are simply not possible to do with C++ without heavy limitations or customized tooling.

Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development where generating the right memory state can be incredibly complex and depend on a ton of very specific and hard-to-reproduce factors. Not to mention incredibly slow.

"Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development"

Visual Studio works with UE and calls that "Edit and Continue" and it works in C++, too.

Yes, but it has many known limitations and isn't nearly as reliable as a runtime that has a full GC and virtualization optionality, which you really need in order to fully track what state can be evicted and what needs to stay.

Game devs want fast iterations above everything else, with performance being a close second. c++'s "toolchain" makes those iterations prohibitively impossible, even with decades of workarounds with hot reloading and extravagant methods to keep compilation times down.

If you're a AAA dev you give up a lot of that iteration because performance overtakes you, but there's little reason some indie 2d platformer will want to deal with even 30 second iteration times (which would be blazing quick for a AAA setup). C# is a mature, familiar environment for devs with similar syntax to C++ that can get decent performance as long as you maintain some discipline (for starters, no LINQ)

I was super excited for Garry Newman's project to bring C# to UE but never transpired: https://sbox.facepunch.com/news/dev-blog-2

Maybe ChatGPT6 can port the UE C++ codebase to C# and we can call it UE6

There was also Mono UE [0] - which was being developed by some of the Xamarin folks.

I’ve not played around with any game development for a long while - does C# end up popular here just because people are familiar with Unity? I definitely get that C++ is not the most productive language - though improving perhaps.

Simply loading the .NET Core CLR is not difficult [1] - but unless things have changed since I last tried binding C++ interfaces to C# is time consuming, especially if you want to be able to implement an interface in managed code.

[0] - https://mono-ue.github.io/

[1] - https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...

Part of C#'s popularity with indies is due to the legacy of XNA. Thousands, probably tens or even hundreds of thousands of indies got started with XNA and released games using it, so it's natural to stay on C# whether you move to FNA, MonoGame, Unity or Godot

To add: C# is a language that is easy to pick up. If you've written Java then you could basically just start writing C#.

Probably even a C or C++ background would allow you to do that. Maybe even knowing js is enough.

S&box is still in progress and using C# but it is now using the Source 2 engine instead. You can actually get invoted to it on Steam and play/build games for it now too.

It previously used UE4 and C# integration was all working with that but, as soon as they found out that they could get access to Source 2, they took the opportunity. Makes sense because the team is significantly more experienced with the Source engine since most of them have previously worked on or with Garry's Mod.

JBMod 2 might be better, I hope fans of gmod unite and make Godot's Mod.

>> [...] I'm amazed they haven't done it.

Never interfere with an enemy while he’s in the process of destroying himself.

I don't mind C++, but can you delete the script file without closing the editor yet? It was such a turn off for me at the time that I abandoned all intentions of ever learning to use Unreal Engine.

Honestly, Unreal C++ isn’t that bad or hardcore. It’s fairly high level, and Unreal APIs are pretty well designed. You spend way more time dealing with Unreal specific stuff and your game objects than dealing with C++ issues.

I don't think that's true, and I don't think the juice would be worth the squeeze. Unreal's flavour of C++ is heavily managed, relying on preprocessing of header files to create garbage collecting pointers and a whole heap of other things you don't think you're signing up for when you think about a C++ codebase. There is no simple place to begin if you're trying to make it C# friendly.

But most of my issues have been with engine philosophy, where Unreal has bent over backwards to expose things to their visual scripting language. It feels like every single feature has a mandate to work in a blueprint tech demo, and as a result few of them are pleasant to code against and almost none of them work together coherently. These are not issues that depend on the language used.

C# being the deciding factor an incredibly common refrain in game development "what engine do you/should I use?"

Whether or not it's justified is another manner. I haven't personally dealt with the modern Unreal Engine but natively supporting C# would, at the very least, make people a lot more likely to switch over.

I think if you used the modern Unreal Engine you would change your tune.

I was surprised that Unreal Engine didn't just translate Blueprint directly into C++ code. They already have a text-based version of Blueprint. You can see it when you copy a blueprint graph and paste it into a text file (or at least you could when UE4 launched).

Disagree. Unity is pretty strong on mobile and multi-plattform. Enough to survive on this alone (imo). I also think Blueprints is already a strong competitor for the share of users who find C++ too complicated (non-programers and people who have only dabbled in scripting). I think for "traditional programers" the difference between C++ and C# isn't big enough to make a difference and frankly people with a gamedev background probably prefer C++.

That being said as a non mobile guy who occasionally dabbles in engine stuff I'll be migrating to Unreal for good now. I haven't been a paying customer for a while now but I used to pay for Unity back in the super early days of AR.

Or I guess take another serious look at Godot :D

Mobile is the kind of use case where the pricing changes will be massively impactful though. If you're selling a non-mobile game for $10+ then you can just eat the per-install fee, but if you're shipping a free to play app or a $1 app? The per install fee could make your business model nonviable.

I mean, knowing c++ and c#, I am always terrified about the former. There is an enormous set of things that shouldn't be touched and a whole set of gotchas in managing headers, writing macros, templates. Granted none of the two are used at my day to day job.

There was C# support for Unreal (contributed by the Mono maintainers) at one point but Epic actively blocked it. They want everyone on C++ and nothing else

[delayed]

the megagrant appears to have happened in 2020, the blocking of unreal C# happened years and years prior and put an end to development (community and otherwise) at the time (pre-2017, I don't know the exact date)

I've been tracking this (Epic Megagrant awarded!) project for a while that attempts to do very much that: https://github.com/nxrighthere/UnrealCLR

I'm also surprised though they haven't just gone and added C# support as a first class option, it seems like such an obvious win.