The black art of platform conversion: How to get your technical assessment right

Adaptations are sometimes considered an afterthought, or simple by-products of the original SKU. Modern game engines market themselves as being 100% cross-platform and instill this false idea of an adaptation just being a flip of the switch.

Furthermore, for every great adaptation out there, there are a few not-so-great adaptations right around the corner. This often leads to adaptations being generally met with skepticism or even negative connotation.

These are just some of the many misconceptions in the industry surrounding adaptations. If done right, and given the proper care and attention, adaptations can become excellent products that can even surpass the original games in sales and review scores. This series of articles aims to demystify what makes a great adaptation by offering insights into our processes, considerations, and solutions, along with examples and stories from the "Abstraction Vault."

"If done right, adaptations can become excellent products that can even surpass the original games in sales"

Let's first start by explaining what we mean by an adaptation and how it is different from a port. A simple port or platform conversion is only part of the process; whereas an adaptation is a version of the game tailored to and fine-tuned for a new platform that plays and feels as if the developers of the original game had designed it with this platform in mind from the get-go. Ironically, this is rarely the case, which causes all kinds of issues that we will describe in these articles.

Adaptations leverage all platform-specific software and hardware features that fans of a platform expect, and offer an experience that is enjoyed and rated equal to -or ideally greater than- the original game. A port, on the other hand, is simply the game technically running on the new platform. The port is the midway part of the race; the full adaptation is the finish line.

Speaking of process, let's outline the individual stages that make up the process of crafting an adaptation. We typically identify the following stages in chronological order:

1. Assessment
2. Straightforward port
3. Tailored build
4. Release candidate
5. Gold master
6. Post launch support and maintenance

