Unity Polyfill - simplifies migration from Unity C# code to Godot

[zhang-z]

Migrating from Unity to Godot is a hot topic recently, due to the well known pricing plan change.

I'm thinking of Unity Polyfill (borrowed the concept from Javascript Polyfill which is is a piece of code used to provide modern functionality on older browsers that do not natively support it).

Here is how a typical Unity C# class looks like:

using UnityEngine;

class CustomClass : MonoBehavior
{
  protected void Update()
  {
    // the logic that runs in every frame
  }
}

Imagine that there is an assembly UnityEngine.Polyfill.dll, which provides a UnityEngine.MonoBehavior class that allows subclasses to behave the same under Godot. That would make the migration of existing Unity projects much simpler.

Of course, achieving complete feature parity takes huge efforts and may not work for some features. But the more the Polyfill covers, the more benefitial it is. Everyone can contribute to it.

If this idea is already discussed anywhere, could any one pls point me the link?

[MeisterDerMagie]

If you think that through, you would have to recreate Unity in Godot. When it comes to simple things like Update() or Start() methods, it is already quite easy to port such scripts.
When it comes to more complex things, the question is which features are adopted and which are not. In the end, it will always be incomplete because Godot is not Unity. It makes much more sense to learn the engine and port Unity projects cleanly instead of building a Frankenstein Unity in Godot.

[zhang-z]

Thanks for sharing your opinion, @MeisterDerMagie .

First, I'm completely new to Godot. It's my first time looking at Godot when Unity announced the pricing plan change. So appreicate whatever knowledge and opinion you shared.

"When it comes to more complex things, the question is which features are adopted and which are not. In the end, it will always be incomplete because Godot is not Unity" -- I totally agree with this statement.

But I'm not sure how true "When it comes to simple things like Update() or Start() methods, it is already quite easy to port such scripts." is. Imagine that there is an existing Unity project needs migrating to Godot, what are the options for code refactoring?

1. Start a new Godot project, rewrite the whole project file by file or feature by feature.
2. Search through existing Unity code, replace MonoBehavior by Node; Awake() by _Ready(); using UnityEngine by using Godot; etc. Rewrite whatever can't be done with simple regex replacement.
3. Create an adaptor MonoBehavior class which inherits from Godot.Node. It invokes base._Ready() in MonoBehavior.Awake(), etc. Also implements common Unity methods like GetComponentInChildren, etc with Godot APIs.

I would defnitely first consider the feasibility of option 3, because option 1 leverage little of the existing Unity project and option 2 is less systematic and more error prone than option 2.

If option 3 is feasible and does save time, it can be shared with other people who have the same migration need. That's my motivation of starting this discussion.

In short, I'm looking for the easiest way to port simple things like Update(), GetComponent, Instantiate(), [SerializeField], etc. I'm not looking for porting features that can't be easily achieved in Godot.

[aXu-AP]

I think option 1 sounds most feasible. Even if you managed to make the project run via simple renames or adaptor class, you likely would get a lot of hard to find bugs due to subtler differences between engines. Finding and fixing those might take even more time than writing everything from scratch. Migrating big projects will be a headache in any case.

[timothyqiu]

I think this could be an addon rather than a built-in feature.

Also, since Unity users can now stay unaffected by the policy change as long as they don't upgrade engine version, I think it would be easier for them to finish their existing projects in Unity, and consider trying other engines for future projects.

[zhang-z]

Yeah, totally agree that this shouldn't be a built-in feature, addon makes more sense.

I'm in the position as you said: finish the current project in Unity, and seriously consider Godot for my next project. Started this discussion just to see whether it's a common need:)

A bit off-topic, what's even more appealing to me (I might do this in my next project) is to split game engine into two parts:

1. Logic engine, which handles things like calculating object positions in every frame, manage game object tree, collision detection, physics, etc.
2. Rendering engine, which handles things like textures, camera, sound, gamepad/keyboard/touch etc.

Benefits of splitting to Logic + Rendering engine:

1. When switching from Unity to Godot, only the rendering part needs to be replaced.
2. More straightforward to make the logic engine deterministic, because the game object positions and collision are controlled. As a result of deterministic, a battle can be Replayable (I like this feature...), also user input can be validated on server.
3. Can leverage Web Aseembly to be the logic engine runtime, which allows people to contribute in different programming languages.

[zhang-z]

Since not many people interested in this idea and some believe it's not feasible, close this discussion