Put templates on the forefront

[theraot]

Godot already has the concept of templates. But they are aside, on a second tab on the project manager called Asset Library Projects… So a beginner might miss that and go for New Project - also, this is what most tutorials will tell you to do - and the Create New Project dialog does not mention templates.

Thus, I believe, asking the user what template to use should be part of the New Project dialog. Consider for reference the process of creating a new project in Visual Studio which will show templates for different languages, types of projects and platforms. Similarly Unity and Unreal show a small set of templates when creating a new project, including blank.

To be clear, I don't think there is anything wrong with the Asset Library Projects tab. And I believe there is no need to remove it. In fact, if templates were to be added to the New Project dialog as I'm suggesting, that does not mean demo projects should be in New Project too… They can remain in the Asset Library Projects tab.

With more relevance, templates can alleviate the desire to have in core features that could be provided by addons. Because templates would become a way to discover said addons, and also a way to promote said addons. And I would encourage addon developers to make project assets or templates assets to provide examples of their addons, instead of including examples in the addon. But that is another discussion: #4761 (comment)

In particular: a very common request is a 3D terrain editor (e.g #4052 (comment)), which I understand. But I also believe that should be done with addons. Well, we could have templates that come with sets of addons. Then templates for 2D games won't have the 3D terrain editor addon (but the user could still install it afterwards if they want to), but templates for 3D could include it. Addendum: I'm not saying that templates replace a terrain editor. I'm saying putting templates on the Create New Project dialog would surface existing, and to be created, solutions.

By the way, the search of templates could use tags/labels. For the case above 2D or 3D. But also for which languages they use, GDScript or C# or something else.

And of course, templates and addons can be either official or community maintained.

---

Addendum: I found a proposal: #3029 (comment)

[bitbrain]

I absolutely support this idea.

A good trade-off could also be to show some sort of check box "remember my selection" or "do not show again" for people who do not care about templates, in case there are reservations about constantly showing a dialog more advanced users won't necessarily care about. Additionally, as part of this dialog, users could maybe even select "popular add-ons" to get started as part of that same dialog. One good example of this in the Java world is Spring Initializr which offers similar capabilities and when starting a new project, users compose their project to their liking before proceeding to actually start using it.

[JoNax97]

I don't think it would be enough of an issue to warrant an opt-out

[ghost]

In particular: a very common request is a 3D terrain editor (e.g https://github.com/godotengine/godot-proposals/discussions/4052#discussion-3890610), which I understand. But I also believe that should be done with addons....

Just a small point 😄
A "terrain editor" is way more than just a simple brush to make mountains, similar to how tilemap is more than just painting tiles (involves performance, rendering, etc).

A Terrain editor involves the whole workflow of a game: chunk creation, terrain, texturing, foliage, performance, rendering, etc.
It's not something that can be simply resolved by a addon or extension, it's need to have a consistent workflow and more important: be maintained.

I wish the devs would understand that, It's make me sad see this part so neglected 😢

[dustin-hitzing]

I do not believe that moving something that is so core to 3d game development out to an add on is a good idea. Terrain AND 3d level editing tools are important to a workflow both for AAA and indie devs. For myself and others I’ve talked to they can create much of their finished assets in Unity/unreal quickly and easily and then only have to bring in an asset pack or create custom models in a 3d program for set dressing. 3d level editing tools should be core to the engine. That being said I do agree that having a template up front could be useful. However I cannot stress enough that this is not a replacement for a very good terrain and level and texture editing tool built into the engine in a similar way to the new tile map

[theraot]

The performance and rendering improvements should be in core. To that I agree. But those aren't editors. If extensions can't make editors, we would need to improve the extension system… However, for what I have seen they can. Yes foliage, yes terrain, yes texture painting.

I'd agree with you on that I don't understand. But you seem to want something beyond editors: A consisten workflow… I don't think there is one way to prototype a level. We could prototype by adding pieces, or with CSG nodes, or yes, painting terrain. To reiterate, I don't understand. It sounds to me you want to remove flexibility.

Addendum: My personal interest is in procedural generation. You can take that as a bias against - and lack of interest in - editors from my part.

However, yes, editors can be included with Godot, and they don't have to affect the game build size by being only in tool builds. On a similar note, we have GridMap that needs improvements. Yes, these features need maintainers. My impression is that Godot developers are too busy to maintain it. Let the community get on it.

@Zylann - What is your take on this?

[Zylann]

It's possible to do terrain as plugin, but then Godot still has progress to make for extensibility. There has been issues with systems like navigation and GI baking, which had hardcoded paths in the engine itself for "nodes-that-are-not-just-a-mesh" like GridMap. And in the past it required to expose heightmap colliders (so add a new kind of shape to the physics engine) for those to work. There is likely more areas affected like custom culling or different rendering techniques which are unique to terrains, mainly because they are one continuous thing covering a large portion of the world, rather than being one bigass mesh. There are tooling issues as well, such as being able to extend some import systems and manage terrain materials, which use different kinds of shaders, packed texture arrays... I needed to extend texture import, and had to rewrite the entire core importer in GDScript just to insert a small feature on top of it. Generated assets also need re-importing but there isn't a function to do that by code. Some of this just needs work in Godot, but it's not always trivial.

For the argument of making it core instead, it's good if it's maintained and works good enough for most users, while not blowing up engine size to much (I know some people don't care tho). But as always, it can't fit everyone's needs, just like every node in the engine. It's not an argument for it not to be core IMO, but the door may remain open for external, different systems. I'm actually one who thinks GridMap should be an official addon. Not just because I havent seen many games use it (at least personally I dont), but because I'm nasty: it would force core devs to maintain a module as a GDExtension instead of in-engine, in turn making GDExtension more tested and worthwile. Things only get better when used and worked on.

[ghost]

"...It sounds to me you want to remove flexibility...."

My guess is that you have not tried to make a more organic terrain, maybe a huge map that needs to be loaded in chunks with foliage. 😄

It's not a question of different prototype techniques or limit choice (?), they are different techniques that solves different problems.

Yes you can use the 3D Mesh Nodes, CSG or Blender to prototype or make the whole game.
They work well for games with more flat terrains and interiors...
But you not gonna use that to make a organic detailed terrain or import a 40 km mesh terrain from blender...

The Developers are awesome people and of course they are busy... I LOVE Godot and use since 2.x.
But unfortunately, these things are completely missing for years, and they don't seen to be a priority. 😢

[theraot]

I think I understand better now. You don't want everybody doing it the same way - which how "consistent workflow" sounds to me - you want confidence that it will continue to be supported. So the issue is not really if it is in core or an extension, but if it is official or not.

And no, I have not done large natural landscapes. The closest I've done is experimenting with an infinite ocean with procedural waves, the approach being similar to that on this video: https://www.youtube.com/watch?v=rcsIMlet7Fw

I understand that people would find it harder to trust a third party extension in the long term. The factors I see are that they have little visibility - which the idea of templates in the new project dialog addresses - and there is virtually no profit in making them without an asset store - as opposed to asset library.

With that said, the idea of moving features to official extensions is out there, for example see #3286 - if Godot goes that way, the terrain system could be another official extension, and tilemaps and gridmaps could also be moved out of core. And that would create doogfooding for the extension system and help it improve, like Zylann was saying above.

On the flip side, Godot already has the means to remove features to optimize the build. I found a related proposal: #1001 - I remember @reduz twitted something along those lines: https://twitter.com/reduzio/status/1547518742560706561

I'm going to count an asset store, and the easier means to rebuild the templates as part of the things that would help Godot increase appeal.