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.
On top of that, polish usually involves some amount of opinionated design, which can be hard to contribute to an open source project - you’ll break someone else’s workflow, or maybe it doesn’t mesh with the ideas of a core maintainer, etc.
IMO the issue is as soon as it's paid, there needs to be a "Software Engineering Manager" of some sort or another in the middle of the payers and the workers. That's a very difficult job to hard-code.
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'd be more okay with donating via Patreon if they didn't do the thing where every internet platform that becomes successful feels the need to start going down the political route. I'm not sure if this is a more of an issue due to the employees, or due to social media pressure, or if it's just "keeping up with the times" but I hate it. And it's also so US-centric, which makes sense as they are usually US-based companies, but it just irritates me looking from the outside.
As someone who doesn’t follow the details of day to day Very Online politics-adjacent drama, I haven’t heard much about Patreon, so… they seem to be threading the needle well enough to stay off the radar of boring normies like myself. What’s their issue?
They started banning creators who made NSFW content a few years ago, might be that. They never allowed porn, but they started hammering down on all sorts of erotic material. I don't really care, but others do.
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.
It's due to chargeback risk. A lot of times folks will be caught paying for adult content on a credit card statement by a family member. They'll just tell family that it was fraud and dispute the charge. This occurs frequently enough that Visa and MC aren't fans of adult content on their payment networks.
This seems like a natural outcome of running such a platform. The platform is trying to optimise revenue. They can choose which user complaints to support/reject but they can’t satisfy everyone.
opencollective maybe? They have multiple "hosts" that handle receiving the money, tax paperwork, and approve spending. So a project probably doesn't need too much trust if you trust the host... if I understand this right.
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).
Wikipedia, Mozilla, Gnome... they've all been found to be poor stewards of donated money, using it for pet ideological projects instead of the projects that are the foundation of each organization. If I go to the discussion site for many FOSS projects, it's hard to go very long without seeing lots of political activism being pushed. FOSS decided to become political or those who are political decided to invade FOSS. Either way, they've made their bed and now it's shrinking their pool of potential resources.
FOSS had always beeen political. How the heck is giving you the freedom to modify and tinker the source code of the software you are using, no string sattached, not a political act?
I think it's fair to say that then "the ones who just want to have things for free as in beer" came. But FOSS has always been pretty utopian.
The word "political" is used in a number of ways. When someone says "How could <x> __not__ be political? Of course it is political." in response to someone complaining about <x> becoming political, I think the person responding is typically using the word "political" in a way different from how it was being used in the original complaint.
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?
I don't know about crowd source, but one of my favorite solutions come from the ElementaryOS team. Their software store allows you to pay for what your downloading and I think that goes directly to the project? So its like opening the GNOME software center, but having the ability to donate right there as you go to download it.
I feel that your point isn't the whole story. Patreon seems to be financing a lot of creators nowadays.
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.
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
I have been using Unity for around 5 years now, and have come across many issues, from lacking documentation, weird APIs, breaking or forever-in-experimental packages, to issues with implementing best-practices for software development.
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.
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
Being used often for projects with cheap production budgets and being good are orthogonal concepts especially when talking about the video game industry where cobbled together middlewares for one shot development is the norm. Unity became tier 1 supported because it was widely used by indie projects. Implying the reverse is mistaking cause for effect.
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.
> 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.
Zoom is limited. It's not infinite zoom. How do I move through the level in Z direction? I saw a video mention WASD keys but it didn't work for me. In unreal you can fly through the level using mouse and keyboard. WASD is cardinal direction and mouse is camera rotation. In godot mouse wheel zooms the camera, but I couldn't find a way to 'move' the camera in Z.
Hold the right mouse button and press WASD Q/E. It works as you would expect. You can press shift+F to toggle this mode if you don't want to hold down the button.
Not familiar with Godot but that sounds like camera dolly.
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.
As most people working on these are probably aware, this is very easy to implement in a 3d engine using a quaternion orientation that rotates the WASD vectors, updating position and view orientation accordingly. Can do it with FPS friendly things like WASD + Q and E for roll, and space and C for up/dn.
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.
> Can do it with FPS friendly things like WASD + Q and E for roll, and space and C for up/dn.
>
> And blockers on patching this into the editor?
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.
TBH, this is completely undiscoverable. I can understand the GP poster missing it. I went looking through the menus and clicked all the buttons in the viewport and didn't find this (and still can't, other than in the settings).
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.
Isn't that true of all software? At some point, things should be able to be fully feature complete. Maybe update the UI toolkit every five years to appear fashionable.
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.
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…
* glfw, SDL - C, low level, require more work to get started with (maybe coupled with bgfx if you don’t want to write your own renderer).
* 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)
Unfortunately, not really. I don't actually have a ton of experience with gamedev outside of engines, I just know what the failings of engines are from using them for a few projects over the years. The one library I might've recommended is a Rust one that's now defunct.
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:
Making games is hard and marketing them for the right audience is even harder. Anyone who want ot make make game development their primary job have to take a risk of their game not becoming bestseller. Though in reality 90% of games simply never getting to release at all.
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.
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.
No, I read it right. I was saying that I was about to explain why, but my explanation turned out to be incorrect, to my surprise.
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.
Isn't PhysX hardware accelerated only with CUDA? In that case it would make sense for Godot to avoid it even if it's open source, becasue it's targeted for Nvidia.
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.
Not really. There are whole genres where physics isn't really a thing (RTS, card games, turn based strategies). Even where there are physics, they don't need to be complex, just fast. Most fps games, for example Fortnite, don't really use complex physics stuff like joints, and most don't even have fast moving objects.
Most games basically just have rigidbodies. Some cinematic-ish AAAs have fancy cloth simulation or something, but even that is usually prebaked I think.
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.
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.
Awesome. I built a decent little top down tile shooter with free graphics but realized making more levels would be mostly an exercise in editing tiny tile squares so I decided to do other things.
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?
On the contrary, bindless means less work for the CPU. Bindless basically means the GPU is responsible for querying image and buffer resources from a global heap or descriptor table.
I wrote extensively about that as part of my vulkan guide. https://vkguide.dev/docs/gpudriven .
The TLDR of it is that you have the cpu upload scene information to the GPU, and then the GPU performs culling and batching by itself in a series of compute shaders. In most games the scene is 99% static, so you can upload the scene at the beggining and never touch it again. this decreases CPU-GPU traffic by orders of magnitude, and if used right, gives you 10x or more performance improvements. Unreal 5 Nanite tech is based on this concept.
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.)
> It doesn't help that they just dropped the Bullet physics engine because it was "too hard" to implement
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.
The difference is that you can, and could, make fully functional physics-based games in Unity and Unreal because their in-house engines were accurate and performant enough. The point of integrating Bullet/physX was to provide the option for even more accurate physics engines.
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 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?
The organization with the 4.0 changes seems pretty haphazard overall, there's no conclusive list of everything that's changed without going through multiple changelogs for each individual release, or even more cumbersome ways like using git log. For example lots of stuff was renamed but I can't find any good list outside of going into the C++ converter at https://github.com/godotengine/godot/blob/master/editor/proj....
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.
Would Godot be a decent engine for kids around 12-14 years old? I don't know a lot about it, but would like to suggest something for a person I know.
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?
GameMaker is pretty much the best game engine to get introduced to programming. It has a visual scripting tool that lets you write basic logic without any raw textual coding, but also provides a smooth transition path to learn an actual scripting language (GML) when the child becomes more ambitious. I’ve started programming at a young age thanks to this.
(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.)
Note that the original GameMaker isn't around anymore. They moved on from that to their new engine GameMaker Studio, and apparently recently renamed that back to GameMaker again.
Shameless self-plug: we make Construct, which has a visual block-based system, runs in the browser with no install, and also supports progressing on to JavaScript coding: https://editor.construct.net/
Question for you and the sibling comment: What are the issues with WebGL, in your experience? It has been around for over a decade at this point, and I often wonder if it has yet to become a viable target.
My youngest (12K) is writing a 2D platform game in it (3.x). He's had exposure to Pico-8 and various other environments (as well as basic Python) and has spent a while figuring out the mechanics of things like double jumps entirely on his own.
(Oh, and he used Bolt visual scripting in Unity for a while, with decent results until we decided that Godot was much less hassle.)
Godot 3 is pretty well supported and maintained for now. It's a great engine for smaller or personal projects IMO. Really reduces the barrier to entry to make a game, especially 2D or basic 3D
It depends on what kind of games they want to make and what they hope to get out of it.
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%.
Super subjective. Not a Godot developer/user/..., just a gamer who played games that were developed with Godot.
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.
The answer is no, you have to write your own networking. They provide enough to say, “Yes, we have multiplayer support,” but the real answer is “No,” because you still have to do it yourself.
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.
I wonder will Godot be the next Unity? Everyone I know who has seriously gotten into it complains about bugs in fundamental things (like floating point operations in one case)
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.
Can someone ask why does it needs to cater to AA and AAA studios?
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.
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.
Who cares? Storage is cheap and is getting cheaper. Huge games are inevitable. (unless we come up with some sort of an AI that generates all the objects and textures close enough to the real ones)
Do you prefer Godot or Unity for 2D games these days? I did a simple game in Unity and it went pretty well. I'd prefer to use C# if possible. Unity is a very nice environment but IIRC it really seems to chug when reloading user scripts from disk after updates.
You can make unity much faster by disabling "version control" in the package manager, you don't need it but it makes code reload time much much longer.
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.
I'm curious to know anecdotal artist impressions of the 4.0 Godot Engine 3D pipeline, since all the bugs that were too hard earlier are now being looked at and there's momentum to deliver a release.
Post Scriptum.
I work on the 3d importer pipeline.
Your users at an AAA studio (artists, scripters, builders, audio designers, etc.) constantly require support: features, bug fixes, band-aids. An engine does not give you that, ultimately you need people.
A red flag for me is all the talk about optimizing which focuses on making things multi-threaded as if that was a silver bullet. Recently we took multi-threading out of a portion of a renderer and then fixed what actually was slow and it's now running single-threaded and much faster than the previous multi-threaded version. Learning to understand what your real bottlenecks comes from experience in how to profile. Saying your are going to fix things by going multi-threaded is great and all but first understand why your single threaded performance is poor. Not all systems are going to respond simply by going multi-threaded.
I don't make a lot of "games", but I do make a lot of tools these days (native OS GUI/console-cli etc.). And I feel like Godot wouldn't really be a good fit for such things, or am I wrong?
I like how they address their own short comings. This is markedly different to a lot of Linux fanatics in the past. (Though I will say for Linux the ux is truly becoming more and more on par with a closed source a os)
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.