As you may know, Godot's development is extremely pragmatic, with the focus solely on solving problems. But do we all share this kind of development approach to full extent?

I'd like that we discuss the future of Godot, which is something that I feel and think is neglected due to the above. I think it's necessary that at least some forethought is considered during development, but not to the point of making the decision-making process paralyzed, of course.

Having said that, let me list some concrete questions that will make it easier to jump start this topic.

If you'd like to see another version of Godot, how it should look like? I think most people are not interested in the division of Godot community, but I do think it's necessary to see what community really wants to see from the engine in order to fulfill those needs.

What you absolutely dislike about Godot? I constantly see Godot being praised for A and B (sometimes in a cultish manner), but is there anything that you really don't like about Godot? Again, knowing is half the battle towards a bright future of Godot, but unfortunately some people prefer to be silent and prefer not to talk about the downsides publicly to avoid being shunned.

What needs to be done in order to minimize the chance of someone making a fork (another version) of Godot? If you look at Linux distros out there, you'll get what I mean. I guess it also depends on whether you see division of community as a good, bad, or neutral thing. But I think it's important that contributors stay connected and proper consensus is reached at all times regardless, so that division of community is not just a matter of bad interpersonal relationships within a development team.

If you ask me, I've seen people forking Godot for the sake of using additional C++ modules. That's why I've personally contributed a feature called "Custom modules" in the past to help this. Unfortunately, for some reason, someone from the Godot core developers said that it was a "mistake" from my part to provide such a feature, explaining that module developers can now dictate the direction of Godot's development. Nevertheless, I think that Godot's development should be focused on improving modules/plugins ecosystem, and treated as having highest priority: this is how Godot can stay lean and mean.

Would you like to see Godot be like a Linux kernel, or be an engine on par with Unity, or even Unreal Engine? I see how Godot is compared to Unity all the time, but is it really a fair comparison?

Do you think that Godot should be more community-driven, or less community-driven? I've seen people saying that if we make Godot (more) community-driven, then this will create chaos, therefore making Godot less community-driven might make engine's features and overall user experience coherent. But at the same time, making something less community-driven could definitely lead to division of community, which I'd personally like to prevent.

What is the definition of "community-driven" for you personally? I honestly think that it's not just about semantics (this is how most discussions are disregarded), I do think it's also about our inner understandings: values, beliefs, assumptions, expectations... It's not always about logic. In fact, what I've enumerated dominate over logic most of the time.

For reference, according to Godot's definition of "community-driven" (see Governance model at Godot's website), this means: "open development", "open discussion", "community-minded".

I'm primarily talking as a Godot contributor, but also as a person who used Godot for the past 4 years. I care about Godot and I hope this discussion could lead to useful insights, at the very least.

Also, I've made some statements without quoting anyone. I was previously accused for allegedly quoting core developers out of context, so please forgive me if what I say sounds like random accusations. I can provide quotes upon a request to prove my point, but I'd first need an explicit permission from forum admins/moderators. I'd just like to have an open discussion, please treat my words as someone who has subjective experience.

I'm relatively a Godot newbie, since I've only been using it for about eight months. Based on my experience so far, I have no complaints about the direction the project is going.

I wouldn't mind having a bit more access to the engine developers in regard to getting answers about using the API.

I really like the Godot interface, how Nodes work, and how lightweight the app is. It also has first-class support on Linux, something that is rare (even when engines claim support). Testing on mobile is super quick, the live edit actually works most of the time, and you can even write shaders and see results immediately. The FOSS aspect is also nice, I don't want to pay a subscription for certain features (ahem, dark mode) or have my projects synced with some cloud database without my permission. The API generally makes sense, and I can read the docs and figure most things out without additional help.

What I don't like is the art/asset pipeline. Getting 3D art into the engine is more difficult than it should be, especially if you want to iterate and change things and see the results without additional hassle. This was one thing Stingray did well, even though other than that the engine was not great. Also with Gridmaps, it seems difficult or not possible to modify tiles, meaning if you want to work with placeholder assets and then replace them later this becomes cumbersome. Not to mention the whole paradigm of inherited scenes for 3D assets is strange, and never seemed to work right in my experience. So you import a model, then create an inherited scene (for example, if you need to apply a material). But then when you reimport the asset (maybe you fixed something in Blender), now your inherited scene doesn't have the latest changes. And if you try to start over, you will have to replace any instances of that scene in your game, it sucks.

