complex process that takes time and some aspects will still require manual handling. Additionally, what’s automatically transferred needs to be thoroughly verified. The process typically starts with an analysis of the core parts of the
project, such as code, base classes, and a portion of the game logic. An investigation is conducted to identify which plugins and project implementations used in Unity can be omitted since they are already available in Unreal Engine from the box or have analog. Next, game content is exported and moved while preserving the folder structure. Most of this is done manually. Then comes the utility phase. Materials in Unity are coded, while
in Unreal Engine they are created in a node-graph editor. However, for several years now, Unity has had similar implementations that are widely used. In such cases, automation will be much easier. Partial automation can also be applied to transform prefabs into Blueprints and transfer game levels and other in-game assets, like particle systems. The most substantial work remains with the game logic itself.
Depending on the workload and the project’s architecture, different approaches can be taken. An option can be to leave the C# code and simply integrate it. However, I don’t think it will be too difficult to rewrite everything, as working with Unreal Engine’s codebase may not be as challenging as it initially appears. Regarding how the tools work, in Unreal Engine you can easily
copy anything from the viewport and paste it into a notepad when converting objects into a textual format. Similarly, in Unity, you can process any information and present it in the required format. This is typically what utilities do: they traverse the selected content in one engine, save it in a neutral format, and then, in the other engine, open and convert this data into the corresponding content format of that engine. This is precisely how we handled the transition for Life is Strange, when we converted it from Unreal Engine 3 to Unreal Engine 4 and performed data conversions between Unity and Unreal Engine.
Teams that have Unity projects at an advanced state might argue that it’s too late to switch to Unreal. How would you convince them that it’s not? EM: Indeed, if the project is at an advanced stage, it is very difficult to transfer it to another engine, because the Unity ecosystem, although hypothetically similar to Unreal Engine, is still different. I also want to note that the complexity of transferring the project depends on its specifics and the technologies used in it. Additionally, it means that the team has good experience in Unity but don’t have such experience in Unreal Engine. It’s essential to consider that this will take time
and a team effort. As I mentioned, not everything can be transferred automatically; a lot of manual work remains. Additionally, it will be very hard (nearly impossible) to preserve the visual style entirely for some projects; the images will be different with straight-forward transition. Additional engine and render modifications and a team of rendering specialists may be required. And it’s a big plus that Unreal Engine has open-source code for everyone, so you may modify it as you need - and we have such experience. Therefore, I would recommend carefully weighing the pros and
cons first and understanding if it’s genuinely necessary. If there’s a need for it, it’s possible. It’s never too late, and the sooner you start, the sooner you’ll see results. However, once again, it’s not magic, and it won’t happen in just a few days. You can emphasise that
during the transition, you have the opportunity to rewrite certain components, address long standing issues, and eliminate technical debt, which is a long-term project advantage.
What are the current limitations? EM: As I mentioned before, not everything can be transferred automatically. Additionally, not all projects are the same because Unity provides complete freedom to developers. Therefore, even with data that is automatically transferred, caution should be exercised, and there may be a need for tool refinement.
For those eager to move on from Unity as soon as possible, what are the costs of using the Unity to Unreal Engine Transferring Service? EM: It depends on the project that needs to be transferred. We precisely investigate each project and prepare a custom proposal according to its complexity and stage of development. In this case, it can be said that the sooner it is started, the less resources are needed to transfer the project and also the overall process will be easier.
What level of support do you offer teams? EM: We are not providing a tool “as-is” because as we described before it’s not a “magic wand” that will transfer the game in one click. Instead, we propose a full-cycle service from start to the end, supporting our partners during each stage and all the way until after the game is released.
How will you be further developing the service? EM: We will extend the toolset by updating it in terms of new engine versions and by automatisation of common cases that we have seen in multiple projects. So with each such project, the next one will be done faster and easier.
October/November 2023 MCV/DEVELOP | 25
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60
