Has Godot Reached The Event Horizon?

duane

By which I mean, has it become impractical to maintain the project?

I posted a crash bug three days ago, and there's already a fix in place for it. That's excellent, but only the crash was fixed -- scaling Tilemaps under 0.5x still doesn't work, and needless to say crashes get a lot more attention than most problems.

In the last week, 109 issues were opened. Fifteen involved crashes. Almost three quarters are still open, which means they probably aren't duplicates or obvious wastes of time. That seems amazing to me, even for a large project. Firefox's bug tracking isn't nearly as open, but they don't seem to be getting as many issues.

Godot is arguably more complex than something like firefox, which always struck me as a juggernaut. Most of the people that use firefox aren't trying to get it to do weird things that its creators never considered (since most people aren't web developers).

Now, before anyone starts to vilify the project leadership, let me remind us all that this is free software. No one has a right to expect any kind of performance from free software or the people maintaining it. (No, not even if you donated.) It's free as in freedom, so if you have a problem with it, you're free to fix it or to start your own project that works.

I'm more concerned that it may be flatly impossible to get godot back into shape with all the features that have been (at least tentatively) added, all the operating systems it claims to support, and the general level of complexity of game design. There are a lot of part time developers and a handful of full-time workers who still can't devote every hour of the day to the project.

And, though I've been a professional programmer, none of the work I did compared to some of the issues I've been browsing on godot's github.

What do you think?

Tomcat

duane I'm more concerned that it may be flatly impossible to get godot back into shape with all the features that have been (at least tentatively) added, all the operating systems it claims to support, and the general level of complexity of game design.

I believe that Godot is now at the turn of development. Such crises accompany any business. Whether the team will be able to cope with it is the question. It depends on many factors, including the users (i.e. us). If the project fails, the local loser troll will be very happy, but no one else will feel good about it.

Megalomaniak

duane I'm more concerned that it may be flatly impossible to get godot back into shape with all the features that have been (at least tentatively) added, all the operating systems it claims to support, and the general level of complexity of game design. There are a lot of part time developers and a handful of full-time workers who still can't devote every hour of the day to the project.

Of course it's not impossible, but it would likely take a good long while.

What's probably really needed is there to be a certain cutoff date or point where main focus should go to maintenance and bug fixing only. Essentially a moratorium on the smexy stuff i.e. new features. I mean new features only in the major release and only a few. Then follow it up with stability fixing period(crashes, freezes etc.), and finally bug fixing(misbehavior, things not working as intended) and general polishing based on user feedback. Then a new major version can be tackled.

This should finally get the project to the point where it would make more sense to release early, release often.

Which ultimately might lead to a point where versioning scheme might make sense to be change to Year.Month.Patch format and perhaps a LTS release every 3 to 5 years or so.

But this all will have to likely happen starting from or after version 5 of the engine. Since it would likely also require that no substantial full stack refactoring needs to occur any longer. Hopefully whatever major systems design and refactoring is still needed can happen during the 4.x cycle.

synthnostate

duane By which I mean, has it become impractical to maintain the project?

Yeah, more or less.

First mistake: building and maintaining a general-purpose game engine, but that's a given.

Second mistake: C++. I made own little 3D engine in C++, doing my best to avoid the pitfalls and bad parts, but I still encountered too much friction and ultimately rebuilt it in C with much better results. One time I suggested C to Juan and he made a dismissive reply like "C++ ain't pretty but it's designed to solve problems". It's a sunk cost.

Firefox, Chromium, Unreal, Unity, Godot - all coded in C++, all slow and buggy.

Blender - coded in C, fast and relatively reliable. Not perfect, but for an application of similar scale and complexity, it's in a league of its own. Some other big old examples are the Linux kernel+core, X11, Git, and possibly Windows kernel+core.

Third mistake: not using a third-party physics library. I've done it too, but that this point it's clearly an error, especially in 3D.

It sounds like Godot may correct that last mistake, but can you imagine a Godot 5.x in 5 years coded in C and NOT trying to be all things to all people including consoles and mobile? I can't. Someone else will do it though.

duane

Anyone who's interested might also read this proposal, discussed in another thread.

fire7side

I'd say they are managing a major rewrite like they did pretty well, but it may be a long time before we can use the word stable in a meaningful way for version 4. It's a very ambitious project, that's for sure. But, yeah, the platforms they are supporting is pretty amazing. I'm sure they are using a lot of other free software, also, for running on other platforms. There are quite a few games being produced on it already. When you look at the size of it, it seems like it's probably possible. Unreal and Unity are monstrosities. I think doing their own physics engine was overly ambitious. There are too many good ones, open source, around they can use.

Tomcat

And, of course, the engine is quite young and childish diseases haunt it. And they can be quite serious.

samuraidan

if I remember rightly they started making their own physics engine because even the best one they could find that they used to use (bullet, I think it was called?) still didn't really fit their needs. same reason they went with GDscript instead of python or lua, neither of those were quite right for them so they made their own new one.

I wonder if the project attracts so many DIY minded people because that's what most of the project leads are.

fire7side

samuraidan Bullet is really stable and it's been around for ages. I've heard a lot of complaints about Godot physics. Lua would be a lot faster than GDscript. You know what it's like getting around programmers. They know what's wrong with everything and how to do it better. I'm not really complaining because it basically works, but they could focus on other things if their scripting language and physics engine were bulletproof, no pun intended. I don't know what Unity uses, but their physics engine walks all over Godot. GDscript is fairly nice, but it's definitely not going to win any speed contests.

Kojack

