5 ms·

If Unreal (natively) adopted C# that would absolutely be a killing blow to Unity, to the point where I'm amazed they haven't done it.

kevingadd 3y ago
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
- msk-lywenn 3y ago
  They gave UnrealCLR an epic megagrant. How can you say they "actively blocked it" ?
  - kevingadd 3y ago
    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)
matt3210 3y ago
[flagged]
- fnordpiglet 3y ago
  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.
  - whoisthemachine 3y ago
    > 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-0/ https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...
    - fnordpiglet 3y ago
      Oh thanks! I stand corrected. Good to see.
    - TylerE 3y ago
      But that does NOT include WinForms.
- Qwertious 3y ago
  Define "better language". If you don't need performance then C# can make your life much easier.
  - kroltan 3y ago
    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.
    - Thaxll 3y ago
      Famous last words, even with the optimization in the latests net core clr, it's nowhere close to C++.
      - sha90 3y ago
        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.
        neonsunset 3y ago
        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.
      - kevingadd 3y ago
        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.
- bilekas 3y ago
  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.
- sha90 3y ago
  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 recompiling and restarting a game can be incredibly slow.
  - fxtentacle 3y ago
    "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.
    - sha90 3y ago
      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.
- johnnyanmac 3y ago
  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)
mentos 3y ago
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 https://sbox.facepunch.com/news/dev-blog-2 Maybe ChatGPT6 can port the UE C++ codebase to C# and we can call it UE6
- bpye 3y ago
  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/ https://mono-ue.github.io/ [1] - https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...
  - kevingadd 3y ago
    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
    - Aerroon 3y ago
      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.
- Rohansi 3y ago
  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.
abrolhos 3y ago
>> [...] I'm amazed they haven't done it. Never interfere with an enemy while he’s in the process of destroying himself.
sBqQu3U0wH 3y ago
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.
dgellow 3y ago
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.
Kapura 3y ago
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.
- Auracle 3y ago
  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.
  - Kapura 3y ago
    I think if you used the modern Unreal Engine you would change your tune.
- Aerroon 3y ago
  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).
kriro 3y ago
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
- ummonk 3y ago
  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.
- Fire-Dragon-DoL 3y ago
  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.
kkukshtel 3y ago
I've been tracking this (Epic Megagrant awarded!) project for a while that attempts to do very much that: https://github.com/nxrighthere/UnrealCLR 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.
deleted 3y ago
[deleted]

kevingadd 3y ago

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

msk-lywenn 3y ago
They gave UnrealCLR an epic megagrant. How can you say they "actively blocked it" ?
- kevingadd 3y ago
  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)

matt3210 3y ago

[flagged]

fnordpiglet 3y ago
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.
- whoisthemachine 3y ago
  > 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-0/ https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...
  - fnordpiglet 3y ago
    Oh thanks! I stand corrected. Good to see.
  - TylerE 3y ago
    But that does NOT include WinForms.
Qwertious 3y ago
Define "better language". If you don't need performance then C# can make your life much easier.
- kroltan 3y ago
  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.
  - Thaxll 3y ago
    Famous last words, even with the optimization in the latests net core clr, it's nowhere close to C++.
    - sha90 3y ago
      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.
      - neonsunset 3y ago
        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.
    - kevingadd 3y ago
      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.
bilekas 3y ago
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.
sha90 3y ago
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 recompiling and restarting a game can be incredibly slow.
- fxtentacle 3y ago
  "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.
  - sha90 3y ago
    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.
johnnyanmac 3y ago
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)

mentos 3y ago

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 https://sbox.facepunch.com/news/dev-blog-2 Maybe ChatGPT6 can port the UE C++ codebase to C# and we can call it UE6

bpye 3y ago
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/ https://mono-ue.github.io/ [1] - https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...
- kevingadd 3y ago
  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
  - Aerroon 3y ago
    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.
Rohansi 3y ago
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.

abrolhos 3y ago

>> [...] I'm amazed they haven't done it. Never interfere with an enemy while he’s in the process of destroying himself.

sBqQu3U0wH 3y ago

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.

dgellow 3y ago

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.

Kapura 3y ago

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.

Auracle 3y ago
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.
- Kapura 3y ago
  I think if you used the modern Unreal Engine you would change your tune.
Aerroon 3y ago
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).

kriro 3y ago

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

ummonk 3y ago
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.
Fire-Dragon-DoL 3y ago
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.

kkukshtel 3y ago

I've been tracking this (Epic Megagrant awarded!) project for a while that attempts to do very much that: https://github.com/nxrighthere/UnrealCLR 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.

deleted 3y ago

[deleted]