[cycloptic]

I am not saying it would be easy, it would definitely be work that someone would have to do. I'm more saying that the Godot authors would not try to threaten you or consider you a threat, it's more likely they would want to help you. Of course as a business you would not do it if your customers weren't going to pay the cost to make it worth it.

I don't know enough about the implementation of C# and Swift to say for sure, but it does seem like the open sourcing of that would making it easier to do things like port some standard library component or algorithm over from one to the other, or perhaps do something like building a Swift implementation for the CLR.

[vvanders]

Let me try to be a bit more to the point, game engine features are not just "drop-in", by adding a feature to one part of the engine there's a high probability that you make another part of the engine worse.

There's a reason that they say performance is the most leaky abstraction.

[cycloptic]

Then that sounds like you would want it to be an optional plugin, or a compile time flag that could be enabled for customers who want it? Why not do it, if that's what the customers asked for?

I get what you are saying and it definitely applies to the core architecture of the product, but if you have a large number of customers each with their own needs then I would be surprised if there were zero parts of the product that were modular or interchangeable.

[PoignardAzur]

> then I would be surprised if there were zero parts of the product that were modular or interchangeable.

You'd be surprised. Game engines are extremely monolithic.

There are some modular components and techniques (eg pathfinding, rendering, physics engine), but most of the effort that goes into an engine like Godot is integrating these components to their specific architecture. While the component is transferable (eg you can always use the Bullet engine in your own project), the integration work isn't.