Groud
@groud.bsky.social
Developer at 🍀@W4Games. Contributor to @godotengine.
Mastodon: @groud@mastodon.gamedev.place
Mastodon: @groud@mastodon.gamedev.place
Oh! That's something I had the idea to tackle someday but never had the time to!
I'm so happy you implemented it, it's such an obvious UX improvement. Good job!
I'm so happy you implemented it, it's such an obvious UX improvement. Good job!
November 13, 2025 at 10:44 PM
Oh! That's something I had the idea to tackle someday but never had the time to!
I'm so happy you implemented it, it's such an obvious UX improvement. Good job!
I'm so happy you implemented it, it's such an obvious UX improvement. Good job!
Hat off for such a quality pun! 👌
November 13, 2025 at 10:01 AM
Hat off for such a quality pun! 👌
I have an integrated AMD GPU and a dedicated nvidia one on Arch Linux. It's a PITA. The topic is quite complex already, and is made even more complicated with the open source vs proprietary drivers situation. I am a bit annoyed by the situation there tbh...
October 6, 2025 at 10:13 AM
I have an integrated AMD GPU and a dedicated nvidia one on Arch Linux. It's a PITA. The topic is quite complex already, and is made even more complicated with the open source vs proprietary drivers situation. I am a bit annoyed by the situation there tbh...
I am pretty sure those bumps are simply due to the project leads asking people to star the project (on Twitter).
A thing that was not done around 4.0, IIRC.
A thing that was not done around 4.0, IIRC.
August 15, 2025 at 7:04 AM
I am pretty sure those bumps are simply due to the project leads asking people to star the project (on Twitter).
A thing that was not done around 4.0, IIRC.
A thing that was not done around 4.0, IIRC.
RGB fans on your computer
July 11, 2025 at 8:10 AM
RGB fans on your computer
I'd say it's a mix between the two. The core of the engine and what people like about it will likely not change. But users opinion is taken into account.
The general idea is that the community kind of drive the engine in a direction, but maintainers (those doing the work) always have the last word.
The general idea is that the community kind of drive the engine in a direction, but maintainers (those doing the work) always have the last word.
July 10, 2025 at 7:31 PM
I'd say it's a mix between the two. The core of the engine and what people like about it will likely not change. But users opinion is taken into account.
The general idea is that the community kind of drive the engine in a direction, but maintainers (those doing the work) always have the last word.
The general idea is that the community kind of drive the engine in a direction, but maintainers (those doing the work) always have the last word.
On the contrary, pointing out a specific issue in your project, and what possibility is missing has more chance to grab attention. Yet the solution to your problem might not be implemented the way you want it exactly. (For many different reasons up to maintainers)
July 10, 2025 at 5:39 PM
On the contrary, pointing out a specific issue in your project, and what possibility is missing has more chance to grab attention. Yet the solution to your problem might not be implemented the way you want it exactly. (For many different reasons up to maintainers)
I'd say proposals made by maintainers (or contributors who discussed with maintainers). Proposing a large rework of the engine without fully understanding its design, and making sure it was implementable and maintainable has little chance to be accepted.
July 10, 2025 at 5:36 PM
I'd say proposals made by maintainers (or contributors who discussed with maintainers). Proposing a large rework of the engine without fully understanding its design, and making sure it was implementable and maintainable has little chance to be accepted.
Indeed. The problem is how much maintenance work they require compared to how much they bring. Small UX improvements here and there often lead to small hacks everywhere, so you gotta be careful. Unless we have contributor time/money to do things properly indeed.
It's always a value/cost balance. :)
It's always a value/cost balance. :)
July 10, 2025 at 2:39 PM
Indeed. The problem is how much maintenance work they require compared to how much they bring. Small UX improvements here and there often lead to small hacks everywhere, so you gotta be careful. Unless we have contributor time/money to do things properly indeed.
It's always a value/cost balance. :)
It's always a value/cost balance. :)
Yeah that's fair. passivestar also exposed similar arguments. TBF, I have no strong opinion on the question, whether it brings a lot of value seems debatable to me. But since someone can maintain it as it's sponsored, I'd say it's acceptable.
July 10, 2025 at 1:56 PM
Yeah that's fair. passivestar also exposed similar arguments. TBF, I have no strong opinion on the question, whether it brings a lot of value seems debatable to me. But since someone can maintain it as it's sponsored, I'd say it's acceptable.
Yet when it's a feature Unity has, people claim we hate Unity instead. 🤷 It's just not true.
July 10, 2025 at 1:37 PM
Yet when it's a feature Unity has, people claim we hate Unity instead. 🤷 It's just not true.
I mean, it's up to you to claim it's a problem or not (and defend such proposal). But saying the team didn't want the feature because it came from Unity is absurd. Many feature get a push back for the exact "problems comes first" reason.
July 10, 2025 at 1:37 PM
I mean, it's up to you to claim it's a problem or not (and defend such proposal). But saying the team didn't want the feature because it came from Unity is absurd. Many feature get a push back for the exact "problems comes first" reason.
Right. That's a pretty minimal annoyance IMO, but I guess it's a sufficient justification for adding it.
I think it was done in the end because someone paid for it, otherwise it would not have been considering how complicated this is (embedding a windows into another is complex).
I think it was done in the end because someone paid for it, otherwise it would not have been considering how complicated this is (embedding a windows into another is complex).
July 10, 2025 at 1:23 PM
Right. That's a pretty minimal annoyance IMO, but I guess it's a sufficient justification for adding it.
I think it was done in the end because someone paid for it, otherwise it would not have been considering how complicated this is (embedding a windows into another is complex).
I think it was done in the end because someone paid for it, otherwise it would not have been considering how complicated this is (embedding a windows into another is complex).
That's not what I said. I said "it wasn't solving a clear problem". This is the important part. The problem has to come first, not the solution. And when you bring in a feature without assessing how important / common is the problem it solves (if any), then you end up with bloat. To read more:
Best practices for engine contributors
Introduction: Godot has a large amount of users who have the ability to contribute because the project itself is aimed mainly at users who can code. That being said, not all of them have the same l...
docs.godotengine.org
July 10, 2025 at 1:12 PM
That's not what I said. I said "it wasn't solving a clear problem". This is the important part. The problem has to come first, not the solution. And when you bring in a feature without assessing how important / common is the problem it solves (if any), then you end up with bloat. To read more:
Yeah I mentioned that in the next posts. But that's quite a good example of people wanting a feature "just because Unity has it". I think many contributors didn't really want it, myself included, as it was not solving a clear problem.
But well, the Unity crowd was loud and someone paid for it. So 🤷
But well, the Unity crowd was loud and someone paid for it. So 🤷
July 10, 2025 at 1:02 PM
Yeah I mentioned that in the next posts. But that's quite a good example of people wanting a feature "just because Unity has it". I think many contributors didn't really want it, myself included, as it was not solving a clear problem.
But well, the Unity crowd was loud and someone paid for it. So 🤷
But well, the Unity crowd was loud and someone paid for it. So 🤷
Whether Unity did it one way or another does not matter.
July 10, 2025 at 9:25 AM
Whether Unity did it one way or another does not matter.
Every time we had discussed technical stuff with Godot contributors, Unity was rarely mentioned. From time to time it does but it's not a recurrent point of comparison. We check the problems the community often complain about, and try to find solutions, that's all.
July 10, 2025 at 9:25 AM
Every time we had discussed technical stuff with Godot contributors, Unity was rarely mentioned. From time to time it does but it's not a recurrent point of comparison. We check the problems the community often complain about, and try to find solutions, that's all.
3) I am not sure scriptable render pipelines are really a thing in Godot. The compositor API is a thing, but I guess it's quite different. (I'm not a rendering expert though)
4) Windows embedding was mainly requested by all the Unity crowd coming to Godot. It was a sponsored work so it got added.
4) Windows embedding was mainly requested by all the Unity crowd coming to Godot. It was a sponsored work so it got added.
July 10, 2025 at 9:21 AM
3) I am not sure scriptable render pipelines are really a thing in Godot. The compositor API is a thing, but I guess it's quite different. (I'm not a rendering expert though)
4) Windows embedding was mainly requested by all the Unity crowd coming to Godot. It was a sponsored work so it got added.
4) Windows embedding was mainly requested by all the Unity crowd coming to Godot. It was a sponsored work so it got added.
For your examples. 1) VCS messing with resource IDs lead us to implement UUIDs. Nobody like them but we couldn't find a better solution. 2) ECS is not a thing in Godot (though some core parts of the engine are data-oriented since the creation of the engine). It's not really inspired from Unity.
July 10, 2025 at 9:21 AM
For your examples. 1) VCS messing with resource IDs lead us to implement UUIDs. Nobody like them but we couldn't find a better solution. 2) ECS is not a thing in Godot (though some core parts of the engine are data-oriented since the creation of the engine). It's not really inspired from Unity.
Godot has a pragmatic, "problem comes first" approach to development. If you come up to a solution (like, "please do like Unity") to a non-existent (or corner case) problem, then it's not going to be implemented. If there's a real issue though, many solutions are assessed besides copying Unity.
July 10, 2025 at 9:21 AM
Godot has a pragmatic, "problem comes first" approach to development. If you come up to a solution (like, "please do like Unity") to a non-existent (or corner case) problem, then it's not going to be implemented. If there's a real issue though, many solutions are assessed besides copying Unity.
That's misleading. I don't think I ever seen a Godot contributor refuse an engineering choice because the same things was made in Unity... That being said, we indeed had to refuse some features as people kept asking them "just because Unity supports it".
July 10, 2025 at 9:21 AM
That's misleading. I don't think I ever seen a Godot contributor refuse an engineering choice because the same things was made in Unity... That being said, we indeed had to refuse some features as people kept asking them "just because Unity supports it".