Develop an open exchange format for Game Engines

[RustoMCSpit]

Describe the project you are working on

A project being transferred between engines

Describe the problem or limitation you are having in your project

Incompatible formats

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

An open exchange format developed by Godot which can be adopted by other engines, especially open source engines

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

https://github.com/bitwig/dawproject

It would be akin to Bitwig's dawproject except for engines

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

No

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

No, it's an essential feature

[Zireael07]

insert xkcd about fourteen formats now being fifteen

[AThousandShips]

Game engines are inherently going to be different, with different design philosophies and architectures

There are exchange formats for various things, like gltf/glb for scenes

But beyond basic ideas for 3D scene geometry you aren't going to have uniformity, anything involving UI will be very different

But the most important part is anything involving game logic, which isn't going to translate, ever, without something far beyond a format, it'd require a standard involving scripting, API, UI systems, etc., etc.

You can't solve these things with a format, you need standardisation

Making a format without that will not really save you any real amount of work, you'd still have to remake most of the project anyway

I don't believe it's realistic to have a situation where switching engines is not a huge hurdle, one caused by unresolvable issues in one engine forcing you to switch, and I don't see the logic in trying to make a format to handle an extreme situation

People just don't switch engines casually

[Mickeon]

I'm very confused. This is a very dry proposal. Godot makes use of a good amount of formats for various purposes.

For example, Resource (.res/.tres) and Scene (.scn/.tres) formats. That's two file formats unique to Godot. As I have heard, old Godot versions used to store Packed Scenes as XML (a commonly adopted format). However, that was extremely painful to work with for various reasons.

Now, it's up to other tools to support Godot's formats if they desire, instead.

Again, this proposal is puzzling and it's difficult to even come up with anything to say.

[AThousandShips]

Also maintaining our own, "in house" formats is enough work when we just have to consider the specific needs of Godot, maintaining, developing, and managing a format for more general purpose is a lot of work, it involves a lot of discussions and surveys and projects and all kinds of things

So someone creating a format and wanting to integrate it into Godot might be interesting, but could most likely be a plugin and not core, but having it be developed and maintained by the Godot project feels out of scope

Also generally these formats are formats you use in addition to formats you use internally, for the same reasons

Edit: the expression "jack of all trades, master of none" is very applicable here IMO, a format that aims to work with many engines that aren't designed the same will work poorly for all, because all have to translate and adjust it to suit their engine, not being able to use their own specific systems to the fullest

The primary point of that being:
This is something that'd be best to develop externally, perhaps with guidance from experience in the Godot project, but it isn't something Godot should use to replace any format already used, or something that should be a major focus as it's a lot of work, and with very little direct benefit, even if executed well

---

A project being transferred between engines

Also, out of curiosity, what open source engine are you moving from if I may ask? Or are you leaving some proprietary engine? If it's the latter I highly doubt they would adopt such an open format, at least I wouldn't if I was heading a proprietary project, it'd be a bad economic decision to make it easier for people to move away from my product (not to mention it'd take years and years if they did adopt it)

[Calinou]

Moving to discussion, as there is no concrete technical implementation provided.