8 ms·

People keep bringing up Godot but there's no way around the fact that it feels like some guy's homebrew engine through and through, especially once you try to u

People keep bringing up Godot but there's no way around the fact that it feels like some guy's homebrew engine through and through, especially once you try to use the native C++ side. But you don't really need to get that far to realize how janky it is. You can't even delete assets that may or may not be used in scenes without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line. The GUI tools are atrocious compared to Unity's and they fail at the most important thing: make sure that when you play the game the GUI looks exactly the same as in the designer. There's also some weird jank with the GUI, where you have to reload the scene to see some changes being applied (like, imagine setting some property in, say, a winform, and having to close and reopen the winform's editor to see it actually having an effect, wtf) but I don't think it's limited to the GUI, I forgot what those were exactly. But there's no indication that you need to reload the scene, you google the problem and the answer is "reload the scene". There's a loooooooong way to go for Godot to reach Unity's level. They'd have to essentially become the next Blender, which I use as the benchmark for open source community driven projects. Godot == Unity at home. The best thing about it is that you have access to the source for free, so you can fix bugs yourself. "We may run into issues three years down the line with the project but at least we can fix them ourselves". How attractive this sounds to you depends, I assume serious developers who want to build large games for profit, will choose either Unity or Unreal because they're expected to work better overall.

brundolf 4y ago
> You can't even [common action] without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line. To be fair, in my experience this is par for the course in Unity too
- noobermin 4y ago
  Caveat, this is a meta post. I'm not a gamedev (not professionally at least), and don't have experience in either. This reminds me of something I rant about often, linux naysayers on HN. Because of them, I tried buying a macbook in 2015 and had some of my most frustrating experiences in my life, culminating in a talk for a national conference I had to redo on a friends windows laptop in half an hour because it failed to display on the projector. Turns out the HN crowd who kept saying "mac is unix like linux but better since it's not a bazaar open source mess" aren't always right after all. People have some bad experiences with X product where X product is often open source and being open source explains the bad experiences. However, when Y product also offers similar bad experiences (and even worse ones) but they paper over it in their minds because "it just happens" although it's probably just because they're used to it. Repeat for photoshop and gimp (my SO is an animator and adobe products crashing is a common experience, as is redoing work in case a save was forgotten), linux and mac, etc. Anyway, I'm not a gamedev, I just see a similar pattern and it's hard not to notice.
  - entropicdrifter 4y ago
    As a Linux user on my daily drivers and a Mac user on my work-issued machine, I agree with this sentiment completely. Linux has weird issues a good amount of the time if you're trying to do unusual stuff, but so do Windows and Mac, and on those platforms you're less equipped to pop the hood and fix the underlying issue.
    - sfteus 4y ago
      I have to agree with this. I moved off Windows into Linux as a daily driver mainly due to issues with docker support (pre WSL2, but even that had filesystem issues the last time I tried to used it). I recently accepted a new position that provided a Mac M1 and it's just a generally frustrating experience comparatively. Specifically, anything that involving keyboard directed window management is either non-existent or flaky at best, and a ton of functionality that it just inconsistent with the rest of the OS / applications (why is a separate fullscreen the default functionality, and why can you no longer Alt-Tab + Cmd + Tilde to a window that's been made fullscreen if you have a second non-fullscreen window open?). Maybe my flow just isn't compatible with the OS (it feels very visual + mouse oriented), but between a previous ~2 year stint with another Mac-only job and these ~3 months, about the only thing I have to say that's positive about the OS is the spaces feature. And like you mentioned, even when I had an ambiguous error on Linux, there was usually enough information to find a similar enough problem online to at least narrow down what I should investigate.
      - lostdog 4y ago
        Yeah, Mac's UI of spaces/desktops is so busted that it usually takes me a couple tries to get the window I want. I've also watched another user lose track of every window that goes fullscreen.
  - dkonofalski 4y ago
    >I had to redo on a friends windows laptop in half an hour because it failed to display on the projector What situation would possibly require you to redo a presentation because it can't display on a projector? PowerPoint is cross-platform and Keynote can export to PowerPoint. This seems like hyperbole.