These stages also serve as the basis for our milestone definitions, goals and deliverables. In this series of articles, we will dive into each one of these and explore them in more detail. Today we will be looking at where this whole process starts, with a little thing called an "assessment". We will go through the logical steps of what goes into a technical assessment (in contrast to let's say a design or art assessment), and identify step by step the areas that our coders focus on when diving into a new proposal.

Assessment

This stage is where the work begins, even before the potentially commissioned (paid) work has officially started. When we receive a so-called Request for Proposal (RFP) from the client, we first sign a Mutual Non-Disclosure Agreement and request access to the game's source code and assets (textures, animation, sounds samples, and so on). Once that is available, we start looking at the nuts and bolts of it, and start crunching the numbers.

Sometimes source code is not available, which can happen because the potential client doesn't want to share the source code so early in the RFP process, or because it simply no longer exists. Naturally, assessments carried out without source code can only yield rough ballpark estimations and could in extreme cases turn out to be off by an order of magnitude!

An assessment is carried out by a small team of two to four programmers as well as a producer and any art, design, or QA leads, depending on project needs. The whole process takes about two weeks. We typically start with a kick-off meeting where we discuss all the ins and outs of the RFP, identify the biggest risks and challenges and collect any questions that may come up, which we then communicate back to the client.

After that, each discipline departs on its own fact-finding mission, and syncs up with the rest at regular intervals, with a final session at the end where we go over the findings and estimations. From that, we derive the project planning and milestones, based on the estimations and amount of FTE (Full-time Employees) that can work on any given task in parallel. Finally, we generate a quote with all the relevant data including the milestones with their payment instalments; a process we've been able to progressively automate over the years while gathering more and more data to derive patterns from.

Let's take a look at some of the technical considerations that go into an assessment as they often come with risks involved, and have a significant impact on the scope of the project. We will break things up into eight main sections, and explain what goes into each one in detail.

Table of contents:

1. Source and target platforms

We can roughly divide the most relevant platforms in several categories:

An adaptation going to a more powerful platform category in this list is a lot less risky than the other way around. However, going up the chain also means adding features and increased visual fidelity as players on those platforms expect more out of their game.

2. Technology

• 2.1. Engine

Considering technology is always important in assessing a project, there is a big difference in doing an adaptation for a project that runs on an engine that already supports the target platform and for one that doesn't. However, even if the platform is supported, there is still a lot of work that needs to be done. Engine support can certainly simplify a straightforward port, but the amount of work needed for tailoring to the new platform and getting the title through certification remains the same.

On top of that, even if the platform is technically supported by the engine, the engine version used for the original game is often outdated, and needs to be updated, which requires merging the source code. This can be tricky, particularly if the engine was heavily modified by the developers in the original game.

Based on the engine used in the original title, we can identify several different types of straightforward ports. These will be explored in more detail when we look into straightforward ports in the future.

• 2.2. Programming language

There are many different programming languages used in building games. Most modern games are written in C++ and sometimes support another scripting language (like Lua) to aid in gameplay development. Unreal Engine replaced its scripting language UnrealScript with Blueprints visual scripting and C++. Unity Engine games are typically written in C# and sometimes in C++ when changes to the engine itself are required. In older games we typically encounter C or assembly code, or a mix of both. There are a lot more languages like D, Objective-C, Swift and Kotlin, but such cases are outliers.

What is most important is identifying if the target platform toolchain supports -- or even allows -- building a game using the same programming language, or if translation is needed. Even if the language is compatible, the version of the source code and "flavor" it was written in for the original compiler can hide many tricky problems for modern compilers to solve.

• 2.3. Code quality

Apart from the language the game was written in, we also evaluate the quality of the code.

The things we usually look at include:

• Is there a good balance and separation between the engine and game code?
• Does the engine code already support some form of platform abstraction?
• Are both the engine and game code nicely refactored, or is there are lot of code duplication? (spaghetti Blueprints! See image below)
• Is the project well maintained and easy to build and extend?

• 2.4. Architecture

Legacy games are even tricker since, apart from programming languages that may no longer be supported, other factors need to be considered. Games that were built for 32 or even 16-bit architectures need to be carefully upgraded to 64-bit to support most modern platforms. This can be very tricky, and we'll explore this in more detail when we look into straightforward ports.

Other things to consider here are the endianness of the architecture and whether custom hardware was utilized. For instance, when porting from PS3 to PS4, one needs to account for the change in endianness and potentially rewrite highly specialized Cell Broadband Engine SPU code.

• 2.5. Graphics API

There are many different graphics APIs out there, with the DirectX family (9, 10, 11 and 12), OpenGL, Vulkan and Metal being the most common. Then there are also proprietary graphics APIs provided by first parties and built specifically for a particular console. Sometimes these are variations of the mainstream ones, but they are usually very different as they usually are more low-level and specific to dedicated console hardware.

Occasionally, consoles also support more high-level APIs, like OpenGL, but this comes at a performance cost and is best avoided. When assessing the work for porting from one API to another, we need to take their differences into account. "Are we going from a higher-level API to a lower level one?", "are the graphical concepts used in the game even supported by the new API, or do we need to rewrite parts from the ground up?" These are some of the questions that we try and answer during the assessment phase.

• 2.6. Shader language

Just like with the graphics APIs, there are also many different shader languages. There are tools out there to aid in the conversion between these languages, but such tools are usually not perfect. This is something to consider carefully, especially when a game uses thousands of shaders.

3. Performance and size

It is always useful to profile the performance and analyze the packaged content of the title. Sometimes performance captures of heavy end-game situations are provided to us by the client, but most of the time we make these captures ourselves. Some questions we try to answer by doing this are: "how well does it run?" "Is the game GPU or CPU bound?" "What are the most "expensive" features?" "How much memory and disk space are used?" Answers to these are especially important for titles that are being adapted to lower-end platforms.

Next to performance we also take a look at the runtime memory levels of the title, as games often use more memory than what's available on the target platform. Having an idea about the memory usage and its layout at different stages while running the game, allows us to account for memory optimizations in the assessment.

"Loading times are also important to measure, as a lot of platforms have requirements for how long a loading screen can take"

Loading times are also important to measure, as a lot of platforms have requirements for how long a loading screen can take. There are also different storage characteristics to be considered that can affect loading performance. Different platforms also have different requirements regarding the amount of storage that can be used by a title which can differ depending on the media that the title will be released on.

Based on all this profiling, we assess what can be done to improve the performance in the identified problem areas. This ranges from optimizing the associated code and shaders, to modifying assets. For asset modification, we take a closer look at the quality of the assets and also the LOD ("Level of Detail").

Even post-launch scenarios have to be looked at during the assessment because some platforms have strict limitations on their patching system which need to be accounted for if the title is scheduled to get content updates later on.

We will dive into several performance problems and the solutions we found when we discuss "Release Candidates" in a following article.

4. Middleware

Games often use a lot of middleware and for various purposes. Generic audio and video plugins are very common, but both Unity and UE4 have specific plugins on top that are very popular with each engine. A lot of the professional middleware already has various platform implementations available, usually at the cost of a separate license.

However, many of these are often built by developers that do not have access to all of the possible target platforms. This means that either a manual port of such middleware is required (when source code is available) or that these plugins need to be reverse-engineered or reimplemented which then involves adapting the surrounding calling code. The same goes for third party technology that is deprecated and no longer supported by the developer.

Another category of plugins (and sometimes even middleware) we frequently encounter is content creation technologies. Usually there is no need to modify these beyond just tweaking some parameters, but sometimes the resulting content needs to be re-tailored to the target platform.

Below a list of popular middleware and plugins we regularly run into during our adaptations:

5. Online multiplayer

Multiplayer is often a huge factor and can easily double the amount of work needed for a given title. Interestingly, while it is often quite easy to get multiplayer functionally working for an adaptation, getting it through certification on console platforms often needs a significant amount of additional work because of all the first party functional and technical requirements.

"Multiplayer is often a huge factor and can easily double the amount of work needed for a given title"

Multiplayer also adds a considerable amount of QA work and, depending on the size of the lobbies and the type of game, may require large group testing across several locations around the world.

We will zoom in on many aspects of multiplayer programming with regards to adaptations when we look into "Tailored Builds" in part 2 of this series.

6. Original developer

There are a lot of different developers out there, from one-man shops, to small studios, all the way to AAA development studios. While every developer is different, we generally found the following to hold true when comparing smaller studios to bigger ones.

Regardless of the size of the developer, we always make sure to request backend access for console platforms from the get-go. This is often overlooked and for some reason tends to always take a long time. While we sometimes work around this by setting up a temporary backend of our own, it is not always an option, not for every project. Resorting to such methods also means that a lot of the tailoring functionality will be harder to complete down the line. Having this access available is mandatory for properly implementing and testing platform features like Achievements, Presence, and Multiplayer.

7. Collaboration

The collaboration depends a lot on the development stage that the original title is in. When the original game has shipped already and is no longer in development, we can simply take the latest code and content, work on the adaptation in isolation and, once finished, merge everything back after delivering the gold master build.

However, if the game is still in active development, we will be required to periodically merge in the latest code and content from the client. This creates a dependency of which the severity is often underestimated. Game development is hard and planning for it is perhaps even harder. As such we have to empathize with our clients, and try to remain flexible. As a result of all this, code and content freezes sometimes go off-schedule.

Since merging is a hard and time-consuming process, we try to minimize the amount of merge sessions. Occasionally our code is not merged back by clients because of potential risks and time pressure on their end, which introduces the risk of merging the same thing over and over again while the progressive merges are also becoming bigger and bigger.

It is important to discuss these dependencies with the client upfront and work out the best workflow (ideally merging both ways) per project. We also make sure to include these external dependencies for the milestone requirements in the contract, to make sure there's no surprises down the line.

8. Milestone planning

The final stage in the assessment process is defining the milestone dates and resource planning.

Once all the work for each milestone has been estimated, we derive the duration for each milestone by considering the maximum amount of resources (usually programmers, as they present a common bottleneck) that can work on the items included in the milestone in parallel and without diminishing returns. This yields the (theoretical) shortest project duration, which is hardly ever realistic, because both internal and external dependencies need to be considered, but is nonetheless a valuable starting point.

Internal dependencies include resource availability from the desired starting date onwards, interdisciplinary dependencies (for instance if a game's UI needs an overhaul, design may become the bottleneck) and iteration times needed by QA to verify and warrant what we have dubbed "abstraction quality™".

External dependencies include sync dates where we pull the latest changes from the original game if it's still in development, getting access to the product and its services on the first party backends in time, QA iteration and milestone approval times by our clients, first party certification expected turnaround times, and potential manufacturing times in case the game is also slated for physical release.

Lastly, although it may feel arbitrary, over the years we found that Tuesdays are actually the best days to set as milestone delivery days and hence we try and plan all our deliveries accordingly. This way we aim to get everything done by the end of the week before, and if last-minute changes are required, they can be addressed without going into overtime or eating into the weekend.

That's it for now! What we tried to do is recreate some of the many moving parts that go into assessments, in an overall effort to show what goes into making a successful adaptation. Getting clients to come back for more relies heavily on being good at anticipating problems and having tried-and-true ways to deal with issues as they pop up.

This is part experience and part proficiency, but it also has to do with preparation, and this is where a strong in-depth assessment comes in. By doing 100% due diligence, and then going a step further, Abstraction has managed to not only build a solid catalogue of adaptations, but also managed to build a reputation for paying attention and respect to even the tiniest details.

Every adaptation is an opportunity for a game to do better, and every platform has behind it an audience that deserves to play the best possible version of that game. In the next article, we will dive into the "Straightforward Port" step of the process, and try to show how to go from that, to a proper full-blown Abstraction-grade adaptation.

If you would like to find out any further information or just have a chat then please contact us here.

You can read the second part of the series, dedicated to the straightforward port, on this page.