Roles of C++ and C# in Flax

Scripting C++
#1

Hey there everyone! I am new to Flax and the Forum.
I have been enjoying my time in Flax pretty much and I am currently having a thorough read of the documentation. I am a bit confused regarding the role of C++ in Flax. In the documentation I found this:

image
image899×47 3.16 KB

Does this mean, C++ scripts cannot be attached to Actors for this purpose at runtime? I am trying to keep myself within C++ since I do not know C#, so was wondering if both languages have the same reach within Flax , meaning that I can do everything in C++ and Visual Scripting, or is there functionality of the engine that can only be accessed with C#? Thanks!

1 Like
#2

No, there really isn’t anything that you can perform with c Sharp that you can’t do with c++, it’s just a matter of preference

2 Likes
#3

notes of the experience I had:
Found the c++ scripting side to be more work because of the ‘only use what you see’ space.
the c# side feels like shorthand with a few extras.
A math helper function on the C# side I couldn’t find a C++ equivalent (RotateAround btw…).
Compile times did seem a bit snappier for C++.
In most all cases, it’s true. The c# naming matches the c++ naming with decoration in some cases.

The C++ content script object attaches visually just like the dragging in of the C# object to an Actor.
Seemed to act as expected at runtime.

2 Likes
#4

Thank you very much for the prompt response. I am glad to know there is virtually full feature parity between both C++ and C#. However, I believe I didnt get this part:

What is that about? Is it about namespaces? Thanks!

1 Like
#5

I said it wrong…didn’t I. :slight_smile:
“include-only-what-you-see”
C++ Scripting | Flax Documentation (flaxengine.com)

I suppose the way I see it is, there is C# to get it done fast or ‘fail fast’, then C++ for when it’s ready to go fast. I’ll admit, I should have not skimmed the next bit in the docs about the common types.
map wasn’t a problem or an array type and understandably string types, it’s List to something c++ish that trips me up. :slight_smile:

1 Like
#6

Oh, I see! Thank you very much! It is much more clear now. :smiley:
Thanks! :+1:

1 Like
#7

Something to remember is If you make your game using C# anyone can read and copy your code using readily available tools. The same applies to everything made with the Unity engine. That’s why many Unity devs also spend extra money and pay a 3rd party in an attempt to “protect” their code. Using C++ with the Flax engine makes it harder for someone to read and copy your code.

If you do your game/app/project in C# you can also obfuscate the code yourself. You can use long variable names and make function/method names nonsensical and put code in your game that does do something but actually doesn’t affect your game at all, like constantly add two numbers together. But make it so if that function is removed from the code it breaks your game. The objective being if someone wants to hack/steal/pirate your code they will consider it a waste of their time and move onto something easier to steal.

From the following website: Game Data Security | Flax Documentation

" Code

Depending on the scripting language used in the game project it might be more or less secure. There are several actions that can increase the final security of the game but remember that it might be very hard or nearly impossible to secure the game fully.

C#

Game code is compiled into .Net assemblies - separate for each binary module such as Game.CSharp.dll (default). Thus no source code is deployed with the game. However, C# DLLs can be easily decompiled with the various tools which make it insecure. Possible ways to overcome this:

  • Obfuscation tools (eg. Eazfuscator.NET, ConfuserEx, neo-ConfuserEx, Babel Obfuscator, etc.) - those can mangle code-flow, variable names, constants, and types. But if the class typenames or field/properties get renamed it might lead to incorrect deserialization when loading scenes or prefabs. For this case Serialization Callbacks can be used to load the data from the asset for runtime.
  • Code signing - after project compilation all game DLLs can be signed with a code-signing certificate which allows validating the file upon the execution to prevent hacking game files (at least partially).
  • Critical-code could be moved into C++ scripts which are compiled directly into the platform bytecode.

C++

Native C++ game code is compiled directly into the target platform executable format (eg. .dll, .so, .dylib, etc.). In Release mode there is no debug information and all code optimizations are enabled in the compiler. This results in secure code in a way it’s unable to decompile and very hard to hack."