What parts of a Unity game can be implemented in C++?

Can someone clarify what part(s) of a Unity game can be implemented in C/C++ via Unity's native plugin support or other native support? Let's say I have a set of game objects (or simply meshes) I'd like to render purely in C++. Would such a rendering setup still incorporate the overhead of per-frame C# rendering/Update calls? Is it possible to architect the game such that tight inner loop stuff stays purely in C++ or does this require we come up to the surface back in managed-C#-land once or more per frame? In short, how much extra performance can you eke out of Unity if you're willing to get your hands dirty with C++? Keeping in mind that premature optimization is the root of all evil and so on. But how much?

 

Rendering is already handled in C++.

 

You can replace pretty much everything if you desire. There are studios that have replaced the entire rendering and physics systems for example.

But none of them did it for reasons you are describing.

 

Does Unity's under-the-hood C++ rendering incorporate a native-to-managed or managed-to-native transition each frame?

 

I'm not positive what you're trying to ask about here. Are you asking about the Scriptable Rendering Pipeline?

 

My understanding is that almost everything other than scripts you create is already handled in C++. Unity itself is written in C++ and just includes the managed C# stuff because it presents a much easier and faster to iterate on workflow for game developers than C++ does.

 

I have a large # of assets in cross-platform C++ and am trying to gauge whether it's practical to integrate these directly or better to migrate them to C#.

 

That approach almost never works, with anything really not just this context. If you are solving the same core problem in a very different environment, then you start by using the idioms and tools in the new environment. If the new environment solves problems for you, don't try to solve it yourself until it's proven you actually need to. Don't fight the environment you are in.

The value of your existing code is not the code itself. It's things like the architecture and approaches used. Which may or may not even fit into another environment. The main point being learn the new environment and then if some previous work just happens to fit, that's great. But don't start out by trying to shoehorn in existing works into something you don't even yet understand that well.

 

So basically, assume the only thing you can carry over is general domain knowledge.

 

In general, you should first identify bottlenecks before trying to optimize a software system. Unity comes with a built-in profiler, so it might be a good idea to use it to measure the actual overhead in each stage before deciding to dump the whole C# layer to optimize your game.

I don't have much knowledge of game optimization, but I'd be much surprised if you can get a big improvement in speed by rewriting game logic in C++.

It reminds me of a common misconception about using a VM language on the server side, as there are quite many people who think they'd get a big performance boost if they dump the VM and write everything in C++. It's not the case because in such a system, most of the overhead can be found in the I/O process and any overhead incurred by the VM is almost negligible compared to that.

I suspect a similar thing can be said of how a game engine works in general, if we substitute rendering overhead to that of I/O. As @Ryiah already said, it's already done in C++, and you cannot expect to arrive at your work 2-3 times faster if you drive a F1 racing car (C++) through congested roads (rendering overhead) on a rush hour, simply because it has maximum speed thats 2-3 times faster than that of your plain SUV (C#).

Even if one actually owns a racing car, he or she wouldn't drive it to work to get there faster, considering how much more it would cost in maintainenance. That's why game engines use various 'slower' languages like C#, Lua, Python, and etc to boost productivity, despite performance being one of the most important concerns in game development.

 

What do you mean by “assets”? Is it game logic?

 

Thanks for all the responses your thoughts have been helpful even if my question was a bit jumbled.

So I have several hundred C++ files in standard cross-platform object-oriented style. These classes implement a simple C++ game engine (yet another custom game engine, oh noes) with a dual DirectX + OpenGL renderer in a DLL / LIB / shared object. Additionally, I have a bunch of C++ classes implementing a separate game executable. So far so good.

Now, let's throw in an external business requirement: make everything work in Unity.

My options are to: a) rewrite everything in C# b) incrementally rewrite some stuff in C# and reuse key pieces of the C++ codebase c) keep as much as possible in C++. The only option I don't have is d) use another engine that supports C++ scripting out of the box and that's okay; I vastly prefer Unity anyway.

The code is a large-N simulation (large-N as opposed to small-N; meaning I'm controlling many 1000s or 10000s of entities in real time) and it strikes me that this -- animating and performing AI for, say, 10k entities in real time -- is one of those areas where C++'s more austere runtime budget is going to make a real difference. So without getting into premature optimization I'm looking for some sort of warm-fuzzy that, in the event it's necessary, I can take control of the low-level aspects of rendering, game looping, and the like; that Unity is aware of this use case and won't impose C# runtime overhead on me in cases where I'm willing and eager to go native.

TL;DR -- please s

 

It seems you can write pretty much everything in C++, see:
https://jacksondunstan.com/articles/3938

This sounds like an excellent use-case of the upcoming C# Job System in Unity 2018, see:
https://forum.unity.com/threads/uni...ob-system-new-entity-component-system.502116/

 

Nice! That's exactly the mentality and approach I am looking for.

Thank you kindly. To me this is a flagship not very well documented feature of Unity.

 

Rewrite. If there’s large chunks that are isolated enough, you could wrap those in a plug-in, but game logic and core stuff you should just rewrite. Shouldn’t be too time consuming if the architecture is decent already.

Obviously the best thing would be to just use the existing engine or something like unreal. But if for whatever reason you need to migrate to unity, creating a fankenstein kludge of the codebase is just going make things a nightmare to maintain and limit future work. Not to mention bypassing things like editor tooling and profiling and other advantages of using Unity. You won’t get any advantage using C++ for game logic and core stuff, and will just create unnecessary work and steps.

I would say if you are going to (need to) switch, then just commit and switch. Doing it half way is a hack,

 

I can't argue with this. Like Mr. Miyagi says:

There are a few isolated areas where the cross-platform work is complete, the domain is self-contained, and these seem like a candidate for native pluginification per @Peter77's link -- but not if it's less work to implement it in pure C# and get easier cross-platform support that way. If pure performance is the yardstick, I'm guessing 99% of the code could be rewritten in C#.

That said, I can tell even from a cursory review of that resource that Unity does, in fact, offer the native support I was looking for even in the case where I want to do a 90% C++ implementation. That's awesome! If I'd known this I would've done many projects in Unity that are currently sitting in Unreal or in my native engine stuff.

 

The GitHub version of Peter's link:

https://github.com/jacksondunstan/UnityNativeScripting

This looks like nice work.

 

There are some cool tricks you can do to manage many thousands of units. You don't need to worry about C# vs C++. What you need to do is think in terms of data sets and GPU instancing instead of using a separate game object for each unit. Since Unity 5.5, there is an awesome API method call DrawMeshInstanced. Here is a link to the docs:
https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstanced.html

I used DrawMeshInstanced in my space game to handle the thousands of laser projectiles flying around in the scene. If you need to do simulations with 10,000 units, you need to master DrawMeshInstanced.

 

You will have to ditch them and rethink the game design in terms of unity. Component architecture is different from the standard top down programming approach.

GameObject and Component classes are largely handles to internal objects that exist on c++ side where your methods act as callbacks with previously agreed upon name and signature.

Moving (or attempting to move) the game logic to c++ side will be painful because a lot of c# functionality is not exposed to native plug in interface.

Basically, unless you already have a finished c++ game and simply want to use unity as rendering framework, trying to carry over your favorite c++ code snippets is not worth it.