Mobile (Android/Oculus) DLC (creation, packaging and playing) training stream and docs - when ?

Is there any way we could have a training stream about creating, packaging and then playing DLC for mobile (Android/Oculus) platform ?

I am sure people would like to learn how to set up main project/game so that it would be easier to add multiple DLCs after the release; how to package (into separate DLCs) additional content added to the project after the main game was completed and the game was released; how to have main game to accept DLC content (also where it needs to be placed in relation to already installed game on Android device or Oculus Go/Quest) after it was acquired by the user.

Ideally Blueprint-only, but if C++ has to be used, it would be nice to accommodate UE4 developers who don’t really code in C++ and are mostly Blueprints developers.

Thanks beforehand

P.S. I assume models/anims/levels/textures/etc. (assets) would be in DLC packages, but the additional gameplay functionality would have to be coded (Blueprints) into the main game. Please correct me if I am wrong.

Hey there motorsep! We’re actually working on organizing these materials as we speak. It’s tough to state an exact timeline before we have them available, but this is currently one of our top requests for mobile docs and tutorials on multiple fronts. I’ve bookmarked this thread and will keep you posted.

Much appreciated. Looking forward the official docs and tutorials!

Finnaly ! Im really glad to see this coming , do you planning to talk about the upcoming Android App Bundle support aswell ? Im really interested by these features who could help us to reduce gamesize and the ability that give us to manage the game by splitting it in little pieces . Im just worried to know if it will be fully supported by the engine or it’s will just simply package the game in this format without any way to manage the packaging ( would be a huge deception ) and would love to see the stream/docs talking and showing how deep we can go with the new format ( managing extra level or translation etc ) when it will be added .

Android App Bundle documentation is coming alongside the release of 4.25. You should be able to check it out under 4.25 Preview 1. However, I will caution that they aren’t really used for splitting up your game assets. Rather, they’re an alternative to APK/OBB builds that’s proprietary to the Google Play Store, used for condensing the upload process for your projects. Where you previously would have needed to make separate APKs for different sets of devices based on texture formatting or other considerations, you upload one AAB file and Google Play uses it to create a final APK customized for the end-user’s device. It’s convenient, and the final APK that’s distributed to the end-user has a limit of 150 MB instead of 100 – but an app bundle is not to be confused with an asset bundle.

You’re looking for information about chunking, pak files, asset management, and patching, I think, which is one of the other topics I’m currently working on revising documentation for. Basically, you can download sets of .pak files and have a device mount them to make their assets accessible. We’ve got robust tools for packaging assets this way that are fairly intuitive to use (see our section on the Asset Manager and Primary Asset Labels), but the process of patching itself is definitely a bit hazy – mostly because different platforms each have their own ways of delivering these kinds of files. Nevertheless, I’ve invested a lot of time in researching this process for mobile, and you can look forward to some new/revised documentation for it soon. :slight_smile:

Hi Mikhail,
Can we please get updates on the documentation side of things? We are currently attempting to work with DLC .pak files at runtime but was only able to find minimal information on properly doing it at runtime on Mobile platforms (Android/IOS). It would be really helpful to get some guidance on this.


Howdy @Sith_Handbuilt!

This has been a surprisingly tricky topic to build documentation for due to the varying methods for delivering patches and DLC. The process of developing these docs started with exploring a fully implemented system, and from there I’ve worked my way down to the building blocks we ship with the engine and the base interfaces they’re built on top of. It’s surfaced enough usability concerns that we are working towards a consolidated patching system that should be more user-friendly and easy to integrate compared with current options, and I’ve been assisting with research on that front. When that solution rolls out in a future engine version, full documentation will be available alongside it. However, I doubt that’s a satisfying answer given your immediate needs, so I’ll try and share as much information as I can to help you on the right track.

