3 ms·

Switching to C# is straight forward - for majority of projects you won't need many language specific features. Most operations are about increasing counters, pe

by kerng 7y ago

Switching to C# is straight forward - for majority of projects you won't need many language specific features. Most operations are about increasing counters, performing if and switch scenarios, some event messaging, and doing math and state tracking. C# is quite a good choice for those things.

DonHopkins 7y ago
But debugging C#, especially on mobile and WebGL platforms, is a horrible primitive retrograde nightmare. And it takes a long long time to recompile, with some projects taking a good slice of an hour to build. That not only slows down and locks up both Unity and your entire computer and spins up the cooling fan like a 747 taking off while it's compiling for so long, but it also wastes orders of magnitude more time than what everyone is used to from interactively reloading and debugging JavaScript code, and it totally destroys the flow of getting into the "groove" and iterating extremely quickly and interactively like you can do with web development. The whole point of UnityJS is to enable you to instantly reload your app and see your changes without recompiling, and use the modern high-quality off-the-shelf JavaScript debuggers built into every web browser to debug your WebGL apps live in a web browser, and your iOS and Android apps live while actually running on the device. And also to benefit from the gargantuan ecosystem of standard JavaScript libraries and the communities and companies that support them, instead of rolling your own half-assed bastard stepchild C# imitation libraries that require constant maintenance and quickly go out of date because nobody else uses them. There are many application domains, especially AR and VR and accelerometers and cameras, that are impossible to simulate in the Unity editor, and developing them requires quick turn-around and interactive debugging. That's where UnityJS really shines! Here's a demo of an earlier version of UnityJS integrated with ARKit on iOS for Pantomime: WovenAR Tools with ARKit and Pantomime https://vimeo.com/240612327 https://vimeo.com/240612327
- jayd16 7y ago
  >But debugging C#, especially on mobile and WebGL platforms, is a horrible primitive retrograde nightmare. And it takes a long long time to recompile, with some projects taking a good slice of an hour to build. A 2gig mobile game should take 20 minutes to build to device tops and that's all from asset compression anyway. Recompiling the code should take no more than a minute unless you're using a potato. The part of the compilation that actually eats your machine because its the only multithreaded part is the shader compilation, again not C#.
  - DonHopkins 7y ago
    Do you mean it "should" or "does" take no more than a minute? And do you honestly find debugging Unity3D iOS apps running on mobile devices and WebAssembly/WebGL apps running in the browser a pleasant experience? Do you think MonoDevelop (when it works and doesn't crash) is better than the Chrome or Safari debugger? I don't know what kind of toy games you're compiling that take no more than a minute to completely compile and deploy with Unity3D: "2gig" of what, code or just video? I'm not talking about pressing "Play" in the editor or deploying on Windows or Mac with Mono, I'm talking running it in the browser with the WebGL back-end, or on an iPad with the iOS back-end, using il2cpp and Emscripten or XCode, which are enormously slow and complex. It certainly does take a long time on my Mid 2014 MacBook Pro (which while not new, is certainly not a potato), and it makes it useless for doing anything else while it's compiling, and spins the fan up to its highest speed and pins the CPU all that time. A large complex multi player networked AR/VR iOS app like Pantomime with a lot of content including code and libraries and resources and plugins and shaders regularly took me a good part of an hour to compile, build and deploy. Developing UnityJS was my response to that problem, so I could rapidly iterate by changing code and JSON data and other resources, without recompiling. https://vimeo.com/154755183 https://vimeo.com/154755183 https://vimeo.com/240612327 https://vimeo.com/240612327 WebGL and iOS builds are especially slow, because they go through layer after layer of cross-compilers, from C# to CIL with the Mono compiler, and then from CIL to C++ with il2cpp, then the XCode/CLang/Assembler/Linker or Emscripten/WebAssembly chains do their own ridiculously complex things, and there's also a significant amount of time spent packaging and compressing resources and data in various formats and wrappers. You have to wait not just for the C# code to compile, and for the shaders and the resources to be processed, but for the entire multi-level Rube-Goldbergesque translation and packaging process to finish, then that build must be deployed on your web server or mobile device. I'm talking about the actual turn-around time between when you make a change to the code, and see the results. You know, the thing you have to do again, and again, and again, and again, and again. So it adds up quickly. UnityJS drastically slashes that time, however long it takes (and I have a hard time believing it takes no more than a minute for you, unless your app is trivially simple), to just a few seconds of refreshing the web page or quitting and restarting the iOS app. For fast debugging turn-around, you can tell it to load the JavaScript code, JSON configurations, and other resources from a web server, and edit the code and content live on the server, so the app downloads the fresh JavaScript code, in mere seconds, each time you run it, without any recompiling.
- golergka 7y ago
  If your builds take a long time, it's definetly asset pipeline and not code. At this point, you should migrate your project to asset bundles to avoid rebuilding assets on every build - it should save you a lot of time.
- tasogare 7y ago
  > gargantuan ecosystem of standard JavaScript libraries and the communities and companies that support them, instead of rolling your own half-assed bastard stepchild C# imitation libraries that require constant maintenance You can't possibly be serious here. You are comparing an ecosystem where the package manager can be gamed to includes malware in your code, where a small project need includes 1000+ libraries some having just one function in them, where core projects used by GAFAM can become unmaintained because of lack of funding, where most modules are created by random developers and will break your code on update to an ecosystem with a two decade old battle-tested extensive base class library made entirely by professionals, maintained by one of the biggest tech corp with a safe package manager. Also breaking API change from third party library are easily detected thanks to the type system.
  - DonHopkins 7y ago
    Having a gargantuan JavaScript ecosystem with many libraries of varying quality to choose from is a much better position to be in that Unity's position of only being able to compile and run a much smaller subset of the gargantuan Microsoft C# ecosystem, and in many cases needing to port or roll your own libraries and maintain them yourself. The existence of bad unmaintained npm modules doesn't detract from the quality and popularity of the many decent JavaScript modules that exist and are widely used and supported. Take d3, for example. It's excellent, well maintained code, that splendidly solves many practical problems. There is nothing anywhere near as powerful and flexible and well documented and maintained (and free!) as d3 for Unity. UnityJS lets you use that JavaScript d3 library directly. Now tell me which C# SocketIO library you use for Unity, and how it compares to the latest greatest version of the standard JavaScript SocketIO library? How many people are actively maintaining it, and how up to date and actively maintained is it? A github link, please? UnityJS lets you use that JavaScript SocketIO library directly.

by kerng 7y ago

DonHopkins 7y ago

But debugging C#, especially on mobile and WebGL platforms, is a horrible primitive retrograde nightmare. And it takes a long long time to recompile, with some projects taking a good slice of an hour to build. That not only slows down and locks up both Unity and your entire computer and spins up the cooling fan like a 747 taking off while it's compiling for so long, but it also wastes orders of magnitude more time than what everyone is used to from interactively reloading and debugging JavaScript code, and it totally destroys the flow of getting into the "groove" and iterating extremely quickly and interactively like you can do with web development. The whole point of UnityJS is to enable you to instantly reload your app and see your changes without recompiling, and use the modern high-quality off-the-shelf JavaScript debuggers built into every web browser to debug your WebGL apps live in a web browser, and your iOS and Android apps live while actually running on the device. And also to benefit from the gargantuan ecosystem of standard JavaScript libraries and the communities and companies that support them, instead of rolling your own half-assed bastard stepchild C# imitation libraries that require constant maintenance and quickly go out of date because nobody else uses them. There are many application domains, especially AR and VR and accelerometers and cameras, that are impossible to simulate in the Unity editor, and developing them requires quick turn-around and interactive debugging. That's where UnityJS really shines! Here's a demo of an earlier version of UnityJS integrated with ARKit on iOS for Pantomime: WovenAR Tools with ARKit and Pantomime https://vimeo.com/240612327 https://vimeo.com/240612327

jayd16 7y ago
>But debugging C#, especially on mobile and WebGL platforms, is a horrible primitive retrograde nightmare. And it takes a long long time to recompile, with some projects taking a good slice of an hour to build. A 2gig mobile game should take 20 minutes to build to device tops and that's all from asset compression anyway. Recompiling the code should take no more than a minute unless you're using a potato. The part of the compilation that actually eats your machine because its the only multithreaded part is the shader compilation, again not C#.
- DonHopkins 7y ago
  Do you mean it "should" or "does" take no more than a minute? And do you honestly find debugging Unity3D iOS apps running on mobile devices and WebAssembly/WebGL apps running in the browser a pleasant experience? Do you think MonoDevelop (when it works and doesn't crash) is better than the Chrome or Safari debugger? I don't know what kind of toy games you're compiling that take no more than a minute to completely compile and deploy with Unity3D: "2gig" of what, code or just video? I'm not talking about pressing "Play" in the editor or deploying on Windows or Mac with Mono, I'm talking running it in the browser with the WebGL back-end, or on an iPad with the iOS back-end, using il2cpp and Emscripten or XCode, which are enormously slow and complex. It certainly does take a long time on my Mid 2014 MacBook Pro (which while not new, is certainly not a potato), and it makes it useless for doing anything else while it's compiling, and spins the fan up to its highest speed and pins the CPU all that time. A large complex multi player networked AR/VR iOS app like Pantomime with a lot of content including code and libraries and resources and plugins and shaders regularly took me a good part of an hour to compile, build and deploy. Developing UnityJS was my response to that problem, so I could rapidly iterate by changing code and JSON data and other resources, without recompiling. https://vimeo.com/154755183 https://vimeo.com/154755183 https://vimeo.com/240612327 https://vimeo.com/240612327 WebGL and iOS builds are especially slow, because they go through layer after layer of cross-compilers, from C# to CIL with the Mono compiler, and then from CIL to C++ with il2cpp, then the XCode/CLang/Assembler/Linker or Emscripten/WebAssembly chains do their own ridiculously complex things, and there's also a significant amount of time spent packaging and compressing resources and data in various formats and wrappers. You have to wait not just for the C# code to compile, and for the shaders and the resources to be processed, but for the entire multi-level Rube-Goldbergesque translation and packaging process to finish, then that build must be deployed on your web server or mobile device. I'm talking about the actual turn-around time between when you make a change to the code, and see the results. You know, the thing you have to do again, and again, and again, and again, and again. So it adds up quickly. UnityJS drastically slashes that time, however long it takes (and I have a hard time believing it takes no more than a minute for you, unless your app is trivially simple), to just a few seconds of refreshing the web page or quitting and restarting the iOS app. For fast debugging turn-around, you can tell it to load the JavaScript code, JSON configurations, and other resources from a web server, and edit the code and content live on the server, so the app downloads the fresh JavaScript code, in mere seconds, each time you run it, without any recompiling.
golergka 7y ago
If your builds take a long time, it's definetly asset pipeline and not code. At this point, you should migrate your project to asset bundles to avoid rebuilding assets on every build - it should save you a lot of time.
tasogare 7y ago
> gargantuan ecosystem of standard JavaScript libraries and the communities and companies that support them, instead of rolling your own half-assed bastard stepchild C# imitation libraries that require constant maintenance You can't possibly be serious here. You are comparing an ecosystem where the package manager can be gamed to includes malware in your code, where a small project need includes 1000+ libraries some having just one function in them, where core projects used by GAFAM can become unmaintained because of lack of funding, where most modules are created by random developers and will break your code on update to an ecosystem with a two decade old battle-tested extensive base class library made entirely by professionals, maintained by one of the biggest tech corp with a safe package manager. Also breaking API change from third party library are easily detected thanks to the type system.
- DonHopkins 7y ago
  Having a gargantuan JavaScript ecosystem with many libraries of varying quality to choose from is a much better position to be in that Unity's position of only being able to compile and run a much smaller subset of the gargantuan Microsoft C# ecosystem, and in many cases needing to port or roll your own libraries and maintain them yourself. The existence of bad unmaintained npm modules doesn't detract from the quality and popularity of the many decent JavaScript modules that exist and are widely used and supported. Take d3, for example. It's excellent, well maintained code, that splendidly solves many practical problems. There is nothing anywhere near as powerful and flexible and well documented and maintained (and free!) as d3 for Unity. UnityJS lets you use that JavaScript d3 library directly. Now tell me which C# SocketIO library you use for Unity, and how it compares to the latest greatest version of the standard JavaScript SocketIO library? How many people are actively maintaining it, and how up to date and actively maintained is it? A github link, please? UnityJS lets you use that JavaScript SocketIO library directly.