light_hue_1 4y ago
I'm surprised you would say that Godot has more bugs than Unity. Unity is an endless fountain of bugs that keeps on giving when you least expect it. Godot does lack some features. But that depends entirely on the kind of game you're aiming for. The 2D market like RimWorld could easily move to Godot. On that note. UI skinning isn't a feature that's lacking in Godot. https://docs.godotengine.org/en/stable/tutorials/ui/gui_skinning.html https://docs.godotengine.org/en/stable/tutorials/ui/gui_skin... If you easily implement that screenshot what prevents anyone from matching any designer's dreams?
- SXX 4y ago
  > The 2D market like RimWorld could easily move to Godot. I really all for Godot and our team have positive experience with it, but I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts. Might be Godot 4.x will get improved profiler, but for now it's really lacking. So unless you move everything into C++ I dont think you'll manage good performance in Dwarf-Fortress-like simulation game. Though might be I overeastimate how much simulation / physics game like RimWorld require.
  - light_hue_1 4y ago
    > I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts... C++ I don't see why that would be. Godot has bindings for all sorts of languages including C#. Why would it be any harder to write C# code with Godot bindings than C# code with Unity bindings?
    - SXX 4y ago
      Problem is not to write GDScript or C# code in Godot, but profiling and performance optimizations: toolset of the engine is really lacking in this area so it's really hard to find out what are major bottlenecks are and what is eating most of frame time. Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. If you have a lot of objects and non-obvious performance drops it's really hard to find them. In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.
SXX 4y ago
Okay I will share some of my own experience over almost 2 years working with Godot / GDScript. We're building 2D pixel art game for Steam. We're fully funded by publisher and have a team of 10 people with 3 programmers. We have around 100KLOC codebase with a lot of game mechanics. Primary downside of using Godot for commercial development is lack of official console support. Everything else will vary from project to project since every game is different. Godot have bunch of weird limitations, lack of proper virtual filesystem (e.g boost::filesystem anyone?), really shitty profiler, some weak UI / UX in editor some of which can be easily compansated by using VSCode. At the same time I can certainly say that you can make proper commercial game using Godot. Engine is stable, performance is not the best, but okay. Will it work for everyone? Probably not, but again it works for us. PS: I also glad to advertise few Godot projects that are not mine, but I find them really enjoyable (check profile if you curios about project I work on): https://store.steampowered.com/app/1637320/Dome_Keeper/ https://store.steampowered.com/app/1637320/Dome_Keeper/ https://store.steampowered.com/app/1953670/Quetzal/ https://store.steampowered.com/app/1953670/Quetzal/
- uwuemu 4y ago
  > some weak UI / UX in editor some of which can be easily compansated by using VSCode ?? What exactly can be compensated for with a code editor? 75% of the value of a "modern engine" is in its tools... with something like Unreal it may be close to 90%. Level editors, object browsers, geometry editing, animation editors, rigging, particle editors, material and UV editors, physics/navigation/ai system and their editors... the list goes on and on. Gameplay code is something you'll either do in visual scripting (UE blueprint) or in an external IDE. Any engine-level coding will be done in an external C++ IDE (Visual Studio). So... I can't imagine what exactly VSCode compensates for?
  - cain 4y ago
    The limitations of Godot's in-engine text editor can be compensated by a more powerful external editor: VScode, emacs, vim, etc. An example would be the lack of remappable keybindings: this can be overcome by using an external editor.
johnnyanmac 4y ago
> I assume serious developers who want to build large games for profit, will choose either Unity or Unreal because they're expected to work better overall. they'd ultimately choose them because of support more than jank, to be honest. They care less about the ability to fix a bug 3 years down the line than the ability to phone up engine experts they don't have to directly hire to fix it for them. I'm assuming Godot doesn't have such support past enthusiast forums.
- hesdeadjim 4y ago
  Yep, I bought enterprise support for my studio for exactly this reason. Great example: Apple updates Xcode to 14, which includes some undocumented change to Clang that ends up completely breaking Burst static initialization. Unity's fault? Nope. But they fixed it quickly. When Godot breaks, glfh, that's on you.
  - Pulcinella 4y ago
    Is this something that happened or an example of something the could happen? I mainly target Apple’s platforms and while moves like this don’t leave me feeling confident about Unity, the acrimony and legal battles between Apple and Epic (and Epic’s level of support for development on Max, especially ARM Mac)leaves me feeling even less confident about switching to Unreal.
    - deleted 4y ago
      [deleted]
    - hesdeadjim 4y ago
      Yep, real: https://forum.unity.com/threads/burst-xcode-13-3-builds-for-ios-ipados-tvos-and-il2cpp-macos.1270415/ https://forum.unity.com/threads/burst-xcode-13-3-builds-for-...
    - darkteflon 4y ago
      I think Epic’s doing a pretty reasonable job of distinguishing between Apple, and people that develop in its engine on Apple machines. The 5.0.2 release, for example, had loads of MacOS-specific bug fixes. There are compromises versus developing on Windows, of course - you lose hardware Lumen, for example. No native AS support either yet, but it runs okay through Rosetta depending on what you’re doing.
