Godot is a nice engine. I did a 3D project in it during the 3.0.x era and it was by far the friendliest and easiest engine I have used to-date. I think it gets a lot of love from people (myself included) because of that. The node system is absolutely wonderful to work with and GDScript is not bad as well. It's the most productive I've been in a game engine and I regularly contemplate going all-in on Godot for the future.
However, ultimately I abandoned that project because there were too many papercuts in Godot for me to be satisfied. Godot felt like it was a sort of "jack of all trades master of none". Everything worked pretty well but not one thing was fully polished for real world usage. There were ultimately at least one or two shortcomings in every system that just made the experience frustrating when trying to deliver a real project. For example, the asset import system is great but it fell down once I imported by 40,000+ assets or there were limited controls for navigating around the 3D viewport or odd behavior in physics functionality like slide and move that basically meant I needed to write my own equivalent. I am more than willing and able to work around limited features or fix bugs but there's something about "almost does what I need but it's not done yet" that is a real motivation drain. Maybe it's unfair of me, the retort is always "it's open source, contribute back!" but alas that is how I felt as a USER before I considered being a CONTRIBUTOR.
I've been tracking Godot since then and there have been HUGE amounts of work in lots of different systems, it's been quite amazing to watch. However, these decisions were quite ambitious as outlined in this blog (rewrite physics, rewrite renderer, massive upgrades to scripting language, etc.) that now the "polished" experience I've been waiting for has been postponed again. I'm optimistic the day will come where Godot becomes "good ole reliable" but until then I will keep waiting and begrudgingly use something else.
> Maybe it's unfair of me, the retort is always "it's open source, contribute back!" but alas that is how I felt as a USER before I considered being a CONTRIBUTOR.
Even as a contributor I've found it very frustrating to contribute to Godot.
I've found lots and lots of bugs while working on my own projects using Godot. I spent a lot of time digging in the engine code to figure out the cause, make an issue and a patch if I could.
However, even small changes take a lot of time and effort. While I used Godot 3 for my own projects most of the PRs had to be based against 4. At the time Godot 4 was in a very sorry state and I ran in many, many issues that made it hard to test if the same fix for Godot 3 also works in Godot 4.
I wrote some libraries to work around issues that I (or others) could not get fixed or reverted (e.g. I replaced the physics engine with Rapier3D because I really needed more stable and working joints) but I eventually threw in the towel and decided to focus on other hobbies.
I don't know about fun, but structurally, polish is one of the hardest things to contribute to an open source project. Polishing usually has a very large "activation energy", where the overhead of synchronizing, making a PR, building consensus, etc. dwarfs the actual effort in the patch. Polishing may involve hundred or thousands of small changes like this. Outsiders are likely to prefer contributing large features where the effort involved is more commensurate to the benefits.
Thanks for the excellent write up with big picture thoughts and concrete examples. I only regret that you didn’t hit the “waiting for Godot” punchline harder.
I've been using Unity for a few months now and what is most frustrating is how lazy and unprofessional the company presents itself.
They basically found that the Asset Store is such a huge source of revenue for them that they now completely over-leverage it and abuse the community for profit. For the few things they do ship, they routinely break things for backwards incompatibility or literally just ship half complete "products". If you want to do anything meaningful in Unity you either have to build it yourself from the ground up or buy plugins.
An example: their AI navigation system is so lacking in features, they haven't updated it in nearly two years, and the last ship they did was literally half broken and buggy for several use cases.[1]
Also their help desk is currently broken, replacing random text with "$$anonymous$$" and deleting replies[2] :)
This comment is definitely a venting comment, but I didn't want it to come across like Unity is pure ass. It has a lot of really great things too. I've especially enjoyed their abstractions around vectors, quaternions, cameras, and local/world space. You can do a lot of really complicated operations that look and feel great, without having what would normally require some pretty advanced math knowledge that is beyond me
Apple, Microsoft, Google, Sony, Nintendo apparently live in another world, given how many of their studios or VR/AR endevours rely on Unity, or give it tier 1 support on many of their projects, while everyone on HN complains about it.
I guess they get special builds no one else has access to. /s
> limited controls for navigating around the 3D viewport
I still haven't figured this out yet. It's really weird it's so difficult to navigate the viewport, which is a really basic operation for a 3D engine. I've made plenty of levels using the unreal editor, but I can't figure it out in godot.
I mean it's a relatively young open source project. It took Blender 25 years to get where it is now and it still has some major flaws compared to the paid competition, and will need extensive rewrites if it wants to move forward because right now the C part is a horrible mess.
Godot isn't going to compete against Unity or Unreal anytime soon. Godot's team doesn't have billions at their disposal like Epic or Unity.
edit: Blender also had major advantage aside from begin free, it could do physics and volumetrics for free when the commercial competition required yet another paid plugin just for that stuff, so why pay when the free solution does more than the competition? and let's not even go into requiring separate paid rendering engines for the renders to look decent...
I think though that there's an apex all game engines reach where technological progression just slows down even when you have millions of developer dollars to throw at it.
It's the reason why something like blender can catch up with state of the art commercial offerings and I think Godot could go through the same thing.
Tangentially to your post, but nonetheless interesting:
"jack of all trades master of none" is the shorthand version of the full phrase "A Jack of all trades is a master of none, but oftentimes better than a master of one” which has been used since 1721.
I love `move_and_slide` and it's perfect for me, but you're right that it's a very opinionated implementation. I found I was making huge strides in 3D very quickly, but a friend essentially had to re-implement it for their game.
I'm curious if the best solution would be to expose more optional knobs and switches for KinematicBody, or to have a bigger ecosystem of open-source variants.
> Everything worked pretty well but not one thing was fully polished for real world usage.
My own experience. I found that once you go beyond toy projects, the minor irritations, the many "papercuts" you talk about, make game development painful.
I havent used Unity, so dont know if it suffers from the same problem
Godot felt frustrating to use every time I've tried it, on both 4.x and 3.x versions. Compared to Unity, it was a massive improvement, the editor was much faster without crashing, and it had a reasonable node-graph design. However, I think some of the "elegant" designs pursued in Godot and some up-and-coming Rust game engines often end up feeling very time-consuming to fit your code in their abstraction (whether it be ECS or nodes), and honestly sometimes it's nice to just sit down, write some terrible macro-ridden C++ that subclasses from 15 different classes in a hierarchy that would make Alan Kay cry, and get an object that can be scripted from your level editor seamlessly. It's janky, but nonetheless it works.
This is why I prefer using libraries to abstract away the complicated parts of doing low level graphics, sound, etc over game engines/frameworks. Engines call me, instead of being called BY me, and that forces me to use their whole environment instead of picking just what I need, as well as forcing me to distort the concepts and abstractions that are most natural for how I think about a problem to fit into the existing way they want things to work. I prefer being able to make my own architectural decisions.
I find this hard because games often end up quite tightly-coupled, so while you don't have the pathfinding code reaching into the rendering, the rendering is usually coupled to the game object model and it's hard to make it reusable outside of a specific engine. That and the fact that AAA studios do not want to open-source anything for some reason.
Agreed. Making custom editors/tools/content pipelines is also much easier when you have your own engine. Of course, you can write custom plugins for some engines, but I always felt uneasy about this - plugin API always breaks and you need to learn a lot of specifics of the engine to make something non-trivial (which is hard, because those engines are usually gigantic in scope).
The downside of making your own engine is that it’s usually gets more fun to develop the engine itself than games with it…
I get where you're coming from, and there is always a certain hackiness to game code it seems.
But I've embraced godot for 2D games and it has been wonderful. I get more code reuse out of the node system than I ever got out of class hierarchies elsewhere. I find myself with the time to set up a lot more test scenarios where I can play two things side by side to find the better feel -- rather than just getting one to work at all.
Yes, that's all subjective and might just be me getting better at game development, but I was immediately productive in Godot, and I haven't run into a roadblock for what I happen to be doing. I imagine there may be a game type, or otherwise simple technique that is nearly impossible in godot, but simple elsewhere; that's true of every game engine it seems.
Okay I'm little late to the party, but our company actually released commercial game on Steam and GOG. It called Dwarven Skykeep and it built in Godot. Now I'll list a few things that for some reason are not mentioned in article, but crucial for Godot success in commercial game development.
1. Official console support and partnership with platform owners. Yes this code will be closed source, but without this there can't be many AA/AAA games. I'm aware that Godot Foundation is a step to solve this, but it's not yet here and unfortunately 3rd-party companies selling porting services are not sufficient.
2. Once console support is here there will be dire need for game publishers who have pipeline to fund and do marketing for games using Godot. Unfortunately it's very hard to find a publisher for game that built with Godot.
3. Godot need more stable and official support for pesky closed source ecosystems like Steamworks, GOG, etc. There are plugins for that, but they are not as easy to use as in proprietary competitors and not easy to find.
4. There need to be much better tooling for debugging and performance profiling. I've already had some lengthy discussion about it in previous Godot topics so I'm not gonna elaborate much. Its slowly being worked on and improved, but it still inferior than competition.
I love open source and love working with Godot, but unfortunately it's difficult to make commercial games when ecosystem is not there. Game development is hard enough on it's own and sometimes you have to make a choice of whatever you want to support FOSS or you want to make a great games.
I don't think the Godot foundation is what's meant to handle porting to consoles and integrating with closed source libraries. You're probably thinking of W4 Games, started by the Godot founders:
I really enjoy creating in Godot. However, I am far from a AA/AAA game dev. Godot is a great tool for creating games independently. Creating 2D tilemaps is significantly improved in Godot 4.
For me, the most exciting thing to happen to Godot is the Steam Deck. The question of how to run Godot on the Nintendo Switch came up frequently on r/godot. There was no practical avenue for small time devs. I'm excited to see what doors the Steam Deck will open as an alternative handheld gaming device.
I think people are interested in consoles because they want access to those communities. There's a lot of people that wont deal with PC gaming, and those people wont use a Steam Deck either. I would want my game to be available to console gamers, for profit and to share my with with as many as possible. As good as the Steam Deck may be, I don't think it will lessen interest in the video game consoles.
You can't just become a console developer though... You need to have proven releases on desktop or mobile before any console maker will even let you touch their devkit...
I think 2D tilemaps is a great example of how quickly Godot can fall over terribly, though. And that's (as has been mentioned elsewhere) mostly an issue of polish. Godot can do the basic version of a lot of things, but if you need more you often get very deep into the weeds, very quickly.
With Godot 4, 2D tilemaps are incredibly awkward to use alongside random generation. You have (had?) to reset neighbor tiles yourself to get it to pick the correct sprite. Setting large numbers of tiles at once is/was terribly slow. The APIs are just a bit awkward, too. Godot 3 didn't have any of these issues.
Basically, once you get off the beaten path, things become noticeably janky in a lot of places. I'm sure some of the obvious bugs will or have already been fixed for the beta, but some, like tilemaps, seemed to simply have a response of "it's working as intended", and others (like GDScript scalability or native DLL hot reload) are simply not fixable without another redesign.
I've been using Godot off and on for the past month prototyping a mobile game. The editor loads/refreshes very quickly on a macbook air m1 (which hasn't been the case w/ Unity of late). The workflow is intuitive and for reasonably scoped games, it's a great fit.
I was surprised to not feel limited by gdscript (having no python background and doing most work in JS for the past decade). I picked it up quickly and it's well documented and integrated into vscode.
Not sure if it would be my choice for a large game with millions of entities (e.g. an online RPG that needs an ECS system) but for small 2d games it is a delight to work with.
I may be the minority here, but I hope Godot doesn't try to cater to AA/AAA devs and keeps small indies front and center as the focus.
> After an unsatisfactory attempt at using Bullet, Godot 4.0 returns to its own physics engine which, despite not being a high end physics engine like PhysX, aims to offer a lot more flexibility and “just works” capabilities to users.
This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.
> This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.
As much of a red flag as say Unreal? Who also dumped both Bullet and PhysX.
The solution where you can plug your own engine in is perfect. None of the physics engines are good enough for all games as all engines have discovered. Better to have something simple and in house for 80% of games who need only the basics and then let you bring your own engine.
Unreal by the way doesn't even let you do that anymore. PhysX support is being removed entirely in 5.
I was about to say "they can't, the project is supposed to be fully open-source." Because, you know, Nvidia. But I looked it up just to double-check, and wow, that's like one of the only open-source projects Nvidia has ever published. At least that I've seen.
Godot is still experimenting with Physics engines, rolling back to more primitive homebrew solution. The original statement was straightforward.
Ofc, that's just 1 aspect of the engine. There are numerous bugs in the IDE for 2d, which I have encountered. Also, the asynchronous event system quickly becomes cumbersome as a project grows. Ordering becomes important, for which there is no amount of control in Godot (dealing with mouse events, for example). This leaves every developer to implement a stateful dashboard, of sorts, to ensure events are handled in the correct order. This then leads to nondeterministic delays, etc.
Most commercial games have scripted character movement (every FPS, RPG, strategy games, basically almost every genre) and the only physics objects are random falling objects that don't affect gameplay... Cloth simulation, cool but can be faked and doesn't affect gameplay. Ragdolls, only really used when characters die and again, can be faked.
So name a single AAA game that actually uses proper physics for anything gameplay related?
Most AAA game engines have both ways to bake in physics _and_ to use the exact same system, real time. If you work with Unreal Engine, you use the same tool to get your cloth physics and you can just click a button to bake it and replay it. And this applies to... everything in the engine.
Moving outside of your editor absolutely blows, and the less you do it, the better it is. Unless the alternatives are thousands of times better (nothing comes close to Substance Painter, and tools like Houdini still do some things better than internal tools for example. And of course, well, 3D modeling is still a hellscape of zbrush and Maya.), you just stay in with your tools. Nothing sucks more than having yet another editor and needing to have a pipeline to keep everything in sync.
It's not about needing crazy physics calculations directly in your engine (although your particle system being affected by it can do cool things), it's about not having to deal with yet another tool that fixes one problem and brings in 20 more.
Also, as said, the days of fully scripted movement are pretty much gone. There's physics interactions any time you have vehicles involved unless you want to feel it slide around and feel like crap, for example.
Fortnite, GTA, RDR, apex, PUBG? I mean, scripted games are way less popular than they used to be. And I actually can't think of more than a couple major games without some sort of physics.
Godot is pretty amazing and certainly a Unity killer for me. It's just that I don't need Unity either.
The problem is that Unreal exists and that's so far ahead it's hard to imagine how the OSS world can catch up. Glad to see that Godot is already thinking about streaming assets.
The licensing model of Unreal for small businesses is pretty attractive as well as they don't charge until you made 1M. If I made 1M with my game I certainly wouldn't mind paying 50k to Unreal on my next million.
On the other side, if I'm doing something for fun (read hacking on unfinished code) and I want to have the perfect abstractions, Unity and Godot are certainly not what I envision. I'd probably just work on something like Bevy.
I think building a custom physics engine might not be the best way to go. Its a lot of work and super complicated to get right. I'd be worried that focusing on the physics will send them down the wrong path. That given I really do want to see an open source and widely adopted physics engine. I too have used bullet quiet a bit and it worked for my smallish experiments.
Seems like they accommodate using custom/third party physics engines as well, according to the post. The built in one is probably just gonna end up "easy to use, get started and just works", but if you need something better, integrate PhysX yourself.
Readit News
However, ultimately I abandoned that project because there were too many papercuts in Godot for me to be satisfied. Godot felt like it was a sort of "jack of all trades master of none". Everything worked pretty well but not one thing was fully polished for real world usage. There were ultimately at least one or two shortcomings in every system that just made the experience frustrating when trying to deliver a real project. For example, the asset import system is great but it fell down once I imported by 40,000+ assets or there were limited controls for navigating around the 3D viewport or odd behavior in physics functionality like slide and move that basically meant I needed to write my own equivalent. I am more than willing and able to work around limited features or fix bugs but there's something about "almost does what I need but it's not done yet" that is a real motivation drain. Maybe it's unfair of me, the retort is always "it's open source, contribute back!" but alas that is how I felt as a USER before I considered being a CONTRIBUTOR.
I've been tracking Godot since then and there have been HUGE amounts of work in lots of different systems, it's been quite amazing to watch. However, these decisions were quite ambitious as outlined in this blog (rewrite physics, rewrite renderer, massive upgrades to scripting language, etc.) that now the "polished" experience I've been waiting for has been postponed again. I'm optimistic the day will come where Godot becomes "good ole reliable" but until then I will keep waiting and begrudgingly use something else.
Even as a contributor I've found it very frustrating to contribute to Godot.
I've found lots and lots of bugs while working on my own projects using Godot. I spent a lot of time digging in the engine code to figure out the cause, make an issue and a patch if I could.
However, even small changes take a lot of time and effort. While I used Godot 3 for my own projects most of the PRs had to be based against 4. At the time Godot 4 was in a very sorry state and I ran in many, many issues that made it hard to test if the same fix for Godot 3 also works in Godot 4.
I wrote some libraries to work around issues that I (or others) could not get fixed or reverted (e.g. I replaced the physics engine with Rapier3D because I really needed more stable and working joints) but I eventually threw in the towel and decided to focus on other hobbies.
The lack of support for anything than the bleeding edge in open source is a huge issue :(
I imagine it has to be a bit complex but it sounds like a solvable problem.
They basically found that the Asset Store is such a huge source of revenue for them that they now completely over-leverage it and abuse the community for profit. For the few things they do ship, they routinely break things for backwards incompatibility or literally just ship half complete "products". If you want to do anything meaningful in Unity you either have to build it yourself from the ground up or buy plugins.
An example: their AI navigation system is so lacking in features, they haven't updated it in nearly two years, and the last ship they did was literally half broken and buggy for several use cases.[1]
Also their help desk is currently broken, replacing random text with "$$anonymous$$" and deleting replies[2] :)
1: https://github.com/Unity-Technologies/NavMeshComponents
2: https://forum.unity.com/threads/certain-characters-and-group...
EDIT:
This comment is definitely a venting comment, but I didn't want it to come across like Unity is pure ass. It has a lot of really great things too. I've especially enjoyed their abstractions around vectors, quaternions, cameras, and local/world space. You can do a lot of really complicated operations that look and feel great, without having what would normally require some pretty advanced math knowledge that is beyond me
I guess they get special builds no one else has access to. /s
I still haven't figured this out yet. It's really weird it's so difficult to navigate the viewport, which is a really basic operation for a 3D engine. I've made plenty of levels using the unreal editor, but I can't figure it out in godot.
Godot isn't going to compete against Unity or Unreal anytime soon. Godot's team doesn't have billions at their disposal like Epic or Unity.
edit: Blender also had major advantage aside from begin free, it could do physics and volumetrics for free when the commercial competition required yet another paid plugin just for that stuff, so why pay when the free solution does more than the competition? and let's not even go into requiring separate paid rendering engines for the renders to look decent...
It's the reason why something like blender can catch up with state of the art commercial offerings and I think Godot could go through the same thing.
"jack of all trades master of none" is the shorthand version of the full phrase "A Jack of all trades is a master of none, but oftentimes better than a master of one” which has been used since 1721.
I'm curious if the best solution would be to expose more optional knobs and switches for KinematicBody, or to have a bigger ecosystem of open-source variants.
My own experience. I found that once you go beyond toy projects, the minor irritations, the many "papercuts" you talk about, make game development painful.
I havent used Unity, so dont know if it suffers from the same problem
Dead Comment
The downside of making your own engine is that it’s usually gets more fun to develop the engine itself than games with it…
But I've embraced godot for 2D games and it has been wonderful. I get more code reuse out of the node system than I ever got out of class hierarchies elsewhere. I find myself with the time to set up a lot more test scenarios where I can play two things side by side to find the better feel -- rather than just getting one to work at all.
Yes, that's all subjective and might just be me getting better at game development, but I was immediately productive in Godot, and I haven't run into a roadblock for what I happen to be doing. I imagine there may be a game type, or otherwise simple technique that is nearly impossible in godot, but simple elsewhere; that's true of every game engine it seems.
Deleted Comment
1. Official console support and partnership with platform owners. Yes this code will be closed source, but without this there can't be many AA/AAA games. I'm aware that Godot Foundation is a step to solve this, but it's not yet here and unfortunately 3rd-party companies selling porting services are not sufficient.
2. Once console support is here there will be dire need for game publishers who have pipeline to fund and do marketing for games using Godot. Unfortunately it's very hard to find a publisher for game that built with Godot.
3. Godot need more stable and official support for pesky closed source ecosystems like Steamworks, GOG, etc. There are plugins for that, but they are not as easy to use as in proprietary competitors and not easy to find.
4. There need to be much better tooling for debugging and performance profiling. I've already had some lengthy discussion about it in previous Godot topics so I'm not gonna elaborate much. Its slowly being worked on and improved, but it still inferior than competition.
I love open source and love working with Godot, but unfortunately it's difficult to make commercial games when ecosystem is not there. Game development is hard enough on it's own and sometimes you have to make a choice of whatever you want to support FOSS or you want to make a great games.
https://w4games.com/
For me, the most exciting thing to happen to Godot is the Steam Deck. The question of how to run Godot on the Nintendo Switch came up frequently on r/godot. There was no practical avenue for small time devs. I'm excited to see what doors the Steam Deck will open as an alternative handheld gaming device.
With Godot 4, 2D tilemaps are incredibly awkward to use alongside random generation. You have (had?) to reset neighbor tiles yourself to get it to pick the correct sprite. Setting large numbers of tiles at once is/was terribly slow. The APIs are just a bit awkward, too. Godot 3 didn't have any of these issues.
Basically, once you get off the beaten path, things become noticeably janky in a lot of places. I'm sure some of the obvious bugs will or have already been fixed for the beta, but some, like tilemaps, seemed to simply have a response of "it's working as intended", and others (like GDScript scalability or native DLL hot reload) are simply not fixable without another redesign.
I was surprised to not feel limited by gdscript (having no python background and doing most work in JS for the past decade). I picked it up quickly and it's well documented and integrated into vscode.
Not sure if it would be my choice for a large game with millions of entities (e.g. an online RPG that needs an ECS system) but for small 2d games it is a delight to work with.
I may be the minority here, but I hope Godot doesn't try to cater to AA/AAA devs and keeps small indies front and center as the focus.
This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.
As much of a red flag as say Unreal? Who also dumped both Bullet and PhysX.
The solution where you can plug your own engine in is perfect. None of the physics engines are good enough for all games as all engines have discovered. Better to have something simple and in house for 80% of games who need only the basics and then let you bring your own engine.
Unreal by the way doesn't even let you do that anymore. PhysX support is being removed entirely in 5.
Deleted Comment
Ofc, that's just 1 aspect of the engine. There are numerous bugs in the IDE for 2d, which I have encountered. Also, the asynchronous event system quickly becomes cumbersome as a project grows. Ordering becomes important, for which there is no amount of control in Godot (dealing with mouse events, for example). This leaves every developer to implement a stateful dashboard, of sorts, to ensure events are handled in the correct order. This then leads to nondeterministic delays, etc.
Most commercial games have scripted character movement (every FPS, RPG, strategy games, basically almost every genre) and the only physics objects are random falling objects that don't affect gameplay... Cloth simulation, cool but can be faked and doesn't affect gameplay. Ragdolls, only really used when characters die and again, can be faked.
So name a single AAA game that actually uses proper physics for anything gameplay related?
I agree it's not all that common but they are definitely out there. As for whether you could build those with Godot's engine I have no idea.
Moving outside of your editor absolutely blows, and the less you do it, the better it is. Unless the alternatives are thousands of times better (nothing comes close to Substance Painter, and tools like Houdini still do some things better than internal tools for example. And of course, well, 3D modeling is still a hellscape of zbrush and Maya.), you just stay in with your tools. Nothing sucks more than having yet another editor and needing to have a pipeline to keep everything in sync.
It's not about needing crazy physics calculations directly in your engine (although your particle system being affected by it can do cool things), it's about not having to deal with yet another tool that fixes one problem and brings in 20 more.
Also, as said, the days of fully scripted movement are pretty much gone. There's physics interactions any time you have vehicles involved unless you want to feel it slide around and feel like crap, for example.
The problem is that Unreal exists and that's so far ahead it's hard to imagine how the OSS world can catch up. Glad to see that Godot is already thinking about streaming assets.
The licensing model of Unreal for small businesses is pretty attractive as well as they don't charge until you made 1M. If I made 1M with my game I certainly wouldn't mind paying 50k to Unreal on my next million.
On the other side, if I'm doing something for fun (read hacking on unfinished code) and I want to have the perfect abstractions, Unity and Godot are certainly not what I envision. I'd probably just work on something like Bevy.