[1] is the single best online course I had. It took ~30 hours to complete, and we all know how easy it is to drop a course after couple sessions.
It teaches from very basics, at the same time the projects are diverse and fun because 3D-assets and effects are provided.
Chunk size is perfect, few minutes video and then it's few minutes of work in the editor. Videos have short text summary so there's no need to rewind the video if I missed something.
Often it solves a problem in a naive but incorrect way, and then fixes it. So when I encounter a problem in real project, I often have experience dealing with it.
It has debugging projects, where you have a complete project which is broken in multiple ways. So smart. In my regular programming work I spend most time debugging, not creating from scratch.
The narrator (Carl D.) is charismatic, videos are very professional.
I wish there were more courses with same structure and quality. Can't recommend it enough.
Correct. I've been using this with my high school Game Programming course this semester. It made the transition to distance learning pretty straightforward for that class. I think the title of the post should include the word Premium since Unity Learn in general is free, it's the Premium content that has been made free for 3 months.
Making good instructional videos is tough. Speaking loud enough, clear enough and slow enough to be understandable to as many people as possible with different levels of language proficiency can make it seem weird for some. I met Carl at a Unite conference and his voice sounded a little off compared to my memory of it and I realized it's because I've been so used to listening at 2x on those videos.
I would highly recommend learning Dreams for PS4. This is going to change the way video games are made. It provides an accessible way to get into game creation in a fun and accessible way. I would have killed to have Dreams when I was 12 years old.
Look up all the amazing things that can be made with this engine. It's incredible!
I was looking at getting it for my kids just last week. Went through a bunch forums, reading through what people are saying and the overwhelming tone was that it's just not good. An ad-hoc collection of tutorials with no overall structure and that are more confusing than helpful. Too complicated for noobs, too trivial with those with a bit of experience.
If anyone has a firsthand experience with Unity Learn, I'd love to hear about it, and I'm sure others will find it useful too.
I'm doing a relatively short course right now on optimization which is instructive. Profiling is an important but strangely ad hoc task so I'm always looking for fresh content on the subject.
A key feature for schools is granting access to Construct 3's full features with access codes, meaning students do not need to proivde us with any login details/emails etc which is popular in educational institutes:
We also have a build service for paid plans that allows for easy building of your games into deployable signed APKs.
If the subscription is a deal breaker, a lot of users do use our free edition which has a 50 event limit if you use it logged in to a Construct.net account (and a few other limits).
C# is not that different from JavaScript but maybe I'm biased, if you still want an easier way than using C# then I would recommend Unity plugins that let you create games without coding such as Playmaker[0] and Bolt[1], after getting comfortable using those they will be more ready to use C#.
I also have deep knowledge of JS, from the time one had to make it work on Internet Explorer 6, and believe me C# is not that different, maybe if you want a smoother transition just learn a bit of TypeScript first, then C#. Which btw were both co-created by the same guy, Anders Hejlsberg.
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.
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:
> 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.
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.
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.
>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#.
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.
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.
We're working on those things, but we agree the debugging, performance, and iteration time are not in a great place for web today. We have plans for how to fix them, though, and are working on several of them currently. These are mostly under the umbrella of Project Tiny (the team I'm on), whose forum you can find here: https://forum.unity.com/forums/project-tiny.151/
It's very experimental still, and iteration times for web are still not amazing, but we do think we have a way to get them to be actually good, while still letting you write and debug C# as you would expect.
I do mobile Unity dev professionally on a team of 50+. A large game will be mostly textures or other art assets. You should profile your builds. The majority is probably texture asset compression, packaging, that sort of thing. Your build should not be dominated by compilation time. Running the Cacheserver can also help with this to some degree.
You can like Javascript more but know that you're doing something wrong if its taking you an hour to build a mobile game in Unity.
Edit: You should look into Rider too. I much prefer it over MonoDevelop. A mid 2014 MBP could be poor if you're running a low RAM config. They only went up to 16GB and if you have 8 you could be hitting swap and it'll be dog slow.
Just going to second this: PlayCanvas is the only top quality JS game engine I've come across that comes with a GUI editor for placing objects, lights, etc.
I'm a big three.js fan, but if I was building something where I could get a lot of benefit from placing/configuring objects through a visual editor I'd definitely use PlayCanvas for it.
The "js support" called UnityScript in old versions of Unity is horrible. Avoid it like the plague. It's not actually JavaScript, just a thin wrapper around the Mono runtime. So instead of standard JavaScript array.push(obj), you have to use C# APIs like array.Add(obj). And there are all kinds of other incompatibilities too. It's totally incompatible with all known JavaScript tools and libraries, and definitely won't run the output of the TypeScript compiler. So you can be sure that code written for the browser will definitely not work, and don't even try to port JavaScript libraries to it.
Not only that, but it's also a compiled language, so has none of the advantages of being able to reload instantly without recompiling for half an hour, or using the excellent JavaScript debuggers built into every web browser to debug and interacting with the code with the console in real time while it runs on the actual device.
It's a very good thing that Unity took UnityScript out back behind the woodshed and shot it (along with "Boo", which was to Python as UnityScript was to JavaScript). It wasn't doing anyone any good, and it was a huge burden for Unity to maintain. People who already knew JavaScript but didn't want to learn C# were screwed because it wasn't really JavaScript so their knowledge didn't apply and their time learning it was wasted, and it prevented or delayed them from learning an excellent language like C#, which they should have done in the first place.
C# has its place, but it's never going to be as quick to reload and run, and as easy to debug and use interactively, as JavaScript.
Another enormous advantage to using off-the-shelf honest-for-goodness authentic JavaScript instead of almost-but-not-quite-entirely-unlike-JavaScript, is that you can easily use all the latest and greatest JavaScript libraries off-the-shelf without any modification. Then you can actually hire somebody who already knows how to use those libraries, too.
A great example is SocketIO (but there are MANY other examples). You can just use the latest standard JavaScript library without modification, instead of desperately shopping around for an adequate C# imitation, finding it only runs on Windows, trying and failing to port it to Unity, finding three different attempts by other people to port or reimplement the same library in Unity that failed and aren't maintained or don't work in the current version of Unity or are incompatible with the WebGL/WebAssembly runtime, and finally spending the time to roll your own, which quickly goes obsolete because you're the only one supporting it.
It's MUCH better to be able to simply drop in the latest version of SocketIO, or the Stripe API, or D3, or whatever you need, and go to town drawing all kinds of graphs and diagrams by copying and elaborating the great examples on observablehq.com, then use those html canvas images on Unity3D textures of 3D objects and user interface overlays, instead of foolishly trying to reimplement D3 in C#.
UnityJS also makes it very convenient to develop hybrid wen apps that are partly Unity3D/WebAssembly/WebGL, but deeply integrated with HTML/JavaScript, so they can send structured messages and data back and forth (including bit-blitting images and buffers of numbers across instead of serializing/deserializing them), and do the text and user interface in HTML/CSS/SVC along side or in overlays, using Angular or React or whatever you like.
Hybrid Unity/Web apps are useful, because Unity doesn't have a decent immediate mode 2D drawing API like canvas or D3, or a decent text/graphics layout engine like HTML/CSS/SVG. (I love TextMeshPro, but it just isn't capable of everything that's so easy to do in HTML, or able to leverage higher level HTML templating or formatting or graphics libraries, or even form inputs. And writing a Unity shader or constructing a dynamic 3D mesh to draw a pie chart is such a silly overkill, when you can do it so easily with canvas or D3.)
Do you want to write code in JavaScript? That’s deprecated.
Do you want to target WebGL? It works but it’s less than ideal. If you want to make a WebGL app, Unity would not be my choice. The tooling used to fall into the “that works, but it’s cursed” category, because it would compile the C# to CIL with Mono, then compile CIL to C++ with il2cpp, and the C++ to JS with Emscripten. I think. If you think this pipeline is “extremely cursed”, well, you’re not alone.
If you want to make a browser game with tooling, there are some better options. Different options for 2D and 3D. You’re going to have to accept some kind of compromise and the ecosystem is a bit difficult to navigate.
Whoa, JavaScript support is deprecated? News to me! I always use C# anyway but still seems like a shame.
And yeah, agreed, it's probably pretty clunky compared to what some WebGL-specific frameworks might give you. I don't know if anything out there has quite the UI setup or polish as Unity though. Do you know of any?
Deprecating JavaScript (UnityScript) is a good thing. Language bindings are a nightmare, and the more languages you support, the worse it gets. Consider that you might want to write a class in C++, wrap it in a C# interface, and then use it from UnityScript. Consider that if you write something for the asset store, the consumers may be using C# or JS.
If you’re looking for something with good UI and polish, maybe GameMaker Studio fits the bill? I don’t keep tabs on this space. I use Unity when I’m collaborating with people, and use simpler frameworks when I’m working alone.
I totally agree that UnityScript and Boo were terrible ideas and executions that were cursed, and it's a great thing they're deprecated.
JavaScript itself though is great. But the standard ways of integrating Unity and JavaScript in the WebGL back-end are extremely inefficient, terribly designed, and leave a lot to be desired.
There are much more efficient ways of communicating by judicious use of P/Invoke and insight into how WebAssembly and the C# / Unity JavaScript runtime binding works, which I've studied and leveraged in UnityJS. See some of the links in the other message I posted about UnityJS that discuss the JavaScript/C# JSON messaging bridge I developed, which is based on P/Invoke instead of Unity's terrible "GameObject.SendMessage", and techniques for blitting images and raw arrays of typed numbers back and forth between Unity and JavaScript.
The great thing about Unity that makes it worth all the effort of making up for its other weaknesses is its editor, and the ability to extend the editor with custom user interfaces, by widgets and editors in the object property sheets and 3d gadgets and objects in the world itself. The editor and its customizable UI facility is a common ground for artists and programmers to meet, that enables programmers to give artists a huge amount of power and flexibility, and artists to see and totally control what they're creating immediately and interactively.
Here's a demo of Unity3D pie menus that shows and explains some custom editors, as well as in-world editing tools. (It's kind of old, so the demo requires the now-obsolete Unity browser plug-in, since it isn't compiled for WebGL.)
They have a full set of useful notifiers so you can tightly integrate them with your application to give rich feedback during tracking (for example, modifying the 3D menu items, or previewing the effect of the menu item and distance parameter in real time, making them more like "direct manipulation").
For example, to show how you can implement feedback like The Sims pie menus with the head in the center that looks at the selected item, I've made a 3d object in the pie menu center with the webcam texture on it, so YOUR head is in the center of the menu, looking at the selected item! (That's why the demo asks for permission to use the webcam.)
The pie menu and each item has a title as well as a description. One feature I've added is the ability not only to disable an item, but also to provide an explanation of why the item is disabled! (PacMan in the demo is disabled, for example.) I wish other menus and widgets would do that -- it's frustrating when you can find an item you want, but can't figure out why it's disabled!
Another nice thing about them is that you can either configure algorithmically with an API, or with JSON data (which makes it easy to make dynamic data driven menus downloaded from a server or database), or construct them in the Unity3D editor out of objects (which makes it easier for artists to design them)!
I've made a custom Unity3D editor that lets you edit the properties, drag and drop textures and objects, edit and rearrange the items, and has some convenience commands, so you can place the 3D item objects in a circle in the 3D world, and call a command that figures out which item is in which direction by their position, and tidies them up. (That is much easier than arranging their order in a linear list of items.)
I'm going to play around with more in-world editing features, to make them easier for artists to design them.
I totally agree that JavaScript sucks, but that's not a good enough reason to boycott it, because it's absolutely ubiquitous and so well and widely supported.
And no matter how bad it is as a language, it still beats compiled languages as a dynamic extension and scripting language.
Another non-technical advantage: Apple allows iOS apps on their app store to dynamically download and execute JavaScript code, as long as you run it in Apple's Safari browser component (which UnityJS does). But even though it's technically possible, you aren't allowed to do that with Lua, Python, TCL, Visual Basic, Pascal, C++, C#, or any other interpreted or compiled language.
So JavaScript occupies a special spot in the universe, the web ecosystem, and also the iOS ecosystem, that makes it not matter if it sucks.
Plus a lot of smart people and big projects are working hard to mitigate its suckyness, make it run faster, and integrate it with all kinds of different platforms and APIs, like TypeScript, WebAssembly, AssemblyScript, React Native, Chrome Embedding Framework, Electron, and all the apps like PhotoShop you can script in JavaScript.
Even Adobe finally figured out they should use the real thing instead of jerking you around with ActionScript or some other weird language like AppleScript.
UnityScript sucks much much more than JavaScript, and has none of its advantages of tooling, libraries, running in every browser, etc. It's a terrible idea to make or use yet another language that's almost but not quite entirely unlike JavaScript.
Who’s boycotting JavaScript? I’m still using it. I’m writing JavaScript libraries right now.
There’s not really a hard line between “compiled” and “interpreted” languages, and there is really nothing that makes JavaScript beat “compiled” languages for dynamic extensions and scripting. The only advantages that JS have here are in the work that we’ve put into e.g. V8 and SpiderMonkey, but those are a bit harder to drop into your project as a library than you might like. I don’t see how they’re radically better than, say, Mono, which accepts any language compiled to CIL (and has P/Invoke!).
I’ve done some pretty deep comparisons of extension languages and my conclusion is still the same—differences in language implementation dwarf differences in language. You need a sandboxed extension language? That’s an implementation issue. You need to avoid dynamic libraries or run-time code generation? Implementation issue.
There certainly is a hard practical line, the build time / runtime line. And the hard line of publishing an app on the app store. No reason to get all hand-wavy or invoke Turing completeness. I'm not talking in the abstract here. I'm talking specifically about Unity3D, the il2cpp tool chain, and also the Apple app store, and specifically comparing them with V8 or whatever runtime JavaScript engine your favorite browser uses, and its runtime debugging tools. All the work that's been put into JavaScript that we all benefit from is the whole point.
C# and UnityScript are compiled at build time, not at runtime. JavaScript is interpreted or compiled at runtime. That line is very hard and crisp and well defined and practical, not a matter of principle of computer science pontification. Unity apps can NOT interpret or compile C# or UnityScript code at runtime, period.
And for many hard reasons, technical and not: It's a violation of Unity's licensing agreement to ship the il2cpp compiler with Unity apps, even if it were technically feasible (which it's not). It's a violation of Apple's app store policy to ship any kind of interpreter or compiler with an iOS app, other than their own JavaScript engine. None of those rules are going to change. You can't cross that hard crisp line.
You don't need to drop a JavaScript engine into your Unity3D WebGL app, because your WebGL app is already dropped into the JavaScript engine of the web browser itself. UnityJS simply uses that one. And iOS and Android have very fine web browser components that have perfectly modern JavaScript engines which are quite easy to drop into your app, and work quite well, which is what UnityJS uses on those platforms.
Show me a Unity3D app that runs on WebGL or iOS or Android, that compiles code at runtime. If you can link to a github repo so I can so how the code actually works, that would be even better. And I'd love to hear from the developer first-hand how they convinced Apple to bend their stringent app store rules just for them, but nobody else.
Now tell me honestly, how do Unity's C# and UnityScript debugging tools compare to Chrome's and Safari's JavaScript debugger? Do you actually use them yourself? Have you been able to use MonoDevelop to debug an app compiled with il2cpp on iOS or WebGL? What's your magic trick? It doesn't work for me. It's simply not supported. Where to I click to make it work? Please link to a youtube video with a tutorial.
And even if you used the Mono runtime, which is deprecated and not supported on iOS or WebGL, it is extremely buggy and unreliable even on platforms where it works, and absolutely and objectively sucks compared to the JavaScript debugging tools. It doesn't even let you interactively evaluate C# expressions, redefine functions, or edit and continue code, which the Chrome Debugger does quite well, and even Microsoft Visual C++ has let you do for decades.
So let me try to rephrase it for you: The position JavaScript occupies is great. No other language occupies that position, or will in the foreseeable future. It's such a great position, that in spite of all your disdain for it, you (and millions of other people) are using and writing JavaScript libraries yourself, even though you hate it. That's what I mean. JavaScript may not be great at making you happy, but it's great for solving common real world problems, in a way that no other language can.
This conversation has taken a very disappointing turn, and it just feels adversarial now. When you say something like,
> And no matter how bad it [JavaScript] is as a language, it still beats compiled languages as a dynamic extension and scripting language.
In a normal conversation, I can disagree, and we can argue all we like about the reasons we like or dislike various languages for dynamic extensions / scripting. Maybe I might learn something! But no, I'm just reading a monologue that you wrote about why JavaScript is better, filled with arguments that I've already heard.
Especially when working in an environment where Quaternions[0] are a core concept and one which often must be manipulated. Never mind JavaScript's inability to encapsulate.
Eh, I don’t buy that reasoning. JavaScript is excellent at encapsulation, since you can just use closures. Never had a problem manipulating quaternions in JavaScript. I’ve written a few 3D games in JavaScript or TypeScript. Some using engines like Three.js, others using bare WebGL, and some using math libraries like glMatrix, others using math routines that I wrote.
It was a javascript-like language called UnityScript, that actually compiled to IL, and had a lot of C#/CLR features tacked on top. It was fairly unused, and kinda cursed to boot.
Unity also had another language called Boo, which was fake Python which also compiled to the CLR, and we're happy that's dead too.
There's some packages like MoonSharp which will let you write Lua for Unity (modulo some bindings), and a few visual scripting tools too. There's also going to be a native visual scripting tool coming out in the next year or so.
One important distinction is that C# and UnityScript and Boo are build-time compiled languages, not interpreted (or JITted) at runtime like JavaScript typically is.
You can't dynamically download and interpret UnityScript code at runtime, or include it in downloadable asset packages.
If you make any changes to your app, you have to release a new version of it, and convince users to upgrade, and you can't just push an update out over the web, like you can with JavaScript.
This comes into play on the Apple app store.
Even if you implemented, say, a Scheme interpreter in C# that could interpret s-expressions at runtime, Apple would not let you publish an iOS app on their app store that downloaded Scheme code and interpreted it. It's not impossible or hard to do, but it's simply against their rules.
On Apple's app store, the ONLY language you're allowed to do that with is JavaScript, running in Apple's own Safari web browser's JavaScript engine.
That is a hard non-technical constraint that there is no way of programming or negotiating your way out of, and it's not going to change any time soon.
The old version of the iOS Safari component, UIWebView, runs in-process, and allows you to call back and forth with native code (it has a nice native Objective C bridge), but it did not have a JIT so it was slow. (Sandboxed iOS apps developed outside of Apple aren't allowed to write to code memory, so JIT compilers are prohibited.)
But the new iOS Safari component, WKWebView, runs in a separate process that Apple trusts, and it has the JIT enabled, so its JavaScript engine is extremely fast and robust, and fully compatible with most modern JavaScript libraries.
But you can't call native code, because it's running in another process, and doesn't support an Objective C bridge.
But you can send messages back and forth (tell it to execute JavaScript code, receive JSON or text messages back from JavaScript, but no directly passing pointers or calling functions).
So instead of using a platform specific Objective C <=> JavaScript bridge like the one Apple deprecated, UnityJS has a cross platform C# <=> JavaScript bridge with a JSON protocol, so it works fine with WKWebKit, without breaking Apple's app store rules.
I've been developing UnityJS for scripting and integrating Unity3D with JavaScript, which works not only very well with the WebGL platform, but also on iOS, Android, and desktop. It's a work in progress, so it's low on tooling and documentation right now, but I've been using it successfully for quite some time for a lot of different things, and making a lot of progress towards modularizing it, documenting it, and making it easier for other people to use. Please contact me if you're interested!
Developing and applying UnityJS, an open source Unity3D C#/JavaScript bridge for rapidly developing and deploying dynamically extensible cross platform Unity3D apps programmed in JavaScript, and efficiently integrating Unity3D with off-the-shelf and bespoke web technologies and services.
Seeking to collaborate with people who can see and benefit from the obvious and subtle applications to rapid prototyping, exploratory iterative development, interactive debugging, live programming, deeply integrating web technologies and JSON with Unity3D, scriptable VR and AR platforms, and delivering open-ended extensible 3D browser-like applications on WebGL, mobile and desktop platforms.
I've been developing and supporting the open source UnityJS core by integrating both popular free Unity and JavaScript libraries (i.e. JSONDotNet, LeanTween, TextMesh Pro, UnityGLTF, SocketIO networking, Ace code editor, d3 visualization library, etc) and proprietary libraries and extensions (i.e. JauntVR SDK, MapBox SDK, your own SDK, or bespoke code that I develop), so they can all be easily and efficiently scripted and orchestrated together in JavaScript.
So far I've applied UnityJS to JauntVR's panoramic VR video player on Android, WovenAR's scriptable AR platform on iOS, and ReasonStreet's interactive financial data driven visualization system on WebGL, and I'm looking for other interesting people to work with on exciting and fitting applications for UnityJS!
You're confusing UnityJS with UnityScript, which is a common misconception. I wrote about the anathema that is UnityScript in another posting to this thread, and it is a completely different thing that the standard JavaScript engine that UnityJS uses.
UnityJS seamlessly supports TypeScript and all the standard JavaScript based libraries, languages, development tools, and linters, just like any browser or node.js server does, while UnityScript is nowhere near compatible enough with standard JavaScript to compile the output of the TypeScript compiler, it's not well supported by many IDEs, it's way behind the latest version of JavaScript, has non-standard half-baked extensions, and it is not capable of running any of the millions of standard JavaScript library, like UnityJS can.
So how do you like the C# and UnityScript debugging tools on the iOS, Android, and WebGL Unity3D platforms?
How does MonoDevelop compare to the standard JavaScript debuggers built into all web browsers, and their interactive consoles and data structure browsers, which support remote debugging of code running on mobile devices?
Can you set a source level breakpoint on your C# or UnityScript code that's running on an iOS device in a WebGL/WebAssembly based browser?
And how long does your typical Unity3D application take to compile and deploy, before you can see the changes you made to your code?
(I know the answers, I'm just asking rhetorically, because you know the answers too: Debugging Unity C# or UnityScript code totally sucks, especially on mobile devices and web browsers, and recompiling it is glacially slow. The MonoDevelop debugger is terrible, and it doesn't even support the il2cpp back-end, which includes iOS and WebGL, and it barely supports the deprecated Mono back-end, and crashes all the time if you can even get it to connect for a few seconds. Those are extremely painful problems that UnityJS solves.)
If Unreal or Cryengine took the effort to create better learning resources like Unity does, they would grow dramatically. To find the name of a function I need in the c++ is a research project involving a dive through years of old forum posts.
We (a FAANG) are actually looking for a dev experienced with Unreal on mobile devices. If anybody sees this and is interested, hit me up. Contact info in my profile.
Edit: Added emphasis that we're looking for an Unreal mobile dev, not Unity.
I used both Unreal and Unity at FAANG. VR and AR apps are obvious use cases but you find the engines in all kind of random places. Especially common in ML research groups for scene and environment understanding
Nintendo and Microsoft have their own custom engines and toolchains for AAA games. Unity gets used for casual titles where teams are smaller, roles are less specialized, and high performance rendering isn't as big of a priority. (Not that Unity is slow, it's just behind the curve of Unreal and the custom engines of big studios)
The safe bet for Breath of the Wild is to assume that Nintendo used an in-house engine. Although it is public information that the dev team used a modified version of Havok as the principle physics engine.
Yes - Unity supports the Quest (through Link mode). You can check out the XR Interaction Toolkit [1] for an easy way to get going with teleport locomotion.
You don't need to use Oculus Link (PC); Unity can build and deploy straight to the Quest itself (Android). That said, it's a lot more convenient to iterate in Link mode when possible due to how slow the Android build process currently is.
Most of the development you'd do for Oculus is 90% the same with what you'd do for any other game, so I'd say yes, but you'll need to supplement with tutorials specifically for Oculus/Unity.
What does the other 10% entail, when creating a VR game vs. a (first-person) 3D environment for PC? I'd never pondered this, and am curious exactly which elements are any different whatsoever. The only obvious thing that comes to mind is making the camera smooth and flexible in terms of variable degrees of leaning/bending/crouching.
You actually want the opposite, as little artificial camera motion as possible. The VR SDKs feed you the camera transform and settings against a reference point so you don’t need to do anything special except render a view from that. The organic platform comes with all the motion smoothing built in. If you watch VR footage you’ll get a feeling for how wobbly people’s heads actually are.
In terms of level design VR has a looot more fidelity of input so the interaction design is richer and consequently there is more to setup. Game spaces tend to be less cluttered and have some slightly distorted dimensions. Both are more noticeable in VR. Games tend to have more fixed sight lines, the player is stood, crouched and maybe prone at most. In VR people will stick their heads everywhere.
Particularly when players have any level of knowledge about what kind of complexities or edge cases are likely involved (eg. any software developer or QA, even if not part of the gaming industry). Or... hell, maybe it's even worse when you have ignorant players who expect the VR environment to mimic real life so perfectly that they get frustrated and can't understand why certain actions aren't supported/working.
The first VR game I got to experience was one of the haunted house horror games, and you're damn right I bent down and tried to shoved my head into an open cupboard just to see if the collision detection stopped at the outer box of the model, or whether my head would be allowed to enter the space. Then repeatedly leaned/shoved my head against VR walls at various angles to see if I could get the camera to clip or bounce/reposition jarringly. Poor, poor developers who have to try and nail all that logic perfectly. It must be so rewarding to see final results when everything works out well, though. :P
I'm curious with this being the case why there don't seem to be more ports of existing games. Seems like most titles are either developed new or virtually rebuilt from ground up - is it because the gameplay mechanics are so different? or other technical reasons (performance sucks if you just use your existing design etc).
Basically, VR as a platform requires a completely different input system if you want to make anything but the most basic game. Game engines by themselves fit very well with digital (buttons) and analog (sticks, triggers) inputs, but none handle positional and rotational inputs properly.
Yes it's rather easy to have the 3D hands tracked ingame, but VR requires much more affordable interactions than a regular 2D game, and that is way trickier to handle.
A practical example: In the Half-Life games, a common trope/puzzle is finding a door (or some other blockage) that has one of those "submarine hatch" type hand crank to open, but it has been misplaced.
In the 2D games, you just need to pick up the crank, go to the door, and hold the interact button on the placed crank to spin it. But in the latest installment (Alyx, which is in VR), you have to actually grab it with your hand, carry it to the door, snap it into place and spin it.
So now technically you have to handle physics joints between the hand models and the crank, ensuring it visually stays attached, but also tracking the position such that if the player moves away while holding the crank their hand doesn't just stay there forever.
And since the player is still physically allowed to move their arms with the model attached to the crank, you have to ensure other interactions that depend on tracked position do not engage, such as grabbing items from the backpack.
That is way more effort than just checking line of sight to a collision box while a key is down, and playing an animation. And writing such a system (even with the provided frameworks) is still a lot of effort.
That, and the level design has to change a lot between 2D and VR games, due to how a player can do tricky things like crouching to see under objects, and you as a designer/developer can never stop the camera from moving.
I'm in the same boat - I think the Quest has amazing potential as a platform, would love to know more about how to get started with development for it.
Get them while you can. The only up to date/interesting courses are in learn premium. All the free ones are _years_ old and most just do not work in current versions of Unity.
No it won't, because it doesn't have the GUI tooling at the same level, an optimizing AOT compiler for .NET, ability to write engine pipeline stages in .NET (DOTS), the quantity of items in the asset store, the sponsorship from Nintendo/Google/Microsoft and most important, it isn't part of the curriculum of many top level schools in games design.
You're right, because Godot's GUI tooling is incredibly beyond anything Unity offers (and I say that as someone who primarily uses Unity).
Unity's GUI solutions so far are plagued by terrible performance on the common usage scenarios, terribly undocumented when it comes to making your own components, and the layout system is simply a big mess.
While Godot's isn't anything particularly worth praise by itself (especially when compared to dedicated UI toolkits), the simple fact that creating a simple 2-screen interface does not melt a mobile device's CPU puts it far beyond Unity. That, and the layouting is relatively saner.
So much so, that at the company I work for (which is sort of consulting, not products), when we need to do 2D or UI-heavy games, we go to Godot, to the extent of training Unity developers on it instead of trying to make do with Unity's UI.
I do agree on the other points though, Godot is still very young as a community and so the asset store is pretty vacant.
It has gotten some limited support from Nintendo, surprisingly. They have let a limited number of developers develop for the Switch using Godot on a new SDK.
Oh, I honestly would have thought it was more. I'm not saying that it's a level playing field. I'm just saying that Godot is making some in roads to normalization and hitting mainstream acceptance in the games industry.
Unity currently does not even have a stable solution for multiplayer. The existing one (UNET) works but is slated for obsolecence by a new solution, but that is still very early in development, so you have to reach for third-party tools to be able to work with a supported platform.
What makes you say that? Other than a belief in open source and a sense of optimism?
Do you have a firm grasp on the weaknesses and gaps in Unity as well as it's strengths? Would you say you have a clear understanding of the breadth of features and how much they matter to it's primary markets?
I'd love you to be right but you'll need to do more to convince me that you have some special insight in this matter.
As an experienced web dev with recent (professional) unity exposure, I can say while it is overall a productive framework, it's definitely a bit messy. Many things feel incomplete, important features like addressable feel needlessly complex, and their web services quality (documentation, support, status notifications, etc) is wanting. Not unsalvageable or unusable, but didn't strike me as high enough bar to keep a quality competitor out. If I were starting fresh I would take a hard look at the competition where as going in id assumed unity was going to be an obvious frontrunner.
It doesn't seem like a bad choice but it's definitely not secured it's lead.
I really doubt it. Maybe one day but certainly not "quickly" and especially not just from Vulkan.
I want to like Godot but it feels like it's making the same mistakes Unity 5.x and earlier did with fixed shader and script languages that just aren't as useful as the languages they're abstracting. I want to use GLSL or Vulkan or DX12 not a custom language that will get in my way. Its a C++ engine that uses script runtimes like Unity did. This makes it hard to optimize across languages and why Unity went down the whole IL2CPP path. Now Unity is moving more and more features into C# with a custom C# compiler to better optimize with user code. Godot will have to succeed where Unity could not.
Godot looks very promising but if you don't think its an uphill battle or that Unity is easy to beat you're mistaken.
As long as the gaming hardware giants (consoles and VR) continue partnering closely with Unity and Unreal and giving those engines several months of lead over open-source engines when it comes to platform support... no, it will not.
It teaches from very basics, at the same time the projects are diverse and fun because 3D-assets and effects are provided.
Chunk size is perfect, few minutes video and then it's few minutes of work in the editor. Videos have short text summary so there's no need to rewind the video if I missed something.
Often it solves a problem in a naive but incorrect way, and then fixes it. So when I encounter a problem in real project, I often have experience dealing with it.
It has debugging projects, where you have a complete project which is broken in multiple ways. So smart. In my regular programming work I spend most time debugging, not creating from scratch.
The narrator (Carl D.) is charismatic, videos are very professional.
I wish there were more courses with same structure and quality. Can't recommend it enough.
[1] https://learn.unity.com/course/create-with-code