Upon hearing about a new service for converting Unity games to Unreal, we fired off a few questions to Pingle Studio’s Eugene Martynenko about how it came about and what can be achieved.
High profile organisations within the games industry shoot themselves in the foot from time to time, but few have so spectacularly blown its own toes off like Unity. With its initially reviled and since revised Runtime Fee policy, Unity has forced developers to question the tools they use for future projects. With its Unity to Unreal Engine Transferring Service, Pingle Studio thinks it’s not too late to reconsider current projects either.
How did Pingle’s Unity to Unreal Engine Transferring Service come about, assuming it wasn’t as a result of Unity’s abortive Runtime Fee announcement back in September?
Eugene Martynenko: In the past, there have been multiple requests from different partners interested in what it would cost to transfer their projects from Unity to Unreal Engine. In general, the answer was that “it will cost the same as development from scratch” because you can’t magically transfer projects from one engine to another – you have to recreate it. But this is not the answer everyone expected, so we decided to investigate how we could reduce the cost of such a process by automatisation and best-practices to propose it as a service for our clients.
What was your reaction when you heard about Unity’s announcement?
EM: When I heard the announcement about changes to Unity’s payment plans, it gave the impression that Unity was having financial trouble and this was their way to increase revenue from users of their engine. Also, that this cost would affect every developer regardless of whether they make services or games. As a developer, I was of course concerned about the potential financial impact of Unity’s payment plan changes on the entire developer community. It seemed like these changes might lead to increased costs for using the engine, which could affect both large studios and indie developers alike. However, as the creator of tools, I thought that this could bring new products to the marketplace and make tools that assist in the transition of existing projects to Unreal Engine popular.
Directly after the announcement from Unity, we definitely saw an increased number of such requests. Another thing that we noticed is that more and more developers of Unity plugins started to adapt them for use with other engines, including Unreal Engine. It would be possible to automate and simplify the transfer of levels, specifically all objects along with their settings, from one engine to another. This would create a more familiar environment for developers and encourage them to make the transition.
How does the Unity to Unreal Engine Transferring Service fundamentally work?
EM: With utilities that help with transitioning to another game engine, it’s not as straightforward as a one-click solution. It’s a 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.