This is unfortunately what happens when programmers design workflows for artists. You really need an artist on the team testing stuff as you develop and providing feedback, or even some sort of tech artist hybrid role creating the design for the art pipeline. I might be able to help here, I studied computer art in college and have been working in 3D off-and-on for about 20 years. But I don't want to promise anything as I'm pretty busy right now (going to school for a second degree and also with some personal projects) so I'm not sure I have time to contribute to Godot.

Also, I think the developers of the engine should try to compete with Unity/Unreal. I know Juan says he doesn't think Godot is made for AAA games, and I think that is a bad direction. Right now Godot is not, admittedly, competitive with either of the big engines, but I think in a few short years it can be. Not at the expense of ease of use (as I think that is what Godot has going for it right now) but in terms of graphics fidelity and features, I think we should try. Just look at where Blender is today. I would say it is up there with Maya/3DS Max and even beats them in some ways. Yes, the project is much older, but I don't think it's unreasonable for a FOSS project to dethrone a market leader in proprietary software. It is very much possible.

I'm happy with how Godot is developed and feel the devs are already incredibly accessible through Git/Discord/Semi-Regular Youtube updates and Twitter and have a pretty clear direction.

Do I, or would I even like a senior developer to be available to me specifically for my concerns? No. I like that issues are raised, discussed generally to gain consensus and support, and if supported, acted on. All seems to make sense to me including the driving principle that the core is lightweight.

A handful of PMs having the final say on merges also makes sense to me, especially when for the most part all they do is act in the interest of the community after polls/discussions confirm consensus etc. I imagine there are cases where they have to make executive decisions and overrule something, but that's their job and I don't envy them, though I don't see this happening often.

Re. Forks, in general forks (or more specifically how people tend to use them), annoy me. I often think it relates to the 'more/less community-driven question, in that it is often the people decrying they want a more community-driven approach who cause them. In reality, they want a more 'THEIR' approach and don't like that a poll, consensus, or executive decision (either current or historical) didn't go their way. By and large, if you are the kind of person who sabotages such decisions, I'm not interested in your fork and wouldn't want to work on that project.

I think what people dislike about Godot is mostly logged here and if I felt the need to add to it I would: https://github.com/godotengine/godot/issues?q=is%3Aopen

Yeah, I really dislike forks. They just split the community and make it harder for the main project to progress (as certain contributers might defect or just leave the project due to ideological differences). In some cases, I can understand, like with Audacity or other cases of hostile management, but usually it is just not progressive for the project.

What kind of forks? Say a fork for professionals(as opposed to hobbyists) implementing things that, frankly, the upstream/base project shouldn't have such as steamworks support? I have no problem with that.

I am very happy with Godot, my only problem is that his tree of nodes in the editor, is used for that, to set up small scenes but if the user sets up a level with items, enemies etc ... the tree is a disadvantage in terms of organization, simply in my opinion the tree needs improvements to be able to organize the nodes once the scene starts to be fairly large.

@Megalomaniak said: What kind of forks? I was sort of referring to a past experience on an open-source project I started. It was going well for a bit, but there ended up being some ideological disagreements that couldn't be resolved, which ended up with the lead developer leaving and starting a fork, and then another developer ditching the project altogether. And then eventually that first developer abandoned the fork since I assume he didn't have the motivation working alone. I wish I could have managed the situation better but (at the time) I wasn't allowed to work on side-projects due to my employment and my hands were tied. But I always felt bad about it and wished we could have kept the project alive.

My biggest irritation is the way you have to set up signals manually for each instance of an object when you want the signal to be received by a parent node if not within the node tree at design time, or code it in. It would be nice if signals can be blueprinted into the class rather than the instance.

If there was a way to connect “this method in this node class will automatically be a callback for this signal” it would be awesome.

Right now this can only be done by using connect via code.