Currently, the most up-to-date patching doc we’ve got published is for Google PAD. This method requires you to use an Android App Bundle build to use it, which means you must also distribute your project on the Google Play store, which itself serves as the back-end for hosting the asset packs. However, this at least gives you a rundown of the principles behind patching and a thorough walkthrough for generating your chunks; if you understand how to implement this system, you’ll have a good idea of how the others work. I’ve written a revised version of the Cooking and Chunking page which should go up sometime next week, which will have more thorough information about chunks/paks and clearer instructions about how to work with them. I hope to follow with an updated doc for HTTPChunkInstaller shortly after, which is the legacy patching plugin that currently ships with the engine.

In essence, patching involves the following steps:

  1. Initialize the patching system. This is usually done in GameInstance, in the Initialize function, which runs when the application starts. Similarly, the GameInstance shutdown function is used for shutting down the patching system.
  2. Connect to the remote service and download a manifest file containing a list of what paks users should have. Manifest entries should have enough information to discern not only whether a pak is present, but also if the pak on the user’s local device matches the pak on the remote server, and necessary progress information. This might include a friendly name for the pak, its file size in bytes, and its chunk index.
  3. After updating the manifest, delete any paks from disc that aren’t supposed to still be around.
  4. Check the manifest for what paks do need to be downloaded, and queue up downloads for them. These should be tracked asynchronously, and once the download is done, they need to be written to local storage. Monitoring downloads, queuing them up at appropriate times, and error handling are the bulk of what you need to concern yourself with.
  5. Once a pak is downloaded and installed to local storage, it is available to be mounted. Mounting a chunk means that you are putting it in memory and telling the engine that its files and directories are available to be accessed. In other words, once a chunk is mounted, you can access its information like you would any asset in the Content Browser. When a chunk is unmounted, it is freed up from memory, and its contents are no longer accessible. Because you need a chunk mounted in memory, you should be judicious when organizing chunks and their contents accordingly.

Under the hood, two major components are involved in this process:

  • UAssetManager - A singleton for accessing game assets.
  • FGenericPlatformChunkInstall - An interface that’s used as the base for installing and mounting chunks – any chunk install plugin will implement this.

The Asset Manager will look for the chunk that an asset belongs to when you try to load it. It incorporates the GenericPlatformChunkInstall interface when it looks for chunks, and if you enable **bShouldAcquireMissingChunksOnLoad, **it will make a call to your chunk installer to download missing chunks when needed. It’s more ideal to know upfront which chunks you’re going to need and have them downloaded and mounted ahead of time, but for really piecemeal loading it can be helpful. You can extend both AssetManager and PrimaryAssetLabels to add custom logic and data for how you want to load chunks.

If it sounds like a lot of this depends on game-specific or platform-specific implementation, it’s because it does. Google PAD manages to automate a lot of the more basic features, natively includes asset pack types, and includes a Blueprint function library that makes its patching more accessible, but it’s specific to Google’s platform. HTTPChunkInstaller is more generic, so you need to fill in a lot more blanks in terms of accessing the remote service for your patches, monitoring progress, and organizing chunks.

Both Google PAD and HTTPChunkInstaller are “some assembly required;” they offer libraries of utility functions, and it’s up to you to decide where you should implement your solution and how to organize it, which is admittedly not super-easy without an example to follow. GameInstance makes for a place where you can handle universal or startup patching needs, while a Game Mode that implements requests for chunk downloads could act as a middleman for loading screens and the like. It’s helpful in those instances to implement a custom AssetManager class that can discern what chunks are necessary when you want to load a new level or do anything similar, then transition to the “loading mode,” then transition to the desired map once all necessary information is loaded. However your game is organized, though, that can vary quite a lot.

Hopefully that at least gives you an idea of where to start looking! In the meantime, I’m going to keep working on this and see if I can provide a more thorough walkthrough with HTTPChunkInstaller soon.

Hi Mikhail,

Thanks very much for the wealth of information. This is quite useful for me to explore further. Eagerly looking forward to your upcoming walkthrough.


Hi @MikhailPrinke_

I am looking into DLC options as well. I want to make a mobile app for iOS and android, and a second for Oculus Quest which allows people to use logins to download extra levels to the base setup. Trying to get around making a user download all the other irrelevant levels and files when they only want access to one.

Has this documentation or video guide been released yet?