An Introduction To Data Files Data files, as you may have guessed, contain data. They can contain any kind of data, but they're most often used for storing large collections of data. Data files usually contain most of the data stored by a program. As the program runs, it makes extensive use of its data files to get all of its information. The actual program executable file is often little more than a manipulator, a tool to use the program data that's stored separately in other files. Because they typically contain all of a program's data resources, data files are also often called resource files. Non-technical people sometimes call them "binary files". Although there is nothing abot data files that makes them inherently more "binary" than a plain text file (after all, every file is stored the same binary way, as a sequence of 1s and 0s), this connotes the implication that data files are meant to be read by a computer, whereas text files can be read by a human. In other words, data files are not meant to be "human readable". However, there is no reason why a human couldn't simply open up a data file, start reading it, and understand everything that was inside it. The only thing they would need is a knowledge of the file's format. This leads to the trouble with understanding data files: They can have any format at all. There is no universal standard for them, and so professional programmers often just end up inventing their own proprietary file format, a format they create themselves which nobody else knows about. Every data file must have a standardized format to make the data inside it usable, but while some file formats are publicly-available standards, other file formats are closely-guarded secrets. A programmer can structure their file format any way they choose, and many programmers don't want people to be able to browse through their resource information at will. If you've ever studied the file structure of a computer game, you've probably noticed that the game's graphics aren't stored as JPEGs or GIF files. Although these are two common standards for computer graphics files, professional game developers will rarely incorporate their game's graphics by simply creating a bunch of standard picture files. Instead, they'll more likely convert those picture files into a format of their own design. The game will come with several resource files which contain all the game's data like the graphics, sound effects, music, and so on, but nobody will be able to use those files without knowing their data format. The game's executable file is simply the "engine", as it is often called in the game industry; What you actually see in the game is stored in separate data files. Ironically, game developers usually work with standard file formats when they create the game. Game artists will create graphics in JPEG, GIF, PCX, BMP, or some other well-known industry standard format, but as the development of the game continues, these pictures are typically compiled into a few large files which collectively contain all the game's picture data. These files contain formats proprietary to the developer. Sometimes, if you view the data files, you can even still see the original graphic file names there, as part of the packaged resource file. This is not necessarily a bad thing; It cuts down on file clutter, because instead of having hundreds or thousands of files for all the pictures in the game, there are only a few packaged data files which contain everything. It's also not always an attempt by the developer to prevent people from manipulating the program data (although that's a possibility as well); Many companies have actually publicized their proprietary file formats, because they want to allow other people to modify the program's data files if they wish to do so. Although this has sometimes led to copyright concerns, it has also led to cases in which the mass appeal of a game is greatly heightened because of user-created modifications to the game. A classic example is the game Doom, which was extremely popular in part because people could (and did) create their own levels and graphics for the game by modifying the game's resource files. In an interesting move, id Software released the source code to Wolfenstein 3D, a game that helped make the company a star, and similarly, Apogee released the source code to two of their games, Rise Of The Triad and Duke Nukem 3D. What was so clever about this move was that only the source code to the games' engines were released; Users who downloaded the source still couldn't play the games, because the resource files weren't included. Users could see all the game code, but unless they actually had the full games, including the resource files, they simply had an empty game shell with no graphics, no sound, and no music. This allowed everyone to study the games' source code for their own interest, and it also gave owners of the games an opportunity to re-program the games however they saw fit, while still preventing the game from being pirated becase of lack of game resources; Nobody wants to pirate just a game engine with no graphics in it. Of course, there are many different ways to make a computer program, and programmers have all different styles. There are many games which are contained within a single executable file. In such cases, all the game's resource data is contained within that one file. There is nothing necessarily wrong with that, but if the game is large, it would result in a single very large file, which could become difficult and inefficient to work with. Logically organizing the game's data into groups of a few files tends to make development much smoother. In the early days of computing, many games were made as single files, because they were small enough that they could be effectively managed that way; Today, only very small and amateur-created games are programmed as single files. There are also several games which do maintain their data as several separate files; For example, all of a game's sound effects might take the form of separate WAV files stored in some directory. Although a bit less compact, such an arrangement opens up interesting possibilities by allowing users to customize their games by changing the sound effects, replacing the original sounds with new ones of their choosing. This is an interesting scenario, but again, in reality, only small and usually non-retail-quality games are arranged this way. Just as in a kitchen, food (a finite resource) is stored separately from the forks and spoons (tools used to act on the food), so it makes sense to package a program's executable code separately from its data. Data files are a way of life in the computer world, and they're here to stay. Once you get used to the concept, you'll appreciate how they make the life of a programmer easier and more organized. Enjoy your data!