I'm a very new beginner so I can only talk about GoDot from this perspective, but I'm also an old guy from the pre internet era and I've seen and tested quite a bunch of projects from the open source scene.

If you'd like to see another version of Godot, how it should look like? It would be cool to have alternative interface approaches, a bit like Blender's forks but within the same base. So we could chose to see GoDot "full" like it is now, or optimized/simplified for dedicated uses. For instance right now a would be quite happy to have a "visual novel builder" version of GoDot.

What you absolutely dislike about Godot? So far nothing, except maybe how overwhelming it can get for beginners, and a bit how ergonomy can be tricky. That's also why I feel dedicated versions would be nice for a simpler approach at first.

What needs to be done in order to minimize the chance of someone making a fork of Godot? I don't see forks as a problem. I get the point about division bringing weakness but what I've seen along past 30 years is more about a reinforcement of projects by the multiplication of forks. It's not only about some people leaving the boat to make their own, it's also a lot about new comers adding their forces to the whole.

When I look at Linux fork's tree I'm just amazed how many projects have born from each others, and knowing what it means (like how Ubuntu have energized Debian) I mostly see the multiplicity of forks as progress for each one. The more forks there are, the more the original source can get stronger because as everything is open source, sources can use good tools developed for their forks.

But liking it or not is just an opinion, we can talk for hours about it, it wont change the fact that as soon as your project is open source there will be forks at some point or an other, that's how it works. If you don't want people to take your project and make a fork from it then don't go for open source. GoDot is open source, so the question isn't "what can we do to avoid it ?" but "how to deal with it when it will happen so our source gets better ?".

And in open source history most projects I've seen died were not destroyed by forks but by the stubbornness to see forks as competitors, and not willing to adapt. Softwares are not made to make devs happy, they are made for users. If devs forget about this real mean then users will go with some other tool as soon as there will be one giving what they are looking for. I don't see any project long lasting against users opinion. Even if there can be some influence from different kind of devs, in the end users are the one to really have the power. Again, some may not like it but that's how it works, beyond having a great idea to develop and looking for code to make it happen, devs have to integrate stuffs like ITIL.

Would you like to see Godot be like a Linux kernel, or be an engine on par with Unity, or even Unreal ? GoDot is GoDot... I don't see it able to grow as Linux because game engines are more of a niche than any OS, nor able to grow as Unity or Unreal because its economical strategy is way different. To me it sounds like "do you want your tomato to be a radiator, a banana or an apple ?" I just want it to make me able to realize what I intend, if it does because it's a tomato then I want it to be the best tomato on Earth.

Do you think that Godot should be more community-driven, or less community-driven? I'm misanthropist, so on that subject my opinion is biased... without communities there's no future, and with communities everything becomes a mess. I guess a mess is better than no future. Again, I just want my tomato salad, not an empty plate because cooks didn't want to ear suppliers, waiters etc. If at some point I'll be able to help so the salad is a bit better, I'll do, if I end up liking the place, as I'm poor and can't give much money, I'll clean the dishes if it can help. But that's not why I'm in the restaurant, I'm here because on the front door is written "free tomato salads".

What is the definition of "community-driven" for you personally? As said... a mess. But it can be a productive one with pretty good results. IMO it depends on how the community is structured, and structuring it is a job by itself, and very demanding one. Often Debian Foundation did great about it, surely would it be a good thing to observe such community driven projects to see how they have done it.

@cybereality said:

@Megalomaniak said: What kind of forks? I was sort of referring to a past experience on an open-source project I started. It was going well for a bit, but there ended up being some ideological disagreements that couldn't be resolved, which ended up with the lead developer leaving and starting a fork, and then another developer ditching the project altogether.

Yeah inter-personal politics can always get messy, but I wouldn't say that's inherently a problem of forks, rather egregious amounts of forks can be the indicative symptom of other issues to watch out for then analyze carefully.

@Doppler You might be glad to hear there are settings for hiding parts of the engines features that in combination with some purpose specific plugins should get you fairly close to a more purpose specific editor/engine.

https://godotengine.org/article/godot-32-will-allow-disabling-editor-features

