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, update, and verify game files.
The asset system serves as the file manager for Source 2. It is what the engine uses to keep track of what resources are loaded into memory. It is also what allows the engine tools to dynamically update assets as they are changed. Changes to files fire events within the Asset System to which tools can subscribe and listen to. When a file changes, the Asset System picks up on that change, and can communicate to the tools what exactly has changed.
The asset system is also responsible for queuing the ResourceCompilerSystem to recompile assets as they change. This is true for most assets with the exception of maps whose lengthy compile process does not warrant immediate recompilation.
The asset system implements inheritance rules when it comes to projects and sub-projects. For example, when creating a workshop addon for Half-Life: Alyx the asset system creates special folders specifically for that addon. The addon inherits all of the existing assets found in the Half-Life: Alyx game directory (hlvr). Assets can be overridden, meaning that existing models, materials (and any other asset) can be changed by the addon and used instead of the original hlvr assets.
The asset system is based upon a two-sided structure. The Content side is where assets are created and edited. The Game side is where the compiled assets are located.
The engine cannot use the content-side assets directly. They are only ASCII files which allow the editor to make changes quite easily. (There are several exceptions - VMAP files contain DMX data for the level geometry) The editor then composites the raw data (meshes, images, etc.) into a final preview which is displayed. The game side is created when the asset compiler processes the content-side file, and outputs the final asset. The engine can then load and render the game-side asset.
On the content side are the uncompiled game files (.vmap, .vmdl, .vmat, .vpcf, .vtex, 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 and PNG textures, WAV and MP3 sounds, etc.)
A content side file does not contain actual asset data. It is an ASCII file with references to the raw files. The file is then parsed by the compiler, which generates the game-side files from the raw files, and from the settings described in the content-side file. As such, it is better to think of a content-side file as a linking point for raw assets. In the case of a model, a .vmdl links together meshes, materials, attachments, and animation data, which the compiler will then export as a .vmdl_c. Similarly, a .vmat file links together the raw texture images used to create the material, and then exports a .vmat_c file.
The content side folders tend to be larger in file size than the game side because it contains the raw files that the content-side files depend on. These files are not directly used by the engine, and are generally not included in the VPKs when the game is shipped.
Game-side files are the files used by the engine and included in the VPKs when the game is compiled and shipped. They are suffixed with ‘_c’ to denote that they are the compiled version of their content-side counterparts. They are much more space efficient, as they contain only the information required by the engine. Game-side files cannot be edited by the tools.
Asset Compilation in Source 2 is a lot like turning source code into machine code. Execution is trivial, but it is not easy to make edits to the program after it has been compiled. The same goes for a game-side file. It can easily be rendered, but editing the file would be very difficult.