5 ms·

> They hid all the hard stuff in c++ so we didn't have to think about it. The more time has gone on, the more bullshit has crept to the forefront. The've gone f

> They hid all the hard stuff in c++ so we didn't have to think about it. The more time has gone on, the more bullshit has crept to the forefront. The've gone from hiding the hard stuff to moving more and more stuff into C#. I love that they are moving more and more stuff in C#. It's a good thing. The C# code is available for developers to view and modify, but no one is forcing you to. The problem is that a lot of Unity's early choices that made it so accessible to novice game devs making simple games, made it to inflexible or slow for bigger or more complex projects. If you were building a high performance procedurally generated game, you were already fighting with all of the "easy stuff".

jayd16 6y ago
I agree. Moving things to C# reduces interop overhead and I think it's the right direction. If you don't want to look at engine code, don't. Why does anyone care it's in C# if they're not looking at it anyway?
- hnick 6y ago
  > Why does anyone care it's in C# if they're not looking at it anyway? Garbage collection probably. Some games have noticeable stutter. But I assume there are ways around that, similar to using Java in HFT.
  - skibidi 6y ago
    A lot of effort goes into making sure allocations are avoided though. You also have DOT's High Performance C# which is a blazing fast subset of C# (Burst Compiler). I like the idea of using a language for everything, then restrict to a subset where performance is critical. You don't have that wall between scripts and (C++) engine code. And as mentioned above, less glue code is appreciated.
ngold 6y ago
This is going to sound insane. But I am developing a perfectly good putt putt game with unity 2018 lts on a 12 year old laptop with 128 Meg video card. It's slow but builds work great. So far. For learning and small games it works well so far. And has a load of tutorials made recently by youtubers. But it is a bit confusing to work out what to use and what is to old to use code wise.

jayd16 6y ago

I agree. Moving things to C# reduces interop overhead and I think it's the right direction. If you don't want to look at engine code, don't. Why does anyone care it's in C# if they're not looking at it anyway?

hnick 6y ago
> Why does anyone care it's in C# if they're not looking at it anyway? Garbage collection probably. Some games have noticeable stutter. But I assume there are ways around that, similar to using Java in HFT.
- skibidi 6y ago
  A lot of effort goes into making sure allocations are avoided though. You also have DOT's High Performance C# which is a blazing fast subset of C# (Burst Compiler). I like the idea of using a language for everything, then restrict to a subset where performance is critical. You don't have that wall between scripts and (C++) engine code. And as mentioned above, less glue code is appreciated.

ngold 6y ago

This is going to sound insane. But I am developing a perfectly good putt putt game with unity 2018 lts on a 12 year old laptop with 128 Meg video card. It's slow but builds work great. So far. For learning and small games it works well so far. And has a load of tutorials made recently by youtubers. But it is a bit confusing to work out what to use and what is to old to use code wise.