已关闭。此问题为opinion-based。当前不接受答案。
**想要改进此问题吗？**请更新此问题，以便editing this post可以用事实和引文来回答。
4天前关闭。
Improve this question
我正在Unity中重新实现一个游戏，但我希望处理游戏资源的大部分代码与引擎无关，这样就可以轻松地将工具放入一个新的C#项目中来修改游戏，排除所有Unity特定的代码。
为了实现这一点，我使用了一些单例来处理某些事情的实现。例如，当加载一个PNG纹理时，引擎不可知代码调用一个纹理工厂单例，该单例包含Unity-specific PNG加载代码。
现在的问题是，我即将开始加载模型，这通常会涉及Unity的Vector 3、Mesh等类，但由于我想成为引擎不可知论者，我必须对这些类或某种编组使用某种抽象。
例如，用Vector 3做这件事的明显方法是创建一个新的Vector 3类，类似于Unity的Vector 3，然后简单地将它们转换成Unity的Vector 3，方法是用相同的XYZ值一个接一个地创建Unity版本，问题是我将有大量的这些数组，所以这听起来效率很低。
我已经在Color 32/Color的纹理生成代码中尝试过了，它太慢了，所以我一直在寻找解决方案。
我曾经想过只使用一个工厂单例来创建UnityEngine Vector 3类，并使引擎不可知代码只期望“对象”类型，而不是任何特定类型，但我觉得这太混乱了，难以处理。不过，这可能是性能方面的最佳解决方案。
非常感谢您的建议！
1条答案
按热度按时间ovfsdjhp1#
你不会喜欢我的答案的：* 别这么做 *
只需要用Unity-specific代码编写就可以了。不要指望复制粘贴，也不要创建20层来创建某种神奇的抽象转换机制。不管是什么语言，这都是一个严重的设计缺陷。首先，让我们考虑一下从一个C#转换到“UnityC #”（这里有一些讨论，但我不会深入讨论，因为它现在不相关）。Unity有不同的代码设计和架构范例和概念。它们略有不同，比如说，网络应用程序、服务器中间件代码，甚至是桌面C#程序。即使你可以制作 Package 器，背后的工作也会很困难，不仅要“翻译”，还要将一种范式与另一种范式匹配。这就像为DOS编写C，然后在Windows 11中制作一个层。当然，这是同一种语言，但概念不同（我在这里不提OS API）。
现在，假设你有一个C游戏。如果你切换到C#（例如使用中间库），那么，假设你想在10年后再次转向C。现在的C标准与C99有很大的不同，以至于那些在这25年里休息过的人可能会认为它是一种新的语言或扩展。如果你真的想转向UnrealEngine，会发生什么？你会把覆盖旧代码的C#覆盖起来吗？
最后，听起来这就是你最终的结局：在旧代码上的视频类和在Unity代码上的视频类，然后是一个翻译层，同样的图形，音频，数学...最后它几乎就像一个新的引擎。
除了可能出现的编码错误之外，想象一下对它进行维护。而且不是由你来维护，而是由一个团队来维护。一个新的团队（如果有人离开，你会得到新的成员）。这里面有太多的因素，以至于整个工作都是不合理的。
迁移是最好的解决方案，只需编写接近本机的代码即可（从引擎的Angular 来看--这里我不是指asm或诸如此类的东西，我的意思是，与引擎期望的一样，而不是一些神奇的 Package 器或抽象层）。（因为相信我，加一，二，500层的一些神奇的代码将增加内存开销，甚至可能增加CPU开销），您甚至可能会发现一些代码可以简化。代码解决方案，可以减少代码。甚至资产（付费或免费），功能扩展的实用程序，插件或共同的代码助手。
P.S.你可能会听到一些疯狂的变通方法，比如用C或C编写，然后添加一个单独的绑定库，该库可以与任何语言接口，然后你可以做这个和那个...也不要。如果这是你所处的情况，想象一下你有自己的分配器/释放器，自己的内存管理器，如果你有一些可变/不可变/原子代码，可能还有一个线程管理器，也许是一些用于多线程的互斥量/信号量，所有这些都会与C#管理器和Unity管理器冲突。虽然在Unity游戏中大部分C#“魔法”都是由框架处理的，但实际上，所有Unity类都是由引擎处理的，它是C并且有它自己的规则。当你可能找到这个的变通方法或者它可能不是一个问题时，随着项目的增长和扩展，你可能会有一些惊喜。太多的依赖会增加问题。