Godot Engine's vision and development philosophy should be better formalized or easily accessible

[Xrayez]

Keywords: ideology, philosophy, vision, mission, end goal, goals, non-goals, principles, purpose, direction, intention.

Describe the project you are working on

Goost - Godot Engine Extension. See my own philosophy at the Goost documentation. It's quite short, but it uses a language suitable to express these kind of things, not necessarily those which stem from pure logical reasoning, but also take into account human relationships/experience, and emotional states (something which Godot prefers not to talk about, the way I see it, despite welcoming various minorities).

It also uses estimations, because some things cannot be measured, but nonetheless, make it easier for everyone interested in contributing to make good judgements about the project, and most importantly, attempts to save the time it would take both the maintainers and potential contributors going into conflicts in the first place by giving alternatives.

Basically, anything which describes values, assumptions, beliefs, expectations etc. That said, most decisions are not governed by logic, despite what logic may say about this.

---

Update 2021: I got excluded from Godot Engine organization as a member for trying to clarify something that I was not even aware of as a contributor, see for instance godotengine/godot-docs#4799, or allegedly trying to quote core members to prove my point against them for the sake of it (which is not the case, all I'm doing is seeking truth/consensus via means of discussion), and I feel like any new willing and capable contributor may fall victim to this kind of circumstances at some point in time eventually.

It's not possible to reach consensus if this kind of ostracism, cancel culture, is used to manage members within Godot organization. The usage of the button is the demonstration of power, unfortunately.

I used to be a regular Godot Engine contributor, and even a member in this organization, because I've been implementing feature proposals as requested by other users, creating and maintaining custom modules and unit tests infrastructure in Godot, contributing features and enhancements I was personally interested in as well, but with various success rates.

Describe the problem or limitation you are having in your project

I recall my enthusiasm back in the days: godotengine/godot#30816 (comment)...

I'm looking forward to using godot-proposals for that matter. 😃

When making feature or enhancement proposals to GIP, I often feel paralyzed by indecision which comes from lack of understanding of existing development ideology/philosophy/intention as seen by Godot members and seasoned core contributors, and a possible fear of rejection.

When I first started making feature proposals in the form of pull requests years ago, my features were not met with much enthusiasm. Having acquired more experience as both a contributor and even a software developer, I have to admit that some of them seem silly by now such as godotengine/godot#19276.

But as I got my hands dirty, I started to contribute features which seem to meet both my own needs and the needs of others, such as godotengine/godot#28013. I then learnt that no amount of "thumbs up" can guarantee that the features get merged, but at least the good feeling you get from that seems to cover up the feeling of rejection, to some extent.

From what I've observed, it seems to me that a lot of people don't seem to get the ideology behind Godot development, or in fact it may have changed recently or rapidly evolving over those years, and I'm not sure how the work is really prioritized and what features are made into the engine. For some time I feel like the dedicated 2D engine is being neglected, and that's actually the reason why I've chosen the engine in the first place.

People coming from previous experience with Unity/UE4/etc. seem to request similar features to be available in Godot too, which may not be actually in alignment with Godot's intended core philosophy. Talking about not meeting expectations, which can lead to disappointment, for no good reason.

I see no formal document which could formalize the development ideology/philosophy behind Godot. We have documentation on how to contribute (talk first, make sure that the feature is needed etc). In general, those pages describe the "what" and "how", but not the "why". Start With Why.

There's even Godot's design philosophy but it doesn't really target the engine developers/contributors themselves with the purpose of giving a good direction towards how the engine should be like, and has only introductory/selling point value for those considering trying out the engine for the first time, not necessarily developing features.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Write an official documentation page or document which fully describes the development philosophy behind Godot Engine which would be mainly targeted at those wanting to make sure that their own development philosophy is in alignment with Godot Engine's one before considering contributing.

The most important questions which I'd like to be answered personally are:

1. Are we aiming for something like what other commercial engines provide, or is Godot becoming a Linux kernel but in the game development field instead (despite having a dedicated editor)? That's important because that signifies that a lot of current proposals should actually be targeted for module/plugin/addon development instead (hence the need for Godot Ideas repository: Link Godot Ideas repository as an alternative for GIP #1476). If that's the case (and it seems like the case, according to some classes already being removed from core in Godot 4.0, such as InterpolatedCamera Mark InterpolatedCamera as deprecated godot#42113), this leads to the next question of whether Godot would be willing maintaining those features via plugins officially. If Godot's development is considered highly organic but aims to prevent bloat at the same time, then Godot should define things like Feature Removal Policy.

2. If Godot can be seen as an open-source game development kernel, does it plan to provide a standard library distributed alongside Godot? Inspired by C++ STL, I'd personally see this being as Godot Standard Library (GSL), which would be written as GDScript, GDNative plugins and packages, and even C++ modules, such as the one I'm currently working on: Goost.

3. If Godot aims to further remove features from the engine to prevent bloat, would those features be actually maintained by the core developers? That would be actually the most important question to answer, because if those features won't be maintained on the same level as Godot core, the maintenance burden will lie on the shoulders of other (non-core) community members, and the amount of donations Godot currently receives would become quite disproportionate.

If the purpose and the intention is not clear, we'll keep accumulating feature and enhancements proposals which go against existing development ideology, making it more difficult to actually focus on those proposals which could benefit the engine in its current state.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams

1. Have a document which formalizes Godot Engine's development ideology to great extent: Godot Engine's vision and development philosophy should be better formalized or easily accessible #575 (comment).
2. Link this document at GIP, so people can have a chance to re-evaluate their proposals and whether they actually fit the ideology.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I think that Contributing and Godot's design philosophy pages might give some answers to this on some level, but I honestly feel like there should be a dedicated document which just translates what seems to be hidden gems inside the minds of geniuses in the form of text. I know it may be difficult to describe a particular way of thinking, but please consider this option. If the vision is not yet complete, lets call the document "The Future of Godot", because we all need to share the same vision to make the development process as smooth as possible for everyone involved: #1333.

Is there a reason why this should be core and not an add-on in the asset library?

Making a document like this can help people realize that most of their feature and enhancements proposals can (or rather should) be implemented via modules, plugins, addons (it may not be the case now, but I hope that this can become a reality in the future). Having a clear set of criteria regarding core development philosophy can help people accept the way the engine chooses what features are essential to realize its vision (which may or may not be in alignment with each individual's vision), and save the time it takes to implement them for core.

It shouldn't be all about attracting contributors from all around the world and taking advantage of the work they do for free, it's about defining Godot's core values and giving correct expectations to people. This way, the Godot project will respect people's own values and expectations. Otherwise, I'm afraid that existing approach may backfire against Godot as a project, leading to division of community caused by conflict of interest rather than mutual understanding that not every problem can be solved by Godot Engine.

[clayjohn]

Would this be solved by http://docs.godotengine.org/en/latest/community/contributing/best_practices_for_engine_contributors.html and #466?

[Xrayez]

@clayjohn I linked to an entire "Contributing" section, and that includes the documentation page you linked. But to comment specifically on this, the page describes a somewhat modified approach towards software engineering principles in general tailored for Godot's established practices. Quote from there:

While some may find it useful to extend this to general software development, our intention is to just restrict to situations that are most common in our project.

Why and how they were established is what interests me too, which is missing, and deserves a separate page IMHO.

#466 assumes previous knowledge and experience regarding core development process for those evaluating them. Also this:

The above considerations are all balanced, no one is more important than another.
Core developers have discretion to weigh the factors as they see fit.

What defines the "discretion" is basically the ideology of Godot development IMO, which is not defined and only live in the minds of people at #godotengine-devel.

What I ask is more like:

• How Godot's way of thinking differs from other engines.
• What makes Godot unique.

Keywords: ideology, philosophy, vision, end goal, mission.

Basically every justification which @reduz uses while discussing (or even closing) feature proposals and pull requests which doesn't match the vision, that's the motivation of this proposal. I realize that you cannot teach all people, but to cover those ideas is essential to reaching common understanding in general.

The closest implementation of this proposal is Godot’s design philosophy page, but as I said:

it doesn't really target the engine developers/contributors themselves, and has only introductory/selling point value for those considering trying out the engine for the first time, not necessarily developing features.

And it wasn't actually written by @reduz who knows the best, IMO and AFAIK. 🙂

[Xrayez]

Actually the Godot Roadmap could contain such a page at the very least, to give a vision towards what Godot should be like in general, like DESIGN_PHILOSOPHY.md. But again, it has to be fairly accessible to most users, the entire repository seems to be mostly abandoned (in favor of GIP I suppose).

[clayjohn]

I understand. I think this could be accomplished with a paragraph at the top of the "best practices" doc. I think what will really make things click for you is a more solid introduction to the best practices about why they are the way they are. The best practices guide was created to be the thing we can point to when closing PRs (e.g. "see best practice #X for further explanation"). I don't think we should be justifying closing PRs by pointing to general ideologies. However, I think some explanation of philosophy would be very useful for more power-users such as yourself who are asking "what should I work on next" and "how can I help the project progress to its next milestone".

I'm not sure that a full fledged Philosophy doc is a good idea. I'm concerned that throwing around language like philosophy and ideology will lead to divisiveness.

[Zireael07]

I think the word ideology could indeed be constructed as divisive, but philosophy, especially in terms such as "design philosophy" and "core philosophy" is fine.

[Xrayez]

To clarify, it's not that I don't understand the current philosophy myself, I've gone through all possible processes of engine development to figure this out on my own by now. There are still questions which remain unanswered but they are negligible in comparison. I'm mostly worried about people who would have to go through a similar (possibly painful) process.

I don't think we should be justifying closing PRs by pointing to general ideologies

This holds true and you don't have to do that. But when someone rejects a big pull request, such a person is forced to reveal the philosophy behind the project to some extent anyway, in order to justify such a decision.

So, that's the whole point of this proposal. If people get familiar with project's philosophy beforehand, there's no need to close PRs, because people won't make them in the first place, and maintainers don't have to reject them either. Kinda silly but simple enough solution.

I'm not sure that a full fledged Philosophy doc is a good idea. I'm concerned that throwing around language like philosophy and ideology will lead to divisiveness.

IMO, there's always a division. Take all closed PRs and compare them to merged ones, we'd get two different engines. And the key link which makes this distinction is the philosophy. Lets just ditch the ideology term if it has some bad connotation, but the idea (no pun intended!) remains the same. There's nothing wrong with the division, there's a reason why there are so many game engines, linux distros etc, because they all tend to solve different set of problems. Even human cells divide. 🙂

I realize this is a sensitive topic but that's also a fundamental one. I'm not sure about the solution either. This mostly boils down to specific human interactions which lead to human decision making which is not deterministic in nature. 🙂

Since we're talking about philosophy, here's the quote from Tao:

The Tao that can be told is not the eternal Tao;
The name that can be named is not the eternal name.
The nameless is the beginning of heaven and earth.
The named is the mother of ten thousand things.

So what I'm asking might not be actually possible to do, because written knowledge becomes "ideologic" in nature, and the mission tends to change over time. But I'll be satisfied if someone could provide at least the surface of Godot Engine's vision/mission. If this mission is in alignment with the person's own vision, we get a big resonance in terms of mutual understanding, which naturally leads to better development process, and even better human relationships.

I've used ideology term because that's what @reduz seems to prefer, but I understand how it's difficult to describe something in a foreign language.

[Xrayez]

Here's some articles/abstracts from Project Management Institute so as to support my claims/requests:

• Lindborg, H. J. (2000). Project vision. PM Network, 14(3), 41–45.

A vision is a picture that links a project with personal and corporate energy and values. Project teams with a clear and compelling vision not only perform better, but yield a high return on corporate and personal investment. Successful visioning requires commitment to service.

• Haddad, R. S. (2013). Are your projects supporting your vision statement? prove it!: Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.

[Xrayez]

@clayjohn

I'm not sure that a full fledged Philosophy doc is a good idea.

• Unix philosophy, see related links.

To be more objective, we kinda have conflicting philosophies there if we take Godot Best Practices and the Basics of the Unix Philosophy:

Godot

• The problem has to exist.

Believing that problems may arise in the future and that the software needs to be ready to solve them by the time they appear is called “Future proofing” and its characterized by lines of thought such as:

I think it would be useful for users to…
I think users will eventually need to…

This is generally considered a bad habit, because trying to solve problems that don’t actually exist in the present will very often lead to code that will be written but never used, or to code that is considerably more complex to use and maintain than it needs to be.

Unix

• Rule of Extensibility: Design for the future, because it will be here sooner than you think:

If it is unwise to trust other people's claims for “one true way”, it's even more foolish to believe them about your own designs. Never assume you have the final answer. Therefore, leave room for your data formats and code to grow; otherwise, you will often find that you are locked into unwise early choices because you cannot change them while maintaining backward compatibility.

---

So that's another motivation of this proposal. I don't quite get why it's so different. Again, while Godot Best Practices seem to cover some of the development philosophies, yet the main purpose seem to be, as you noted @clayjohn:

was created to be the thing we can point to when closing PRs

Even if that's not the case, it gives that impression, so I'm for clarity. 🙂

[Xrayez]

I've stumbled upon SCons Principles user guide page (the tool used to build Godot). This is kind of a thing which the Godot documentation could have. Look at their 3 principles:

• Correctness
• Performance
• Convenience

While I think Godot follows Correctness principle, it:

• does not implement Convenience principle to full extent (look at "there's no need to implement this in core, this can be implemented in a one-liner/script/plugin" etc. throughout GIP). Instead, Single-responsibility principle is preferred even if it hurts the user experience, or allegedly promotes bad programming patterns, which might or might not be the case for some developers IMO. Note that I'm not talking about Usability/usefulness of the engine, it's certainly useful and can handle most of the things. But when it comes to availability, this is where you'd have to make additional effort, making it inconvenient. Again, nothing wrong with this approach, but this should be made clear that not everything is available out-of-the-box and people should not expect their requested/proposed features to be built-in.

• does not prefer Performance, but rather readability and easier debugging. Correct me on this if that's not the case. Using the slowest data structure almost every time. godot#23998:

See reduz response while closing the proposal (which is ok but to demonstrate the typical behavior which has to be done everytime, with different wordings):

Again, I really appreciate that you have good intentions, but you don't understand any of the inner workings of the engine, or the philosophy [emphasis mine] behind it. Most of your comments are towards things you don't really understand how they are used, how critical they are to performance, or what their priorities are in general.

Again, there's nothing wrong with those approaches, but it's reasonable to make them obvious to developers considering contributing, and to minimize the chances of such collisions in ways of thinking, ideologies, because that's what they are.

Google gives me this definition for ideology word:

the science of ideas; the study of their origin and nature

If the origin/history is also important to understand the philosophy behind this, that's also good to include.

[Xrayez]

Some philosophy discussion has happened starting from #639 (comment). In there I learnt that there's a thing called "do-ocracy", see the entire twitter discussion as described by the lead developer and the project manager.

Quote from #639 (comment):

From what I remember, we called the Godot development a "do-ocracy", where the ones who contributed to the engine decide. Thus having the support of users only is definitely not enough.
So well, if your question is whether or not Godot is managed as a democracy, the answer is: it's not. :)

Now it just takes some adaptation/copy-pasting to make this an official statement in docs.

But if we take the "The problem always comes first" from the "Best practices for engine contributors":

Many contributors are extremely creative and just enjoy the process of designing abstract data structures, creating nice user interfaces,or simply love programming. Whatever the case may be, they come up with cool ideas, which may not be actually solving any actual problems.

Isn't that the thing which the lead developer constantly does with Godot? I respect the privilege of creators adding new features (which may not actually solve my own problems, whether I talk about them or not), but does it basically suggests that every new feature is not welcomed by new contributors? My logic is that: if there's no feature, then there's no problem in the first place. To me it's more like a cycle:

But with the current diagram:

It simply suggests that: "let me create problems, and you just solve them". 😛

I mean, I might be definitely wrong, but that's my interpretation.

In other words, how am I supposed to be a "doer" if the creative part of software development is a privilege of those already having a place in the project? (most of the time simply because they were first to contribute). Over the years I've seen how other contributors has "climbed up the ledges" by testing, fixing existing bugs, and writing documentation, dedicating a large amount of free time and resources just to gain some recognition before even considering proposing new major features to be implemented. Is that the recommended path?

As a creator, should I just focus my energy on creating something new instead (not necessarily the engine itself)? That's where I think my conflicts arise in this regard perhaps. If you look at my PR history, you'll mostly see enhancement/feature-proposal labels being assigned starting from day 1 (when I do fix bugs, that's mostly because I've personally stumbled upon them in my own project).

I definitely lack the understanding behind FOSS to full extent, but Godot is the only FOSS project I've been working on so far so excuse my ignorance. And I fear I have Godotitis by now, thanks for that. 😄

[clayjohn]

Over the years I've seen how other contributors has "climbed up the ledges" by testing, fixing existing bugs, and writing documentation, dedicating a large amount of free time and resources just to gain some recognition before even considering proposing new major features to be implemented. Is that the recommended path?

I think you are missing the point here entirely. Other contributors aren't "climbing the ranks" so to speak. No one is out there trying to "gain some recognition" so that their feature proposals get auto-merged. You'll find the people you are talking about are not just suggesting their own proposals and getting them accepted, they are continuing the pattern of "identify problem, find solution" at a larger scale.

To you it may look like they have created a feature out of nowhere, but to someone who has been spending large amounts of personal time trying to solve as many problems as possible, it is more clear. For many of us, the majority of the time we contribute to Godot isn't in writing code, it is in responding to bug reports and assisting users on community channels, like the q&a, facebook, reddit, and discord. By spending so much time in those areas you get a good knowledge of what barriers users are facing.

So, while it may look like other contributors are not following the "problem first" philosophy, they actually are.

I can see that you are struggling to find the best way to support the project as someone with strong programming skills. I would suggest focusing on bug fixes, documentation (please!), community support and (once this GIP process is smoothed out) implementing accepted proposed features.

The core team is taking a harder stance against solutions in search of a problem, so continually submitted PRs with feature proposals that suit your needs is going to be very disappointing.

[Xrayez]

I think you are missing the point here entirely.

When I say things I may be over dramatic and choose rhetorical wordings to express my opinion depending on the emotional state, but no I understand that the problem must always come first. That's actually one of the mantras I keep telling myself when working on my own projects when I find myself stuck, because asking "Why?" somehow returns your inner genius towards the goal by the mere intention.

I can see that you are struggling to find the best way to support the project as someone with strong programming skills. I would suggest focusing on bug fixes, documentation (please!), community support and (once this GIP process is smoothed out) implementing accepted proposed features.

I guess you're misinterpreting my motivation. I do not ask: "What can I work on next". I ask: "Why should I work on this". The question can have a bad connotation but that's also quite a legitimate question to answer. And it's not about arrogance, it's about honesty and coming up with a consensus and a clear vision.

In fact the entire "problem" of this proposal can be seen as:

1. Why should a person be working on the project in the first place? (not specific to Godot at all)
2. Is the person's own vision and intention is in alignment with the project?
3. Does it make sense to work on the project having particular requirements over what goes into core vs plugin? Can the engine provide necessarily tools of out-of-the-box?
4. At what pace the project is developed and what areas are prioritized? How much effort and time does it take for the new features to be reviewed and implemented?

And implementing this proposal by documenting the answers is the solution to this problem. Not everything makes sense to document as certain things are "live" in nature and change constantly of course.

To you it may look like they have created a feature out of nowhere, but to someone who has been spending large amounts of personal time trying to solve as many problems as possible, it is more clear. For many of us, the majority of the time we contribute to Godot isn't in writing code, it is in responding to bug reports and assisting users on community channels, like the q&a, facebook, reddit, and discord. By spending so much time in those areas you get a good knowledge of what barriers users are facing.

I live in a country where altruism is not commonplace. Saying that nobody has some personal agenda regarding the direction of development is surprising for me. We all have some particular skill set we'd like to realize in a concrete manner. It's just that so far I think my own skillset is too specific to be seen useful by others, and all I want by now is to draw a clear line really, and contribute in a way to minimize interpersonal frictions.

When I implemented new features in Godot, I almost always take at least some feature request and/or bug report to justify it/back it up. But when I make new features "for myself", rest assure that those features do not stem from illusionary problems and they are governed by my own specific limitations. Alas, I cannot answer the Describe the project you're working on to describe my particular problems to full extent with the engine, because:

1. I cannot allow myself for such information to be available to other developers for years on GIP with the lack of review.
2. I want to "protect" my ideas, but I have no legal power to do so in my country.
3. The question is intimate in and of itself (am I on the dating site). ❤️

All of this makes it difficult to communicate the exact problem, while the problem is quite real. But it doesn't matter anyway because those problems are "too specific" to be solved on the engine side. Thanks goodness even those kind of problems can be worked around with a non-trivial script: #565 (comment). 🙂

Again, I fully accept the process by now, it's just that it would be good for this to be clear, and thanks for shedding some thoughts on this already. I just want other (new) contributors to be aware of them too.

While I agree that some of the questions pertain to all types of FOSS projects and it's just me not knowing about them, there are certainly philosophical questions which are specific to Godot Engine development, see all of my above posts. Altruistic or egoistic, this is work hours I'd like to spend effectively. If we have a clear vision, that's effective. If we don't, that's like chasing rainbows:

At the end of the rainbow there’s happiness
And to find it how often I’ve tried
But my life is a race just a wild goose chase
And my dreams have always been denied
Why have I always been a failure?
What can the reason be?
I wonder if the world’s to blame
I wonder if it could be me?

[mhilbrunner]

I cannot allow myself for such information to be available to other developers for years on GIP with the lack of review.
I want to "protect" my ideas, but I have no legal power to do so in my country.
The question is intimate in and of itself (am I on the dating site). heart

@Xrayez

Sorry, but asking for your project isn't in any way, shape or form intimate.

If what you're working on is really so highly confidential, then do the work yourself.

You're asking people to spend time of their life for something you want, for free, for a complete stranger, but lack the will to share even information where you expect work from others.

Hire someone to do the work then. Or create a test case to demonstrate the issues you face you can talk about.

Or talk in the abstract, about the genre.
Nobody expects you to dump your complete source code under a free license.

By the way, ideas aren't nearly worth as much as you make them out to be.

Execution is, a great team is, marketing is. Ideas are plentiful and cheap.

Really, if your idea is that proprietary and you believe it to be worth so much, do it the proprietary way then, pitch it to someone and fund the work.

(This isn't meant in a hostile way. Reading it over I realize it may sound that way, written not spoken. It's just: Godot is not asking for much. But even if that's too much for your project, that's completely fine too. Godot comes with the freest of the free licenses attached, use it. Fork it, fix it. Hire someone to do it. You don't need to tell anyone anything. You know what's completely normal when you run into a problem with any of the commercial engines? Or even Apple as a platform? Being asked to send over your complete source, to attach your project and let them have a look. Sure, there may be some NDAs attached, but you're paying them a lot for the hassle. I'm sure someone would be willing to be paid for that hassle with Godot too.)

[Zireael07]

@Xrayez: I'm sorry, but there is no such thing as "protecting your ideas". Ideas are a dime a dozen and you can't "protect" them under any law, this applies to computer games, tabletop games, books, and any other form of creativity.

The "describe your project" note can be as short as "a 2D RTS game" or a "3D racing game"... No one is forcing you to divulge ALL the details.

[Xrayez]

Sorry, but asking for your project isn't in any way, shape or form intimate.

@mhilbrunner I insist this is an intimate question. What is intimate for you?

If what you're working on is really so highly confidential, then do the work yourself.

No, my work is not confidential. But I equally don't want to talk about it actively within the developer's community specifically.

then do the work yourself

I always do. 🙂

You're asking people to spend time of their life for something you want, for free, for a complete stranger, but lack the will to share even information where you expect work from others.

The thing is, I don't want to ask. In fact, it is very difficult for me to ask something from people, I mostly give but don't ask. And giving the full project details is like, asking too much. What do you think the answer to "Describe the project you're working on" should be?

Hire someone to do the work then.

I wouldn't be here. If you think that I'm asking somebody to do the actual work by implementing the proposed features, it's not the case. I'm willing to do the work myself. The question is, is it really worth describing and proposing the features if they won't be accepted/approved in the first place? I mean, one of the most frequent answers I get: "your feature is too specific". #779.

I understand that my use cases might be specific, but as I'm using the engine for free, I do want to give back. That's why I've open-sourced some of my C++ modules written for Godot Engine, if you look at my GitHub profile you'll get what I mean.

By the way, ideas aren't nearly worth as much as you make them out to be.
Execution is, a great team is, marketing is. Ideas are plentiful and cheap.

Beauty is in the eye of the beholder.

Imagine saying this to a mother about her child. What kind of response would you expect? 😝

So, regarding the question itself, it must be clarified, but I kind of accepted the fact that this won't happen. #42.

Fork it

I don't want to.

@Zireael07

you can't "protect" them under any law

This is why I put "protect" in quotes too, yeah I really didn't mean to say that, just to convey the hurdles and drama of the solo indie dev.

[mhilbrunner]

@Xrayez

Well, if it's that private for you, that's fine. Just saying that's somewhat unusual.

Most people are fine talking about their game in general terms, some even more than that.

I mean, especially in indie dev, you want to build a community for your game as early as possible, so you will eventually have to share your idea - on dev blogs, in trailers, in early access, in demos, in betas...

The vastly bigger danger to an indie dev is nobody knowing or caring about your game.

Look at Minecraft. That was shared when it was just a rough prototype, dirt blocks only, years before being really ready and released.

That's one of the most popular games out there, and yes, there were clones. I don't thino any of them hurt the original though.

How many people tried to copy and kill WoW?

How many great indie games do you know that were harmed by a clone?

Besides maybe mobile were people steal your released binary and release it under their own name. And even their, they're stealing assets or the game, not ideas.

I think you're worrying too much, but maybe that's just me. Now, that's fine, of course. But then you need to accept that it's hard to understand where you're coming from if you don't want to talk about it.

Again, you can build unrelated test cases to demonstrate.

[Xrayez]

In order to make this proposal actionable, it would be enough if we could include some paragraphs which could describe the vision of Godot development at the very least.

I've found some response on Reddit from @reduz which can be seen as a manifestation of this proposal, but it must be documented. Quoting an entire reply here for the sake of recording and discussing it. Also let me put some emphasis on some points marked with either bold or italic.

reduz

Let me contrast with Unreal and Unity, so you can understand better where our priorities are.

Unreal has probably a lot more settings you can tweak to optimize corner cases, or different rendering paths, effects, options etc. This complexity definitely aids for very large big budget AAA games, but for medium and small studios this will usually go unused because you need a render engineer that understands them.

Unity has a very simplistic renderer that doesn't look very good (as it's mainly aimed to mobile), but gives you a huge amount of flexibility under the hood to tweak it and improve it on your own. They are betting even more on this approach with their scriptable pipeline. You can often download stuff from he asset store to get more advanced rendering features too, although the drawback of this approach is that the stuff you get from the asset store rarely plays well together, as each reimplements a part of the rendering. This works great for their business model, though.

Godot in contrast aims for mostly high-level only rendering backend that looks pretty, covers most common use cases and only allows some tweaking. The idea is that out of the box it looks as good as Unreal, is much easier to use, but of course may lack the ability to tweak performance for corner use cases (though it should still be good for most games). The vision here is that this can be achievable with a relatively simple renderer (there is not as much rendering code in there as you migt think), and that if a large company ever wants to use it, they have the money to hire a render engineer and tweak it themselves.

Regarding other stuff not on the goal list, actually networking and sound are very mature already (3.0 got a new sound system), the consensus of AI is to not support it out of the box (too many different possible approaches). Pathfinding for 3D still needs some work, but since we have a dedicated contributor who enjoys working on all that, it's going nicely.

---

Unless the vision has changed (this was posted a year ago), I guess it's safe to say that this vision and philosophy can be generalized and extended to other aspects of Godot Engine development, not only rendering. This is where I probably failed to recognize that Godot isn't very suited configuring for corner cases, hence the collision of expectations, and any contributing work done in providing support for corner cases is basically in vain.

There's some existing From Unity to Godot Engine documentation page which talks about the concrete differences of these engines, but not the difference between the more underlying development philosophy about them.

[Xrayez]

Closing not because the proposal is resolved, but because I don't want to put any pressure on the core developers at the moment, as long as the engine is doing well, again sorry for the troubles this may created for anyone.

This proposal has received quite some number of thumbs up though, so maybe it's not only about my own particular mentality regarding the topic, so feel free to reopen this.

I may add some more thoughts whenever I discover something unexpected regarding the direction of the engine/let my philosophical nature emerge, but please don't interpret my words badly, that's for the greater good. This may be actually a good place to collect all of those not-so-obvious revelations which are spread around other community channels like Twitter, because we as humans tend to talk more freely about the things we do on a non-official level, which describe the intentions more honestly, yet there's no centralized place to track those, and I'd like to document this on some level.

The vision is never constant (nothing is eternal, except for the universe perhaps), but it's equally important to let people take a glimpse behind the scenes at the very least, and because "someone has to do it".

For historical purposes, this is the result of suggestions and requests which were made in #10 (comment), which lead to #39, which lead to #47, which finally lead to #575.

I feel like I've said enough.

Peace. 🙂

[Xrayez]

Reopening upon warning in #1424 (comment).

[Xrayez]

@groud, in order to keep the discussion on topic, you've expressed your opinion regarding the allegedly non-existing development philosophy in Godot in #69 (comment). To quote:

I don't really see your point... When I give my opinion on something I give it case by case. I might indeed favor proposals I agree with, but that's all. I, regarding my own experience, consider the pros and cons, then give my opinion. it's indeed subjective as I have my own opinion on what should Godot look like, and what it should not look like [emphasis mine].

Could you please elaborate on this in relation to my previous question here? #575 (comment)

What are Godot's non-goals?

You can also describe how do you see Godot should look like in your opinion, but expressing your opinion on how Godot should not look like would be sufficient in this case, in my opinion, I'm just trying to outline some vision because we likely have different views on this topic, and I'd like to know how it differs from my understanding of what Godot should be like.

Thanks!

[groud]

I said there is no absolute philosophy of Godot. Like there are no Bible of Godot telling you in advance what will be accepted or not. What is accepted come from discussion, the usually arguments you can rely on being more or less in the godot development guide. On which I also usually rely to express my points.

I don't know what you want me to say... I don't like useless or redundant features, I don't like things that are too complex to understand, I don't like bad UX, etc...

Anyway, I'm going to stop this conversation here as it has already taken too much of my time. I can't give you a detailed manual on what I want Godot to exactly look like, as I don't even know myself... 🤷‍♂️

[Xrayez]

I said there is no absolute philosophy of Godot. Like there are no Bible of Godot telling you in advance what will be accepted or not.

Well yeah, I'd certainly won't go the dogmatic way of describing that, but I think this is still wrong, in a way that there are gazillion of game engines which are not like Godot, what makes them different from Godot could possibly tell what will be accepted or not for Godot development. As I said earlier, take all the feature pull requests (prior to existence of GIP), and you'll get a set of approved and rejected ones. What determines the outcome?

What percentage of existing proposals on GIP will be actually approved? Note that I'm not saying "implemented", also excluding small enhancements of existing features, and potential suggestions-only "proposals", which are not proposals per se. Mostly talking about those who are really going to implement those features themselves (#1485 (comment)). I'd like estimate numbers.

If the approval rate is at least 50%, I say that we have a good, well-known development principles, vision, goals etc. which facilitate this approval rate.

If the approval rate is below 50%, it means that people who are not deeply involved with existing development processes and conventions don't actually understand the intention of the project to full extent, else they wouldn't create a proposal in the first place. Do you agree? In it's current state, I feel like GIP is a some kind of bug zapper which has a bright light to attract lost souls, but when you come closer, you get, well, zapped: #779.

And please, no, I don't think talking on IRC is absolutely necessary. Godot is a community-driven game engine so what core developers think about a feature may not be actually in alignment with the opinion of majority of community members.

I personally estimate that only 5-10% of new feature proposals like outlined above will be actually approved (like those proposals created by core developers themselves), which is a really poor success rate in my opinion.

I mean, as stated in the documentation, Godot cannot solve every problem that exists under the sun. But the approval rate could be improved naturally by creating a proper "beacon" (not a "zapper") which could attract proposals which are actually useful for the engine, and documenting development philosophy, vision, purpose, goals etc etc. is the answer to this. I mean, thanks to Calinou who recognized some points in this proposal and did the necessary steps to document at least some aspects, like "usability over absolute performance" principle: godotengine/godot-docs#3788.

I believe there's always some principles which governs the development (toss away the "philosophy" word if you don't like associating with the Bible), it just tells that only a few people are aware of those principles consciously (including core developers). And by the way, the fact that you don't know exactly how Godot should look like is not particularly your fault. Alas, those who should convey this information the best are the project founders of Godot, but unfortunately they won't ever notice this discussion unless you link it directly on IRC channels, even if they do notice, they won't have the time to read the entire discussion anyway, and say that it's not important. But then again here I am, trying my best to figure out this all on my own via various community channels such as reddit.

