Hacker News Reader

Comment by ImprobableTruth | Hacker News Reader

I'm a hobbyist who tried switching and really didn't like having to use C++ or blueprints.

Epic is working on a new language called verse though, so that might change the situation.

Why does every game engine seem to write their own language? Why not choose an existing one - in this case C# seems like an obvious choice because it's already used in another major game engine and seems to be well liked.

First of all, you need to understand that all current (serious) game engines primarily use C++, in order to provide maximum performance at the low-level. But C++ is incredibly unproductive as a language for actual high-level game development, since C++ takes ages to compile and has more weird and dangerous footguns than any other language. So developers often end up binding a scripting language onto their C++ core, so they can have fast development cycles and move fast. So even C# in Unity is just a scripting language binded onto the core C++ engine. The problem is that C# isn't a language intended for embedding, and you need a lot of effort to bind the two seamlessly.

When Unity started making their engine in the 2000s they had engineering troubles with integrating the Mono C# runtime into their engine, and eventually they needed to obtain a custom license from Morell to fork and modify to their liking (at the time Mono was the only C# runtime that supported other platforms like Mac OS and mobile, and it was dual licensed as LGPL/commercial). There were also myriad problems with this choice, including being stuck with an outdated version of the Mono runtime which they needed to relicense (at a hefty price) to upgrade, myriad issues with the very slow Boehm garbage collector, etc etc. Eventually Microsoft would buy Xamarin (the successor of Morell) and relicense Mono to the MIT license, which was a lifesaver for Unity since they could now update to the latest Mono runtime at no cost. Still they're kinda stuck with their initial decision of using the Mono runtime, and it seems ever unlikely that they're going to migrate to dotnet (which I've never heard any success of embedding with C++). So in conclusion, it took a lot of time for C# in Unity to be useable to the degree we're at now, and it's more of a special edge case of gamedev history than anything else. Most game engines use a much more easily embeddable scripting language such as Lua for good reason (or end up creating their own language!)

About the topic of why does every game engine seem to go the route of creating their own scripting language, I find the explanation of the Godot Engine devs very well written: https://docs.godotengine.org/en/3.0/about/faq.html#gdscript-... (Godot Engine tried integrating many other languages before deciding to write their own scripting language called GodotScript.)

>The problem is that C# isn't a language intended for embedding, and you need a lot of effort to bind the two seamlessly.

I don't think that it's actually very hard to do it, I've done it easily for Java and I think I remember doing it for c# as well: https://docs.microsoft.com/en-us/dotnet/core/tutorials/netco...

It's honestly just a few lines of C code that you point at some c#/java method and run it. The truth is probably that people want to invent their own languages for their own reasons, e.g to have full control. Personally I've never understood that which is why I know so much about language interop now. Embedding is even easier for various scripting languages. I've also done interop for Dart. I don't like Lua but I've also looked at how easy it is for that. Imo there is no justification for game engines not having a C API so that everyone can code in whatever language they prefer.

> https://docs.microsoft.com/en-us/dotnet/core/tutorials/netco...

Well that's something I've never heard of, seems like a pretty recent API. Though it doesn't explain how to call C++ functions from CLR (not the other way), which is the most tedious and error-prone part. It also doesn't explain how to expose foreign C++ objects to CLR either.

Isn't that just p/invoke?

Unity is currently working to make Unity compatible with .NET 6 / CoreCLR, but they don't yet have a release date for that yet. The progress is being tracked in this megathread:

https://forum.unity.com/threads/unity-future-net-development...

That's interesting. I think it will take quite some time though, it's going to be a monumental task.

I agree, it seems like a huge effort. But if they reach their ultimate goal of shipping an unmodified version of .NET, it seems like that work would pay off:

https://forum.unity.com/threads/unity-future-net-development...

It's also encouraging that they expect it to be less than two years out:

https://forum.unity.com/threads/unity-future-net-development...

> The problem is that C# isn't a language intended for embedding

It has always been intended for embedding, since netfx 1.0: https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-.... Microsoft used it for Office, MSSQL, and probably much more. Netcore has been trivially hostable since 3.0: https://docs.microsoft.com/en-us/dotnet/core/tutorials/netco.... Both can be done under 50 lines of code, that couldn't be further from "not intended for embedding."

You'd still need to export your internals to the CLR, but you'd have to do that with any embedded language anyway.

Actually since Burst and DOTS, Unity has been incrementally replacing C++ with C# Burst subset.

Burst is such an interesting project. The fact that, because they know what they are trying to do more than a c++ compiler really can due to the intended use cases, they can be more aggressive with optimizations like SIMD. I remember a talk where they were discussing replacing c++ code with the Burst stuff as you mentioned, and I recall the biggest reason being they could write more succinct code that kept the speed because they weren't having to convince the compiler to do a lot of optimizations they needed to keep it fast.

Agree. I was so happy when I heard they were introducing an intermediate language and so disappointed when I found out it was custom.

I'm back to being quietly hopeful though:

- Epic ships games and has internal game developers. They're probably not going to create something too dynamic or untyped that has issues scaling. - I was worried about coverage but then realised all of BP is generated from code annotations using the unreal header tool, and they've already done it for Python (I think? maybe just editor functions).

If it's just a textual replacement of blueprint that will be enough to make me so much more productive for gameplay programming.

Might be more likely it'll be used for player-generated-content and their metaverse push ala roblox though.

Verse isn't entirely a new language, it's actually them acquiring the team behind SkookumScript, as well as some external hires such as Haskell/Microsoft Research's SPJ.

Excited to give it a try when it releases, will be interesting. The syntax previewed was... different.

Thing is, it's not just having an approacheable/hireable language, its about the availability of tutorials, learning materials, community, and existing code. That takes a lot of time and its Unity's moat that Epic can't really replicate by creating yet another Unrealscript

You absolutely cannot use UE without ending up with C++, blueprint only shines with animation rigging, material, vfx where you need a lot of quick feedback loop by exploring possibilities.

Reply on news.ycombinator.com