hesdeadjim 4y ago
This * 1000. I'd love to meet a single person on this site who has used Godot to ship a commercial game of any note. Ship a Godot game on macOS 11+/iOS 13+/tvOS 13+/PC/Linux/Switch/PS4/PS5/Xbox and then come tell me how it went. Godot is basically completely unproven for a game requiring this level of release support. I feel like a Unity apologist sometimes, but what options are there? If your studio doesn't have high level competency with Unreal, committing to a project using it adds an immense amount of risk. This merger is a real kick in the gut for me, but I'm all in with Unity and I can't afford to bet my studio on an Unreal switch without major partner financial support.
- SXX 4y ago
  For the time being Godot going to be PC-first game engine and our 10-people studio dont have any issues building for Windows/macOS/Linux. Test imports for web work amazingly well, but we dont need it. Lack of console support is just limitation of what can be done with open source code since even SDKs for consoles are under NDA. I guess if you building project for consoles then you have to look elsewhere. You are not wrong in any way. At the same time there are plenty of small teams that can work with Godot and build some fun games using it.
  - extrememacaroni 4y ago
    The lack of console support comes especially from the fact that there's no company behind godot itself that can become a licensed Nintendo developer for example. There are other companies that can port your godot games to consoles and publish them, but in the stores the games will be listed as theirs not yours. If you're an indie without a publisher, that's probably not a big deal. Although it would be if it were me, I'd want the game to be listed under my own name, not someone else's, especially if a player might start to avoid games published by X because they played games they did not like in the past. But if you're already backed by a publisher, that will probably not fly.
    - SXX 4y ago
      I will just add a note about publishers: if your project is not using Unreal / Unity most huge publishers just wont be interested. It has nothing to do with Godot console support or anything else about Godot itself. Basically all big publishers have their own pipeline and in-house teams for porting / QA / certification and it's all built around Unity or Unreal. So it's all about market share. So yeah choosing Godot will certainly limit your options in terms of what publishers might fund your project.
deleted 4y ago
[deleted]
gg2222 4y ago
I second this opinion. As a (non-hobbyist) game developer, I started my current game with Godot, but after running into many issues including performance which was the final dealbreaker, I decided to port the whole game to Unity. Finally I could focus on developing the game rather than running into engine related issues and limitations and having access to all the time saving assets in the Asset Store was (literally) game changing. Having the Asset Store is a whole new world. And as a dev with funds, paying for assets to save weeks of time was a no brainer. Back to Godot, yes deleting stuff in Godot is pretty scary cause there is (or at least was) no way to know what effects/errors it could cause. GUI system (at least last time I used it) was very unfortunately not well designed making it extremely hard to get consistent positionings. I feel it's so bad that just using HTML+CSS would be better cause then it would be possible to confidently put things and keep them where you want to. And yes, overall as someone who has also used the C++ side, it does feel like some guy's homebrew engine. I felt things weren't as solidly designed as they could be. And this is talking about foundational stuff. The C++ source code is really not modern C++ (or you could call it anti-modern C++). I would not advise anyone to develop a game on it if your livelihood depended on your game's success. Of course people can and will prove me wrong by still powering through and creating a successful game with it, but your time is better spent using a more mature engine like Unity or Unreal. Even if you want to get your hands dirty and help fix bugs or add features to the engine, there is no guarantee that your PR will be merged. Game development is probably the most riskiest type of software development already business-wise. No need to up your risk. Of course if you are a hobby indie dev and do it just for the enjoyment of building things, then no problem. As for Godot's future ... well it's been many, many years, but if I understand correctly they're mainly still working on 3D rendering features. There are tons of other areas that are still the same with the same limitations as they were years (5 years+) ago. I think with not so solid foundation and the pace of development, it will take many many years if ever to catch up to Unity. I do like the way Godot engine does some things and I do hope for it's success as competition is always good. I just don't have much faith in it from what I've seen. I do hope I will be proven wrong though.

