FreeGameDev

fluffrabbit mentioned that he couldn't easily upgrade an old Godot project. What is compatibility like in Godot? Are projects usually broken on upgrade? Are they easy to fix?

I don't have first hand experience, but it seems like the step from v2.x to v3.x was quite major.

I wish this was an experience that was isolated to Godot, but it seems like a system wide free software ecosystem problem.

Deleted.

Jastiv {l Wrote}:I wish this was an experience that was isolated to Godot, but it seems like a system wide free software ecosystem problem.

Hardly unique to free software though.

From my experience of using Godot for a week, it looks like that the graphics quality is decent and you can make games with fixed levels with very few code (compared to using engines designed for C++ since you don't need to reinventing most of the wheel, e.g. data serializing).

However it seems that it's completely a mess if you want to make a game with built-in level editor. A lot of internal details can only be accessed with C++ but not GDScript, for example:

* You can't inherit Mesh of PrimitiveMesh in GDScript in order to create new type of procedural meshes; the corresponding C++ class have pure virtual member functions, and have some private/protected helper functions vital in logic but not exposed to GDScript. The only way is to inherit ArrayMesh, but ArrayMesh will store the generated vertices to file, which defeats the purpose of procedurally generated meshes.

* It's a mess to write a custom property editor, even for a simple POD type (usually represented by a Dictionary in GDScript). The C++ code already defined a bunch of property editor control for each built-in types, but their usage is restricted: they can only be setup to edit a given property of a given object, but in order to tell it which property need to be edited for which object, a function need to be called which is only available to C++ but not GDScript. This means you can't reuse any of them. Also, there is a function in a control to set a custom color for label, but again, this function is only available to C++.

... and there are some fundamental flaws in the implementation of GDScript: https://github.com/godotengine/godot/issues/21461 https://github.com/godotengine/godot/issues/25252

Jastiv {l Wrote}:I wish this was an experience that was isolated to Godot, but it seems like a system wide free software ecosystem problem.

And free software should be immune to it, or very nearly so.

Instead, people try to make it more like proprietary software. Debian has endless excuses why they don't want to enable other maintainers to create stability-- it's a pattern: KDE vs. Trinity, GNOME vs. Mate, Python vs. Python 2 (I believe PyPy is still available) Systemd vs ANYTHING else. Freedom > choice, but freedom tends to lead to choice as well. If you're being dragged from one thing to the next, it's because people are willing to try to drag you there. People WORK HARD to provide choice, and Debian (among other "vendors" or projects) treats those people like bums on the street. But they're the farthest from bums, they're heroes.

I think Jastiv was talking about the upgrade path from Godot v2 to v3 (and soon to a lesser extend v4).

Looking at propriatory legacy systems that due to commercial demand maintain (usually broken) backwards compatibility over decades, I am actually happy that this usually isn't the case for Free Software projects.

I also prefer that developers spend their time to improve the actual software, rather that trying to work around edge case backward compatibility bugs.

Yeah, but how the heck are you supposed to learn how to upgrade the software to a new version? There aren't exactly straightforward guides around.

Julius {l Wrote}:Looking at propriatory legacy systems that due to commercial demand maintain (usually broken) backwards compatibility over decades, I am actually happy that this usually isn't the case for Free Software projects.

I also prefer that developers spend their time to improve the actual software, rather that trying to work around edge case backward compatibility bugs.

There are good and bad ways to do upgrades. If you are going to break compatibility, you should have a guide on how to handle the change. Compatibility breaks should have a clear advantage not simply because you decided to change something. Breaks should crash hard or not compile so it is easier to find and fix.

SDL is a good example of this. The previous API didn't match how hardware had changed. They needed to change the API to get good performance. They have a guide to help developers transition.

SFML is a bad example. Between 1 and 2 they changed the camelcase used for function names because he didn't like that style anymore. Everyone had to update their code for no reason.

Love is another bad example. When switching to 11.0, they changed color values from 0..255 to 0..1. Your program would run on love 11.0 but most colors suddenly became white. If they had simply renamed the function, everyone would have easily know what needed to change (or even output an error message when greater than 1).

Personally I'd prefer to keep backward compatibility for a time. Usually the cost is not high. For example Love could have easily added a new set color function and have the old call it. In the case of SDL, I understand that and the distributions generally have both 1 and 2.

Julius {l Wrote}:Looking at propriatory legacy systems that due to commercial demand maintain (usually broken) backwards compatibility over decades, I am actually happy that this usually isn't the case for Free Software projects.

This really avoids the points I made-- which is your right-- but it uses what I consider a false generalisation to try to pooh-pooh the relevance of arguably widespread problems.

I realise the problem is even worse in proprietary software. That doesn't necessary mean the demand that is artificially deemed unimportant goes away when the demand isn't commercial. On the contrary-- you're saying it's the demand that is more like the proprietary legacy systems. And I'm saying it's the response to the demand that is more like it. Sure, some backwards compatibility is maintained for ages. But the KEY features that people are dragged through via lock-in-- that behaviour gets emulated in the free software world (especially by the open source dark side.) I've spent years writing about that, and the Halloween documents talk about it as well. So for the sake of a simpler thread I'm willing to let that go, but only under protest.