CryEngine V scripting in C#? Really?

Well, on the plus side it sounds like they're using a LOT newer version of Mono than what the Unity guys are stuck with. Unity is currently all-in with their IL2CPP converter in order to escape from Ancient Mono hell (and simplify support for multiple platforms).

I haven't used CryEngine at all, so I can't say whether it's implementation will be good/bad/ugly or what. Try it out both ways; C++ and C# are both great languages, but they both have aspects where they're much better than the other. You'll have to decide which of those aspects you care the most about.

For your first question, as far as I can tell from the documentation, C# is an option and you can use C++ as well.

Honestly, with Unity being my only experience, pretty much every other openly available game engine looks better, and I'd think the blame lies with it being written in C# rather than C++.

This is incorrect. Unity uses native code for many of the performance-intensive routines just like Cryengine or Unreal does.

Imagine you are trying to move from one location to another. When the distance is less than 50 meters, you'll probably just walk/run. If it's up to a kilometer, you might want to use your bike. If it's several kilometers, you'll probably benefit from using your car, even though it's a bit messier to find parking spots etc.

Scripting in C# is a bit like using your car. Very fast once running, but it might be heavy to start/end. If your scripts are complex and/or resource intensive, C# is a great option. If your scripts are very simple one liners, chances are something like Lua would perform better.

Unity is currently all-in with their IL2CPP converter in order to escape from Ancient Mono hell (and simplify support for multiple platforms).

There are also plans to upgrade the runtime/compilers in the works so that it matches the modern stuff kicking about.

IL2CPP is largely for mobile platforms, I believe iOS in particular due to not being allowed a VM on those devices.