I mean, that's what you get by making the engine open-source and a "world-wide" organization, people will try to change the engine to cater to their specific game requirements, because they really do have a particular way of thinking and they do have some pre-conceived vision for the project, which may not be actually in alignment with what most Godot core developers think.

Don't you agree with at least some points I've made? There are a number of posts I've written here which did not receive any comments so far. Don't know about you, but in my culture, that usually a sign of agreement. 😛

Anyway, I'm going to stop this conversation here as it has already taken too much of my time. I can't give you a detailed manual on what I want Godot to exactly look like, as I don't even know myself... 🤷‍♂️

That's very unfortunate. You're so active community member and now you're fleeting away just like that, dedicating your lifetime to express your further disagreement regarding existing proposals. I wouldn't like to constantly disagree with people, so I'm trying my best to minimize those unnecessary interpersonal frictions. I care about the project, else this proposal/inquiry wouldn't exist in the first place.

[Xrayez]

Again, please take a look at my previous post where I show what the lead developer's vision is regarding Godot: #575 (comment). Adapting and putting this somewhere in the documentation would be enough to implement this proposal.

Regarding goals and non-goals of a project, here's a concrete example as well: Goals and priorities for C++

Also, if anyone thinks that Godot doesn't have any kind of pre-existing development philosophy, that's also a philosophy! It would look like a stupid request from my side and deemed as already something obvious, but perhaps that's the only thing which has to be documented. Paraphrasing and building upon the previous groud posts #575 (comment) and #69 (comment):