Also you can always compile your own godot with some of the things such as 3D features left out altogether.

https://docs.godotengine.org/en/stable/development/compiling/optimizing_for_size.html

Thanks @Megalomaniak for these tips ! That's some really good features. I don't feel it to be "beginner friendly" (most people just want to click install and run) but it's a pretty awesome capacity anyway.

@DaveTheCoder said: I'm relatively a Godot newbie, since I've only been using it for about eight months. Based on my experience so far, I have no complaints about the direction the project is going.

I wouldn't mind having a bit more access to the engine developers in regard to getting answers about using the API.

You can use https://chat.godotengine.org/ to get more in touch with Godot contributors, or simply be a lurker. :)

@cybereality said: Also, I think the developers of the engine should try to compete with Unity/Unreal. I know Juan says he doesn't think Godot is made for AAA games, and I think that is a bad direction. Right now Godot is not, admittedly, competitive with either of the big engines, but I think in a few short years it can be.

True, but at the same time being lightweight implies being small. Engines like Unity/Unreal are definitely not!

According to recent news/discussions, Juan said that some non-essential features could be moved into extensions (GDExtension in Godot 4.0-dev), so I guess that's how they're going to make the engine both lightweight and feature-rich.

The potential problem I see with this approach is that if Godot keeps removing features out of core and push stuff into plugins (like already done with InterpolatedCamera in Godot 4.0-dev), then this kind of fragmentation in and of itself won't lead to "batteries included" experience. To resolve this, core extensions should still be treated as first-party and be properly packaged into a single bundle to retain the current user experience.

Also, whether Godot will be able to compete with Unreal largely depends on type of contributors working on Godot I think... If you look at AndreaCatania's work, you'll definitely notice a pattern.

@Bimbam said: Re. Forks, in general forks (or more specifically how people tend to use them), annoy me. I often think it relates to the 'more/less community-driven question, in that it is often the people decrying they want a more community-driven approach who cause them. In reality, they want a more 'THEIR' approach and don't like that a poll, consensus, or executive decision (either current or historical) didn't go their way. By and large, if you are the kind of person who sabotages such decisions, I'm not interested in your fork and wouldn't want to work on that project.

To clarify, one of the major reasons why I raise those questions in a "fork" manner is because this allows to reveal those inner values we all have much better.

Also, I think it's perfectly fine if someone wants to do their own way. Competition is at the root of our being as humans.

I'm personally not interested in forks either. But as a contributor with plenty of energy, and taking into account the desire to "share" the work with the community, and who tends to work with the engine itself, I've been working on project called Goost. Someone told me that they see Goost as a "Godot fork". Not at all. If you look at epigraph, you'll see "Let it be in Godot". Yet most features that you see in Goost were already rejected by Godot core developers (or implicitly labeled as having "no consensus", despite user interest).

