Thanks , for that clarification.
Few comments though…
[= Sweeney;194593]
Finally, when an engine is written in C++ and gameplay is scripted in another language, the interoperability barrier between languages eventually grows overwhelming. is why we ultimately abandoned the UE1-3 era’s UnrealScript language and moved to a pure C++ programming model. gives UE4 the ironic property of making it harder to learn the engine and start writing a game, yet ultimately easier to grow, finish, and ship.
[/]
What about Blueprints ? You are not very constant in you argumentation since one can develop its own game-play via another programming paradigm than C++…
[= Sweeney;194593]
Specifically, we put substantial work into documentation, samples, pre-release testing, compatibility, porting, and support on C++ and Blueprints that we can’t feasibly replicate for a third-party plug-in. For example, unless the documentation on UE4 programming were updated to include side-by-side examples of C++ and C#, the programming experience with C# in UE4 could feel disjointed, and downside may outweigh the upside of one’s familiarity with C# and its easier header-free programming model.
[/]
I shall also remind that “Mono for Unreal” does is exposing to a C# environment the blueprint-exposed functions that are already defined in the C++ environment, and therefore maintaining the C# API would rather be trivial.
tl;dr -> Blueprints-exposed code in the C++ will automatically be made available in C# via the tool.
[= Sweeney;194593]
The challenge with and other programming language integrations into Unreal Engine 4 is that, unless they were to be genuinely and thoroughly adopted by Epic, they would not quite be first-class citizens in the way that C++ and Blueprints are.
[/]
Do you think that if Mono was completely open-source and free to use for any body then Epic would have done it’s move towards ?