Godot: What are Godot's intended software bounds?

[willnationsdev]

Godot version:
Godot 3.x

Issue description:
Just a discussion topic. What sorts of feature limitations do we intend to apply to the Godot Engine?
We have some impressive audio editing tools. What about tools to edit other media? Are there limits to what Godot will integrate in this regard?

At what point are we going to say, "Ok, this feature isn't something that will be incorporated directly into the engine, so don't even bother implementing it. You can make a plugin for it or you can just make it using Dedicated Application X instead."? Do we have any guidelines to help give people a sense for what should and shouldn't be developed for a pull request?

[vnen]

We have some impressive audio editing tools.

Not really, we can't slice and bounce audio tracks, for instance. It has no encoding capability. There's only buses for audio targets (also limited in comparison with audio editor tools) and a set of standard effects.

Godot is for making games, but not assets for games. We can't create images or models or music inside Godot's interface. Trying to accomplish that would only spread the engine thin, making it poor for game creation and for asset creation.

For game-related stuff, if it applies to a bunch of game genres, it could be incorporated. If it applies to a specific genre, it'll probably be better to be offered as an external plugin.

Disclaimer: this is just _my_ opinion. I can't speak alone about the future of Godot.

[willnationsdev]

@vnen I kinda got the sense that this would be the case. If others feel the same way, then maybe we should make a modification to the CONTRIBUTING.md file that says as much regarding PRs? As far as I know, the bulleted list of reasons to make a PR doesn't include guidelines for functionality outside of "this functionality is desired". I mean, it would obviously be useful to have asset creation or more powerful asset editing functionality, but we should probably provide a point that explicitly encourages that those be built into plugins of some sort.

[vnen]

Usually this is stated if someone opens a feature proposal ticket, but making it more clear is not a bad thing.

[vnen]

For instance, an "inventory system" is too game-specific, each game has its own needs for such system (it can be limited by weight or by amount, maybe it needs to be rearranged to fit like Resident Evil 4, etc.). It's impossible to provide one with Godot that will serve many games.

However, if someone comes and says "I need feature X on ItemList so I can make the inventory for my game", then this feature can be considered. If it's not a corner case, it can certainly be added.

[NathanWarden]

The answer to whether a feature should be added is "it depends" :)

I think the line is typically drawn where a feature would be useful for a wide variety of games, not diminishing features for other games in the process, or is absolutely necessary for even a small amount of games where making a feature in your game is simply impossible with scripting or a custom module.

Just as @vnen mentioned, an inventory system wouldn't make sense because not everyone wants to draw their inventory the same, some games would need different categories, some items need to be consumable, some should not be consumable, some equipable, some items would work passively while others actively, some items should display how many you have and others should always only ever be a single item and never draw how many you have while others should say "x1" or "1" since you can get more etc, etc, etc. It would also need to be flexible enough to incorporate features that were impossible to have been considered in the first place when designing such a system.

All of the overhead for the person who wants all of these inventory features would also have to be in the game of the person who just needs a list of consumable items. This simply doesn't make sense.

So, the goal is to have a flexible GUI system that allows the developer to make their own inventory system as quickly and painlessly as possible where they can include whichever features they want for it.

There are a few corner cases where it makes sense to have the feature.

For instance, I won't link to it here, but there's a thread here for compiling Godot with double precision floats. This doesn't make sense for most games and actually causes a 2x performance degradation anywhere where SIMD instructions are used. This would only be useful for games that have large play areas, IE. space games with planetary/astronomical scales. These types of games are somewhat rare, but when you need it you really need it. Granted, you'll likely have to compile Godot yourself, but it makes sense to have it as an option.

So, this makes sense because in some cases you need everything in your game to have double precision, which you can't simply script in since it's an internal engine precision issue. You can workaround this issue (with something C#), but it's more of a hack than a solid solution.

[puppetmaster-]

I would like to be able to read and modify text files within the editor. (json, cfg, plugin files)
I don't know if this has been discussed before, but I find it awkward to change the editor for such banal things.

[vnen]

@puppetmaster- #1390

[puppetmaster-]

@vnen Very old wish :)
I didn't think it was that complicated.

[akien-mga]

Closing as the discussion is stale.

But to answer the original question: Godot's purpose is to make games, and its features should be those needed to make games by a significant proportion of game developers, and not already well supplied by thirdparty open source tools (so the example in OP of video editing is clearly out of scope - at least for the foreseeable future).

There are many non-game applications made with Godot, and we do our best to support the use case, but it's not the main target.