I am considering using Unity for my iOS game project because of strong toolset support, prebuilt particle, shader editor, rendering engine and asset management.
But the CLR based scripting layer is really unattractive because it is depending on GC system known as making spike frame rate problem which is unable to prevent with deterministic method. For my case, this can discard all of those benefits.
So I want to use unity without CLR layer. Is this possible? I mean I want to access raw C++ asset management and rendering system directly without scripting layer.
And, also want to handle Unity as a part of my iOS app. I don’t need any cross-platform-ability. I just need visual/audial rendering middleware with strong toolset support. Can I use unity in this way?
You can write a significant portion of your game in C++ or Objective-C if you want, but I don’t believe Unity exposes much to you at that level – AFAIK you have to either interface with your own script code that (at least) tells Unity where to draw things, or use Apple API’s directly for rendering and bypass many of the benefits of Unity.
But, I think you may be too focused on GC here. From my experience with Unity, GC is very low on the list of things to worry about. I find it’s pretty easy in Unity to write script code (lots and lots of script code) that puts so little pressure on the garbage collector that it’s essentially never running during gameplay. Making a game with a high framerate and no spikes is still a challenge, but I don’t think it’s because of the GC. And I use Unity’s profiler a lot, so I would probably notice if GC ever showed up as a problem.
Unity has plenty of other issues (e.g. the memory footprint is quite huge, there are many things you need to avoid doing because they are inexplicably slow, and there are certain fundamental design problems), but personally I find the scripting system to be one of Unity’s greatest strengths (which makes it all worthwhile), and I would recommend either embracing it or using another engine.