Asset System

From Valve Developer Community
Jump to: navigation, search

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 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.

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.)

A content side file does not contain any vertex, image, sound (etc.) data. It is an ASCII file that is read by the ResourceCompilerSystem, which performs the actual compilaton and generation of a game-side file. As such, it is better to think of a content-side file as a linking point. In the case of a model, a .vmdl links together all of the meshes, materials and other data the ResourceCompiler needs, which will then export the game side .vmdl_c file. Similarly, a .vmat file links together the raw texture images used to create the material (which they themselves are compiled into .vtex_c files). Each different asset type depends on different raw files, and compiles them in the way which is most appropriate. A map and material use a completely different compilation process, each of them following their own rules, and generating the appropriate game-side files.

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 assets depend on. These files are not used by the engine, and they are generally not included in the VPKs when the game is shipped.

Game Side

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 to render them. (or play in the case of a sound)

Game-side files cannot be edited by the tools. They are binary files that were written with the intention of being read-only. These files tend to be standalone (as in they do not depend on other files like the content-side) with certain exceptions. (.vmat still depends on .vtex files) As such, they do not facilitate editing, as they only contain enough information to be viewed.

Asset Compilation in Source 2 is a lot like turning source code into machine code. The machine code can be executed, 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 to edit the file would be an extremely tedious process due to the way it's structured.