How We Ported ARK: Survival Evolved

So we were asked to do a port of ARK: Survival Evolved. ARK: Survival Evolved, as you might know, is a high-end title that requires a fairly good PC to run well.

This already sounds like an interesting and challenging project, right? Here are a few additional things to spice it up:

• Ark runs on a custom version of Unreal Engine 4.5 with a lot of core changes/tweaks and additions.
• It needed to be ported to the Switch platform, which is effectively a handheld device.
• Needs to be based on the same content/codebase as the original.
• The target date for the Gold Master Candidate gave us around ~6 months development time.

The major problems we identified when assessing this adaptation were:

• CPU Performance: The Switch uses a mobile ARM CPU with 4 cores (only 3 usable cores). Other console platforms have more than twice that number of cores, and easily twice the raw power per core.
• Switch support: Unreal Engine 4.5 is several years old (from 2014), it doesn't have /any/ Switch support.
• Graphics: Our goal was to keep the entire deferred rendering pipeline of the original game. The Switch GPU can be compared with a downclocked Nvidia Shield.
• Memory: The Switch has 4GB of memory. But due to the Switch's OS and other overhead we're effectively limited to 3GB. Which is nearly half of what is available on other consoles.
• Package Size: The original game is around 27gb on PS4 (and that is with PS4 supporting native package compression..). On Switch we where limited to a 16gb cartridge.

Get it running

So the first question a lot of people ask is obviously "why don't you just upgrade to Unreal Engine 4.20?".

There are many reasons to not take this approach, the most important ones being:

• Asset compatibility. UE4 serialization is only backwards compatible for a few versions. Additionally, Ark uses a custom Engine version and isn't even completely compatible with a clean UE4.5.
• DLC / Patches. How are we ever going to integrate changes from the main game if there is such a huge difference in source code/assets.
• Gameplay consistency. Later UE4 versions behave differently, also a lot of custom changes where made all through the UE4 networking and gameplay systems. Bringing all of these changes back to 4.20 would be a huge and extremely risky undertaking.

The main issue with doing these integrations where of course engine system refactoring and a full header restructuring Epic did several versions back to improve compile times making basically any code file we integrated a completely manual operation.

Stream all the things

Ark preloads a lot of data since most of the Dinosaurs can walk around and items can be used at any time.

The main approach we took to address the memory limitations of the title was to implement dynamic streaming on a much broader scale. Some data is already streamed such as higher quality dinosaurs, items and parts of the level.

But we needed to take this a few steps further. Making nearly all of the textures stream in was a huge memory gain. We also improved the Mesh streaming to allow nearly any mesh in the game to stream in a restrictive memory pool.

Texture compression

A lot of textures were already compressed with formats such as DXT. We replaced most of the texture compression with the more efficient, and more importantly hardware supported ASTC format which also reduces texture memory requirements.

Mesh optimization

Other Ark console versions already apply some mesh triangle reduction, but for Switch, we needed a more rigorous approach. Just increasing the pre-existing triangle reduction settings wouldn't get us there since triangle reduction is not very good at keeping the original form/details intact.

We introduced a second pass of mesh reduction using a max deviation approach. This allowed us to further reduce any sub-optimal meshes as much as possible without deviating from the original visual quality (over a certain factor).

Gameplay performance

Much of CPU budget went to updating all the Dinosaurs gameplay behaviour and animations. To address this we worked on amortizing all of this using two major approaches:

• Animation update rate optimizations from the more Recent UE4. What this does is spread out animation updates over multiple frames and interpolates for the rest of the frames. Objects that are further away get lower effective tick rates.
• A new gameplay update rate optimization system. This is essentially very similar to the animation update rate optimizations but then applied to the gameplay behaviour/simulation of NPCs.

Temporal Aliasing / Upscaling

This feature did cause a lot of headaches though. A lot of the existing materials (mostly postprocessing) were not compatible with this technique and had to be manually fixed.

Dynamic resolution and view distance

Ark already has an existing dynamic resolution system in place which we replaced with a much smoother scaling system. Stepping up/down the resolution is normally very noticeable but Temporal Aliasing / Upscaling allows for this quite nicely.

This new system also scales the view distances to reduce the overhead in GPU heavy locations (especially forest areas, where you can't see very far anyway)

We had to make some cuts

• Only ship with The Island map to reduce final package size to something manageable
• Remove console hosted dedicated server support (which is an extremely CPU and Memory heavy feature)

End result

I think with more time, perhaps doing some content changes on lower LOD levels to improve their looks (you can only do so much with automated mesh reduction) this could've been even closer to the original Ark.