packrat (i can't tell what's going on in your avatar photo, but it looks funny)
here is a bigger version of the avatar pic:
packrat (i can't tell what's going on in your avatar photo, but it looks funny)
here is a bigger version of the avatar pic:
d2clon Does the author have a point regarding the use of nonoptimized structures in the core code?
Did you read the github issue I linked? It addresses that.
d2clon Is it true there is no clear road map for the project?
The closest that I'm aware of is the Blog:
https://godotengine.org/blog/
If that doesn't satisfy your definition of "road map", then the answer is: There is apparently no road map.
DaveTheCoder d2clon Does the author have a point regarding the use of nonoptimized structures in the core code?
Did you read the github issue I linked? It addresses that.
Fair enough clarification about this point. Cristal clear here.
DaveTheCoder The closest that I'm aware of is the Blog:
https://godotengine.org/blog/
If that doesn't satisfy your definition of "road map",
Well, no, unless there is a specific post about the road map. What is in there are progress notifications and some notes about the immediate future but not a clear long-term route of path and direction.
d2clon Or are we just defensively counterattacking to what is no more than a personal opinion?
It looks to me like a very uninformed, fairly belligerent opinion, which usually prompts me to respond with disdain. The comment about the author fixing everything really made me roll my eyes.
- Uncertain console support
This quote is really all you need to know:
In all, supporting consoles properly is very costly and beyond the possibilities of Godot as a project to do so.
If consoles are really your target, not just a pie-in-the-sky goal, you should probably look elsewhere. Free software cannot, by definition, address that.
Does the author have a point regarding the use of nonoptimized structures in the core code? If so, is this the signal of an un-optimal code review politic, or maybe the lack of experienced developers taking care of code review?
There are other explanations. A data structure might be used because it makes things easier when supporting different platforms.
Or it might be used because no one has actually demonstrated that changing it would make a significant difference. It's easy to say that you should always use this or that, but if you don't show actual tests under realistic conditions, it's just an opinion.
It might even be used because it's a major change, and the people with the most experience are busy fighting fires at the moment, and they don't have time to do something that might cause even more.
You might also consider that these explanations are valid.
Is it true there is no clear road map for the project?
I've never encountered a piece of software that actually stuck to their projected schedule. That includes software with dozens of paid programmers. A road map for a project built by thousands of volunteers with different agendas would be guesswork at best. Anyone could produce that for you.
Godot has a very uncertain future. So what? Unity's not looking all that steady these days either. The difference is, I've got the godot codebase on my computer. If all the godot contributors beamed up to Alpha Centauri tomorrow, I could keep using godot, legally, indefinitely. That calms any trepidations I might have.
...the trend of criticising other engines, and other companies’ strategies, and entire software patterns is… noticeable
In the sense of: "defend our way in an unquestionable way"
That's not how I interpreted the quote, but ok. What "way" do you think we're defending? Free software? It's not a defense to say that this is how volunteer projects work; it's just a statement of fact.
Is it true there is not a clear group of experienced people making the main project decisions? and that is only the leader (Juan) making all the decisions? Is it true the leader is not friendly with delegating?
You could look at the links on the godotengine.org site to answer this, unless you don't believe them. If that's the case, why would you believe anyone here? The project developers don't generally hang out here, so what other information are you hoping for?
The main project decisions are made by people with the authority to accept pull requests to the godot github. Whatever politics may be involved, it really boils down to that. If you make a change and submit a pull request, it might be accepted, even if it never occurred to any of the core developers.
Godot is just a collection of software, and the developers are just people who added to it. The actual software development is not as organized as a company, and you're going to be disappointed if you try to think of it like that.
Is it true that Godot 4 can't be considered production-ready? (it is a personal opinion of course, but we can honestly reflect on this point)
Production ready for what? You've already read people say that 4.1 isn't stable, and you should stick with 3.x. You've heard people say that you'll never make a AAA game with godot. Then again, someone might manage it any day now, for all I know.
The only person whose opinion you should trust on that would be someone who's actually made a popular game of the type you're interested in making, with godot. That's likely to be a small set of people, who probably have better things to do than hang out on the forum.
If I was paranoid and didn't trust your stated motivation, I'd guess that either you were looking for someone to trash godot with you (not likely). Or you were padding your post count (meh). Or you wanted someone to show you a golden road to getting the problems you have with the engine fixed. (As far as I know, it doesn't exist.) Fortunately, I'm not that paranoid.
Is it super wearing to see how we are focusing on what is wrong in the critical thoughts. Cherry-picking sentences that we can nullify and focus only on that ones. It is not my intention to be right in what I say, it was not my intention to say "everything is right" in this article when I shared it here. My intention is: "Is there something here we can reflect on, and learn from?". And focus on this, ignoring the rest, or even expressing our gratitude that someone took so much time writing it and saying: "Hi, thanks for your thoughts, this and this we have been working on it already, on this I don't agree, can you extend?. This other is important and helped us to reflect, we will back to you".
duane If consoles are really your target [...] Free software cannot, by definition, address that.
I am not expecting Godot to have an "export to console" button in-house (for the reasons that have been mentioned). I am just expecting that a project created with Godot can be ported to the consoles, even if it is done by a third-party service, and that there is not any intrinsic technology dependency that makes this impractical. A good answer will be to see examples of Godot 4 projects successfully ported to consoles.
I am reading here, and I am not finding any example of a successful Godot 4 ported game (I see a show case in youtube but don't know if they are Godot 4). I read this though:
That being said, we support console porting for Godot 3 and 4, GDScript or C# (other lang support also possible). We might be even doing a port of a Godot 2 title soon, but we'll see
Also some notes about technical limitations:
You can use compute shaders if you like. All current platforms support it nowadays, but it might not be a good idea on the Switch as it would severely affect performance. This would require further assessment in order not to have problems later.
duane If consoles are really your target, not just a pie-in-the-sky goal, you should probably look elsewhere
I really hope this is not right. It may be, right now, "a pie-in-the-sky goal", but definitely I would love to have once a game in the Switch. And it is possible as shown in the show case above. But a lot of things have changed in Godot 4 and I would like to know if it is still doable in an affordable way, and what are the caveats.
duane You might also consider that these explanations are valid.
I do
duane I've never encountered a piece of software that actually stuck to their projected schedule
My neither (25+ years software architect experience, 8+ years CTO), believe me, I know this by heart. This doesn't undermine the importance of having one.
duane A road map for a project built by thousands of volunteers with different agendas would be guesswork at best
The fact that the project has thousands of volunteers with different agendas makes the importance of having a long-term road map even more important. It may be a guesswork but it makes common objective visible.
duane What "way" do you think we're defending?
The "we are doing everything totally right, God blesses us, and anyone showing a slight critique thought should be expelled when not burned to the ground" way.
duane Godot is just a collection of software, and the developers are just people who added to it. The actual software development is not as organized as a company, and you're going to be disappointed if you try to think of it like that.
I understand this. I am a very satisfied user of many open-source software, including Godot. The fact it is open source doesn't compete with a proper PR review organization. Of course, things can be leaking, it happens in all software projects, but I was curious about the infamous "inexperience-based" data structure decisions. That if they are true, they should be spotted by an experienced developer doing the code review. Again, this has been clarified.
Production ready for what?
We are fooling ourselves if we are ignoring the obvious flaws of Godot 4. We just have to take a look at the change log in 4.x versions.
If I was paranoid and didn't trust your stated motivation, I'd guess that either you were looking for someone to trash godot with you (not likely). Or you were padding your post count (meh). Or you wanted someone to show you a golden road to getting the problems you have with the engine fixed. (As far as I know, it doesn't exist.) Fortunately, I'm not that paranoid
Or you can just have a positive thought about my intention. I am a humble hobbyist (so far) indie developer who is very happy to have found Godot (almost 1 year ago, coming from 2 years with Unity), and who likes it a lot. And who is worried about the orientation may have been leaning towards, and who is interested to know if the community is healthy (humble and self-critique) and has a warm attitude towards newbies and that the decisions and the long-term goal resonates with me.
d2clon Is it super wearing to see how we are focusing on what is wrong in the critical thoughts.
Well, that's how the scientific method works. You post a theory and everyone tries to shoot holes in it. If someone proves you wrong, you go back to the drawing board.
"Is there something here we can reflect on, and learn from?".
I thought that was what we were doing. However, I found the original blog post a bit silly, and I don't apologize for that.
"Hi, thanks for your thoughts, this and this we have been working on it already, on this I don't agree, can you extend?. This other is important and helped us to reflect, we will back to you".
Ok, you may be speaking to the wrong we. The we here on the forums are not necessarily the most prolific project developers. Most of us have helped, but you may be in the wrong place to reach your target audience. I don't think anyone here can speak with that authority.
duane If consoles are really your target, not just a pie-in-the-sky goal, you should probably look elsewhere
I really hope this is not right.
I hope someone can give you proof. I haven't seen any, but hope springs eternal. Regardless, any method you find will have the caveat that you don't own it, unless you develop it yourself. You'll still be at the mercy of a third party which is basing its business on an uncertain model. (Not to mention the console companies.)
The fact that the project has thousands of volunteers with different agendas makes the importance of having a long-term road map even more important. It may be a guesswork but it makes common objective visible.
I don't think you can prove that. I disagree at any rate. There are many examples of successful processes that don't require central organization. I submit that free software has shown this repeatedly. The key difference is that a free project doesn't require a business model to survive.
duane What "way" do you think we're defending?
"we are doing everything totally right, God blesses us, and anyone showing a slight critique thought should be expelled when not burned to the ground" way.
I think you're taking this too personally. If someone I like says something I think is nonsense, I tell them so. That doesn't mean that I've shunned them or attacked them, even metaphorically.
The fact it is open source doesn't compete with a proper PR review organization.
Again, I don't think you can prove this. Lots of ad-hoc software projects have been around for decades. And I'm pretty sure godot has some review process, though probably not what you're thinking.
Production ready for what?
We are fooling ourselves if we are ignoring the obvious flaws of Godot 4. We just have to take a look at the change log in 4.x versions.
You've also probably noticed lots of negative opinions posted here on the forum. Most of us don't shy away from critisizing godot, we just focus on what we think is important, just like you do.
And who is worried about the orientation may have been leaning towards, and who is interested to know if the community is healthy (humble and self-critique) and has a warm attitude towards newbies and that the decisions and the long-term goal resonates with me.
Again, the majority of the posts on the forums are warmly welcoming. That doesn't mean people won't call you out, if you say something they disagree with. I'm not sure there is a long-term goal that everyone in this project can agree with, let alone does agree with.
On the other hand, this is a godot forum, filled with godot enthusiasts. If you state a negative opinion about godot, it stands to reason that more people here will disagree than agree, because they've already made a choice to use godot. You shouldn't take that as any sort of defensiveness, it's just the composition of the community and simple math.
Tomcat But I have a question: in what exactly did you see the value of this trash and why do you propose to discuss it
Language please! And also, try to be more constructive in your response.
DaveTheCoder Instead of talking about "the article", why not pick a specific idea that's in the article and discuss that?
I would like to repeat Dave here in order for this thread to be digestible and constructive.
@d2clon I did read the entire thread (took a while to see everyone's side here). I suspect you might be a bit misunderstood here, and that's probably due to trying to open up a discussion based on an entire pretty long-written article about many topics. If you want this thread to be helpful and productive, then try to break down the different areas to learn from and be solution-oriented. I'm sure that if there are good ideas to improve things, the people behind the engine would love to hear about it as long as it's constructive. Trying to keep a productive discussion about the entire article would probably need a big workshop with everyone included to get anything out of it.
A lack of documentation... I wish one would elaborate. I am incredibly unbiased on game engines, Each one does things differently - some things better, others worse...
With that being said, Godot 4 seems to have made quite a bit of changes compared to Godot 3.x, and I was learning Godot when they were branching from 2.x. I still don't know all the changes in 4.x.
I suppose I could start there.
Starting small, is there a doc that offers changes from 3.x to 4.x?
How are the docs for C# vs GDScript? Is C# as good as an option for 4.x as 3.x or better?
Start small, there's too much content to cover in those paragraphs to answer everything right away.
Nerdzmasterz Starting small, is there a doc that offers changes from 3.x to 4.x?
Dev snapshot: Godot 4.2 dev 5. What’s new
You can review the complete list of changes with our interactive changelog, which contains links to relevant commits and PRs for this and every previous release.
Thanks, although I was referring to changes in GDScript, itself. IE I still have no idea how to make a variable public anymore. (It used to be export var var_name...)
So far, I find GDScript in Godot 4 unusable. Is it harder? IDK, but it would take way too long to have to go through all the docs for it to find every single little change.
Nerdzmasterz I was referring to changes in GDScript, itself.
And how do you even organize the search for small changes? If you have ideas, you are welcome to suggest them. It is quite in demand and maybe someone will be interested in it.
For now, I look through each new version report and look for things that concern me.
Nerdzmasterz Starting small, is there a doc that offers changes from 3.x to 4.x?
This what you are looking for?
https://docs.godotengine.org/en/latest/tutorials/migrating/upgrading_to_godot_4.html
Thank you! That helps a lot! It is true, though - if you change the name of the node type, it's incredibly hard to figure out what it's called.
I'll double check, but I didn't see anything on export var yet. It's crucial as I often need to use variables from one node to another (enemy with X damage on the player, items offering Y health, etc.) Signals even seem different now.
export becomes @export
d2clon or try this one for size:
Ill comment as i see people still pinging me about this issue. Modern godot has fixed most of the issues detailed here, and the architecture has changed enough that the 2 versions are not comparable. Even the tps demo used as the benchmark has changed significantly.
This fork performance upgrades as detailed in posts above were done over the base of godot 3.3, and things have really changed since then. Also the fork is a experimental thing i created for fun so it goes into absurd levels just because i felt like it, like running shadow casting render logic in parallel threads or heavily parallelizing most of the renderer beyond what makes practical sense. It only really works for the TPS demo and its near guaranteed to be bugged for anything else.
That's from the person that originally opened the issue in the first place.
Nerdzmasterz a doc that offers changes from 3.x to 4.x?
In addition to the official migration link posted that Toxe posted, there's an unofficial migration guide that may have additional information:
https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976
Nerdzmasterz I find GDScript in Godot 4 unusable. Is it harder?
GDScript in Godot 4 is an improvement over Godot 3. I've been using it for several small projects. The only challenge is that many API classes/nodes have been renamed, as well as some keywords. The "Search Help" feature that's built into the editor can be very useful. For example, try searching for export.
MikeCL Language please!
I am very apologetic, but I am using a translator and there are two terms for what I wanted to refer to: "trash" and "garbage". As far as I know they are both literary terms. I would be extremely grateful if someone could enlighten me on the difference in their usage and why one of them is undesirable.
And also, try to be more constructive in your response.
I'm trying very hard to be constructive. But it is extremely difficult to do so when the base of the proposed discussion is itself completely unconstructive. The article was even quickly deleted by the author ("garbage collection" is a well-established term in programming), which shows that the "arguments" and "reasoning" contained in it are too unreasonable.
It is a very negative base to work on, I agree... but it's also a mountain that can't be fully examined in a few phrases. I wish, instead, people would just find a section of it and work on that.