Video games store their assets in bits and bytes on a computer's hard drive. If you hear a sound or see a particular image inside a video game, it is almost certain that that is stored as a file somewhere on your computer¹⁾. The task of a user wishing to extract these assets is to know where to look and to understand some fundamental video game concepts, especially in regards to file and file formats.

Some games store their assets plainly, ie. their textures, sounds and many other things are just literal picture and sound files. In this case, “extraction” is as simple as copying the folder's contents elsewhere. DEFCON (Game) is one such case. As a “dataminer”, it's useful to know what is a plain file and what isn't. More on that in a bit.

While it is possible to build games from a text file - and is in fact how the earliest video games were made - that method is an incredibly tedious and painful endeavor. This is particularly notable when you consider that much of the legwork in video game development is similar to each other, and building completely new systems for a 2D or 3D renderer, physics engine, audio engine, scripting, animation, artificial intelligence, networking, streaming, memory management, threads, localization support, scene graph, and cinematics²⁾ every time you make a game is expensive and wasteful. A game engine provides basic structures for all of these which lets developers focus more on actually making the game.

Video game engines and plugins tend to use their own, custom file formats for things. For example, a very popular middleware audio plugin called WWise uses the file format WEM (amongst others), in place of things like MP3 or WAV, for audio. The technical reason for this is that creating your own audio format gives you full control over the features it should have. Your own audio format can be programmed to support audio layering within a single file, to contain data about the context in which it is played, to contain data about the programming [keyword 'Event Data'], other instructions to the audio or the game engine and all kinds of other information and interfaces to the audio that aren't present in more standardized formats like MP3.

The same applies to the game engine's files. They contain all kinds of information for the renderer, the physics engine, the audio engine, scripting, animation, AI, networking and so on and so forth. It's stored directly within the file. All of this is cool for a developer, but it means that your audio player won't be able to decode these files anymore. It will encounter data in the file it doesn't know what to do with. This will typically require conversion.

When nearing completion, games made in game engines need to be “baked” or “cooked”. That means compiling the game so that it no longer is a project file in a developer's game engine but rather a finished product that can be played by players. During that process, many game engines take all the game assets, index them and store them in Container Files from where they will be loaded when the game is played by a player. These files are essentially just a bundle of many files, comparable to ZIP or RAR archives. Like ZIP or RAR archives, they cannot be loaded directly and require specialized software to read.

Middleware does this as well. BANK files are container files generated by FMOD that contain multiple audio files (typically). Opening them requires knowledge about how those files are structured. To see all of this in action, you should read Extraction Tutorial.