fire7side I don't know what Unity uses, but their physics engine walks all over Godot.

If you are using regular (non DOTS) Unity, it uses PhysX for 3D and Box2D for 2D.
Unreal engine 3 and 4 also used PhysX, but UE 5 replaced it with their own Chaos Physics.

duane

fire7side Lua would be a lot faster than GDscript.

This is certainly true. Even with the improvements in gdscript2, I can do the same processes in luajit in one third of the time as gdscript. However, my favorite feature of lua is its tables, and I've been banging my head against several routines that practically begged to use lots of tables. Then I realized that the garbage collector was choking on them. So I tried to cut way back, which made the programming process painful, and the resulting code ugly.

I think I'm starting to get a real feeling of why the godot developers got sick of that garbage collector. I can imagine the result if every godot object (vectors, rectangles, etc.) had to be garbage collected like that.

AnidemDex

Isn't the same that happened when they released Godot 3? It was not fully usable until godot 3.2 or 3.3 I think?

Megalomaniak

AnidemDex No, godot 3 was not as substantial refactor as godot 4 was. So not the same. But that's a difference of degrees or scale. Not difference in kind.

fire7side

duane I might mess around with the lua-godot plugin or whatever it is, but I don't have the time to learn it right now. It doesn't sound like it's really stable.
"WIP (heavily updated so you can expect constants changes - no commitment with feature freezing at this moment)"

synthnostate

duane This is certainly true. Even with the improvements in gdscript2, I can do the same processes in luajit in one third of the time as gdscript. However, my favorite feature of lua is its tables, and I've been banging my head against several routines that practically begged to use lots of tables. Then I realized that the garbage collector was choking on them. So I tried to cut way back, which made the programming process painful, and the resulting code ugly.

I've tried Lua a few times; it's fast but it's such an ugly and oversimplified language. I initially used it in the C rewrite of my engine, then I remembered there's a wildly popular language with almost all the benefits of Lua. Javascript! There are at least two embeddable JS engines with no-bull licenses: MuJS and QuickJS.

GDScript has the advantage of multithreading support, however. None of the other scripting languages I've considered do: Python, Lua, Javascript, HaXe. With Godot's popularity it could catch up with those languages (excluding Python) in performance. The devs have made solid decisions in GDScript 2.0 in that regard (favoring static typing and such). I could see myself using GDScript in my engine or another if it's spun off as an independent library. Tim Sweeney has said he likes it, he's contributing money to its development, and we may actually see it in UE6.

duane

fire7side heavily updated so you can expect constants changes

Sounds familiar. 🙂

DaveTheCoder I'm satisfied with GDScript.

It's got a lot of room for improvement. For instance, I wanted an iterator over a rectangle to save having a double loop in dozens of places. Here's the gdscript version. (And keep in mind that all the functions in inline classes end up clogging up your function list in the godot ide.)

class BoundIter:
	# This is slower than a pair of simple loops by ~300%,
	#  but it's neater. The speed shouldn't be a major issue
	#  in the dungeon generation, which is fairly fast anyway.

	var rect:Rect2i
	var perim:bool
	var v:Vector2i

	func _init(r:Rect2i):
		rect = r

	func should_continue():
		return (v.y < rect.end.y and v.x < rect.end.x)

	func _iter_init(_arg):
		v = rect.position
		return should_continue()

	func _iter_next(_arg):
		v.x += 1

		if v.x >= rect.end.x:
			v.x = rect.position.x
			v.y += 1
		return should_continue()

	func _iter_get(_arg):
		return v

Here's the lua version.

function _M:iter()
	local x, y = self.x1 - 1, self.y1

	return function()
		x = x + 1
		if x > self.x2 then
			x = self.x1
			y = y + 1
		end

		if y > self.y2 then return end

		return x, y
	end
end

DaveTheCoder

I'm satisfied with GDScript. It lets me do what I need.

DaveTheCoder

duane It's got a lot of room for improvement.

That's true. But the improvements aren't going to happen without lobbying for them in proposals, or implementing them in Pull Requests. I'd rather spend my time using what we have now to make projects.

fire7side

DaveTheCoder I I just play turn based rpg's and puzzle games. GDscript is more than capable.

duane

synthnostate can you imagine a Godot 5.x in 5 years coded in C and NOT trying to be all things to all people including consoles and mobile?

That's the problem. Everyone wants something different. If I couldn't do html and mobile, I'd move on to different software. 😕

Megalomaniak

synthnostate One time I suggested C to Juan and he made a dismissive reply like "C++ ain't pretty but it's designed to solve problems". It's a sunk cost.

I see no lie there. Of course features of C++ were added for a reason. But just because a feature is there doesn't mean it's right for your project. This is why collaborative projects need style guides and enforcement of them. Plenty of patches/pull requests that won't get accepted because the code is a mess to maintain(even if on it's own it's well written, internally consistent and fine) because in the context of the wider code-base it just doesn't adhere to style guide and would be alien to anybody but the author. So ultimately unmaintainable technical debt.

Blender - coded in C, fast and relatively reliable.

Blenders codebase is a mix of languages(including the rather esoteric D IIRC) and C++ portion is increasing/trending upwards.

synthnostate Third mistake: not using a third-party physics library.

As with anything there's pros and cons to this. Positive: Don't have to maintain your own code for this(i.e. don't need to reinvent the wheel) Cons: Should the upstream stop maintaining it you are screwed. Plus unless you wrote the engine from scratch around the physics engine you've picked you'll probably have lots of odd bugs(see godox 3.x and bullet) or just straight up some of your engines features might not be able to integrate with or benefit from physics.