Or when you look at projects like Godex. In this case, Juan explicitly stated in his news article that Godot is not interested in ECS (which is good, in a sense that there's a better understanding of goals).

@Doppler said: Would you like to see Godot be like a Linux kernel, or be an engine on par with Unity, or even Unreal ? GoDot is GoDot... I don't see it able to grow as Linux because game engines are more of a niche than any OS, nor able to grow as Unity or Unreal because its economical strategy is way different. To me it sounds like "do you want your tomato to be a radiator, a banana or an apple ?" I just want it to make me able to realize what I intend, if it does because it's a tomato then I want it to be the best tomato on Earth.

True, but according to responses here, this is exactly what happens... :open_mouth:

But yeah, if you see a tomato, you expect it to taste like a tomato. Again, talking about expectations!

Also, when you make a room for something, it tends to fill with things. If Juan all of the sudden says: "Godot is like Unreal", we may also expect appropriate contributions. So I don't think it's about economics at large, if someone is ambitious enough and there's enough of community interest, economic problem should resolve in an instant, so to speak.

Some people see Godot, and they see Godot. Some people see Godot, and they see Unity/Unreal (and not because of the fact, but because of vision that "Godot is not yet there", or because "Godot is not yet fully developed").

@Xrayez said:

According to recent news/discussions, Juan said that some non-essential features could be moved into extensions (GDExtension in Godot 4.0-dev), so I guess that's how they're going to make the engine both lightweight and feature-rich.

The potential problem I see with this approach is that if Godot keeps removing features out of core and push stuff into plugins (like already done with InterpolatedCamera in Godot 4.0-dev), then this kind of fragmentation in and of itself won't lead to "batteries included" experience. To resolve this, core extensions should still be treated as first-party and be properly packaged into a single bundle to retain the current user experience.

I agree, but it seems to me that GDExtensions is a solution perfectly catered to that so I don't see an issue. Especially if extensions including the bundled defaults only get included in exported games when actually used.

But also I think that third party extensions should be able to exist in a manner where they can function on an equal level to core features and in that respect the GDExtensions api getting used and tested by core contributors via default extensions is perfect IMO. Especially if/once we get an official asset/extensions store as per what the polling indicated the community wants(me included!).

I have previously proposed to enable GitHub Discussions as an alternative (a lot of questions go simply unnoticed in chats), but yeah it mostly boils down to user support (which is something that should be prioritized in a project like Godot, where problems are solved on a case-by-case, pragmatic basis).

I have to be honest, I haven't visited Godot forums all this time, I mostly used to hang out at GitHub. I know some people dislike GitHub, but you have to make compromises sometimes, or try to solve a problem yourself (I rarely ask for help myself... Perhaps I should do this more often).

To clarify, plugins/extensions are in my mind 'Godothonic' (idk, that made sense in my head) and serve to keep the engine lightweight by being a bolt-on. Forks, technically, fall into this category depending on their intent and without Forks we wouldn't have many of the extensions available that require more extensive changes to core code (like navigation-lite). That said, these extensions do not tend to be a whole slue of extensions bundled together a la goost, which I admit I have only briefly looked at, so apologies if I'm jumping to conclusions, but it strikes me more like a competing/complementing project (I mean it's called 'goostengine') with a different core direction (i.e Godot core is too lightweight). Saying it's not a fork is like saying WINE is not an emulator. Even if it is not technically by definition, the majority of people using it won't/don't care or know the difference, because it serves the same purpose. Whether this is a good or bad thing is yet to be seen, I don't know the historical/political reasons for the 'not a fork' and was only basing my reply on situations I have seen first hand.

While musing on your reply though, I do think Godot could benefit from an updated project loader that prompts the user at project creation to select the components they want to enable which may download them additionally if required, similar to how things like the OSGeo installer works, something like:

Godot Core Ticked and greyed out, this is basically what Godot master branch is and therefore does not need to change it's current direction or behaviours

Godot Curated Essentials Plugins/Extensions that have undergone some element of peer review/general acceptance of being useful This includes extensions that require a rebuild, so can only be enabled here at project inception.

Godot Community Extensions The rest of the plugin store, which is also still available within the editor at any time

This ensures: Godot Core continues as is and if anything can become more lightweight New and existing users can clearly see and decide what is and isn't available right from the start * Solves the 'the extension I want isn't in core' debate.

Yeah, I think the extensions are a good idea and allow people to add custom stuff without requiring core source code changes or forks.

There could be some prepackaged downloads that include popular extensions along with the core. It would be more work for the packager(s), but that should keep almost everyone happy.

@Bimbam said: That said, these extensions do not tend to be a whole slue of extensions bundled together a la goost, which I admit I have only briefly looked at, so apologies if I'm jumping to conclusions, but it strikes me more like a competing/complementing project (I mean it's called 'goostengine') with a different core direction (i.e Godot core is too lightweight). Saying it's not a fork is like saying WINE is not an emulator. Even if it is not technically by definition, the majority of people using it won't/don't care or know the difference, because it serves the same purpose. Whether this is a good or bad thing is yet to be seen, I don't know the historical/political reasons for the 'not a fork' and was only basing my reply on situations I have seen first hand.

Well, goost seems to me like a redistribution of godot including some extra things, but not really substantially changing the core of whats already there. Feel free to correct me if I'm wrong on that. To me a 'Fork' can be that but what most people think of when using the term fork is probably something more significantly divergent.