brundolf 4y ago

> You can't even [common action] without running into errors and warnings that may be benign but eat away at your trust that things will still work fine later down the line. To be fair, in my experience this is par for the course in Unity too

noobermin 4y ago
Caveat, this is a meta post. I'm not a gamedev (not professionally at least), and don't have experience in either. This reminds me of something I rant about often, linux naysayers on HN. Because of them, I tried buying a macbook in 2015 and had some of my most frustrating experiences in my life, culminating in a talk for a national conference I had to redo on a friends windows laptop in half an hour because it failed to display on the projector. Turns out the HN crowd who kept saying "mac is unix like linux but better since it's not a bazaar open source mess" aren't always right after all. People have some bad experiences with X product where X product is often open source and being open source explains the bad experiences. However, when Y product also offers similar bad experiences (and even worse ones) but they paper over it in their minds because "it just happens" although it's probably just because they're used to it. Repeat for photoshop and gimp (my SO is an animator and adobe products crashing is a common experience, as is redoing work in case a save was forgotten), linux and mac, etc. Anyway, I'm not a gamedev, I just see a similar pattern and it's hard not to notice.
- entropicdrifter 4y ago
  As a Linux user on my daily drivers and a Mac user on my work-issued machine, I agree with this sentiment completely. Linux has weird issues a good amount of the time if you're trying to do unusual stuff, but so do Windows and Mac, and on those platforms you're less equipped to pop the hood and fix the underlying issue.
  - sfteus 4y ago
    I have to agree with this. I moved off Windows into Linux as a daily driver mainly due to issues with docker support (pre WSL2, but even that had filesystem issues the last time I tried to used it). I recently accepted a new position that provided a Mac M1 and it's just a generally frustrating experience comparatively. Specifically, anything that involving keyboard directed window management is either non-existent or flaky at best, and a ton of functionality that it just inconsistent with the rest of the OS / applications (why is a separate fullscreen the default functionality, and why can you no longer Alt-Tab + Cmd + Tilde to a window that's been made fullscreen if you have a second non-fullscreen window open?). Maybe my flow just isn't compatible with the OS (it feels very visual + mouse oriented), but between a previous ~2 year stint with another Mac-only job and these ~3 months, about the only thing I have to say that's positive about the OS is the spaces feature. And like you mentioned, even when I had an ambiguous error on Linux, there was usually enough information to find a similar enough problem online to at least narrow down what I should investigate.
    - lostdog 4y ago
      Yeah, Mac's UI of spaces/desktops is so busted that it usually takes me a couple tries to get the window I want. I've also watched another user lose track of every window that goes fullscreen.
- dkonofalski 4y ago
  >I had to redo on a friends windows laptop in half an hour because it failed to display on the projector What situation would possibly require you to redo a presentation because it can't display on a projector? PowerPoint is cross-platform and Keynote can export to PowerPoint. This seems like hyperbole.

light_hue_1 4y ago

I'm surprised you would say that Godot has more bugs than Unity. Unity is an endless fountain of bugs that keeps on giving when you least expect it. Godot does lack some features. But that depends entirely on the kind of game you're aiming for. The 2D market like RimWorld could easily move to Godot. On that note. UI skinning isn't a feature that's lacking in Godot. https://docs.godotengine.org/en/stable/tutorials/ui/gui_skinning.html https://docs.godotengine.org/en/stable/tutorials/ui/gui_skin... If you easily implement that screenshot what prevents anyone from matching any designer's dreams?