Unity's Mono integration is much more coupled than CryEngine's. CryEngine uses the latest mono and provides bindings (https://github.com/CRYTEK-CRYENGINE/CRYENGINE/tree/release/GameMono) that leverages the same binding techniques they use for Lua and the like.

The advantage here is it's a direct exposure of C++ Objects on top of the Managed interfaces so it's a bit of a cleaner API on the C# side but the real measurement is adoption. Unity has always been a C# first kinda thing. Cryengine just recently released this binding to try to gain market share. I think until they have a slew of tutorials on the API in C# they won't get the kind of numbers they were hoping for.

That, and being subjected to Windows Only development environments hurts CryEngine when comparing to Unity. Unity wins because you can develop on a mac, it's C# from the get-go. CryEngine wins on the engine feature front as it's a much more powerful engine, but the lack of tutorials make it something that can't really be measured until that is rectified.

I believe Lua is the "preferred" (for lack of a better term) scripting in CryEngine but they did add a C# interface.

The reason why so many Unity games look so similar is due to the readily available common asset pool.

The technical issues of the engine would be next in line and whether it's C++ or C# is pretty far down the list.

The days of pushing a PC "to the limit" are just gone and left in the dust behind us.

There's not even a lot of focus on getting everything out of the GPU because all of the blockbuster titles are console ports.

Basically unless you are writing AVX based algorithms what language you use isn't relevant anymore (with regard to performance).

And you can always some bits in native code if you need to and dynamically link it in.

To me, the portability of the language and its supporting libraries is the dominating characteristic and that's where C# just comes unglued. (I wish C++ 14 was released ten years earlier.) YMMV.

I believe Lua is the "preferred" (for lack of a better term) scripting in CryEngine but they did add a C# interface.

The reason why so many Unity games look so similar is due to the readily available common asset pool.

The technical issues of the engine would be next in line and whether it's C++ or C# is pretty far down the list.

The days of pushing a PC "to the limit" are just gone and left in the dust behind us.

There's not even a lot of focus on getting everything out of the GPU because all of the blockbuster titles are console ports.

Basically unless you are writing AVX based algorithms what language you use isn't relevant anymore (with regard to performance).

And you can always some bits in native code if you need to and dynamically link it in.

To me, the portability of the language and its supporting libraries is the dominating characteristic and that's where C# just comes unglued. (I wish C++ 14 was released ten years earlier.) YMMV.

I would agree with most of this. The fallacy of this argument is that all games *need* to push the limits. Because our hardware is so good now compared to the average skill of the developers writing for it, we are in this weird black-hole time where we are getting API's to interact directly with the GPU (Vulkan, DX12) but that was driven by the big-boys in the pond and leaves most of us wondering what in the hell we are doing with them.

As for C#, C# is cross-platform (has been for a while, if you know the ecosystem) but the real kicker for C# is the lack of universally supported cross-platform. Cross-platform exists for C# but it's a hodge-podge of compiler defines and spaghetti code to make it work.

This is from direct experience writing an OpenGL game engine in pure C#.

C# is amazing for the productivity and it's close relationship (syntax wise) with c/c++. Where it really breaks down is when you want to move platforms. Mono on linux/mac is great, but not this Xamarin fork. It will get better now that microsoft bought Xamarin, but it's still like trying to force a square peg in a round hole.

C/C++ is better suited for easy cross platform development because of libraries like SDL, GLFW, etc. These have C# wrappers now, but it's still not getting the most out of the language and runtime because this kind of stuff should be available as part of the framework (cross-platform windowing/input).

But I digress. CryEngine's C# bindings are pretty good. LUA is still preferred with that engine but it's nice to see them catering to more of the indy crowd (who average more use of C#). But the lack of documentation and samples with it still make it wanting...

does writing scripts in C# compromise the capabilities of the engine's performance significantly?

People place far more emphasis on language choice than they ought. You can write bad code or good code in any language. Some languages are more naturally a better fit to certain problems than other languages, but you can still get great performance out of mainstream languages if you try.

There are portions of games that need to have good performance, especially on games with a soft realtime requirement of 10ms or faster per screen.

While the game engine code may have strong performance requirements, usually the gameplay scripts have minimal concern over performance. You've got tens of millions of CPU cycles every frame, you can use nearly any language to get enough work done to run gameplay scripts.

Two examples: Back in my college days two decades ago we were on 300 MHz machines and were observing the direction of a pointing hand in front of contrasting backgrounds: that's doing camera-based gesture recognition (generally considered a slow processing task) doing it in Java (often called a slow language), and a simple, naive implementation was taking only a few hundred thousand cycles, leaving about 1.5 million free cycles per frame for other work. On several programs we've written simple "just enough to get the thing working" scripting systems, all interpreted, and a few people were worried they would be too slow. They weren't super speedy, but the were never actual bottlenecks. Processing was taking place outside of critical paths and never blocked or notably impacted performance.

Performance problems are seldom where programmers initially think they are. Language choice itself is generally not the cause of performance problems. Bad algorithm selection, useless memory allocations, blocking operations, and stupid simple errors are the typical source of issues. But for deciding between C++, Java, C#, Lua, even JavaScript, all of them are viable languages in today's games.

does writing scripts in C# compromise the capabilities of the engine's performance significantly?

People place far more emphasis on language choice than they ought. You can write bad code or good code in any language. Some languages are more naturally a better fit to certain problems than other languages, but you can still get great performance out of mainstream languages if you try.

There are portions of games that need to have good performance, especially on games with a soft realtime requirement of 10ms or faster per screen.

Performance problems are seldom where programmers initially think they are. Language choice itself is generally not the cause of performance problems. Bad algorithm selection, useless memory allocations, blocking operations, and stupid simple errors are the typical source of issues. But for deciding between C++, Java, C#, Lua, even JavaScript, all of them are viable languages in today's games.

Completely agree. I think most people think "This needs to be fast, and I don't want to think too hard to make it fast, what can I do from the get go so it gives me peace of mind that it might be fast" and C++ is born... (j/k). Indeed, languages, architectures, etc have plenty of power. It's all about how you use it.

And I completely agree with the algorithm, useless memory allocations, blocking statement here. Most programmers don't have to worry about cycles, but rather execution time overall. Welcome to pushing the limits. Every aspect of a game engine can be finely tuned by implementing the best algorithms. However, one algorithm that may make it super easy and fast to draw tree's for example, may end up not working at all for grass... etc etc.. So it's a giant game of compromise, vs features, vs speed, vs look.