IMPORTANT: Feature freeze for 3.2 will be on Aug 31

[akien-mga]

Important announcement for all Godot contributors: As done for 3.1 (#21490), we'll have an alpha / feature freeze period for Godot 3.2's development, before the beta / release freeze.

I plan to release a first alpha build in coming days, and the feature freeze will happen around that time, a priori on Aug 31.

Once the feature freeze is active, no new feature PRs will be considered for 3.2. Existing PRs from the backlog and with the 3.2 milestone will still be able to be merged until the release freeze, if they are deemed ready and safe enough.

I'd like to have a fast alpha / beta release cycle so that we can release 3.2 as soon as possible and move on to 4.0. So I would ask all contributors to put their focus on bug fixing, as well as reviewing existing PRs, so that we can finalize and stabilize this release in a timely manner.

[akien-mga]

BTW, if you have a feature that you planned for 3.2 and which might not be ready by the deadline, feel free to discuss it with me directly. Depending on the scope and how mature the implementation is we can make exceptions. But the focus should really be on polishing what we already have, release it, and then move on to 4.0 - so big features should likely wait for after 3.2 to be reviewed and merged once the vulkan branch has been merged with master.

[MustaphaRashiduddin]

Does this mean if optional typing for signals isn't completed by Aug 31st it won't be included In 3.2?
Typing For Signals #26045

[Teashrock]

So, a "code freeze" suggested by me will eventually happen?

[TheSHEEEP]

Is significantly improving the NavMesh ( #17885 ) considered a new feature? I hope not.

[Zireael07]

@TheSHEEEP are there any open PRs regarding this? I don't think so...

[TheSHEEEP]

@Zireael07 Not that I know of, but that wasn't really the question. The question was if working on improving the navigation would be considered a new feature (as really, NavMesh/navigation in general requires some serious rework to get up to modern standards) and thus not considered for 3.2.

[akien-mga]

Yes, significant changes to core features would be "new feature" work. That's exactly the kind of thing that should not happen after the feature freeze, unless we want to release 3.2 with those improved features in an unstable state. Any major rework of an existing feature adds a lot of bugs, just like any major new feature comes with its share of bugs.

But anyway Navigation features are planned for 4.0 already with a big rework of the way things are handled, likely breaking compatibility, so it's unlikely that PRs would be merged to further change NavMesh even if they were done today. There have been lots of improvements to NavMesh for 3.2 already though.

[TheSHEEEP]

Yes, significant changes to core features would be "new feature" work.

Thanks for clarifying that.

I get that some of the required improvements to navigation (such as introducing actual agent logic with avoidance, etc.) would likely be so big as to be considered new features.
But there are other things as well, smaller things that wouldn't break compatibility, like being unable to bake navigation meshes at runtime or not supporting dynamic obstacles - some issues as old as 2015 ( #3130 ).
My concern is more that those smaller issues won't even make it to 3.2 with the reasoning that the entire navigation will be reworked anyway - despite a 4.0 release being quite some time away.

[eligt]

@TheSHEEEP feature-freeze and release-freeze are referring exclusively to PRs, i.e. where code has already been written. Issues can't even be considered for this because no one has written the code yet.

I know, it sucks that features that are important to you are being ignored but that's an unfortunate consequence of limited manpower and shifting priorities. If those features are planned to be reworked it further decreases their priority as any work on them would essentially be "wasted".

[TheSHEEEP]

I know, it sucks that features that are important to you are being ignored but that's an unfortunate consequence of limited manpower and shifting priorities.

I don't care so much about that for me. Implementing those smaller features wouldn't even be a week of work for a developer who knows the engine. I might end up making a plugin as a workaround for me as I have with another issue already, so for me it would just be a week of added work or so. And if it ends up being generic enough, I'll put it out there as well.

But a lot of other people have added their +1s and voices to these issues as well, and who knows how many decided to give up on using Godot for 3D projects as the pathfinding is so limited.
Hell, another developer actually even made a PR ( https://github.com/slapin/godot-fork IIRC) including a recast/detour implementation, which afaik was never even reviewed or considered for a merge. And the developer by now has given up on it - which I can't blame him for.

On the other hand, I doubt too many have decided to not use Godot because it doesn't have a Vulkan renderer... yet that's what is being worked on right now. And I'm sure it will be worth it in the end as it will improve rendering as a whole, but what I am not understanding is the prioritization here. When you already have a functioning renderer, but only a barely functioning pathfinding, how is the renderer a higher priority?

As of right now, what is going on for Godot "behind the scenes" is quite a mystery if you do not follow Github very closely or hang out in Discord.

That is definitely an area where more communication would be welcome: An explanation not only for what is being worked on right now (and by whom), but also why, and what is the roadmap going forward (for the core developers, obviously open source projects cannot be fully planned ahead). Basic project management reports, maybe weekly, or at least monthly.
Or take a look at the Haxe roundups where someone gathers weekly news of what's been going on in the entire Haxe ecosphere. That's commendable!

Developers of games do that quite often, too, to keep their users informed. It would be nice if we could have something similar. I'm quite certain I would be a lot less confused if I knew what was actually going on and what the plans are.

I do not intend to come off too negative, it's just my style of communication which is generally very direct.

[Calinou]

@TheSHEEEP The News section on the website also has many "devblog" articles on it. Most of its activity occurs when large new features are being implemented, as the format wouldn't work so well for smaller items unless they're batched together.

[eligt]

@TheSHEEEP Yup I understand your perspective, but at the same time I don't want core developers to be wasting their time writing reports or blog posts, I'd rather them focus on development efforts. I do realize though that it's not your usual open source project, people are actually putting their money in through Patreon, so expecting some level of explanation is justifiable.

Maybe we could have a Github page in the repo for each core (paid) developer and inside they can write a very simple item list of things they're working on and why and then volunteers and non-developers can look at those lists as well as commit messages and expand them out into biweekly blog posts? Just a random idea.

[TheSHEEEP]

The News section on the website also has many "devblog" articles on it. Most of its activity occurs when large new features are being implemented, as the format wouldn't work so well for smaller items unless they're batched together.

That is there and always nice to read, but it does little to nothing to inform normal users of what is happening on a regular schedule, about decisions, plans moving ahead, roadmaps, etc.
Godot users also following Github closely are probably a minority to begin with, and a minority among those knows.

And "batching together" smaller things is exactly what I'd suggest as well.

Yup I understand your perspective, but at the same time I don't want core developers to be wasting their time writing reports or blog posts, I'd rather them focus on development efforts.

I don't think spending half an hour or so per week (at max) to collect what people have been doing and writing a bi-weekly or so report also including what the plans are for the next period is a waste of time.
If you are working for someone on a paid basis, you'd also give them at least a weekly summary of what you've been up to and planning to do. Which would make this a patrons only thing, but I see little reason for keeping that information "private". On the contrary, I think it would add quite a bit of professionality and might actually "lure" a few supporters more.

[eligt]

It would take much longer than half an hour to write a full report, plus it's not so much the time, but stepping away from development to write blog posts is distracting. That's why I proposed the above, where the devs just write a rough list of items and then some volunteer takes on the burden of writing a full blog post using the list of items as well as the commit messages.

[clayjohn]

@TheSHEEEP Reduz already does regular blog posts for the "core" roadmapped stuff see here: https://godotengine.org/article/vulkan-progress-report-2

Other than the work he is doing, nothing is really planned. Things just kind of come together whenever a contributor decides to add them. Nobody gets together and decides on a list of priorities because we are all volunteers who work on what we want. Reduz is the only one who works according to a set roadmap and he is very open about his work, see the blog posts and his twitter account.

edit: Maybe it is worth saying. There is no real "core" developers. There are just a handful of people who choose to contribute more than others. But like everyone else they contribute what they want, when they want to.

[girng]

I do not intend to come off too negative, it's just my style of communication which is generally very direct.

I'm the same way, it's hard to convey tone over the internet too. I try to re-read my posts and remove/edit any kind of ambiguous language that could come off as negative (but if said out loud with tone of voice, it'd be very different). I'm very emotionally invested with Godot and have a stick-in-the-mud and eccentric personality. I have learned throughout the years that the developers really do have the best interest for Godot. And honestly, that alleviates a lot of my concerns, so I don't worry as much.

I'm very excited for 3.2, and can't wait for Vulkan!

[zayngdev]

Agree to put more time on improve the performance of renderer other than enforcement features at current phase, users really care how fast the engine could run, how cool the rendering looks like, how small the app to download, what they can make using Godot. To be honest, AI, path-finding is quite important in game production, the thing is, at the early phase of a growing game engine, producing eye-catching games based games is vital to attract more attentions, it leads to grab more game players and developers. In result, what functionalities and abilities could match that needs should have higher priorities. We all come here to post our thoughts to help godot get better, and expecting the coming 3.2 and future 4.0 give a hit. Peace.

[jahd2602]

@akien-mga Is 3.2 already on feature freeze?

It may be a good idea to announce it in a blog post.

[Toshiwoz]

I think the problem here (referring to what @TheSHEEEP was pointing out) is that most of the games developed for Godot are a few genres, thus, need for improvements in certain areas is not felt as urgent.

As a result, whoever wants to develop something different, say a 3D racing game, or an open world sandbox game (with procedural generated worlds), an RTS, a flight simulator, etc. They have to fix eventual bugs for themselves (so they need to learn C++ or use some workaround), that require extra time, making it harder to develop. As a result it pushes away certain developers.

I mean, I follow quite a lot the issues here, on reddit, and sometimes on the Q&A section, and I can see some ask about raycast improvements, navigation (as mentioned here too), issues with collisions on fast moving objects, CSG bugs.
Yet, just a few of those problems are addressed and fixed.

Anyhow, here I do not mean it's wrong as is it going now, I'd like to see performance improvements in 3D (even if, in my case, I'm more concerned about GLES2, for mobile games is still relevant). But only pointing out what the consequences of keeping this direction may lead to. That, IMHO, will result in being "Godot is a good 2D game engine, for platformers, metroidvanias and similar".

Man, it's hard to manage a game engine, now I can see it. Egoistically I just hope I can finish my game with this engine, not having to wait for Godot 5.0 or so (I won't switch to any other gamengine).

[akien-mga]

Now moving to beta and release freeze, see #33389.