SXX 4y ago
> The 2D market like RimWorld could easily move to Godot. I really all for Godot and our team have positive experience with it, but I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts. Might be Godot 4.x will get improved profiler, but for now it's really lacking. So unless you move everything into C++ I dont think you'll manage good performance in Dwarf-Fortress-like simulation game. Though might be I overeastimate how much simulation / physics game like RimWorld require.
- light_hue_1 4y ago
  > I think that it's will be hard to mantain game that is heavy on simulation with a lot of moving parts... C++ I don't see why that would be. Godot has bindings for all sorts of languages including C#. Why would it be any harder to write C# code with Godot bindings than C# code with Unity bindings?
  - SXX 4y ago
    Problem is not to write GDScript or C# code in Godot, but profiling and performance optimizations: toolset of the engine is really lacking in this area so it's really hard to find out what are major bottlenecks are and what is eating most of frame time. Godot profiler for their "scripting" be it GDScript or C# is a dumpster fire. If you have a lot of objects and non-obvious performance drops it's really hard to find them. In case you use C++ you will be able to use mature profilers for C++ projects like built-in one in Visual Studio or Xcode, Valgrind on Linux or some 3rd-party solution like Intel XE Studio. All of them are just 10000% better than what Godot have at this moment.

SXX 4y ago

Okay I will share some of my own experience over almost 2 years working with Godot / GDScript. We're building 2D pixel art game for Steam. We're fully funded by publisher and have a team of 10 people with 3 programmers. We have around 100KLOC codebase with a lot of game mechanics. Primary downside of using Godot for commercial development is lack of official console support. Everything else will vary from project to project since every game is different. Godot have bunch of weird limitations, lack of proper virtual filesystem (e.g boost::filesystem anyone?), really shitty profiler, some weak UI / UX in editor some of which can be easily compansated by using VSCode. At the same time I can certainly say that you can make proper commercial game using Godot. Engine is stable, performance is not the best, but okay. Will it work for everyone? Probably not, but again it works for us. PS: I also glad to advertise few Godot projects that are not mine, but I find them really enjoyable (check profile if you curios about project I work on): https://store.steampowered.com/app/1637320/Dome_Keeper/ https://store.steampowered.com/app/1637320/Dome_Keeper/ https://store.steampowered.com/app/1953670/Quetzal/ https://store.steampowered.com/app/1953670/Quetzal/

uwuemu 4y ago
> some weak UI / UX in editor some of which can be easily compansated by using VSCode ?? What exactly can be compensated for with a code editor? 75% of the value of a "modern engine" is in its tools... with something like Unreal it may be close to 90%. Level editors, object browsers, geometry editing, animation editors, rigging, particle editors, material and UV editors, physics/navigation/ai system and their editors... the list goes on and on. Gameplay code is something you'll either do in visual scripting (UE blueprint) or in an external IDE. Any engine-level coding will be done in an external C++ IDE (Visual Studio). So... I can't imagine what exactly VSCode compensates for?
- cain 4y ago
  The limitations of Godot's in-engine text editor can be compensated by a more powerful external editor: VScode, emacs, vim, etc. An example would be the lack of remappable keybindings: this can be overcome by using an external editor.

johnnyanmac 4y ago

> I assume serious developers who want to build large games for profit, will choose either Unity or Unreal because they're expected to work better overall. they'd ultimately choose them because of support more than jank, to be honest. They care less about the ability to fix a bug 3 years down the line than the ability to phone up engine experts they don't have to directly hire to fix it for them. I'm assuming Godot doesn't have such support past enthusiast forums.

hesdeadjim 4y ago
Yep, I bought enterprise support for my studio for exactly this reason. Great example: Apple updates Xcode to 14, which includes some undocumented change to Clang that ends up completely breaking Burst static initialization. Unity's fault? Nope. But they fixed it quickly. When Godot breaks, glfh, that's on you.
- Pulcinella 4y ago
  Is this something that happened or an example of something the could happen? I mainly target Apple’s platforms and while moves like this don’t leave me feeling confident about Unity, the acrimony and legal battles between Apple and Epic (and Epic’s level of support for development on Max, especially ARM Mac)leaves me feeling even less confident about switching to Unreal.
  - deleted 4y ago
    [deleted]
  - hesdeadjim 4y ago
    Yep, real: https://forum.unity.com/threads/burst-xcode-13-3-builds-for-ios-ipados-tvos-and-il2cpp-macos.1270415/ https://forum.unity.com/threads/burst-xcode-13-3-builds-for-...
  - darkteflon 4y ago
    I think Epic’s doing a pretty reasonable job of distinguishing between Apple, and people that develop in its engine on Apple machines. The 5.0.2 release, for example, had loads of MacOS-specific bug fixes. There are compromises versus developing on Windows, of course - you lose hardware Lumen, for example. No native AS support either yet, but it runs okay through Rosetta depending on what you’re doing.

