Godot for AA/AAA game development – What's missing?
godotengine.org
godotengine.org
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.
I imagine it has to be a bit complex but it sounds like a solvable problem.
There needs to be features like feature/bug-bounties that you can trust even if you don't fully trust the repo-owner/maintainer?
WAT? I pay for porn on patreon and have for years. Maybe it's just live video porn that's banned? I have no idea. AFAIK the artists I'm subscribed to are not hiding their creations. In fact they're all over sites like pornhub, spankbang, etc with their patreon address in their videos. It's all CG or real time 3D but it's most certainly porn.
We ask our company to set aside of a small amount of money each year, and we distribute it among projects we most used that year on librapay.
Personally I feel more inclined to donate myself when I feel there is a reliable way for others to donate in unison with me, so that it has a chance to become substantial enough to make a difference. I think that's the value proposition of Patreon and Kickstarter.
I think it would be best to attempt to understand what the person complaining meant by "political", (and if one dislikes using the word "political" by itself to express that idea, or if is unsure if one is interpreting correctly, perhaps rephrase the idea in one's own words, and maybe ask if that was what was meant) and respond to that.
I saw a poll result the other day, which said that, in 2020, some voters and some corporate executives were asked whether they approved of companies expressing support for political/electoral/whatever causes/social issues, and given the options of "yes", "yes, but only if directly related to the company's core business", and "no". According to this poll result, less than 40% of voters picked "yes", and almost 80% said either "yes" or "yes, but only if directly related to the company's core business". (for completeness, but not really relevant to my point : over 60% of the corporate executives polled said "yes", and under 10% said "no")
Perhaps an analogy can be drawn between these two situations?
No fees - 100% non profit.
Probably not "widely successful", though, otherwise you would have heard of it. And the overal money flowing through it, is quite modest. The main problem is still in the minds of people, I think. If something is free, then there is no need to pay, then most won't pay (or they pay 5€ and think they own the developer now).
Having spent some time maintaining large OSS projects as a first party engineer, these are the options I see:
- pay a fixed donation per month, a la patreon/etc. I would never do this. If I'm buying software for a company I want a real support contract, not a "I'll really try to respond to your issues with higher priority!". If I'm using software in a personal project, I want the monthly burn to be as close to 0 as possible. Also, who takes that money? What do third party PR submitters get? What do people who submit excellent issue reports with crash dumps and full debug traces get? What do first party PR reviewers get? Third party? etc. etc.
- stake money on the closing of a given issue/PR. This is better, but comes with a whole can of worms. The obvious failure mode is a third party contributor submitting a PR, the maintainer saying "eh.... I don't really agree with the way you've done this", then building it themselves. Next step on that train is a fight between the third party and the maintainer about how much influence one's code had on the other. Even if that doesn't happen, the maintainer is almost guaranteed to request changes of some sort, who decides how much the maintainer gets for their work reviewing versus the third party for their work contributing?
Not to mention the dirty little secret behind many third party contributions: if you are new to the repo, the frameworks, oss in general, etc., it is highly likely that the maintainer's work in holding your hand through contributing to the repo will far outweigh the work they'd need to put in to make the change themselves. But few would agree to paying the maintainer to accept their PR, or likely even the maintainer getting more money than them for their own PR.
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.
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
However, its core is really robust and powers almost all VR experiences and startups, such as Gravity Sketch and Arkio. Which is why I still find myself drawn to Unity.
I guess they get special builds no one else has access to. /s
In fact, Unity is actually the example I generally give of a product which is both widely used and terrible. It's better than it used to be. At some point, it was downright terrible. I remember Wasteland 2 running worse than a modern AAA game while looking like a ten years old game at launch.
To be blunt, given the new licencing terms of the Unreal engine, I don't think you should ever use it unless you are already really familiar with it.
I rather support an engine that embraces C# than one that keeps the C++ status quo.
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.
In practice, the industry loves to replace fully working projects rather than tweak existing, so we will never get to such a state of nirvana.
The software never gets to total nirvana. What happens is it gets to a state of nearly nirvana such that changes are tiny.
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.
And blockers on patching this into the editor?
Context: I have a very basic engine written in Rust/WGPU. Mainly using for chemistry sims. This is its default nav system.
This is exactly how the editor works. It's just not the default mode. They call it freelook mode. You can either hold the right mouse button or toggle it with shift+F.
Afaiu the reason for two different camera control schemes in DCCs and game engines is that they’re suited to different workflows. On the one hand, object-centric orbit-style controls are great for, eg, modeling, whereas free-fly WASD / mouselook controls are great for level blockout, in-scene camera positioning, etc.
By default you have to hold the right mouse down to enable free-fly controls in Unreal.
Sorry you might know all this. Just if you are expecting one camera control scheme and getting another I know it can be frustrating.
"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.
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 :(
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
* SFML (C++), Ebitengine (Go), bevy (Rust) - high level, easier to use.
* LÖVE2D (Lua), raylib (C) - even higher level.
And Dear ImGui is a must for implementing debug UI/level editor/tools. And maybe PICO-8 as an alternative (it’s something in-between of a low-level framework and a game engine)
Of course, it might also just be that you don't want your employees to get any fame, but they do seem to be allowed to talk at GDC.
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.
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.
At the same time I think 2 years working with Godot full time is enough to talk about it's strong and weak sides including ecosystem problems that make commercial game development even harder.
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.
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.
However, they say:
> That said, Godot 4.0 introduces the ability to bind custom physics engines at runtime (without recompiling Godot) via GDExtension, so it’s perfectly possible for the community to integrate other engines such as PhysX, Jolt, or Box2D if need to be.
I'm liking this work on GDExtension. It'll make Godot a lot more capable just on its own.
The only tried to integrate Bullet.
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?
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.
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.
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.
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.
* 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.
But the workflow of designing e.g. a tile hitbox and then applying it quickly to multiple tiles is exactly how it works now.
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.
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.
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.
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.)
If it's "too hard" for Unreal, why wouldn't it be too hard for Godot? I think this is really an unfair criticism when you look at other game engines. Unreal had Bullet support in version 3 and dumped it. And they had PhysX in version 4 and dumped it in 5.
> now promise to make an "engine agnostic" interface for physics engines
Which is exactly what Unity did.
It seems like you have a problem with what Godot does no matter what they do, even when they just follow what Unity and Unreal are doing.
Godot's in-house engine is neither performant, nor accurate, and it boggles the mind to think that having abandoned the relatively easy task of implementing a single physics engine written in the same language as their game engine (and that their competitors were able to integrate and support) that they would be able to accomplish the far more difficult task of implementing an engine-agnostic interface supporting multiple physics engines, as accomplishing the latter would require them to first accomplish the former...
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.
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.
[1] https://godotengine.org/article/dev-snapshot-godot-4-0-beta-...
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! :)
But the culprit are c++ gcc devs, not godot devs.
I'd also be curious what the Godot support is like in terms of maintaining older releases. I think it would be a mistake to tell a young person to use a beta version since they could hit a lot of bugs and get discouraged, but having them use an existing version that doesn't get a lot of new support might also be discouraging.
Does anyone have any thoughts on what they'd suggest for building a simple side scroller?
PyGame is also a good starting place.
If these two seem too elementary for their needs, consider Unity and Godot.
Godot and Unity allow exporting into web projects.
I'd get them started on something like Construct 3, or maybe Pico-8.
(Oh, and he used Bolt visual scripting in Unity for a while, with decent results until we decided that Godot was much less hassle.)
I'd say that he has come across zero bugs so far.
(Godot had a visual scripting system but they removed it in 4.0. And it wasn’t really intuitive to learn anyway, compared to how GameMaker does things.)
A simple side scroller? Gamemaker.
A more-advanced 2D game? Gamemaker or Unity.
A 3D game? Unity.
An FPS or other first-person game? Unreal.
Programming skills that will be useful for a career in programming generally or in game development specifically? Unity or Unreal.
With Godot, you'll be perpetually waiting for Godot to finish up and polish the 30% of features you actually want/need. I gave Godot 5 years before I gave up on it. Unity has announced, implemented, and abandoned features in less time than it takes Godot to finish that last 30%.
Not much I'd say, given that there's quite a few "successful" (eg. enough buyers for many positive reviews) games on Steam. Also based on those games typically being very small studios I'd assume that if a company that repeatedly throws out AAA games (that aren't just some small improvements of an existing codebase) would use Godot to do so it would be a AAA game.
I know Unity abandoned their old networking and is working on a new one, but at least there are open source options like mirror, and paid options like photon fusion.
It’s a farce. It’s like including fmod bindings and saying yes we support fmod, but having zero integration.
There’s no serialization, deserialization, no prediction, no reconciliation, no interpolation, nothing.
Thinking back, early Unity was rock solid. The core stuff was great, it's all the newer stuff in Unity that sucks.
I guess if people keep patching Godot then it will be fine.
Unreal is already great for this, with Unity trying it's best to get there. We need an engine focused on the problems of smaller developers, especially on mobile. Defold is another open source engine that seems focused on this, which makes more sense to me.
Real time GI makes such a radical difference in a way games look.
And while it doesn't have streaming as mentioned it does have automatic LOD reduction and occlusion culling which are both a part of what Nanite does.
Sure, Roblox does too, to some extent. Nanite allows all of this to be taken to the extreme, allowing you to do things that are practically impossible with other engines, including Godot. I think the next gen of games, that use Nanite, are going to stand out in a ridiculous way, which is often appealing for AA/AAA studios.
Another huge thing to make things faster is to check the "enable playmode run settings" box and ensure that you don't reload the entire code base every time you press the play button. If a "waiting" box pops up every time you press play then the settings aren't right, you can remove that so entering and exiting play happens instantly.
Post Scriptum. I work on the 3d importer pipeline.