Asset System

Please note: this page is a work-in-progress.

The Asset System is the system by which Source 2 manages its files. An asset is any file that is used as part of a game, whether it be a model, mesh, texture, material, or map. The asset system is a key part of Source 2, and is what allows the engine and engine tools to read, write modify, update, and verify game files.

Features

-CRC verification for all files.

-Integrated Mod and Addon Support

Structure

The structure of the Asset System is based upon the internal structure used by Valve for asset management in Source 1. It is split two different sides known as the Content Side and the Game Side.

Function

The asset system serves as the file manager for Source 2. On the content side, it is what allows the engine tools to dynamically update assets as they are changed. Changes to assets fire events within the Asset System to which tools can subscribe and listen. Each file in the content directory is monitored for changes. When a file changes, the Asset System picks up on that change and fires the appropriate events. It will also recalculate a CRC hash for later verification. The tools can listen for these events and perform actions accordingly.

The asset system is also responsible for recompiling assets as they change. This is true for most assets with the exception of maps, which are simply a collection of geometry and references to other assets. (A map does not need to be recompiled in order to reflect a model change.)

Content Side

On the content side are the uncompiled game files (.vmap, .vmdl, .vmat, .vpcf, etc). These are the files that are edited by the engine tools to create the maps, models, textures, particle effects that the game will use. Additionally, this side contains all raw source files for these assets (FBX meshes, TGA textures, WAV and MP3 sounds, etc.)

It's better to think of content-side files as linking points for the raw source files used to create them. Most of the content-side assets require these source files in order to open properly. In the case of a model, the mesh, and material need to exist in order for the content-side file to load properly into the editor. The same goes for a material file. All of the textures and texture maps used to create that texture must be present in their raw forms. A compiled texture will not suffice, as that is a game-side file. A compiled material can use a compiled texture, but an uncompiled material cannot use a compiled texture.

The content side tends to be larger in file size because it contains all of the raw meshes used for models, as well as lossless TGA texture maps and other raw files that the content-side assets depend on. These assets are completely useless to the engine. Again, it’s better to think of the content-side files as linking points; they are references to raw files, which they themselves are compiled alongside the other assets.

Game Side

Game-side files are the files actually used by the engine. These files are the files that will be compressed into the VPKs and shipped through the Steam app depot. They are usually suffixed with ‘_c’ to denote that they are the compiled version of their content-side counterparts. They are much more space efficient as they do not contain the raw dependencies required by the content-side files. They are also compressed and contain their own CRC hashes for validation.

Game-side files cannot be edited by the tools. They are natively viewable, but not editable as they are a binary file that is specific to the engine. They only contain enough data for the engine to use them properly. Additionally, these files tend to be standalone (with the exception of .vmat_c, which still depends on the compiled .vtex_c files). They do not include any of the necessary source files for editing.