The Future of Godot

XrayezXrayez Posts: 12Member
edited August 2021 in General Chat

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.


Tags :
«1

Comments

  • DaveTheCoderDaveTheCoder Posts: 666Member

    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.

  • cyberealitycybereality Posts: 3,792Moderator

    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.

  • BimbamBimbam Posts: 219Member
    edited August 2021

    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:open

  • cyberealitycybereality Posts: 3,792Moderator

    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.

  • MegalomaniakMegalomaniak Posts: 4,430Admin

    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.

  • TheMnkTheMnk Posts: 66Member

    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.

  • cyberealitycybereality Posts: 3,792Moderator

    @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.

  • harihari Posts: 38Member
    edited August 2021

    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.

  • DopplerDoppler Posts: 6Member

    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.

  • MegalomaniakMegalomaniak Posts: 4,430Admin
    edited August 2021

    @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

  • DopplerDoppler Posts: 6Member

    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.

  • XrayezXrayez Posts: 12Member

    @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").

  • MegalomaniakMegalomaniak Posts: 4,430Admin

    @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!).

  • DaveTheCoderDaveTheCoder Posts: 666Member

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

    They don't like helping people with project-related API questions.

  • XrayezXrayez Posts: 12Member
    edited September 2021

    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).

  • BimbamBimbam Posts: 219Member
    edited September 2021

    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.
  • cyberealitycybereality Posts: 3,792Moderator

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

  • DaveTheCoderDaveTheCoder Posts: 666Member
    edited September 2021

    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.

  • MegalomaniakMegalomaniak Posts: 4,430Admin

    @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.

  • XrayezXrayez Posts: 12Member

    @Bimbam said:
    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).

    It's quite interesting to see how you interpret this!

    goostengine is an umbrella organization for all extension-related repositories. I could've picked goost name, but it's already taken by some user at GitHub. :D

    Due to this, I've decided to (re)name organization to goostengine, in a way which reflects the intention of "if something should be in Godot, let it be in Godot". The idea is that, if you were to take all Goost features and git merge it into Godot, on a conceptual level it would not lead to "merge conflicts" and it would "just work", so to speak. This is to speed up the process of upstreaming features to Godot, if seen useful by Godot core developers.

    Even when you look at the source, you may mistakenly say that it's a Godot fork, but the thing is that the structure is made in a way to reflect Godot's one, for maximum workflow compatibility (again, with an intention that features could be easily ported to Godot in the future).

    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

    Yes, I strongly recommend going through Goost development philosophy and principles first, and Goost documentation in general.

    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.

    You say that you don't know whether it's a good or a bad thing. But according to previous discussion here, when people hear "fork", they get annoyed, which in most likelihood means that they see it as a bad thing. That's why I have to explicitly state that it's not a fork, and the intention is completely different. If this intention ever changes, it's going to be another project, but maintaining a fork for a project like Godot is a full-time job endeavor, so no thanks... :tongue:

    @Megalomaniak said:
    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.

    I'm distributing Godot + Goost builds, and don't call it just Goost (you can see this as a Boost C++ libraries). Unfortunately, distributing binaries by recompiling the engine is the only way C++ modules can be integrated, it's just that some people asked me to distribute Godot + Goost builds (I'd even recommend compiling your own version of Godot if you already code in C++ in your project, especially when you need other stuff like Steam/FMOD integration). I know that there's GDNative but I have found it quite complex to use, and not everything can be implemented via GDNative alone. I really hope GDExtension could change this!

    And by the way, one cannot really change the core via C++ modules. You can only patch it, but as I said, it's a great maintenance burden of having to constantly update those patches due to merge conflicts, so I only revert to this kind of approach in cases when it's simply not possible to implement a feature without applying that small patch, yet in most cases those kind of patches eventually get merged directly in Godot.

    Having said that, it boils down to intention, and it's essentially about trust: do you believe what I say? :)

  • Vale-gitVale-git Posts: 209Member
    edited September 2021

    @Xrayez said:

    If you'd like to see another version of Godot, how it should look like?

    No more features please! Stop all of them! Priority to make documentation complete .
    All of it! ( I mean we can exclude all features that are going to die - in this case they need an attribute like [Obsolete] or [GoingToDie] :))

    API included, width example for each of minimal feature. All of example divided by three levels: Beginner, Intermediate, Expert; plus best practices for everything.

    I tell you this: I don't want things that I cannot use. They make confusion and BUGS!

    What you absolutely dislike about Godot?

    You can guess: incomplete documentation + code not enough tested.

    What needs to be done in order to minimize the chance of someone making a fork (another version) of Godot?

    Free forks for everyone - not a problem at all. :) Everyone is free to do what they want with their live.:)

    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.

    Modularity is the key! But the core cannot be bound to any module.

    Would you like to see Godot be like a Linux kernel, or be an engine on par with Unity, or even Unreal Engine?

    Linux - free, open, and stable (main source like Debian).

    Do you think that Godot should be more community-driven, or less community-driven?

    Community driven is a MUST. But someone with great vision have to be in charge to give the right direction (dictated by community).

    My vision? Godot best game engine of this planet! Ready even for games "AAAA". Its not a mistake: are 4 "A"!

    (INFJ here)

  • ignatoffignatoff Posts: 1Member
    edited September 2021

    Hello, long time following the Godot, but so far what stops me from using is the awful UX of the editor and lack of onboarding for people using it for first time.

    1. I think the UI/UX should be main focus of the editor
    2. Hard to understand documentation, i mean there are many words written in each documentation page that they say nothing at all, or there is complete lack of documentation for some features and you have to guess how it works, refer to unity documentation where there is few simple sentences and code example how to use it, in godot also you started this approach but it seems like they are far less than what i described above(auto generated documentation would still be better than what is this long description in each page)
    3. 3d rendering is still bad for so long
    4. Not enough libraries from the community like unity, unreal, but lets be real they are longer ago on the market than the godot
    5. Community driven is defiantly how you screw up a project, cause you cant make everyone happy but still if you decide to use community driven approach for development use something like https://www.upvoty.com/ where you can put like 4 things you'd like to work and community votes on what they want more so you can understand where to go from there.
    6. Straight good road map with a timelines on it, like can be put in public trello
    7. Better project management

    Kind regards, Georgi

  • XrayezXrayez Posts: 12Member
    edited September 2021

    @ignatoff said:
    2. Hard to understand documentation, i mean there are many words written in each documentation page that they say nothing at all, or there is complete lack of documentation for some features and you have to guess how it works

    Yeah, oftentimes I see method descriptions which basically repeat what the interface says, like "Given X argument, returns Y." Documenting this way produces "good documentation coverage" as seen in https://godotengine.github.io/doc-status/, but if you set "to document everything" as the main goal, that's going for quantity rather than quality.

    1. Not enough libraries from the community like unity, unreal, but lets be real they are longer ago on the market than the godot

    I think this is also partly because of Godot's open source mission which does not facilitate the idea of marketplace, unlike commercial engines out there. Someone else would have to lead the commercialization part of Godot. I guess this is what already happens with console ports of Godot made by third-parties (or second-parties). :tongue:

    1. Community driven is defiantly how you screw up a project, cause you cant make everyone happy

    It's not possible to make everyone happy, therefore it's a matter of defining scope, vision, and project goals, and of course being able to manage contributors input. If there's a bottleneck in handling contributions, I'd say it's a problem of unclear project goals, priorities, and most importantly: philosophy. Attracting the entire world is definitely a bad idea if one cannot handle the community input.

  • Erich_LErich_L Posts: 591Member

    I don't understand why Godot hasn't surpassed Unity yet. Is there not a long list of things that the engine needs? Is there not a long list of contributors? What's the holdup? Yeah I know that's a blunt and possibly stupid question but I'd appreciate a blunt and simple answer.

    It seems like there's just like 4 guys guarding the code floodgate saying no to as much code as possible. Honorable men indeed... but wouldn't their time be better spent just making very clear instructions on what's needed next? (not that I know.. I don't)

  • cyberealitycybereality Posts: 3,792Moderator

    The issue is that contributors usually want to work on things they need, not necessarily things the engine needs. So you might have a ton of new features and bug fixes, but they may not be what is holding the engine back or even what would make it compete with Unity. For example, there are things that are severely broken, like the model import process, but still remain a hassle probably because the people writing the code are programmers and not artists.

  • MuktiMukti Posts: 4Member
    edited September 2021

    I LOVE Vector graphics, and I would LOVE to see it implemented in Godot !

    • Ability to import static .SVG and animated .SVG / .RIV (Rive)
    • Ability to use Vector images and Vector animations as texture for 3D objects
    • Ability to export .SVG / .RIV when exporting for web

    ...imagine 3D games with animated billboards/TV screens !
    ...or 3D game with a clock tower with the clock's hands actually moving !

  • CalinouCalinou Posts: 1,140Admin Godot Developer
    edited September 2021

    I don't understand why Godot hasn't surpassed Unity yet. Is there not a long list of things that the engine needs? Is there not a long list of contributors? What's the holdup? Yeah I know that's a blunt and possibly stupid question but I'd appreciate a blunt and simple answer.

    It seems like there's just like 4 guys guarding the code floodgate saying no to as much code as possible. Honorable men indeed... but wouldn't their time be better spent just making very clear instructions on what's needed next? (not that I know.. I don't)

    Adding new features isn't just about merging code. We have functionality and code quality standards, along with a policy that is designed to prevent feature bloat. Keeping Godot reasonably lightweight is important to us, as it's something that sets it apart from most other engines. Not everyone has recent hardware and a fast Internet connection. This is also why there's been a greater focus on allowing functionality to be moved to add-ons lately.

    Many of the currently open feature pull requests were made without a proposal to back them up. This makes it difficult to know whether the feature in question is actually desired by the community (and if so, how much). To increase the likelihood of their pull request being merged, their authors should open a proposal and try to gather community feedback on it.


    ...imagine 3D games with animated billboards/TV screens !

    This can be achieved using frame animation, or even by playing back a video with a VideoPlayer node in a Viewport and assigning the ViewportTexture to a material.

    ...or 3D game with a clock tower with the clock's hands actually moving !

    No need for vector animation. This can be achieved by rotating a mesh above the clock to act as needles for hours/minutes/seconds. The same applies to 2D :)

    Either way, this is getting off-topic, as this isn't a place to request features.

  • MuktiMukti Posts: 4Member

    @Calinou said:

    ...imagine 3D games with animated billboards/TV screens !

    This can be achieved using frame animation, or even by playing back a video with a VideoPlayer node in a Viewport and assigning the ViewportTexture to a material.

    1. Low resolution raster animation gets pixelated when zoomed in, or moving closer to it in 3D environment
    2. High resolution raster animation takes too much storage. For example, 8K raster animation for each element will make the game/application hundreds of GB.
  • OpinionatedGamerOpinionatedGamer Posts: 201Member

    I think the best thing that could be done for Godot's development would be to do what blender is doing. "Open Movies" except in Godot's case, "Open Video Games". The devs behind blender make shortfilms with blender, and that helps them figure out what needs to be added or improved to blender. Also it provides really cool showcases for blender. I think video game projects would be really cool in general, and they would probably help the Godot devs improve Godot a ton! I'm considering making a post about this.

  • zitkipzitkip Posts: 5Member
    edited November 2021

    @OpinionatedGamer said:
    I think the best thing that could be done for Godot's development would be to do what blender is doing. "Open Movies" except in Godot's case, "Open Video Games". The devs behind blender make shortfilms with blender, and that helps them figure out what needs to be added or improved to blender. Also it provides really cool showcases for blender. I think video game projects would be really cool in general, and they would probably help the Godot devs improve Godot a ton! I'm considering making a post about this.

    I think users of Godot already do that. Sincerely, if Godot continues at the pace they are doing, slower or faster, it is just fine.

    Why Godot needs to compete with Unity or Unreal?

    Csound have an open-source text book that would be very cool if Godot copy it. Unifying the community can be something good too, as jumping from Youtube, Answers Hub, Forums and some random blogs is where decentralization is pointless.

Sign In or Register to comment.