A very well written and inspiring post. I haven't used Godot much, but I feel 2020 and the next decade is going to continue growing much more :)
> 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.
This is really something that I can speak to with personal experience. When you believe in open-source software and decide to quit your job because you want to try and build a business around it, it is incredibly scary and fulfilling. You sacrifice a lot so that others can benefit. It's a bit of a life of illusion, but you make do. Good on these guys for providing to the community something that is genuinely awesome.
In financial terms, we are sure that each are paid at least 4.4k USD/mo, based on their Patreon goals. If that is the right compensation is subjective, I'm not familiar with the market rates for that level of experience.
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.
They're moving from their existing Actor/Component model to a Entity/Component/System model.
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.
They are migrating several modules from C++ to C#, by making use of their Burst compiler stack, and have introduced a new ECS based framework named DOTS, on the quest to appease to AAA studios.
I don't think its a AAA request, per se. Unity seems to constantly need features to slap on the box. At this point it feels like DOTS is significantly influenced by the marketing team. I mean, engineers would spell out the features and not wrap it up into this vague concepts of "DOTS."
It's wrapped up in a new concept because it's a complete re-architecture. You do almost everything differently with DOTS. And its driven by the CTO and Mike Acton from what I can tell.
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.
Unity is making some good tech decisions but "DOTS" is just a marketing device so Unity can make vague tech promises without getting into details. Its a blanket rebrand of several technologies Unity is currently pursuing.
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.
>These are all fine changes but they could all happen on their own.
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?
IMHO there is a basic error they're making, which is to do all of this in one product. When they have two internal architectures sharing one interface, the overall scope bloats up, which leads to some miserable UX.
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.
>IMHO there is a basic error they're making, which is to do all of this in one product.
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.
An almost constant criticism of Unity that I hear is that it's "too slow", that games made with it run slower than what their visuals would suggest. This has been such a common criticism of Unity for so long. So I don't think it's solely a response to requests from AAA studios either. My impression is that the current Unity model just doesn't scale by default (as in, yes it can be made to work but it's not the default and you'd be fighting with the architecture to do it). Or perhaps a much better way of saying it is that the default Unity architecture encourages less-experienced developers to write slower code. I've heard them say that "performance by default" is a goal for DOTS in a number of talks.
A real draw for me is working with C++ in it, since both Unity and Unreal appear to favour managed languages (C#, some JS variant, some weird Python style thing, etc.)
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.
Unreal has dropped their scripting language for a visual alternative called Blueprints. It is possible to make an entire game with it not writing any C++ and is possible to make one completely in C++. The best is of course using them together. And exactly the same applies to Godot. Just swap Blueprints for GDScript a Python-like scripting language. In a final note Unity, has dropped JavaScript. Though C++ can somehow be used, C# is indeed more or less Unity's language.
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).
>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.
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.
As I am not a Unity developer, I thought the differences between US and JS were superficial and I wasn't aware they're incompatible in that degree. UnityJS seems interesting. What is its status? Is it a draft or usable already?
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.
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:
(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:
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.
The Unity portion of this comment is very out of date. UnityScript ("some JS variant") and Boo ("some weird Python style thing") had support dropped years ago.
> yet another web app/thing that renders DB records to HTML/thing that takes one JSON blob and turns it to another
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.
I think it's a rehash (conscious or not) of Thomas Figg's famous "Webapps, or as I like to call them: Skins around databases."-joke that he used in his "Programming is terrible—Lessons learned from a life wasted" talk from many years ago.
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 ;)
It's probably my main source of disappointment as a programmer specialising in web applications. There are a lot of other things I know how to do or like to play with, but the main money is in the boring stuff.
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.)
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.
It's all about the $$$ and the community. Blender started as a commercial project too. I was already using it in the 90's alongside POVRay.
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.
> there is no real industry wide vendor lock-in when it comes to formats in 3D
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.
It seems like some of you have some real love for Godot. How come you decided to use/recommend Godot over Unity when it was less mature? Was it much better along some axis that Unity didn't provide? What makes it better along that axis?
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?
I'm not a Godot user, I'm a Unity user, but the fact that you don't have to pay is one of the big draws of Godot. Unity Pro is $150/month per seat.
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.
> 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.
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.
I know quite a few game devs (side-effect of both living in Malmö and being active on the TiGsource forums) and if there is one common thing I hear about Unity it's how it does not seem to care at all about backwards compatibility, and how upgrades can completely screw over projects.
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.
Every version change, even minor revisions, come with a real risk of breaking your compiled asset bundles. From shaders to light maps to referenced classes. It's a huge amount of effort to keep a project tracking Unity version upgrades.
What's funny is I think all of the major game studios that I know of essentially lock game engine per project once they're coding along. It's just expected that you stick with it for the rest of the project. Maybe 1 upgrade mid project. I had heard bungie used to, in the halo days, lock the engine 8-11 months out and the core tech team started working on the next game. The AAA studio I worked for essentially did that 3-6 months out.
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.
I wonder why this discussion always falls to Unity and Godot; Unity source is not available, while Unreal Engine source is.
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.
Last time I checked, the 2D features of Unreal were abandoned.
Godot and Unity have both very nice 2D features and I would say that 2D is simply more manageable for a small indie game by a single developer.
The core benefit of unity over unreal is that it has community momentum. There are more tutorials, documentation and things available in their store. I prefer unreal myself, but those are things that are hard to combat against without epic making a more conscious effort.
History I expect, Unreal was a expensive closed engine for AAA games for something like 15 years before moving to a source provided model where you paid with revenue. Unity had a free tier for something like 10 out of those 15 years.
I have been looking into godot every once in a while when it came up on HN and liked what you could do but was not convinced that I want to use it.
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
Mostly that it runs super smooth on linux and I do not have a high end laptop, so I wanted something on the lightweight end of the spectrum.
I then came along a youtube tutorial about getting started with VR development on Godot by the main Godot dev. So I'd say all the stars aligned and I had a reason to try it out.
The Godot discord is also a very nice place, as I got in contact with the developer who works on the hand tracking support.
It's really very much like the Blender developer community, from the people hanging out there.
In a lot of ways godot handles 2D sprite based games better. The easiest way to explain it is that in unity it's a 3D game acting like a 2D game, in godot it really is 2D. I've made a few game jam games in both, and got up and going much faster with godot, but the tutorials and documentation were lacking. But it installs right away, takes up very little space and we managed to get sprite based games up and running in less than a day. There were quirks and things that need to change, but on the whole I'm very hopeful for what godot becomes.
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.
I often wondered if that's the curse of building a horizontal product where you're trying to satisfy multiple types of users with different jobs to do (typical in enterprise products)
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.
Conway's Law (which of course is not really "law") would suggest the last option is the most likely. Given that other game engines don't really have this issue the other two options seem less likely to me too.
Oh, really? That can't be good for development. Other companies at least have different projects for different teams but since Unity is really one big umbrella project that is bound to get messy with that set-up
I use Linux and Godot is easy to install and use on Linux, and fits with the open-source philosophy. I have not made professional games, but I had a good enough time playing around with Godot for a few hours here and there that I recommend it when I can.
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.
I've been a Godot hobbyist for years. Big factors for me at first were that it's open source and that it's lightweight. I started using it for those reasons, and then I found that the node system "clicks" much faster than Unity's model. Once you "get it", Godot is both very easy to work in and program for, and while it's not as polished as Unity, it's basically the perfect tool for solo hobby projects.
For me the first reason was the open source nature of the project. But the more i've used it, the more i've really started to love the node system and editor workflow. I have to be honest, i've never used unity and don't have much interest in it, so I cant compare.
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.
I like Godot to play around with because there's no mental effort attached to "but what if I release this eventually". 99% of everything I've ever built is just quick little play projects, but taking on a commercial engine (even if the license is free) ties my brain to different concepts.
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.
I used Unity in a work environment for about a year and a half, so I feel like I have a reasonably informed, if potentially a little outdated opinion, since that experience was some years ago. Whilst Unity is generally more mature there definitely are areas where I strongly prefer Godot. (Disclaimer: I am a FOSS nerd)
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.
Thanks for the insights. You comment about VCS resonates with the workflow experience in data science. Jupyter notebooks aren't conducive to collaboration.
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 real reason is that godot feels lightweight to devigners and they want to use it. there were tons of other html5/js game engines, some who have been there longer, but none have had support from mozilla!!
Godot doesn’t just feel lightweight, it is lightweight: the entire program is a single modestly sized executable, it takes very little time to go from startup to making something, and it runs well even on lower spec computers. It’s also not very mentally imposing: once you get the hang of nodes, the scene tree and signals, you’re pretty much set.
And that's exactly it! Why do people adopt seemingly less mature technologies? If they never did, we'd never have new stuff, and startups would never win! But they do, and the question is, how does it happen?
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.
I am coming back to Unity for a side-gig VR thing after not touching it for a couple years. Unfortunately the timing is not great since they are still sorting out all the new offerings (XR Plugin vs. Player settings, Input systems, ECS from prefabs, etc.)
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)
I have started VR development very recently for a small side project and I am very happy with Godot (I mentioned the link in one of the other replies, it's calle VRWorkout).
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.
I only released the first test version a week ago and it's relying on the beta of godot as well as a patched export template to support hand tracking, that's why I haven't released it yet. There is currently development going on to integrate the necessary changes into the godot_oculus_mobile plugin and into Godot itself to support that. Once it can be run without patching several different components I will add the source.
Or if too many people ask and giving that explanation becomes more work than actually supporting them to get it running before everything works out of the box :)
I have done some VR with Godot and I'm very pleased with it. I also did a VR game in Unity for a course at university 2 years ago so I have some experience in both engines for VR.
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)
I've been using godot for about a year now, and really like it. I am really excited about the upcoming vulkan renderer which should help with my main gripe which is no ambient occlusion. Some people have found some novel ways around it but I am choosing to just focus on my gltf assets and work on my blender skills in the meantime.
That the Godot scene editor is made with Godot seems to be an excellent example of how eating one's own dog food can exercise and improve the basic technology.
It's fairly common practice in compilers (for good reason), i.e. the D compiler is now written in D and the Rust compiler is written in Rust etc. I think the first Haskell compiler was written in Miranda but that's before my time.
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.
You compile the next version of the compiler using the previous version. That does mean that the first version of the compiler cannot be written in the target language. Once you've got that working you can write a new compiler in the target language and compile it with the previous compiler.
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.
I've been using Godot engine for the past two months now, I evaluated both Unity and Unreal Engine of course, and in the past I've built my own 3D engine (took me 2 years, C++ with Lua scripting, OpenGL 3.3+).
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.
Trying to find the best way to introduce friends/family (with programming backgrounds) to game programming for fun. (So not kid-focused stuff like Scratch or Logo.)
Godot looks pretty good. Is there anything else you've had success with?
https://love2d.org/ is pretty popular with people who are likely to be overwhelmed by 3D things and talk of engines and renderers. It is pitched as a beginner-friendly framework, but you can do a lot with it..
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.
What's Godot's C# support like nowadays? I remember there being some criticism of the early implementation, but I haven't checked back recently.
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.
Felt the same way about the scripting language at first but dug in anyway and it's so close to Python it wasn't too bad to use in practice. Has some short hand for referencing nodes via $ that C# version didn't have.
Yeah, I thought this too and was thrown off by learning a proprietary language but I found it didn't really get in the way both because of its familiarity and simplicity with talking to the event system and scene graph (as you would expect). Any shortcomings I found were clearly identified and documented. (Mind you this was a basic parallax game so was a shallow dive). It's really a hard thing to balance and can understand why c# would be choosen to perhaps deprecate this (but this choice I think is mostly from unity's success (and convertible user base)
I’m curious as I’m playing around with these myself and trying to make a decision from a beginner’s perspective (right now I’m just rolling my own from scratch with libsdl, to get to grips with C++ and the fundamental concepts).
Other than it being open-source and light-weight, I liked the fundamental concepts more. Also, GDScript let's you iterate much faster than C# and is sufficient for most cases. If not, you can still switch to C# or any other language (there are bindings for quite a few now).
Have you seen raylib? IMO (also using sdl, but making a 3-d engine and using opengl), sdl's standalone 2-d capabilities are--okay, but not great. It's capable enough, but the ergonomics aren't that great, compared to raylib.
Oh, I didn't know about this! I've been using the raw library and handling cleanup myself (and understanding when and where I need to do it). It's probably a boon I started on PHP4 which basically had a 1:1 C interface for a lot of things, including manually deallocating variables to save memory and depending on variables passed by reference, so I knew what to expect even if I lacked the experience of the underlying system.
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 keep debating whether I want to commit time to doing a hobby project in Godot or Unity (yes, I know I should just pick one and do it). Unity has made massive strides but I just find Godot so damn pleasant to work in, especially with code editing being built right into the editor and GDScript being such a nice language.
I can really see Godot becoming the Blender of game engines. Kudos to the team!
I have nothing but love to give for Godot and its incredibly dedicated community. Sure, it's still rough around the edges, but many of my gripes (e.g. poor documentation) have been slowly fixed over the years and I've been recommending it to people new to game dev (although not necessarily new to programming) in order for them to tinker on and make their first games with.
Great post. Is there a 3-year, 5-year, even 10-year roadmap for Godot? It's a tool I'm very interested in using but the industrial backing and stability of Unity/Unreal is hard to beat. Some kind of assurance that the creators of Godot plan (or at least hope) to keep working on the project for a long time would go a long way.
The developers have stated their intention to continue development long term... funding permitting. So the way to help ensure you get what you need is to help fund its development. Looking at Godot as a free resource and then expecting anything from the developers is setting yourself up for disappointment.
Godot Engine was awarded $50,000 in 2019 by Mozilla as part of the Mozilla Open Source Support (MOSS) program. Godot also received a MOSS grant of $20,000 in 2016.
I'm not asking for support. Godot could definitely go the for-profit route and charge for cloud builds and other features like Unity does. I just want to make sure that if I invest in learning the tool as well as I know Unity that it'll be around for the next few years.
Continuing development is continuing development ... support is answering questions on forums, responding to issues on github, community management, that sort of thing.
I could be wrong, but I believe that's what they mean when they say they hired a "generalist" this year to help cover off those things. It's not a direct 1:1 of "I pay, I get support", but donating will be intrinsically linked to it and seems part of their overall plan for the future.
I've been looking for a lightweight 2D engine to use on Android. Something I can use to build simple 2D games with small binaries that load quickly and run on lots of hardware. (Like I might use SpriteKit for on iOS.)
Should I look further into Godot Engine, or is it more of a "heavyweight"/loads-of-features engine like Unity and Unreal?
Godot is worth trying. I found it easier than Unity/Unreal to pick up, especially for 2D.
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).
Last I checked, Defold/King require that you let them collect analytics from players' devices in order to ship games with their engine (i.e., your game becomes a trojan horse for their data harvesting regime). It was buried in the terms and a nasty surprise when I found that out (luckily, still in the early stages of experimentation). Permanently destroyed any trust I might put in their offerings.
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.
Um, okay. I'm not sure what I'm supposed to say to that. I remember this clearly from when I trialed Defold immediately after the public launch. I'm glad if things have changed, but the analytics were not opt-in back then.
I've been with the Defold team since before the public launch, but I'm not going to debate you over this :-)
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.
Am intrigued, as I was an early Defold user and the analytics requirements were quite explicit at the time (as was the requirement to put code through their VCS) throughout the dashboard and general information pages. When were you using it?
I believe both of those are now no longer required though.
I’m not familiar with Godot, but word on the street is that its 2D pipeline is nicer than Unity3D’s. Unity3D does 2D, but focuses on 3D. I’m using Unreal right now and I expect it is 100x heavier than you are looking for. It’s one of the top 5 largest public C++ codebases in the world.
I don't have a ton of experience in this space, but I've been looking for a good, simple 2D engine as well. My two top picks are Godot and GameMaker [1]. I've been building prototypes in both, and both have their strengths. I'm currently leaning a little more towards Godot since I've had a bit of trouble getting GameMaker to work well on my Mac (it's been fine on my Windows PC).
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.
Godot's strongest areas currently are probably its 2D engine and that it's lightweight. I'd suggest trying it first to see if it's a good fit. From the needs you describe, it might be.
Interesting post. I haven't that much experience with Godot, but I found the recently published YouTube Video where Juan explains the source code quite interesting: https://www.youtube.com/watch?v=5RIPRlCvRAk
> The new rendering architecture will also allow companies working on console ports to more efficiently port the engine and offer our users the possibility of running their games on the most popular game consoles (something we will, unfortunately, never be able to offer officially due to legal reasons, thus forcing us to cooperate with companies porting it on their own).
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 are not allowed to publish any information about console APIs. That is part of the agreement for getting access to the SDK.
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.
> You are not allowed to publish any information about console APIs. That is part of the agreement for getting access to the SDK.
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.
It's not lower than Vulkan (Vulkan pretty much matches GPU functionality already). Lower would be GPU assembly or machine code.
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.
It doesn't matter what they use. We are talking about engines themselves here, like Godot. And they shouldn't be wasting time and resources working around lock-in stupidity. Offering Vulkan for developers is the right thing to do for every platform.
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.
The point was explained above, and you get it. Godot case demonstrates it more than clearly that having a common API is good for developers. You simply avoid admitting that lock-in is bad - all this talk about "IP" has no relevance to the issue.
So let me put this in another way, neither OpenGL or Vulkan are a common API, beyond the basic step of putting a triangle on the screen.
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 let me put this in another way, neither OpenGL or Vulkan are a common API
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.
According to Khronos, OpenGL is still the API to go when one doesn't want to deal with Vulkan boilerplate.
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.
Does anyone have any experience or knowledge about the process of porting a Godot game to consoles?
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 )
As a side project to get me back into lower-level programming, I've had the pleasure of working on a personal fork of Godot.
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.
> 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.
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”.
I'll give you a list of pitfalls I've ran into on my current project.
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 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.