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.
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.
> 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...
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.
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 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.
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.
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?
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.
I love Godot to pieces, have used it for several games and will continue to do so. Here's what's missing:
* Sane animation import toolchain. The current one from blender is enormously finicky.
* Good enough pathfinding (supposed to be fixed in GD4)
* Better native map support (heighmap or some sort of interior)
* Fix the 2d tileset editor, doing anything interesting in it is way too labor intensive because it lacks copy paste for tile parameters. A better system would let you set up a small number of tile templates and just map tiles to templates to quickly rig up huge tilesets.
The new tile editor works much in the way you describe and people overall seem to hate it. I quite like it. I'll grant them that it's a bit weird and needs some cleanup (there's a tab that's in two places for two subtly different purposes, for example), but I still prefer it to the old version.
But the workflow of designing e.g. a tile hitbox and then applying it quickly to multiple tiles is exactly how it works now.
If you are looking for a AAA open source engine today with an open community, check out https://www.o3de.org
I hope Godot continues to improve and competition increases in the open source AAA gaming engine space as this space is well overdue for fully open source options.
I wouldn't attach myself to it, the community( Amazon employees mostly) are friendly, they'll even offer to help you with any issues you run into.
But seriously, no games exist, no real demo projects with it exist. For some reason it uses Lua instead of strongly typed language like C#.
Seriously, games NEED types. At scale projects get really messy without them. Oh wait, O3de pushes script canvas on you.
At the end of the day , I find myself getting sucked back into Unity. Unity could be better, but it's still the best engine for most people. Much of that is just due to documentation. For some reason Amazon decided effectively hide all of it's old Lumberyard docs and examples when they rebranded as O3de. No one will ever know why.
I really don't like the RenderingDevice abstraction they've ended up with.
It's strongly reminiscent of OpenGL, doesn't expose command buffers or queues (no async compute). Barriers are too coarse. There's also no support for a bindless approach, no GPU driven rendering or even just GPU culling.
What's an example of something that does blindless fully GPU driven rendering? Would it mean CPU lag wouldn't slow your game because the camera could be fully controlled by the GPU?
Godot's showcase game was supposed to be the poorly-reviewed remaster of Sonic Colors Ultimate that came out 2 years ago. Unfortunately, the remaster was extremely buggy to the point of being unplayable on a PC.
And Godot has pretty much been DOA for AA/AAA development since then.
It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement and now promise to make an "engine agnostic" interface for physics engines, which is significantly more more work than just figuring out how to implement a single physics engine (and extending that implementation to be engine agnostic).
Godot is the anti-Blender; it's perpetually 70% of the way "there" but they are always abandoning that last 30% because it's too hard, or too boring, to finish.
(For comparison, at this point in its lifecycle, i.e., 9 years old, Unity was well-polished and had already been the choice for indie and mobile game development for several years. In the past week alone, multiple one-developer games made in Unity have made it to the front page of HN.)
I have been using Godot since it was open-sourced in 2014. I'm also familiar with the source code and I have made some contribution. I mostly created prototypes until two years ago when I started working my first commercial project, it's called Outer Space: War Gears and it's a six-degrees-of freedom space shooter.
I chose Godot mostly because of the familiarity and hackability. However I spent a lot (too much) time working around/fixing obscure bugs in the engine. I figured I was definitely the first one to use some features (given they really didn't work), like using GDNative in a MT fashion.
Another issue (for Godot 3.x, Godot 4 is much better in this regard) is that GDScript is really slow. I got to a point where it took longer to run all the script than to run the physics step (and my game is physics-based, all actors are rigid bodies!). Luckily GDScript is fully parallelizable as it doesn't have a GIL. So now I run a lot of code in thread pools and do a lot of sub-step optimizations. If you do use it with MT, though, you won't be able to debug GDScript and profile on any other thread than the main one - for better profiling I just use perf.
However I'm reluctant to use Unity and UE because even just loading the project in the editor is much faster in Godot. I like it being so lightweight. I also like how you can easily write native modules for it. Recompiling the Engine is quite fast.
I hope Godot 4, with more support from companies and the community will get much better.
At the very least, language support should be better thanks to GDExtension.
I'm not a fan of GDScript either and C# is too heavy for my tastes, so I'm waiting to see which alternate language implementation matures enough for someone to actually publish a game with it.
Has 3D performance improved in Godot 4? I remember messing with 3 and the overall performance was pretty terrible compared just about any other 3D engine as soon as you started adding any complexity.
Does anyone know where the Godot 4.0 source is? I don't see any branches or tags for it on the main repo on GitHub. I've only seen the pre-compiled dev snapshots. It would seem weird for them to develop an open-source project behind closed doors. I must just be blind?
Whether it's the scripting language or the physics engine, Godot's in-house solutions (and general differences to other game engines) always draw a bit of criticism. The article mentions the 'considerable amount of issues' for the in-house physics solution, but it doesn't make a direct statement about the quantity or severity of issues to do with including bullet over the years.
Hugely powerful and complex physics engines have become the default solution to practically everything motion or collision related in games. But most games don't need most of what the big/serious physics engines provide. Unfortunately, there is an expectation that game engines come with one of these included and so they are, usually as the only built-in way to perform collision detection.
If you're making a game that has modest 'physics' requirements, you're stuck trying to break the big physics engine to get it to do less. If you're making a game that does have a need for a high-end solution (e.g. PhysX), it becomes increasingly painful as you are forced to access the physics engine via the APIs that the game engine provided.
I also think it's a sign of where Godot is in development that the scripting and artist interfaces are mentioned at the tail end. There's a vast graveyard of unused "programmer-led" features on big game engines, ignored by the artists or designers who make up 90% of the production team because of a lack of editor polish or discoverability.
Between that and... no Perforce support (what... 95% of AA+ game studios use), I would bet that Godot's first usage for AA/AAA will come from a new team that grows an indie success and with a plucky engine team that can keep bolting on exactly what they need for their game to grow. I'll be interested to see what it is! :)
On elf/linux, it is missing a static libstdc++ which has the decency to libdl(dlopen/dlsym/dlclose) all its (module/version)s&(symbol/version)s from the system.
[+] [-] lazypenguin|3 years ago|reply
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.
[+] [-] demindiro|3 years ago|reply
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.
[+] [-] rstupek|3 years ago|reply
[+] [-] brookst|3 years ago|reply
[+] [-] raffomania|3 years ago|reply
[+] [-] snarfy|3 years ago|reply
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.
[+] [-] throw_m239339|3 years ago|reply
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...
[+] [-] therein|3 years ago|reply
"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.
[+] [-] avx56|3 years ago|reply
[+] [-] logicprog|3 years ago|reply
[+] [-] LanceH|3 years ago|reply
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.
[+] [-] hugs_vs_toph|3 years ago|reply
[+] [-] SXX|3 years ago|reply
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.
[+] [-] manchmalscott|3 years ago|reply
https://w4games.com/
[+] [-] georgeecollins|3 years ago|reply
[+] [-] frompdx|3 years ago|reply
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.
[+] [-] Buttons840|3 years ago|reply
[+] [-] singingboyo|3 years ago|reply
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.
[+] [-] bdickason|3 years ago|reply
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.
[+] [-] mkl95|3 years ago|reply
This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.
[+] [-] light_hue_1|3 years ago|reply
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.
[+] [-] seanw444|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] teawrecks|3 years ago|reply
[+] [-] Mikeb85|3 years ago|reply
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?
[+] [-] jokethrowaway|3 years ago|reply
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.
[+] [-] 88stacks|3 years ago|reply
[+] [-] capableweb|3 years ago|reply
[+] [-] EamonnMR|3 years ago|reply
* Sane animation import toolchain. The current one from blender is enormously finicky.
* Good enough pathfinding (supposed to be fixed in GD4)
* Better native map support (heighmap or some sort of interior)
* Fix the 2d tileset editor, doing anything interesting in it is way too labor intensive because it lacks copy paste for tile parameters. A better system would let you set up a small number of tile templates and just map tiles to templates to quickly rig up huge tilesets.
[+] [-] sli|3 years ago|reply
But the workflow of designing e.g. a tile hitbox and then applying it quickly to multiple tiles is exactly how it works now.
[+] [-] caniszczyk|3 years ago|reply
I hope Godot continues to improve and competition increases in the open source AAA gaming engine space as this space is well overdue for fully open source options.
[+] [-] remram|3 years ago|reply
[+] [-] 41209|3 years ago|reply
But seriously, no games exist, no real demo projects with it exist. For some reason it uses Lua instead of strongly typed language like C#.
Seriously, games NEED types. At scale projects get really messy without them. Oh wait, O3de pushes script canvas on you.
At the end of the day , I find myself getting sucked back into Unity. Unity could be better, but it's still the best engine for most people. Much of that is just due to documentation. For some reason Amazon decided effectively hide all of it's old Lumberyard docs and examples when they rebranded as O3de. No one will ever know why.
[+] [-] Rhedox|3 years ago|reply
It's strongly reminiscent of OpenGL, doesn't expose command buffers or queues (no async compute). Barriers are too coarse. There's also no support for a bindless approach, no GPU driven rendering or even just GPU culling.
[+] [-] koolala|3 years ago|reply
[+] [-] MikusR|3 years ago|reply
[+] [-] Thaxll|3 years ago|reply
[+] [-] gamblor956|3 years ago|reply
And Godot has pretty much been DOA for AA/AAA development since then.
It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement and now promise to make an "engine agnostic" interface for physics engines, which is significantly more more work than just figuring out how to implement a single physics engine (and extending that implementation to be engine agnostic).
Godot is the anti-Blender; it's perpetually 70% of the way "there" but they are always abandoning that last 30% because it's too hard, or too boring, to finish.
(For comparison, at this point in its lifecycle, i.e., 9 years old, Unity was well-polished and had already been the choice for indie and mobile game development for several years. In the past week alone, multiple one-developer games made in Unity have made it to the front page of HN.)
[+] [-] m4nu3l|3 years ago|reply
I chose Godot mostly because of the familiarity and hackability. However I spent a lot (too much) time working around/fixing obscure bugs in the engine. I figured I was definitely the first one to use some features (given they really didn't work), like using GDNative in a MT fashion.
Another issue (for Godot 3.x, Godot 4 is much better in this regard) is that GDScript is really slow. I got to a point where it took longer to run all the script than to run the physics step (and my game is physics-based, all actors are rigid bodies!). Luckily GDScript is fully parallelizable as it doesn't have a GIL. So now I run a lot of code in thread pools and do a lot of sub-step optimizations. If you do use it with MT, though, you won't be able to debug GDScript and profile on any other thread than the main one - for better profiling I just use perf.
However I'm reluctant to use Unity and UE because even just loading the project in the editor is much faster in Godot. I like it being so lightweight. I also like how you can easily write native modules for it. Recompiling the Engine is quite fast.
I hope Godot 4, with more support from companies and the community will get much better.
[+] [-] krapp|3 years ago|reply
I'm not a fan of GDScript either and C# is too heavy for my tastes, so I'm waiting to see which alternate language implementation matures enough for someone to actually publish a game with it.
[+] [-] tekni5|3 years ago|reply
[+] [-] seanw444|3 years ago|reply
[+] [-] throwawayben|3 years ago|reply
[+] [-] ydnaclementine|3 years ago|reply
[+] [-] sprkwd|3 years ago|reply
[+] [-] qwery|3 years ago|reply
Hugely powerful and complex physics engines have become the default solution to practically everything motion or collision related in games. But most games don't need most of what the big/serious physics engines provide. Unfortunately, there is an expectation that game engines come with one of these included and so they are, usually as the only built-in way to perform collision detection.
If you're making a game that has modest 'physics' requirements, you're stuck trying to break the big physics engine to get it to do less. If you're making a game that does have a need for a high-end solution (e.g. PhysX), it becomes increasingly painful as you are forced to access the physics engine via the APIs that the game engine provided.
[+] [-] liamkf|3 years ago|reply
I also think it's a sign of where Godot is in development that the scripting and artist interfaces are mentioned at the tail end. There's a vast graveyard of unused "programmer-led" features on big game engines, ignored by the artists or designers who make up 90% of the production team because of a lack of editor polish or discoverability.
Between that and... no Perforce support (what... 95% of AA+ game studios use), I would bet that Godot's first usage for AA/AAA will come from a new team that grows an indie success and with a plucky engine team that can keep bolting on exactly what they need for their game to grow. I'll be interested to see what it is! :)
[+] [-] Avamander|3 years ago|reply
[+] [-] sylware|3 years ago|reply
But the culprit are c++ gcc devs, not godot devs.
[+] [-] alex7o|3 years ago|reply