There is no absolute philosophy of Godot. There's nothing which can tell in advance what is useful or not. Community discussion is the only reliable tool used to determine what kind of features are deemed meaningful for Godot development. The core development philosophy of Godot is exactly the uncertainty in the direction of the project, and accepting the reality of that nothing can be truly finished, because of the very nature of the never-ending process of growth.

Would you write that down in the documentation? 👍 if agree, 👎 if disagree.

[Xrayez]

I wrote "Development philosophy" page in godotengine/godot-docs#4069, so you can see exactly what I'm requesting. 🙂

[me2beats]

Sticking to the old (compatibility, hardware, technologies) is not about Godot.
Requirig powerful hardware is not about Godot

Trying to be the best at something at all costs is not about Godot

Trying to be special at all costs is not about Godot.
Trying to be like everything else is not about Godot.

Not thinking about the consequences is not about Godot.
Thinking too much about the consequences is not about Godot

Not listening to users is not about Godot

Forcing the user to do something in only one way is not about Godot.

To be convenient, intuitive, feature-charged, versatile, flexible and customizable — that's about Godot imo

[Xrayez]

@me2beats is this sarcasm or flattery? 🙂

Being able to extend the engine probably alleviates most (but not all) problems and limitations which may be inherent to Godot's intended design (whatever it is). But for everything else (core development), this requires:

• upstreaming bug fixes. If that doesn't help (see failed attempts such as Register Bullet-specific classes only when the module is enabled godot#32272), then:
• patching Godot manually (takes some sophisticated approach to git apply godot.patch), or:
• forking Godot and maintaining a custom version of the engine (I don't yet).

Now, those kind of fixes make perfect sense to me, but for some reason or another they get rejected like that, and I wonder why. Problems exist in the present moment, rather than in the future, and that's another problem with Godot development.

That said, I'd argue about customizable part. I mean yeah there are certainly ways you can extend the engine and do whatever you want, but when it comes to customize some core functionality, it could take quite a discussion even for smallest possible changes in Godot, the way I see it.

For example, I don't quite understand why simple changes like godotengine/godot#28343 need a discussion in the first place. Even if we don't want to facilitate those kind of usages, isn't making something fail-proof is always desired? (talking about convenience and intuitive parts), see godotengine/godot#33405 which could benefit from the PR above.

---

Also, small things like #1229, and the limitations like GodotSteam/GodotSteam#151. Maybe that's lack of documentation back in the days, but the documentation is not needed to take advantage of something to the fullest, and making sure that users cannot possibly stumble upon limitations which are easy to prevent. That's probably where our development philosophies differ, but I don't quite understand the rationale for those restrictions and decisions, to quote my previous posts:

See reduz response while closing the proposal (which is ok but to demonstrate the typical behavior which has to be done everytime, with different wordings):

Again, I really appreciate that you have good intentions, but you don't understand any of the inner workings of the engine, or the philosophy [emphasis mine] behind it. Most of your comments are towards things you don't really understand how they are used, how critical they are to performance, or what their priorities are in general.

That said, I've seen numerous discussions where customizations were seen as complications for Godot: godotengine/godot#30816 (comment). Yes, I understand that piling up settings into one place is likely a bad idea, but then I see no discussion which could improve the current settings easier to categorize and find, but it seems like, for core developers, it's just easier to remove customization features from Godot, instead of coming up with a proper solution.

So, all I'm asking is making the decision process explicit, developers don't have to propose features which are bound to be refused, because they go against development philosophy in the first place. 😛

I believe it's the responsibility of the core developers to define this development philosophy the way they see it, so it could further establish the scope for the project, especially important for future generations which may adopt Godot in it's current state, else Godot may end up being very different from what it is now.

[reduz]

@Xrayez I would say that Godot development extremely pragmatic, with focus solely on solving problems. Because of this, there is not really a "Development philosophy". There is zero dogmatism here and theoretical or philosophical discussions are generally irrelevant in this context.

So, the Problem -> Solution is what best expresses this mindset.

[GonziHere]

@reduz It still leaves room for ambiguity:

• People needing a solution for problem X won't use Godot because it doesn't solve X, so they won't propose it. So there is an argument to be made for "preemptive solutions" if they make the solution better for a given problem space. This leads to:
• The problem space needs to be somewhat defined (would you care if my Godot project will have issues communicating with my coffee maker?) It also relates to the priority (RTX vs mobile devices, voxels in the engine, fluid simulations... ).
• Even though there might be a well-understood problem that needs solving, it can be solved with many different implementations (engine vs plugin, performance vs ease of use vs generic solution vs scalability vs override ability...)

I personally care about it, because I've tested Godot, Unigine, and Unreal and I've ended with the third one only because of its maturity. I still check Godot because I like it more. The thing is, If Godot doesn't have X, or doesn't do Y, I have no way of knowing if it will maybe have it in the future or if it's something that "shouldn't be there" and that I should implement it myself (64-bit positioning in 4.0 - it has an issue, it has PR, it's not completed. And it's not needed for 2D platformers, while extremely important for large areas ).

To add to it. The Unreal philosophy is that the content creators don't have to leave the editor. This is why they have asset reimporting, blueprints, animation editor, 3D mesh editor in the works, and so on. But it's also a pain to use for programmers, it's kinda messy and all over the place, their actor is "too smart" for general use, ... . If you compare this with the Unigine, you'll see the cleanliness of the API. It targets the pro users, the engineers, so it doesn't have many "fancy" features but what's there is integrated incredibly well. It doesn't really have UI, but it has geodata, satellite positioning systems, 64bit coords, and so on...

So yeah, I still think that the philosophy (why the project exists, where it's going, who is its intended user, what problems it should solve... ) is an incredibly important thing... This is what defines where the project will be in 5 years. (I'm pretty sure that the unigine will still be better for the hardcore simulators, while unreal will still be better for the movie production).

I really like Godot and I check it out regularly, but if I were to describe it to someone as a project, I would say that it's an engine that is opensource and plays catchup with Unity. I don't think that's a fair description, but I have a hard time coming with another one. And I have no way of knowing how well it will support 64bits. Maybe it won't because it wouldn't work on older phones, maybe it will because sim apps are among intended usage ...

[Calinou]

I have no way of knowing if it will maybe have it in the future or if it's something that "shouldn't be there" and that I should implement it myself (64-bit positioning in 4.0 - it has an issue, it has PR, it's not completed. And it's not needed for 2D platformers, while extremely important for large areas ).

This is being implemented already: godotengine/godot#21922
The goal is to merge it for 4.0, but it will be a compile-time option that's disabled by default to not harm the low-end experience.

If you're wondering about whether a feature is being worked on, I suggest searching in the list of open pull requests. The same advice generally applies to any open source project out there 🙂

[GonziHere]

@Calinou I know about that PR, I've literally mentioned it in the part that you quoted. I also don't really care about what currently is being worked on, but rather WHY it is or isn't being worked on. How that decision gets made (outside of "someone wants it").
That being said I would like to point out that it's almost 7 years old: godotengine/godot#288 and it was moved down several times over the years (3.0,3.1, 3.2, now 4.0...).
Why wasn't it done already? >> It doesn't have a priority. >> Why doesn't it have a priority? >> Because it's less important than ... . >> Why it's less important than ...? >> Because ... is more relevant for the philosophy of the project.

Do you really not see why some philosophy/goals might be useful? How it relates even to this lifetime of the 64bit issue? How "Problem -> Solution" isn't enough?

[Calinou]

Why wasn't it done already? >> It doesn't have a priority. >> Why doesn't it have a priority? >> Because it's less important than ... . >> Why it's less important than ...? >> Because ... is more relevant for the philosophy of the project.

Double-precision physics weren't implemented yet because the engine (up until 3.2.x) isn't very optimized. This means there are relatively few people working on large-scale projects, and those who are working on 3D projects generally stick to small-scale projects. This in turn means there isn't a critical need for double-precision physics right now.

With 4.0, this will change as the engine will be a lot more optimized. Large-scale game development will become more viable even for those with less optimization knowledge.

[aaronfranke]

@GonziHere The vast majority of PRs are reviewed and merged by either @reduz or @akien-mga, so pretty much everything goes through them. The only way you can truly understand Godot's philosophy in detail is by knowing what their opinions are. For example, you can follow their Twitter accounts, or chat with them on IRC. In fact, they encourage people to come on IRC.

64-bit positioning in 4.0 - it has an issue, it has PR, it's not completed.

I've been maintaining the PR for about 2 and a half years at this point. This is a good example of things having to go through the core devs to get added. There is nothing else I can do but wait for @reduz to decide that it's time to review the PR. Any work I do quickly becomes out of date. The bigger the PR is the more I have to constantly rebase the PR to keep it in a working state.

If you want to test it out early, here is a link to a Linux debug build with doubles enabled, based on the current master. However, be aware that it's held together by duct tape and prayers, for example it can't open 3D models or SCN files because there is a size mismatch, but in its current state it does open TSCN files and run scripts successfully.

EDIT: It has been merged! There is now a float=64 option available in the current master branch.

[Xrayez]

I've been maintaining the PR for about 2 and a half years at this point. This is a good example of things having to go through the core devs to get added. There is nothing else I can do but wait for @reduz to decide that it's time to review the PR. Any work I do quickly becomes out of date. The bigger the PR is the more I have to constantly rebase the PR to keep it in a working state.

What do you mean by this? Do you say that it's normal to constantly rebase a PR over the years to get something merged? Or you want to say that the game is not worth the candle and the changes must be discussed with the core developers first?

If the PR won't be merged, this will prove our point that it's actually quite important to know what kind of changes are meaningful for Godot development, else it's just a waste of precious time.

[YuriSizov]

This is ultimately a questions of: do we want Godot to have a biased authority in the form of one or two people accepting all PRs, or do we want it to have a formal set of conditions that make any PR accepted (provided that the code itself is sound). In the first case we will always have people with PRs which hang for years and years waiting for that moment when the authority has time to handle it. But I'm not convinced the second option is ultimately better, even though it may provide a clearer and faster release cycle for individual features. Currently we have a personal touch, even though it means that we may operate at an extremely slow speed at times.

But this is true for any project, open source and community driven or made proprietary by a company. There are things that can be in development hell for years because nobody deems them a priority. People will research different issues and may come to a solution that would require a lot of "higher-ups" to give an approval and that would not be important for the product at the moment, and to the backburner it goes. And with open source we will always have more people contributing (whether ideas or code) than people that make final decisions. It's not even about the vision or philosophy.

[GonziHere]

@pycbouh - well, there still can (and should) be something in between the two cases. The authorities could state that Godot 2.x, 3.x is about the basic performance, bugfixes, and overall stability and no-one would really try to introduce 64bit into it, for example. The whole issue is that there is a "biased authority" (which is fine, welcomed even), but without any outlining principles/vision for the project as a whole. I get that it might be hard to put the philosophy into words, or that the author doesn't really have time for that, but the discussion about why it might be a good idea is a weird one.

If I were to build a car, I need to know if it's a racecar, or a family saloon, or a dune buggy. It might get built over the next ten years, but I would have at least some idea of what it's supposed to do, what are the main features and what can be just added at a later date, if ever. No one would propose a roll cage into a family car or a winch into a track car... that's all that this is about. Who is actually supposed to use this engine and for what. This shapes its core/top features, it's biggest engineering focus and it also automatically decides what isn't needed.

[YuriSizov]

If I were to build a car, I need to know if it's a racecar, or a family saloon, or a dune buggy.

This is a general purpose game engine with some bias towards accessibility and ease of use. Everything merged into the core serves this general idea, with a single caveat that the core team doesn't want to bloat the engine with too much features, and prefers to delegate to the plugin/module land wherever possible.

What is asked here currently is a defined set of principles why each individual PR or proposal may or may not be accepted. I think the position from the core team is — there is no such set of principles at all, and each PR is decided on based on its own merits, as long as they fit what I mentioned above. The comment I was answering to directly was discussing if it is normal to have a PR stagnate for over 2 years, but this is not a question about core principles. A PR like that would stagnate because it is generally welcomed, but there is no time to go in-depth on it at any given moment. So it's a question about ideas and PRs funneling into just a few people with limited time on their hands, and those people being the authority.

Don't get me wrong, I too have my frustration with the approval process. But I don't see what we can do in practice. If we accept a biased authority model, a model where there is no set of rules, but rather an opportunity to influence one's opinion, then we need to account for the time required by said authority to evaluate each idea. Basically the system in place currently: ask for time to be heard and make your case, if you provide compelling evidence for your idea, it is greenlit.

[Xrayez]

pycbouh

This is ultimately a questions of: do we want Godot to have a biased authority in the form of one or two people accepting all PRs, or do we want it to have a formal set of conditions that make any PR accepted (provided that the code itself is sound).

GonziHere

This shapes its core/top features, it's biggest engineering focus and it also automatically decides what isn't needed [emphasis mine].

I'd like to emphasize on the "not needed" part, which may be actually more important to define rather than coming up with a list of criteria of what kind of proposals/PRs are going to accepted, given Godot is documented to be a community-driven game engine. In short: I think it would be much easier to figure out what is absolutely not needed rather than what is needed.

But according to the previous discussion above months ago, there's a fear that this will lead to division of the community, and as I've already said, that's totally ok, unless you want to attract all game developers/software engineers from all around the world, and be able to deal with all their own way of thinking, mentality, culture, and needs, which I think is practically impossible to achieve.

---

This is a general purpose game engine with some bias towards accessibility and ease of use. Everything merged into the core serves this general idea, with a single caveat that the core team doesn't want to bloat the engine with too much features, and prefers to delegate to the plugin/module land wherever possible.

From Godot official homepage:

Godot provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.

How huge the engine should be? If we delegate most of the feature development to plugins/modules, then it just goes against that logic. If anything, I'd replace the "huge" word, or omit it completely then. The fact that InterpolatedCamera is removed from the engine in Godot 4.0 further distances it from what is actually written.

Those are all small things, but they are actually crucial and contribute to the development principles, I'd just like those words to reflect the reality.

Building upon the topic on what kind of features are very unlikely to be implemented in Godot: if there's too many ways to implement something, then it won't be implemented in Godot out of the box at all (like AI), and I think that's another quite important point to convey to potential contributors.

[Xrayez]

If I were to build a car, I need to know if it's a racecar, or a family saloon, or a dune buggy. It might get built over the next ten years, but I would have at least some idea of what it's supposed to do, what are the main features and what can be just added at a later date, if ever. No one would propose a roll cage into a family car or a winch into a track car... that's all that this is about. Who is actually supposed to use this engine and for what. This shapes its core/top features, it's biggest engineering focus and it also automatically decides what isn't needed.

I really like this example, so I've come up with another one!

@reduz says that:

Godot development extremely pragmatic, with focus solely on solving problems

Lets say there are two types of toothbrushes: a plain one and electric one. Now, they solve the same underlying problem of keeping your teeth clean to prevent cavities, but note that they are quite different. As engineers, we'd just like to know what kind of toothbrush we're building, that's all.

Or are we trying to build a toothbrush which is based on some kind of singularity principle? 😄

[aaronfranke]

What do you mean by this? Do you say that it's normal to constantly rebase a PR over the years to get something merged? Or you want to say that the game is not worth the candle and the changes must be discussed with the core developers first?

I am simply stating the reality of the situation. Ideally PRs would be either merged or closed within a month of being opened.

In the case of double support, the concept has already been approved by the core devs. The engine already has partial support since it was first open sourced. I'm trying to complete it, but it's always a low priority for the core devs, low enough that even if someone does all the work, the core devs aren't willing to review and merge it. This statement can also be applied to most of the open PRs, the code that the community has already written is considered a low priority by the core devs compared to having the core devs write new code, and PRs stagnate for a long time. I understand the core devs writing new code, but if it were me I would give more focus to the community contiributions since they are likely to solve real world problems people are having with the engine and are from contributors who care enough about the problems to put effort into solving them. Or as reduz puts it:

So, the Problem -> Solution is what best expresses this mindset.

[Xrayez]

How do you solve this problem? 🙂

Fable by Krilov: https://ru.wikipedia.org/wiki/%D0%9B%D0%B5%D0%B1%D0%B5%D0%B4%D1%8C,_%D0%A9%D1%83%D0%BA%D0%B0_%D0%B8_%D0%A0%D0%B0%D0%BA

[Hoimar]

A PR like that would stagnate because it is generally welcomed, but there is no time to go in-depth on it at any given moment. So it's a question about ideas and PRs funneling into just a few people with limited time on their hands, and those people being the authority.

Yeah, I think Juan knows this and that's the reason he'll shift focus to administration, organization and helping contributors, see this tweet:

As much as I enjoy programming, Godot is at a point where I can't do that luxury anymore. My last big task will be re-implementing GLES3 support after Vulkan is completed.
The project needs me more for administration, public relations, overseeing, and helping new contributors.

- https://twitter.com/reduzio/status/1378153889451630593

[Xrayez]

Would you say that Godot abides to YAGNI principle?

This principle is part of Extreme programming, let me quote the entire thing and put some emphasis on sentences which I think do greatly resonate with current Godot development principles:

Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, not programming features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously (i.e., the practice of pair programming).

I think this really applies to Godot, don't you think?

The "customer" in this case is the Godot community, and the development is driven by community in the sense that community itself guides Godot development.

Is this correct? If so, it's worth to write this down in the documentation that Godot uses many development principles derived from Extreme programming. In this case, being explicit is better than implicit. I think reduz would confirm #575 (comment).

I'm asking because not every software developer abide to those principles (religiously). Please interpret "philosophy" as a set of principles, if using "philosophy" word makes you think that we're talking about dogmatic concepts here.

I have best positive intentions, thank you!

[Calinou]

Is this correct? If so, it's worth to write this down in the documentation that Godot uses many development principles derived from Extreme programming. In this case, being explicit is better than implicit.

My issue with adopting a label such as "Extreme programming" is that you also get the negative stereotypes associated with it. (Remember how much damage happened with the "Move fast and break things" motto?)

[Xrayez]

I wanted to link Juan's development article called "Why isn't Godot an ECS-based game engine?".

This is a clear example of development philosophy aspect. In fact. I'm glad that articles like this get written from time to time.

Juan calls it "design decisions". This "shedding of light" is what this proposal asks for, really. However, the problem is that these kind of articles are not immediately accessible to new contributors via documentation.

So again, perhaps I've made a mistake by using "philosophy" word, because according to responses I've got (at Godot contributors chat), most treat "philosophy" as something useless, too abstract, something that you're forced to learn in college/university. But no, it's not useless, there's a reason why they teach you philosophy in school. So at least, lets talk about design decisions, and lets hope this kind of terminology will shed more light on the overall development philosophy behind Godot.

Again, I'm probably sacrificing my reputation/trust/respect of the core developers by talking on a topic like this, but regardless of the recent circumstances that happened to me, I want to care about Godot and want to improve the engine. I mean, this exact proposal is my contribution to Godot, and I hope that you appreciate my efforts.

Again, this proposal is quite actionable. There's godotengine/godot-docs#4069 but I've closed it because I'm not really sure whether you'd approve writing development philosophy page in this regard, but I can reopen it and further improve the PR. Yet this is something that Juan can do better.

[Xrayez]

I have written Godot's development philosophy, published at Goost's documentation, see:

• https://goost.readthedocs.io/en/gd3/development/godot_development_philosophy.html

Please read the entire thing before jumping to conclusions.

Feedback welcome! If you have any objections, feel free to suggest changes, but do note that I can back up every statement there given my 5 year contribution experience with Godot.

I'm certainly not a lead developer of Godot, so you can further infer the development philosophy from the links to news articles created by Juan, but I've tried to summarize and categorize it at least, it could be much longer if those external articles could be merged into one, so to speak.

I aim to build upon existing material, of course. By now, this is an independent and collected effort of https://github.com/goostengine/goost contributors, and obviously should not be seen as an official vision behind the Godot project.

We have best positive intentions, thank you.

[YuriSizov]

obviously should not be seen as an official vision behind the Godot project

Then it shouldn't be published under the title of "Godot development philosophy", even if you have a disclaimer below, because that's what search engines and casual readers will see.

[dalexeev]

If we apply the Godot philosophy recursively to this proposal, then it is obvious that we have a problem that needs to be solved. Or at least a user request that received support and wide discussion, touching the minds and hearts of many people.

What is a problem and what is not? When and how does a user request become a problem that Godot solves? After all, community support for a request does not always mean that Godot leaders recognize this request as a problem.

What is the solution to the problem? The same problem can be solved in different ways and to different degrees. Why is one solution better than another? What problems does Godot solve completely, what problems does it partially solve, and what problems does it not solve at all? Perfect solutions are unattainable, but how are compromise solutions born?

Just as there are no perfect solutions, there are no definitive answers to these questions. But the need for good answers is there, as is the need for good software. I'd like to read about Godot's goals. It doesn't have to be the Bible, rules or guidelines to refer to. It could just be an explanation, a story about the vision of the project by its leaders. This document should not prevent anyone from contributing to the project, but should help to better understand which contributions are most likely to be accepted.

And besides these philosophical questions, there are a few more mundane ones:

1. What if the interests of different users contradict each other?
2. What if the desires of a large number of users differ from the vision of the leaders?
3. How important is community support and discussion, and how important are leaders' decisions?
4. Is there any indicator of issue/proposal approval and PR preapproval (besides the High priority label)? Of course, without a 100% guarantee.*

* I understand that Open Source works a little differently and often you just need to wait a while. But the unpredictability of this process makes many people disappointed, it seems to them that their problem/proposal/solution was simply forgotten/ignored, without explanation. Sometimes it's even worse than rejection.