How the mod assets system works in VR Constructor

1. The virtual world engine itself is written and implemented on top of the "Unreal Engine" game engine. However, UE does not allow for the creation of assets and game extensions outside of the Unreal Editor.

    The typical cycle for making changes and additions requires: having the Unreal Editor, most of the game project's source code, creating a new plugin via the Unreal Editor, adding and importing new assets from files (textures, mesh models, audio), and compiling/building the project within the Unreal Editor. After the build is complete, the compiled plugin content can be copied and distributed to users, provided that the game project initially supports the dynamic loading of plugins and modules.

    Currently, out-of-the-box, dynamic loading is not implemented for .pak files (packaged plugin content data), dynamic loading of any assets from Plugins/PluginName/Content directories, or compiled C++ modules.

    A similar situation exists with creating new maps, locations, missions, and Data Assets—all of this goes through the complex process of project compilation and building.

What VR Constructor Offers:

    Built-in support for dynamic loading of any Content Plugins and compiled C++ UE modules.

    Dynamic loading of Content Plugins created within the virtual sandbox. Every user of the virtual sandbox has the ability to create their own plugins.

    The directory and file structure is analogous to that used in Unreal Engine but possesses a number of advantages.

Dynamically Creating New Runtime Assets in the Virtual World

    Currently, there are thousands of file formats for storing and working with data. For specific file formats, wrappers have been created that allow Unreal Engine's internal system to work with the file as an asset.

    A native file, for example, a *.png (image storage format), is copied into the Content directory.

    2.1 Let's assume this is a texture that the user wants to use inside their virtual world. For textures, there is an internal wrapper asset class PngTexture2d. Through the in-game editor, when the user imports a PNG file, they automatically receive a PngTexture2d asset. The PngTexture2d asset is stored and serialized in a text or binary format: *.tasset, *.basset.

    2.2 The *.tasset / *.basset files store metadata: the linked native file, the asset class, and asset instance parameters. The texture data itself continues to reside in the native file and can be modified at any time, either by an external editor/program or by an internal one, if an internal editor is implemented for that specific file type.

    2.3 The internal editor also supports changing the asset instance parameters.

    2.4 The dynamic loading of assets created from native files is supported at the level of Unreal Engine's base functionality and is fully integrated into Unreal Engine's asset lifecycle.

Advantages

    Assets created dynamically can be added, removed, or modified at any time, without the need to rebuild the game or virtual world.

    The basset/tasset layer allows you to change nothing in the virtual world itself, but simply replace the native files (e.g., textures or audio) and immediately see/hear the result, without the need to rebuild the virtual sandbox and the content plugin.

    *.basset, and especially *.tasset, are easily readable and can, if necessary, be edited manually in any text editor or in an editor that allows for byte-by-byte editing of binary files.

    Simple support and sharing of plugins, consisting entirely of basset/tasset files, simplifies functionality management within a chosen virtual sandbox.

    The ability to edit tabular files and use them as UDataTable—a standard asset for working with tables in Unreal Engine. UDataAsset—for working with structure-like data—which can be stored as JSON or XML.

    In a client-server setup, when in plugin editing mode, changes to the plugins are applied on the server. For the end-user, the process of updating plugins and assets happens as seamlessly as possible, without unnecessary actions or long waits for downloading gigabytes of updates.

    Without U3DSBVRGE, even minimal changes to just one asset, texture, or a single plugin would require rebuilding at least one entire plugin, followed by copying the built plugin/content .pak file to the target build.

    No need for expensive specialists to make changes to the virtual world and environment, as the iteration process for making changes is maximally simplified. This reduces the subsequent cost of maintaining and developing the product created inside the VR Sandbox Constructor U3DSBVRGE.

    The virtual world itself, created inside the sandbox, is ready-to-use out of the box and does not require compilation, building, copying, or installation steps.

In Simple Terms:

Any file type for which support is already implemented can be used as an asset and imported into the virtual world. This includes making direct changes on the server to any plugin, without the need to go through the complex iterations of asset import, project/plugin rebuilding via Unreal Editor, and complex updates of the server's virtual world and the assets it consists of. There is no need for expensive specialists to make changes to the virtual world and environment.

In the best traditions of user-friendly development for the end-user: KISS (Keep It Stupid Simple), WYSIWYG (What You See Is What You Get).