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.

Many games these days use 3rd party software for their audio. One very popular solution is WWise, which is a bit like a game engine, but for audio. It provides structures for developers to make the game's audio development easier. For example, developers often want audio that reacts to the in-game physics - they want sounds to be muffled when you hear them through walls or corridors, they want a Doppler Effect applied when there is a speed difference between sound source and the listener and many other things. Wwise comes with all these features pre-built and developers can just use them and mix them around to their liking.

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.

The reason video game engines, middleware and container files are important to talk about is because they both affect what you can expect to find inside game files. Importantly, video game engines and plugins tend to use their own, custom file formats for things. For example, files in Unreal Engine games are generally stored in Container Files generated by Unreal, ending with .pak and .utoc. Inside them, you will find Game Engine Files ending with .uasset, among others. When you extract these, it is possible that you will actually end up with a readable .wav audio file, but if the game used WWise Middleware for its audio design then you will probably find .bnk, .bank and .wem files instead. .bnk files themselves are another container format and often contain multiple individual audio files.

It is helpful to know what to expect. To get to a game's audio, you will often have to break through multiple layers of file formats you won't immediately know what to do with. .pak/.utoc can contain .uasset which can contain .bank which can contain .wem which you can convert to .wav/.mp3/etc. Each step requires understanding what you're dealing with and how to work through it. That's what this tutorials are here for.

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.

You are now ready to properly get into video game extraction. Return to overview.