One change coming with CoreCLR is the addition of AssemblyLoadContext, which offers more fine grained control of assembly reloading.
The intent is, over time, to eliminate unnecessary reloading of assemblies when you make code changes.
One change coming with CoreCLR is the addition of AssemblyLoadContext, which offers more fine grained control of assembly reloading.
The intent is, over time, to eliminate unnecessary reloading of assemblies when you make code changes.
Itād be good if we could refrain from taking ableistic takes. Yes the games industry has an extraordinarily high density of neurospicyness (Iād say weeeell south of 50% by pure Anec-data and vibe checks) but that also means we should be very well aware that it is a very wide spectrum and includes conditions such as dyslexia and dyscalculia and different shades of it, which are not the only conditions that could affect oneās ability to focus on textual coding tasks.
I have friends in this industry that have to rely on Text3Voice and Voice2Text tools to be productive and their creativity and overall capability to make great games is in no way diminished by that.
Encouraging each other to learn more and lean in is ok but also trust that when an ND person tells you what they struggle with, that this struggle is real.
I mean itās not ableist to say Unity Visual Scripting is terrible and that they should use literally anything else rather than vainly hoping Unity will someday resurrect its corpse. Even if thatās another visual scripting solution.
But fair, point taken. My language was out of line.
I used to love bolt, especially bolt 2, it had a way to go but i loved it. Now, I find visual coding weird but I did love bolt to show how things were working to people who were less adept. I wish they never bought it and did their usual āhey amazing next great thingā and killed it moments later.
Indeed the conversation around Unity Visual Scripting would be completely different if Unity didnāt kill Bolt 2. Thereās really no defending uVS at this point.
Happy to point out that Unity 6.7LTS Alpha 2 includes the first release of the Experimental CoreCLR Desktop Player release.
This is an optionally installable component that will afford partial validation against the upcoming changes when the scripting runtime is replaced with CoreCLR.
Iāve added an update to the original post to better detail what you should expect from the experimental player, but to summarize: this is an unsupported component of the release.
If you do try it out⦠thank you
And please send in your bugs or feedback!
Success
I created a CoreCLR player build that references a gameās .NET Standard C# library containing 1,200 classes. It ran without issue, generating a procedural galaxy with one million star systems. Performance was on par with .NET 10.
Modding
I also noticed that referenced .NET Standard DLLs are now included in build output, which is great news for the modding community. For users coming from IL2CPP, is there a mechanism to keep referenced assembly code in GameAssembly.dll ?
how much of this is coded with agents? seems like this has been stuck for 6 years until now
Weāve leveraged AI for sure this year - it was very helpful in, for example, prepping all the 1st party packages for the new Code Reload model - but mostly weāve just been working behind the scenes and these things take time.
Making a mostly backward compatible change to such a fundamental system in an engine used by so many developers is a unique challenge. The making-of story would make a good Les Blank style documentary. Well, Iād watch it at least :).