Mfcttrf

While for other platforms of that era (primarily, Amiga), putting a game on a bootable disk was quite a normal practice, this approach never taken off on IBM PC. Why not?

I do remember people having multiple menu-driven autoexec.bat and config.sys configurations because one would have to boot MS-DOS with only the bare minimum to satisfy the requirements of some memory-demanding games. Since MS-DOS was by and large a single-task operating system, wouldn't booting a game directly from disk be more efficient than going through all the hassle of finding a working configuration of HIMEM, EMM386 and whatever else?

Even when Windows took over, would there be benefits for a demanding game to have full control over the PC resources as opposed to competing with a multitude of random background processes potentially spoiling the smooth FPS?

I understand that games in such a scenario would have to include a minimalist operating system, but I guess a carefully tuned Linux kernel along with drivers for all the popular graphics cards would be enough? This is for the Windows era, that is - for MS-DOS, I guess all the essentials games of that time needed were available directly from BIOS (well, file system support could have been an issue but I recall Amiga games of that time used to read the game data directly from sectors on the disk).

Bootable game disks do exist for the IBM PC. Conflict in Vietnam is an example of such a game. As can be seen on page 8 of the manual, the game boots directly without loading DOS first.

The main reason it wasn't common was for compatibility. A self booting game has to have its own drivers for all the hardware it wants to support. As PCs quickly diversified and software was used to provide compatibility with the original IBM hardware, it became much easier to use DOS drivers instead. In comparison the Amiga hardware was largely fixed and compatible through it's entire commercial lifespan under Commodore, and no clones ever gained significant market share.

Well there were some PC booter titles (MobyGames lists 249), but most of these were quite early games, even before hard drives, XMS or EMS even existed. These were almost always self contained single floppy games, that could run on the very specific hardware that existed. All they used was BIOS for disk access. Also DOS was not the only operating system, so it sort of made sense to have a simple booter game that could be booted from a single floppy, without a specific OS. As the game itself does not require DOS for anything, it would have taken too much floppy space to include DOS just for the purpose of loading a game.

When games became larger and hard drives mainstream, and in practice the consumer OS had settled to DOS, it was much simpler to boot the PC to DOS as usual and then run the game executables either from floppy directly or from the hard drive. Also games that have multiple files like graphics and sound files can just very easily read those files under DOS, without understanding anything about the actual file system structures.

Even later, with 386 and 32-bit protected mode games, DOS was just used as the platform that was able to execute the DOS extender and load the 32-bit game executable into memory for the purpose of running it.

The IBM PC was NOT a Game Machine

Plenty of people played plenty of games on IBM & compatible computers. But the IBM PC was designed as a business machine, not a game machine.

This is most obvious with audio capabilities. Where Atari 400/800, VIC-20, Commodore 64, Amiga and many other machines of the era included some (for the time) serious sound capabilities, the IBM PC did not. As a result, within a short amount of time, there were a number of different sound cards available, each of which needed a driver or specific application programming to work.

Video was not quite as bad, but even there, the original PC had a choice of two very different video cards (MDA & CGA) and soon EGA and others came along, each with their own video modes (bit depth, resolution, memory-mapped video RAM location, etc.), while many of the other popular machines had video, often with better support for games (e.g., sprites), built in to the motherboard.

Due to the sheer size of the market, there were many games available for the IBM PC. But due to design issues, many of these games needed either extra hardware (e.g., sound card) or extra software (to support different sound, video, extended/expanded memory), all of which was a lot easier to support by booting into MS/PC-DOS first. In addition, hard drives were quite common with the IBM PC (at least after the introduction of the XT), so installation of a game onto the hard drive, sometimes with insertion of the original floppy at the beginning of the game for copy protection, made a lot more sense than trying to cram everything into one or two bootable floppy disks.

Games that were designed to be run from floppy were usually self-booting, and often could only be run by booting from floppy. In many cases, the game code could be stored in ways that would not be understood by MS-DOS (using things like non-standard sector sizes), and booting into a game would be faster than booting MS-DOS and then booting the game. The big problem was that a self-booting game would be generally be able to access anything that required any sort of loadable device driver, nor--in most cases--any information that was stored on a normal MS-DOS disk. If one wanted to save one's progress in Zork I or Wizardry, one would have to format a disk specifically for that purpose, as opposed to merely being able to store a file on an existing MS-DOS volume [I think Wizardry used disks formatted to the UCSD P-system standard, and its save files might have been able to co-exist with files for other P-system applications, but Wizardry is the only one I know of].

Note that if a game knows that it will need to use a certain specific set of files, it can simply have a list of files and their locations built into the game's code. If a game were using MS-DOS and wanted to read foo.dat, it would need to read one or more sectors of directory information, then one or more sectors of the FAT, before finally being able to read the data for the file of interest. If instead the game code is hard-coded table that says file #23 is stored from sectors 293 to 299, the code can simply read those sectors directly, thus offering faster performance than if the game were using DOS to read the information from floppy (though probably slower than using DOS to read from a hard drive).

I'd like to question the premise, here.

I understand that games in such a scenario would have to include a minimalistic operating system, but I guess a carefully tuned Linux kernel along with drivers for all the popular graphics cards would be enough?

Space is an issue, so it would be beneficial if it were possible to have the kernels separately, or else have multiple different copies of the game with different sets of drivers. The "separate kernel" model seems more efficient, and what is DOS if not this?

Now, even when Windows took over, would there be benefits for a demanding game to have full control over the PC resources as opposed to competing with a multitude of random background processes potentially spoiling the smooth FPS?

There is a convenience in being able to start your games quickly, and to Alt-Tab, and to use the network you've already configured your computer to use, etcetera. And computers powerful enough to run Windows were often powerful enough to run most games without stuttering, especially since Windows gave priority to the programs the user was interacting with.

Nevertheless, many games on my Arcade ClassiX CD-ROM required me to boot into single-process (MS-DOS) mode in order to run properly; it appears that such games existed. It wouldn't surprise me if such bootable disks as you describe in your question also existed. But such launch systems reduce the target audience with very little benefit, so I wouldn't expect many to exist.