3 ms·
There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most o
by Nition 3y ago
There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store.
As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.
- Rapzid 3y agoEasily room for both though. Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting. Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings. Maybe GDScript could just get the concept of a struct and the differences minimized over time too.
- johnnyanmac 3y agoFrom what I'm reading here and elsewhere, we'd need to do some fundamental mucking into the c++ layer as well, given some data oriented hostile practices. But yes, I think it'd be best long term to treat GDScript ad C# the way Unity treated GameObjects and DOTS. DOTS's goal wasn't to kill gameobjects, and in fact a lot of work went into bridging between the two with hybrid packages. I guess we'll see if that kind of initiative gets some momentum (and I'd love to help out if so!)