Godot Engine – A decade in retrospective and future
godotengine.org
godotengine.org
> This was an extremely hard decision to make [work full time in Godot], because at the time, my experience (...) was paid a lot more, and I was receiving extremely good job offers(...). [T]he same happened to Rémi (an Energy Engineer), who also changed his life plans and profession to work full time for the project.
It really speaks of the love for the project. I hope the motivation and joy for writing the engine is balanced with the right compensation.
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.
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.)
Usually happens when something is 10x better at something new that people care about that the incumbent is blind to or is structurally incapable of addressing. I'm just wondering what it is in this specific case.
Ease of use? Beginner friendly? Open source so you don't have to pay? The node system makes it easier to do X?
The fact that it's open source is also big, because there are often bugs in the Unity engine that I can't fix since I don't have source access.
A lot of devs also like jumping on new technology because it feels good to learn new things.
Oh and then because it's open source, you can improve the engine and it gives you the "Ikea effect" where you like something more because you helped to create it.
I don't know what the story is with Godot (beyond the breaking changes between 2.0 and 3.0 that was mentioned in the linked blog post) but if that is a lot better then I can imagine that some game devs might be more interested in Godot for that reason too.
Or is it that you can't fully trust them, and you'll need to do that by hand anyway, because you might be one of the exceptional cases?
Do they have a culture of incompatibilities so they can simplify their development and keep the best features and discard the worst?
They make older versions of the engine available in their management app, and projects are linked to a specific version unless you explicitly upgrade.
But those were 2-3 year game cycles. Maintaining a project would be less fun. But it'd be like choosing to do a rails or react upgrade.
And very bad ones, at that; which will persist for years and several major versions.
For instance: let's say you have a game that supports user generated content via loading asset bundles. This being the lowest barrier to entry for games to leverage the unity editor for UGC, it's quite common.
Well, now and always, and known and reported since at least 5.2, any asset bundle that references a class not found in the compiled game client will crash the client on load.
The only work around is to write your own asset bundle inspector and pre-analyse on load.
Unreal also has more features available than both engines out of the box, as far as I am aware. I don't want to sound like an advert, but the shading and Blueprint systems in UE4 are extremely intuitive and easy to work with, and the C++ is definitely managable. I've never used Godot, but the last time I compared Unity to UE4 it felt extremely clunky. Lastly, prototyping stuff in UE4 is fun, once you get used to it and develop your own workflow.
The canonical story is described by Clay Christensen in the Innovator's Dilemma, where the new toy X is inferior to the mature Y along most dimensions. However, something changed in the world, and people are starting to value a dimension where the new toy X is 10x better than the mature Y along a single dimension. And that allows the new toy X to gain a foothold. I'm super curious as to how Godot managed it, even if it has been a long time in the making.
Of course, not all toys end up replacing the incumbent. But by dismissing everything as a toy, you're shutting off a line of inquiry to see how this process happens. If you're on HN, it's a good chance you're a programmer and by definition a creator. And if you're at all ever wanting to bring something new into the world, it'd behoove you to understand how new creations are accepted.
Here's a meme which is actually very illuminating. Someone in the comments mentions checklist-driven development, which seems about right. Unity doesn't feel like a complete product right now, it's full of systems which are either incomplete and badly documented or outdated and buggy.
Or if it's just an inherent complexity in the actual job.
Or if it's an issue with management and product managers that can't decide which users to service, so they do the easy, but wrong thing and try to service them all.
It also works well with Git, which as a coder first, game creator second, I appreciate. I don't think this is the case with Unity, but I am not sure.
Recently I wanted to write a workout game for the Oculus Quest for my own use and I am really impressed how well VR development works in Godot. I have never made a godot game before and never made a VR game before and it is really progressing nicely. An added benefit is that one of the devs has already added experimental hand tracking support. So even if the big game studios do not support it yet godot games can already support it, which is a real benefit for a workout game where you also have to do pushups (unsing the controller is a bit unwielding there)
For those who are interested what a first game looks in godot
First up the added Unity maturity isn't always as helpful as you'd expect. There were many areas that felt very incomplete, requiring us to write our own solutions, or find third party ones often at cost. An example was I believe we encountered strong limitations with the built-in AI Navigation system that made it pretty useless to us. There were third-party navigation solutions, but this sort of summarizes part of the problem with Unity: there is a lot of third party addons, but a lot of them felt like things that just overcome the often confusing limitations of the original product that I already paid money for. Lots of game engines can suffer from being particularly suited for certain genres and not others, even supposedly generic ones like Unity. So if you were making something that was kinda weird and would require a lot of bespoke special work, using Unity didn't really get you any wins.
Godot plays better with VCS systems using a nice human-readable scene format called tscn, that is swapped for a binary format on project export. I find this format is usually readable enough to review scene file changes in PRs, with the usual exception being a scene that was primarily imported geometry data. To get around that we'd import geometry data into bespoke geometry scenes, and they'd be nested by reference into the scenes that you'd like to be able to review diffs on. Additionally this scene format merges nicely in git, and has allowed me to work on team projects and have people edit scene files in their own branches without fear. Unity (and Unreal) at least at the time, had nothing approaching this. There was a Unity text-scene format, but it was a merge nightmare regularly. In practice we ended up using a VCS product (I believe perforce) that allows you to exclusively check out a scene file. Which at least stops people stepping on each others toes too much but hinders productivity.
Unity as of last I heard still does not have an out-of-the-box solution for nested prefabs, with many opting to use a commercial add-on to supplement the short-coming. This feels like it has been the single most complained about Unity pain point, so it was very confusing that nothing really seemed to be happening. Godot uses an approach that I find much more elegant. There's no distinction between a scene file and a prefab, which allows for some nice refactoring where something becomes a prefab after not initially being conceived as one. You simply have the ability to make a scene graph node that is a instanced reference to an external scene, and this nests nicely with no limit that I've ever encountered.
The Unity Editor was a bit of a dog. It regularly crashed and experienced general slowness. I find Godot much more stable snappy, and don't experience anywhere near the amount of tool frustration. But I have heard that it has been quite a bit more stable in the past year or so.
I encountered a lot more weird rigid design in Unity. IIRC if you wanted to runtime load content such as textures or models, they had to be inside of one specific subdirectory of the project. In general Unity seemed to force its philosophy of project organization onto you, while Godot will happily go along with whatever approach you want.
I still think there are reasons to use Unity. It is more mature, companies generally want access to an existing talent pool, and let's not forget that often it is worth sticking to the tool you know. But I definitely have found that I enjoy working in Godot more than I did Unity, and as a fairly experienced programmer I don't mind not having as big of a community to rely on for assistance. I don't work as a game programmer anymore, but I continue to do hobby projects near exclusively in Godot.
I'll have to check out Godot's note system, and it seems like when everything can be represented with the same thing, you have the ability to refactor your code as it resizes and scales.
The choice to move the projects i've been working on to godot though was after setting up some sprite animations I'd set up previously manually using Sfml. What took me almost two weeks originally took me 30 minutes to redo and improve upon using godot.
Also, sort of insiginificant but, I really enjoy the way you can enter equations into any input box that accepts a number and it'll solve it for you automatically. The only other software I've used that does this is alphacam and it's such a handy feature I really miss it when it's not there.
Godot just frees your mind from that side of things, and so in that case, it's a 10x experience if that long-range commercial element taxes your mind.
Is anyone doing VR with Godot? I have a couple questions:
1. What's the development cycle look like? In Unity I can hit play and put on the headset (Oculus Quest w/ Link, so essentially a Rift). No need to export a full build or go through multiple steps. Honestly this is the single most important factor for me since it allows quickly figuring out other problems. Does Godot support it?
2. Unity has made a big deal about DOTS and from initial tests it's legit. For VR on low-powered headsets (ultimate target is Oculus Go) these performance savings matter. How does Godot compare?
3. I don't know C++ and worried that I wouldn't be able to squeak by from bad usage of it. GDScript looks interesting but in this use case performance matters. I am doing a significant amount of Rust these days esp for hobby projects and would LOVE to be able to code in that. Are the Rust bindings to Godot good? Does it interfere with quick iteration? (looking at the repo it's hard to see what's going on and what the impact is on a real project)
Currently you should use the 3.2 Beta and have to install the godot_oculus_mobile plugin yourself, but once that is setup, you have an Android symbol in your Godot Editor and can hit play to get it running on the Oculus Quest headset.
It's reinstalled for each time you hit play, so that takes a few seconds. I don't know how unity handles this.
Performance wise you are on your own I guess, so you should know what to do and what not to do to achieve good performance.
Don't know about language bindings, I am using GDscript as it is close enough to python to get by.
From my point the whole experience was a breeze, given that's it's free and a really small download I would definitely at least check it out before trying something heavier.
Unity also takes a few seconds, it's not instantaneous, but much better than the proper build/deploy route which can be minutes
In terms of performance & lag of the implementation of VR I didn't notice any differences between the two engines.
From my experience with Godot :
1. The dev cycle is I press play and then everything just works instantly. The game automatically connects to the headset and I can see the game both on the screen and in the headset. No build, no exports, nothing. It just works. From what I understood this is mainly thanks to Bastiaan Olij' work, so big thanks to him !
Also VR support in Godot has a "native" feel, you have AR/VR nodes ("ARVRCamera", "ARVRController", etc.) in the engine. I spent less time setting up VR in Godot than in Unity.
2. I never used wireless headset so I can't compare battery usage. For wired headset at least, in terms of performance Godot is far sufficient for making games like any of the popular VR games out there.
As a big rewrite of the rendering engine is going to happen for 4.0, I think we should wait for this before making comparisons of rendering perfs.
3. Godot has support for GDScript , C#, and "others" (via NativeScript). In others we have C++, Rust, Python, JS, etc. I never used any of those other languages with Godot so I can't tell. It seems the setup of NativeScript is quite complicated and much less convenient to use than C# & GDScript, but I'd also like to hear from someone who used that.
However it's a UI problem and I don't see why in the future NativeScript couldn't be just be as convenient (maybe we indicate once the path to GCC and Godot automatically download the NativeScript headers, set up everything and compile automatically on play)
Also for performance intensive tasks there should be compute shaders in 4.0 and it was also mentioned that compiling GDScript AOT (maybe by transpiling it to C or targeting LLVM) should be doable (GDScript' static typing is a first step in that direction).
From my personal experience, Godot is such a breath of fresh air compared to Unity where everything seems messy and overengineered. There is no prefab or other wierd things. Just nodes in trees and scenes. It makes everything so much cleaner and more enjoyable to develop with. Unity seems to pile up the latest shiny features on top of each other but without thinking about overall coherence.
However the popularity and $$$ of Unity gives it many advantages in terms of support , tutorials, asset store, more features, etc.
So I would recommend Godot :
- if you like clean architecture
- if your VR game is not more graphically ambitious than popular VR games or if you're okay to wait for 4.0 (then it should be on par with other engines)
- if you don't need YouTube tutorial for everything and you're okay with reading the doc API.
- if you are used to code your own logic & assets and not to rely heavily on the Unity asset store (you can consider Godot asset store is basically nonexistent in comparison)
Linux native gamedev is possible!
You get to test the product without waiting for feedback from the real world and you also end up with a test suite (in effect) for free.
Back in ye olden days the first assembler was written in machine code. The first C compiler was written in assembly, and the first D compiler in turn was written in C.
The explanation of how a compiler can be implemented in its target language still holds though.
What got me started with Godot was the fact that it is completely open source, and I was evaluating also writing my project with Rust, and Godot had already support for interfacing it's scripting interface NativeScript even with Rust already (although much work in progress).
Ultimately I decided to develop the project with mostly C++, but during learning the engine I noticed that GDScript is very capable and seems even faster than Lua at least according to my 2 month experience, mostly coming probably from the fact that it has native types like vectors and matrixes and so on integrated directly into the scripting language and implemented with C++.
I was pleasantly surprised how easy and logical the engine is to use, they've made a lot of correct decicions when it comes to the technical viewpoint, for example getting engine scripts written with C++ was very easy, which surprised me.
The documentation is also very well written, with up-to-date examples and I haven't seen any missing information yet.
Only thing I've been missing is more complete examples of games utilizing C++ for example, and more complete projects to be looked at as an example. Most of the projects I could see were written mostly with GDScript, so I would have wished to see more indepth and professional examples in how to write performant projects using Godot.
But mostly GDScript even seems to enough to implement most of the game or application logic.
For me though, the fact that the engine is open source and that people are actively fixing issues in it, and I can even contribute myself is a big factor. The MIT license also grants me to do whatever I want with the end product, which is a big plus.
I hope to contribute to the project as I go along, been looking at the source code and it's really readable also, the architecture is pretty solid and clean at least according to my quick evaluation of the project.
I'm projecting great success for Godot in the next year, especially with the upcoming Oculus Quest support already well under way, this could be a easy and more flexible way for people to get into VR development possibly.
Godot looks pretty good. Is there anything else you've had success with?
It's as simple as the BASIC language that comes with the calculator, but it compiles to assembly so it's lightning fast. And you can write and build the entire game from your calculator. I spent hundreds of hours making games with Axe back in high school.
https://ramilego4game.itch.io/liko12
And then there's the BASIC engine:
I keep on getting really curious about Godot, it seems like an engine that should be up my alley, and I really am in the market for Open Source engines. I don't want to keep coding everything myself.
But I'm a little thrown off by the idea of learning a new scripting language, and dipping into C++ for an engine like this seems counterproductive. If I cared that much about memory management, I'd probably write a game-specific engine again.
What sold you on godot over unity?
Thanks for pointing it out, I'll take a look at it.
(edit: I am using the fancy renderer in favour of the old surface manipulation; I guess that's a step up, comparing the code)
I can really see Godot becoming the Blender of game engines. Kudos to the team!
I can’t remember if the team is getting outside funding from grants or such, but this is the main payment system I believe.
https://godotengine.org/article/godot-engine-awarded-50000-m...
How is continuing development not "support"?
Should I look further into Godot Engine, or is it more of a "heavyweight"/loads-of-features engine like Unity and Unreal?
I tried Unity, but it really feels like an overkill for what I want. Both Unity and Unreal are really geared more towards 3D, and to me they complicated 2D development because of it.
Also check out https://defold.com/ — it’s an excellent game engine that perfectly suits your 2D/mobile/lightweight requirements. The team behind it (at King) are very active both in listening to the community and with their release cycle. It has a bunch of features bigger engines still lack (hot reloading, fast testing cycle and export process).
They shut down the dashboard/analytics service and offer opt-in analytics add-ons and third-party analytics services now: https://forum.defold.com/t/announcing-dashboard-and-analytic...
I believe both of those are now no longer required though.
There's not a shred of truth in the above statement. We offered an OPT-IN analytics services that provided you, the developer, with install and retention numbers for your game. No one at King or in the Defold team ever looked at any data. King has hundred of millions of monthly active players of their own games. That's enough data. No need to try and steal data from anyone else...
The optional analytics service along with the optional project hosting was shut down four months ago.
We do use Google Analytics for www.defold.com and the editor. This is clearly stated in the terms and conditions. And it's pretty standard stuff in the industry to keep track of product usage like that.
As you say, things have changed and we have worked hard since the launch three years ago to show our community of developers that we are serious about Defold as a professional choice for game developers and that we do not have any hidden agenda with giving Defold away for free.
I didn't quite understand that part. What legal reasons prevent them from making ports for consoles? Do consoles ban open source projects?
Also, are they planning to use some translations layers like for DX12 and GNM from Vulkan when working with Xbox and PlayStation? Would be nice if gfx-rs could offer a GNM target for the Vulkan portability option.
Alternatively, Sony and MS can of course start offering an option to use native Vulkan, as they should have from the beginning.
You can't publish any code that calls non-standard APIs. So therefore any code that interacts with those APIs cannot be open source.
You would have to publish a seperate extension to the engine that is not open source and make it only available to those who have signed the Developer Licence Agreement for the platform. Depending on what licence you chose or how the code is structured that might break your own open source licence.
Sounds very much like paranoid '80s - '90s approach where everything including development tools was viewed as some kind of super guarded secret. But I guess incumbent consoles are stuck in that mindset. They should realize it's been a different century for two decades already. Hiding an API is not helping anyone.
And older isn't the reason not to offer Vulkan for developers. Nintendo managed to figure that out. So it's not "no", unless they are dumb and stuck in extreme lock-in mentality.
Very few Switch titles actually use Vulkan.
Just like GL ES 1.0 on the PS 1, it is more a box to tick than anything else.
I.e. targeting Switch for them aligns well with their current Vulkan work. Targeting PS or Xbox - not really, they'll need to rely on translation (like gfx-rs), if one even exists. I'm not sure if anyone implemented Vulkan → GNM translation yet.
Any production grade, cross-platform engine, has so many extensions and workarounds for drivers and cards, that each code path ends up looking like a different API is being used.
They are common only on paper, write once, patch everywhere.
In fact, if you want to use OpenGL in a way to avoid such mess, OpenGL 3.3 is probably still the best target to hope for, with all the constraints that it entails as legacy version.
Just like on mobile devices, as Godot was forced to redo their engine, anything beyond OpenGL ES 2.0 is more headache than it is worth.
Google has made Vulkan a required 3D API on Android, because most drivers outside flagship devices are unusable and they hope that via this option to force OEMs to actually provide something that developers can actually make use of.
So much for "portable" APIs.
OpenGL is legacy case, so no point in bringing it. Vulkan is the only common API, there is simply nothing else for that role. With all your talk about how "great" proprietary APIs are, none of them ever can be common, because they all are the total antithesis of it - their goal is lock-in in, not something that helps developers reduce their work duplication by providing the standard.
So so much for "great IP". They are DOA basically in this sense, and exist only because walled garden owners force developers to use them by not providing them a choice.
Your personal advocacy for lock-in is also more than questionable.
Middleware is the common API.
Taking advantage of raw performance from hardware, exposed with SDK tooling that Khronos has never offered.
Basic stuff like math, loading textures, material description formats,...
Instead every newbie has to go through the challenge of creating their own little engine.
My advocacy is based on real experience, having been IGDA member, attending a couple GDCE and Design School meetups, having had the opportunity to visit a couple of well known AAA studios.
So I have enough hours talking with such devs to know what they care about.
Being religious about 3D APIs is usually not on their agendas, rather getting customers, turning game ideas into IP that they can explore across various commercial channels, consulting opportunities porting game engines, how to take advantage of "whales" and such stuff.
The node system seemed weird to me at first, but it's really grown on me. I can heartily recommend the engine now.
I know it’s not built into Godot because all the sdks/apis are behind NDAs for the consoles, I was wondering how difficult it is, what it entails and if anyone has experience going the suggested route of hiring the company on the Godot site to do the porting.
More so than performance this would be the biggest blocker for Godot I would think ( not that it’s in any way it’s Godot fault ... it’s consoles being consoles )
The engine's simply fantastic from a programmer's perspective. The code is readable, the architecture is quite intuitive, and with the exception of a few engine components, you don't run into much in the way of incomprehensible spaghetti code.
Adding features is more or less trivial, as has been merging upstream modules from more modern branches into the project.
I see a bright future for the engine, especially after the 3.1 update, and I anticipate that it'll start seeing significant commercial adoption in the second half of this decade (it needs a few more years of refinement and PR).
The release of the Vulkan renderer will be a massive boost to public interest, and developers will increasingly consider it for their next projects.
That said, I do have a few concerns about its development. I'll preface these critiques with the fact that I'm working from 3.1 stable, and have only merged from 3.2 as needed.
There's a wide-spread conception among the Godot community that Godot's performance (especially in 3D) is abysmal. This has been blamed on a number of factors, such as the memory model (largely heap-based), and the rendering engine (it uses quite a bit more cpu time than it needs to).
It is exactly the second-issue that has lead many community members to see the Vulkan renderer as Godot's salvation. I can't speak to that, but as is, many of the criticisms Godot faces are legitimate.
But among the projects I've seen where performance has been an issue, it's largely been the product of a developer's failure to understand how the engine is processing their content, and by extension their failure to architect their game around that.
This is an issue many inexperienced developers run into on just about any engine. Godot also lacks editor tooling that would allow anyone but a programmer to easily mitigate these issues in a scene, even if they knew where the performance issues were. This, compounded with the fact that Godot has largely focused on accessibility first and foremost has resulted in a lot of inexperienced community members without much understanding of the engine's internals to discourage people from even trying to adopt the engine for 3D projects until 4.0.
I hope that 4.0's release will be enough to minimize what I believe to be largely a PR issue, but I also fear that the inevitable bugginess that comes along with an entirely new rendering architecture may just exacerbate them, or that it will simply fail to live up to the expectations of many people who expect a more modern renderer to somehow fix their poorly considered code.
I'm concerned that this will slow the engine's development with respect to its tooling, as there are few people really testing the bounds of it's capabilities and workflows.
What are some pitfalls everyone is falling into and what needs to be understood conceptually about how the engine processes scenes?
I’ve found a lot of good documentation and videos on getting started and particular workflows (eg animating), but haven’t see any regarding performance optimization or what Godot is doing “behind the scenes”.
But I'll also caution you not to worry too much about performance until it becomes an issue for you. You want to make something, first and foremost. And a lot of developers just getting into games tend to severely underestimate the amount of work their processors can do before it becomes an issue.
The most easy two to fall into are improper draw call management (requests made to the GPU to draw an item), and not accounting for the engine's lack of native occlusion culling (it ends up drawing items obstructed from view by nearer or larger objects).
The first is an easy fix. The engine draws objects using two object-types: MeshInstance, and MultimeshInstance. For each MeshInstance you have, you're going to have a single draw call to the GPU, and the overhead of that really adds up in more complicated scenes. It's generally a good idea to batch multiple objects with the same display geometry into a MultimeshInstance, which will send a single call to the GPU with a list of transforms to assign to that specific object. This minimizes the communication overhead between the CPU and the GPU.
The problem with this is that the MultimeshInstance has (to my knowledge) no in-editor tool for managing its transforms. It has to be done through a script.
For the time being, I've written a script that enumerates all MeshInstances in my scene that share a material and display geometry, and assigns them to a set of evenly spaced MultimeshInstances based on their position in space (this prevents the GPU from attempting to render too many instance elements that are off-screen).
Occlusion culling is trickier, and outside of manually setting your own visibility lists for objects, and deactivating them via script at runtime when they're out of sight, there's not too much to be done other than to keep overdraw in the back of your mind right now.
Less specific to Godot, there are a number of optimizations you can make that work well in any engine.
- LOD (level of detail) geometry:
Godot doesn't natively support object LODs (different resolution versions of objects displayed at difference distances). This can be rectified fairly trivially by toggling different MeshInstances at different distances from your parent object, and can go a long way to reducing the amount of rendering overhead in your scene.
- Shadow casters are expensive:
If you're got a light that casts a realtime shadow in your scene, you might as well be rendering the scene twice (especially in Godot, since there's no occlusion culling). Even if you don't have a LOD system in place, I recommend using a lower-resolution version of your scene to cast shadows, and even disabling shadow-casting on smaller objects. This can be done by adjusting the visibility mask in your shadow caster.
- Minimize Texture Sampling:
If you're writing your own shaders, keep texture lookups to a minimum, especially on large objects.
- Adjust the physics tick:
The physics simulations in most modern game engines run at a fixed rate, usually somewhere between 30 & 60hz. This is (mostly) decoupled from the game's frame rate. Godot lets you set the update frequency from its project settings, and I recommend you play with that number until you find the minimum value that works for your title.
- Stagger object updates:
If you can get away with running an update less frequently than other elements in your game, do that. A good example is running the decision loop for your AI every nth game tick, or every nth second. Batch your AI into n groups, so you end up doing 1/n amount of the processing you otherwise might have been doing per-frame.
- Try to offload purely visual things to the GPU if at all possible:
I've seen a few people writing scripts to add real simple motions to visual elements that weren't directly related to the game's simulation. A good example would be a quest marker bobbing up/down above a character's head. This is something that could easily be done on the GPU using the vertex function of a shader, and represents an absolute waste of CPU time.
- If you can get away with it, lower the visual fidelity in your project settings:
Pretty self-explanatory. Especially when editing your project, you'll experience a much lower (nearly half) the frame rate you'll see at deployment at runtime. It's to be expected, you're running debug code, and an editor. Disable some of the extra visual features if they're only icing on the cake of your game's aesthetics so you can get a better idea of your title's actual performance.
This was the only thing I could not easily find when trying to peruse the projects utilizing Godot online.
[0] https://www.gamefromscratch.com/page/Godot-3-Tutorial-Series... [1] https://www.gdquest.com/