As the title suggest, it may be wise to create a mapping of Unity's scripting API to facilitate conversion from Unity to other engines.
This would unfortunately require scraping Unity's documentation since there is no download available, however this would significantly reduce the amount of tokens necessary and would improve conversion accuracy.
Mappings would need to be curated, either manually (higher accuracy) or via GPT-3, having it create the mappings once and save those to file.
Pros:
Higher accuracy during conversion
Easily expandable
Compatible with any number of engines.
Cons:
Requires curating of the mappings
May need frequent updates depending on the target engine's API changes
In my opinion, this is worth exploring as it reduces token count and improves the results.
<Unity class>:
eq:
<Some Class>
<Some Other Class>
fn:
<Some Function>:
eq:
<Some Class: Some function>
<Some Class: Some Other Function>
This formatting is everything but perfect, however it should get the point across. Classes may get mapped to one or more equivalent. Ideally there would be a one-to-one mapping, but that may not always be possible which is why I suggest having the option of having multiple potential mappings. Mapping functions instead of classes may also be viable as they would be considerably more accurate but may not always result in a match.
This is just a proposal and I would love to hear your opinion about it.
As the title suggest, it may be wise to create a mapping of Unity's scripting API to facilitate conversion from Unity to other engines. This would unfortunately require scraping Unity's documentation since there is no download available, however this would significantly reduce the amount of tokens necessary and would improve conversion accuracy.
Mappings would need to be curated, either manually (higher accuracy) or via GPT-3, having it create the mappings once and save those to file.
Pros:
In my opinion, this is worth exploring as it reduces token count and improves the results.
Suggested file hierarchy:
Potential mapping formatting:
This formatting is everything but perfect, however it should get the point across. Classes may get mapped to one or more equivalent. Ideally there would be a one-to-one mapping, but that may not always be possible which is why I suggest having the option of having multiple potential mappings. Mapping functions instead of classes may also be viable as they would be considerably more accurate but may not always result in a match.
This is just a proposal and I would love to hear your opinion about it.