I would certainly hope not. C# implementations are terrible for lots of games on not-Windows. The version of Mono that has been included with Unity is particularly bad with respect to stop-the-world garbage collection pauses.
- As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.
- As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or "interop" layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.
- Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.
- Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can't trace the C++ that code led to it, and vice-versa.
I don't think so. If I remember it correctly, the Epic guys said something about switching back (for the Unreal Engine 4) from their own scripting language to C++, because multi language debugging was a nightmare, and working on a big Python/C++ project myself, I can comfirm this.
If you download VR games, all the ones I have seen so far - that give credit - have been done with Unity. I know ones made with Unreal are out there, I have not download any with the Unreal logo yet though.
I dabbled with the Daydream Google VR NDK C++ sample app and did a demo app for myself of simple shapes moving around. While I could do simple things, I couldn't imagine doing the type of games others have done on the platform (or Oculus, or Vive) without Unity. For most people the question will be, why reinvent the wheel?
I don't know if C# will be the lingua franca of modern game engines, but for the foreseeable future, I think it will be the lingua franca of VR.
I doubt it. C++ has been the standard for a long time now and what we're really talking about is scripting languages for higher-level stuff, not the actual game engine. On the one hand, yeah, C# is a good choice since Windows dominates the desktop market. But it's the sort of thing you can easily change and that users might have personal taste and preference for.
I went and looked up all the major game engines I could think of:
Blender: Python only
CryEngine: Lua and C#
Gamebryo: C++ only
Unity: C# and Java (Boo is no longer supported)
Unreal: C++ only (UnrealScript no longer supported)
Amazon Lumberyard: Lua (maybe C++ too?)
id Tech: C++
I was actually surprised at how common Lua was, but now that I think about it I have heard of it being used increasingly in games.
Why not use Lua, Squirrel or JavaScript as game programming language? Many game engines use one of these languages, especially Lua is very very popular in this niche, and LuaJIT is sooo fast. Also Java is used in several game engines. C# (Mono) was only used in Unity as one of three languages (one being JavaScript/Actionscript). What other well known game engines that are used for triple-A games use C#? We all know the troubles of Mono that meant for Unity for many years, they had to fork an old version due to draconic license changes - Mono was a bad choice for Unity. As triple-A games are developed for Windows7+ and PlayStation4 (and less often also macOS, Linux, XboxOne, Switch) usually cross platform languages like Lua, Javs, JavaScript or Squirrel are used.
We are talking about the game scripting language, the game engine is always coded in C++ for triple-A games, with only a handful outliers. It's different for indies. We all know how the "Managed DirectX" and the incompatibile successor XNA turned out, the C# DirectX community is dead, end of life and last supported on the old XBox360, dead like Silverlight https://en.m.wikipedia.org/wiki/Microsoft_XNA .
Even outside the engines available to us plebs C# is becoming extremely popular in game dev. It's basically ergonomic C++ so it's very familiar to the kind of people who do games for a living, the VM is world-beatingly fast, and it's an easy language to hire for. Most games companies use Windows anyway so the MS lock-in isn't so much of a downside (obviously C# isn't Windows-only now but it's still controlled by MS).
Nope. This project is using patched engine and easily could be in the same position as present Linux support (which is "Builds for, not working well").
> Is C# becoming the lingua franca of modern game engines?
Unfortunately. It's a decent language, but it just seems a bit too heavy to use as a scripting language, but not as good as C++ for heavy lifting.
I'm doing some stuff on Godot, and will probably just end up using GDScript for basic stuff, and GDNative for more intensive stuff (It's a C/C++ API for shared libraries that you can load up through the editor).
The lead for this project[1] recently gave a great talk[2] at .NET Fringe on some of the interesting things coming up for Mono. Definitely worth a watch.
A little bit unrelated, but serious question. Mono and .net core are not going to converge? I mean that would be awesome. Since most of game developers nagging about Mono's bad performance
They're not strictly converging, but there is ever increasing code reuse where it makes sense. Mono supports a lot more in the box than .Net Core currently does. I could see a point where .Net Core covers as much as Mono does within reason, and the rest of Mono eventually becomes separate packages in Nuget.
But wouldn't expect that in under 3-5 years. Just an observer from the sidelines.
Would be interesting if the author could comment on the memory footprint and performance of having an additional GC'ed language running alongside the engine. It seems like it could lead to complex hitching issues.
A good thing. The C# bindings for Unity are great for scripting - the language is surprisingly suited to lightweight logic. This should be a nice gift to developers not yet familiar with C++.
Why wouldn't it be? There are tons of entries on HN on [insert random project]. If enough people upvote in short enough time it hits the FP and is considered interesting. Not sure what else there is you want to see answered?
The question: "Why is this interesting to me." Is entirely different and we cannot possibly start to answer that for you.
We can give you the executive summary though. This brings access to UE4 to people without c++ knowledge. You can compare it to any managed wrapper around an unmanaged library. Some will curse it, others love it.
Previously you could only write code for the Unreal Engine with C++ or the visual scripting system, Blueprints. This allows people to use C# for everything that they would normally need C++ to add to their games - which will particularly help with people who are trying to transition from Unity to Unreal.
[+] [-] TazeTSchnitzel|8 years ago|reply
Is C# becoming the lingua franca of modern game engines?
[+] [-] thehardsphere|8 years ago|reply
[+] [-] WillPostForFood|8 years ago|reply
https://forums.unrealengine.com/showthread.php?2574-Why-C-fo...
- As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.
- As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or "interop" layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.
- Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.
- Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can't trace the C++ that code led to it, and vice-versa.
[+] [-] dan00|8 years ago|reply
[+] [-] Ologn|8 years ago|reply
I dabbled with the Daydream Google VR NDK C++ sample app and did a demo app for myself of simple shapes moving around. While I could do simple things, I couldn't imagine doing the type of games others have done on the platform (or Oculus, or Vive) without Unity. For most people the question will be, why reinvent the wheel?
I don't know if C# will be the lingua franca of modern game engines, but for the foreseeable future, I think it will be the lingua franca of VR.
[+] [-] c3534l|8 years ago|reply
I went and looked up all the major game engines I could think of:
Blender: Python only
CryEngine: Lua and C#
Gamebryo: C++ only
Unity: C# and Java (Boo is no longer supported)
Unreal: C++ only (UnrealScript no longer supported)
Amazon Lumberyard: Lua (maybe C++ too?)
id Tech: C++
I was actually surprised at how common Lua was, but now that I think about it I have heard of it being used increasingly in games.
[+] [-] frik|8 years ago|reply
We are talking about the game scripting language, the game engine is always coded in C++ for triple-A games, with only a handful outliers. It's different for indies. We all know how the "Managed DirectX" and the incompatibile successor XNA turned out, the C# DirectX community is dead, end of life and last supported on the old XBox360, dead like Silverlight https://en.m.wikipedia.org/wiki/Microsoft_XNA .
[+] [-] nonsince|8 years ago|reply
[+] [-] mwkaufma|8 years ago|reply
[+] [-] chupasaurus|8 years ago|reply
[+] [-] Mikeb85|8 years ago|reply
Unfortunately. It's a decent language, but it just seems a bit too heavy to use as a scripting language, but not as good as C++ for heavy lifting.
I'm doing some stuff on Godot, and will probably just end up using GDScript for basic stuff, and GDNative for more intensive stuff (It's a C/C++ API for shared libraries that you can load up through the editor).
[+] [-] b0rsuk|8 years ago|reply
[+] [-] Nelkins|8 years ago|reply
[1] https://github.com/mhutch
[2] https://www.youtube.com/watch?v=uxzS-grpN4c
[+] [-] 0xFFC|8 years ago|reply
[+] [-] tracker1|8 years ago|reply
But wouldn't expect that in under 3-5 years. Just an observer from the sidelines.
[+] [-] org3432|8 years ago|reply
[+] [-] Drakim|8 years ago|reply
[+] [-] laythea|8 years ago|reply
[+] [-] ivanbakel|8 years ago|reply
[+] [-] garaetjjte|8 years ago|reply
[+] [-] Nelkins|8 years ago|reply
[1] https://github.com/mono-ue/UnrealEngine
[+] [-] squeeeeeeeeeee|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] markatkinson|8 years ago|reply
[+] [-] protomyth|8 years ago|reply
[+] [-] paste0x78|8 years ago|reply
[+] [-] cantorRuth|8 years ago|reply
[+] [-] bastijn|8 years ago|reply
The question: "Why is this interesting to me." Is entirely different and we cannot possibly start to answer that for you.
We can give you the executive summary though. This brings access to UE4 to people without c++ knowledge. You can compare it to any managed wrapper around an unmanaged library. Some will curse it, others love it.
[+] [-] Blaaguuu|8 years ago|reply
[+] [-] throwaway2048|8 years ago|reply
https://news.ycombinator.com/newsguidelines.html