I wonder if Godot has a chance of becoming the Blender of game engines. From the way it is growing it's starting to look like a real long-term possibility to me, especially for the smaller game studios.
Though the Blender situation is a little different. Blenders main competition are paid software. While Unity and Unreal are technically paid too, many users can use them "for free" for the most part.
Unity and Unreal are both foraying into non-gaming applications like Cinema, and whatever the word is for working with architectural programs/formats. Might be an opportunity for Godot to stay focused and gain mind share that way?
I know Unity is under a bit of an upheaval right now with their engine architecture and it's putting a lot of strain on it's userbase.
Care to elaborate?
DOTS doesn't seem that vague to me.
I've been making a game with DOTS for the last year, so I've been following this pretty closely. DOTS is what convinced me to use Unity because I hated the old Unity way of doing things.
There are several tutorials and Unite talks on Unity's YouTube channel.
ECS, the job system, the Burst compiler, large rewrites of several systems into C# from C++ (and more if you want to break out things like animation and physics rewrites) all fall under DOTS. These are all fine changes but they could all happen on their own. DOTS is not a technical term. Unity has just decided to wrap this all up into the more marketable DOTS name.
They really couldn't all happen on their own. They wanted to write more code in C#, so of course it makes sense that they'd start with the new systems they were making for the ECS. To support being able to write more in C# they developed the burst compiler. And the jobs system is a huge part of the way they developed their ECS system.
DOTS really just means Unity ECS plus a lot of other stuff that exists mostly to support ECS, and some stuff they've wanted to do for a while but it makes sense to add now since they are changing so much of the public API anyway. They brought Mike Acton in and "Data Oriented Technology Stack" is just all the stuff they needed/wanted to realize his goal of making things more performant/data oriented.
They were just calling all of their re-architecture ECS until a little while back, but it was kind of weird and ECS is already a severely overloaded term.
Would you be less upset if they called it "The re-architecture" instead of coming up with a convenient name for the new way of doing things?
With most game projects, the point is to ship them once and then start anew with the next one - long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business - they can afford to keep around the staff dedicated engine work for the long run. The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.
If they were to start from scratch, DOTS would be missing so much functionality that it wouldn't really be useful. By essentially using the strangler pattern, they are allowing people to get access to the newer architecture immediately, and then gradually adding more and more over time. Eventually, years from now, they will completely replace the old architecture. I'm sure there will be some version of what you're talking about here
>as long as the previous engine has the proverbial lights kept on
with the old architecture.
> long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business
That's less the case these days with plenty of indie games produced by very small teams that are in early access release/development cycles for years. It's also very common to reuse existing codebases for new games.
>The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.
The outcry over Unity abandoning the old way of doing things is pretty loud. Many people use Unity for multiple projects, and they get mad when Unity makes big changes that invalidate their knowledge, which is one reason Unity is making the changes so slowly.
It might help them get some perf but its not as user friendly, nor trivial, so in Unity fashion they're just going to have several systems available is less than perfect interopt.
They're also rewriting more things in C# but I think that's a pretty good change, personally.
Which, in many cases, is way worse than the alternative pricing model.
With Unreal Engine, there is also an exception for hobbyists, specifically you only have to pay 5% to Epic if you make more than $3000 in a quarter.
No real reason for preferring C++ except I want to learn it, and my pet project is a little game rather than yet another web app/thing that renders DB records to HTML/thing that takes one JSON blob and turns it to another. I never did computer science so this sort of trial by fire is super appealing to me.
Trust me, C++ is far from computer science (as in, the actual science). You might even be at an advantage if you're more of a hands-on person than a mathematician.
The thing that Unity dropped wasn't really JavaScript, and nobody in their right mind actually used it. It was called "UnityScript", and it was just a thin veneer over CLR that looked a bit like JavaScript, but exposed the CLR object model and C# APIs to arrays and dictionaries, etc, instead of supporting standard JavaScript APIs. The biggest problem was that most JavaScript libraries aren't compatible with UnityScript. Another big problem is that it wasn't as powerful, useful, and standard as C#. And yet another problem is that it wasn't an interactive language, so you couldn't load it at runtime, and had to run it through the compiler (which could take half an hour before you could see your changes).
https://wiki.unity3d.com/index.php/UnityScript_versus_JavaSc...
>It is not uncommon for Unity developers and even members of Unity Technologies to refer to Unity's JavaScript like language as simply "JavaScript", as if it was equivalent or interchangeable with what most people know of as JavaScript on the web. However, the two are actually very different languages. Although they do resemble each other syntactically they have very different semantics. While "JavaScript" is merely a generic name and could refer to any one of many implementations of the ECMAScript specification, Unity's "JavaScript" language doesn't even come close to conforming to that specification — nor does it try to. It's a proprietary language and it doesn't actually follow any concrete specification of standard JavaScript and is modified at will by the engine developers.
>Because of this, the vast majority of JavaScript libraries you find will not work by default in Unity. Unity's "JavaScript" is most similar to Microsoft's JScript.NET, although it is not quite identical. Thus many developers prefer to call the language Unity uses "UnityScript" instead, to help differentiate it. Some people consider this to be "just semantics", but when people call both "JavaScript" it becomes a lot harder to search the internet for solutions and help related to Unity. It's also quite a lot of trouble to continuously specify whether one is referring to "real" JavaScript or Unity's version. So it's best to just stick with "JavaScript" for real JavaScript and "UnityScript" for Unity's language.
Unity also had a language called Boo that was to Python like UnityScript was to JavaScript, and nobody in their right mind used that either. UnityScript is actually a layer on top of Boo. Both UnityScript and Boo are obsolete and deprecated, fortunately, and nobody will miss them. Your time is MUCH better spend learning C# than UnityScript or Boo.
UnityScript’s long ride off into the sunset
https://blogs.unity3d.com/2017/08/11/unityscripts-long-ride-...
On the other hand, I've been developing UnityJS, which lets you program Unity3D in real honest-to-god JavaScript, download and debug code at runtime without recompiling your Unity app (which makes development astronomically faster), and use any standard JavaScript libraries and tools. And it works really well with the WebGL platform, for integrating Unity apps with web stuff, as well as on iOS and Android too.
https://news.ycombinator.com/item?id=19804242
https://news.ycombinator.com/item?id=19748582
https://news.ycombinator.com/item?id=20744552
https://news.ycombinator.com/item?id=20745676
Here's the original github repo:
https://github.com/SimHacker/UnityJS
I recently refactored that monolithic repo into a bunch of smaller nested repos, to make it much more modular and layered, so that different projects for different platforms can pick and choose which modules to use.
Here is the root repo of the new version:
https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...
I'm still in the process of documenting how to install it (now that you have to wrangle git submodules it's tricker), and how to use it (there are a lot of moving parts, and different platform specific pieces). But here is some high level stuff:
Anatomy.txt: https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...
Architecture.txt: https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...
InterestingFiles.txt: https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...
(Some of the paths in the above file have changed in the name of modularity.)
Since Unity insists that you put different kinds of files in certain fixed directories like StreamingAssets (for all the .js files and web content) and WebGLTemplates (for the WebGL wrapper that loads your JavaScript code), you can't make a module with one single github repo that has different sub-directories that would straddle the fixed Unity directories. (And symbolic links don't work on all platforms, so you can't fudge it.) So it is necessary to split some modules up into different repos, so the one with C# code can go into Libraries, and the one with JavaScript code can go into StreamingAssets, and the one with the html wrapper can go into WebGLTemplates.
Here's the repo with all the C# code and resources:
https://github.com/SimHacker/UnityJS_UnityJS_Library
For example, here's the C# side of the JavaScript/C# bridge:
https://github.com/SimHacker/UnityJS_UnityJS_Library/blob/ma...
Here's the repo with all the latest UnityJS JavaScript code:
https://github.com/SimHacker/UnityJS_UnityJS_StreamingAssets
And here's the JavaScript side of the JavaScript/C# bridge:
https://github.com/SimHacker/UnityJS_UnityJS_StreamingAssets...
Send me email if you want to know more! I'm happy to answer questions and help you get it working, and to hear your feedback, which will help me write more and better documentation.
Ouch, this is currently my "pet" project. I totally get what you mean though. I'm honestly not sure if it can even considered a pet project anymore, as it works way better than I expected.
It's no longer completely true, but honestly it's still kind of true. And I've been making my living writing them for years now ;)
Of course, it's not boring to the newcomers and our new juniors. But the step up for me isn't a more interesting problem to tackle, it's leadership. (Although at my current job I do get a few interesting challenges on top of that.)
The good thing is unlike in the photography or the print industry there is no real industry wide vendor lock-in when it comes to formats in 3D, so it's always possible to create a challenger.
Right now Godot isn't really on par with Unity, but it could become the de-facto game engine for Blender in the future if Godot allows deep integration with the former.
Mmm, Blender had a lot of problems having to reverse FBX from autodesk, which AFAIK is or was a de-facto standard. About open standards, I kinda hate xml, so I didn't like Collada much. I'm looking forward for knowing more about glTF[1]. Thankfully Blender 2.8 had the official add-on from the beginning.
Khronos YouTube channel has lots of talks on the format.