hesdeadjim 4y ago

This * 1000. I'd love to meet a single person on this site who has used Godot to ship a commercial game of any note. Ship a Godot game on macOS 11+/iOS 13+/tvOS 13+/PC/Linux/Switch/PS4/PS5/Xbox and then come tell me how it went. Godot is basically completely unproven for a game requiring this level of release support. I feel like a Unity apologist sometimes, but what options are there? If your studio doesn't have high level competency with Unreal, committing to a project using it adds an immense amount of risk. This merger is a real kick in the gut for me, but I'm all in with Unity and I can't afford to bet my studio on an Unreal switch without major partner financial support.

SXX 4y ago
For the time being Godot going to be PC-first game engine and our 10-people studio dont have any issues building for Windows/macOS/Linux. Test imports for web work amazingly well, but we dont need it. Lack of console support is just limitation of what can be done with open source code since even SDKs for consoles are under NDA. I guess if you building project for consoles then you have to look elsewhere. You are not wrong in any way. At the same time there are plenty of small teams that can work with Godot and build some fun games using it.
- extrememacaroni 4y ago
  The lack of console support comes especially from the fact that there's no company behind godot itself that can become a licensed Nintendo developer for example. There are other companies that can port your godot games to consoles and publish them, but in the stores the games will be listed as theirs not yours. If you're an indie without a publisher, that's probably not a big deal. Although it would be if it were me, I'd want the game to be listed under my own name, not someone else's, especially if a player might start to avoid games published by X because they played games they did not like in the past. But if you're already backed by a publisher, that will probably not fly.
  - SXX 4y ago
    I will just add a note about publishers: if your project is not using Unreal / Unity most huge publishers just wont be interested. It has nothing to do with Godot console support or anything else about Godot itself. Basically all big publishers have their own pipeline and in-house teams for porting / QA / certification and it's all built around Unity or Unreal. So it's all about market share. So yeah choosing Godot will certainly limit your options in terms of what publishers might fund your project.

deleted 4y ago

[deleted]

gg2222 4y ago

I second this opinion. As a (non-hobbyist) game developer, I started my current game with Godot, but after running into many issues including performance which was the final dealbreaker, I decided to port the whole game to Unity. Finally I could focus on developing the game rather than running into engine related issues and limitations and having access to all the time saving assets in the Asset Store was (literally) game changing. Having the Asset Store is a whole new world. And as a dev with funds, paying for assets to save weeks of time was a no brainer. Back to Godot, yes deleting stuff in Godot is pretty scary cause there is (or at least was) no way to know what effects/errors it could cause. GUI system (at least last time I used it) was very unfortunately not well designed making it extremely hard to get consistent positionings. I feel it's so bad that just using HTML+CSS would be better cause then it would be possible to confidently put things and keep them where you want to. And yes, overall as someone who has also used the C++ side, it does feel like some guy's homebrew engine. I felt things weren't as solidly designed as they could be. And this is talking about foundational stuff. The C++ source code is really not modern C++ (or you could call it anti-modern C++). I would not advise anyone to develop a game on it if your livelihood depended on your game's success. Of course people can and will prove me wrong by still powering through and creating a successful game with it, but your time is better spent using a more mature engine like Unity or Unreal. Even if you want to get your hands dirty and help fix bugs or add features to the engine, there is no guarantee that your PR will be merged. Game development is probably the most riskiest type of software development already business-wise. No need to up your risk. Of course if you are a hobby indie dev and do it just for the enjoyment of building things, then no problem. As for Godot's future ... well it's been many, many years, but if I understand correctly they're mainly still working on 3D rendering features. There are tons of other areas that are still the same with the same limitations as they were years (5 years+) ago. I think with not so solid foundation and the pace of development, it will take many many years if ever to catch up to Unity. I do like the way Godot engine does some things and I do hope for it's success as competition is always good. I just don't have much faith in it from what I've seen. I do hope I will be proven wrong though.