Chunking and Deployment Strategy Cont. - Build Pipeline

Development Pipeline & Plugins
, ,
1

This question was created in reference to: [Chunking and Deployment Strategy for a Simulation [Content removed]

Thanks for the response. I think I understand the approach better now.

When you say deploying a single application with on-demand packaging and dedicated builds per potential customer, are you referring to using Game Feature Plugins / Modular Game Features in Unreal? So that we would structure each Vehicle as its own Game Feature Plugin and then include or exclude them at cook time depending on which potential customer we are building for?

We are already using World Partition and Data Layers for our exercise content. Would the idea be to combine that with Game Features so each Vehicle plugin manages its own Data Layers and exercises?

Also when it comes to the build pipeline, would you recommend using BuildGraph to set up the different customer build profiles? Or is there a simpler way to handle the plugin toggling per build?

Any pointers on examples for this kind of setup would be helpful. We have looked at Lyra but it would be good to know if there is something more specific to this use case.

Thank you!

[Attachment Removed]

2

Hi there,

Thank you for the update. I’m glad my previous post was helpful.

Given the limited context available, it can be challenging to recommend an ideal setup for this product. Based on the information provided so far, there are a few general suggestions from me.

Developing standalone VR products, especially simulation products, typically requires on-demand packaging and dedicated builds, which differs from traditional games. These products are often tailored to specific clients and maintained accordingly. As a result, the development process should emphasize reusability and flexibility within the core system, gradually building the asset library and a packaging pipeline that enables rapid assembly and release of different versions. If I understand correctly, this case will have its own vehicle library and level library, combined with exercise data collection to deliver customized versions for different customers.

To support this, a modular design is essential. This modularity should apply to core functionality, data handling, and asset organization. The idea of using Game Feature Plugins as you mentioned, could be a viable option for this. However, in practice, a well-structured folder system with well-designed blueprints and disciplined version management can also achieve the production pipeline effectively. Whether to adopt the plugin depends on your project’s specific requirements and architectural approach. If you do choose to use the plugin, you may need to manage separate uproject for different clients.

Combining the vehicle with its own data layer and exercises can work, but the primary goal of a modular design should be to decouple levels and vehicles as much as possible.

I am not sure if there are public examples for this type of workflow. A practical approach is to first streamline the entire development pipeline, simplifying each stage as much as possible. Start with a minimal setup, a simple vehicle and a basic level, then package and deploy it to the target device. From there, iterate incrementally based on project needs. For instance, you might begin with manual packaging and later introduce tools like BuildGraph to improve efficiency once the workflow becomes more established.

I hope this helps answer your questions. Please feel free to reach out if you have any further questions.

Best regards,

Henry Liu

[Attachment Removed]