How DOS Games Were Made in the 1990s – Step by Step

If you remember games from the DOS era, you probably immediately think of the iconic startup screen displaying:

DOS/4GW Protected Mode Run-time Version X.X

It was the unmistakable sign that you were about to enter a world of pixels, sprites, and sound effects coming from an 8-bit sound card. But what actually happened behind the scenes before that magical gameplay began? In the DOS days, games weren't built with ready-made engines or user-friendly editors—everything required hands-on programming, careful memory management, and clever workarounds for hardware limitations.

The 1990s were a time when games became increasingly sophisticated, evolving from simple platformers into full-fledged 3D shooters like Doom and Duke Nukem 3D. At the time, a typical PC often had just 640 KB of conventional memory, an EGA or VGA graphics card, and a 386 or 486 processor. To unlock the full potential of the hardware and enable smoother graphics and larger game worlds, developers relied on tools such as Watcom C and DOS/4GW.

DOS/4GW was essentially the key to the processor's 32-bit protected mode. It allowed developers to create games that were larger, faster, and far more impressive than anything possible in the standard 16-bit DOS environment. Every time a game launched, that familiar startup message appeared—a reassuring sign to players that they were about to dive into an exciting virtual adventure.

But before that screen appeared and the pixel magic came to life, developers had to go through an entire production pipeline—from writing the code, compiling it, integrating it with DOS/4GW, testing it, and finally packaging all the game assets. Let's take a look at what each of those steps looked like.

Welcome to the world of Watcom C and DOS/4GW.

1. Writing the Game Code

Everything started with programming in C or C++, sometimes combined with assembly language for performance-critical routines such as graphics rendering or sound playback. The source code was stored in simple text files with extensions like .c, .cpp, and .h. Developers typically used DOS-based editors such as EDIT, Vim, or the more advanced Watcom IDE.

A typical project structure looked something like this:

game/
├─ main.c
├─ graphics.c
├─ input.c
├─ sound.c
└─ game.h

Below is a fragment of the original Duke Nukem 3D source code, which has since been released to the public and can be downloaded as a complete C project. The game's source code (version 1.5) was published by 3D Realms under the GPL 2.0 or later license.

switch (key) {
    case KEY_UP:
        if (sectorFloorZ <= spriteZ)
            inputFlags |= FLAG_FORWAR
        break;

    case KEY_DOWN:
        inputFlags |= FLAG_BACKWAR
        break;

    case KEY_LEFT:
        inputFlags |= FLAG_TURNLEFT;
        break;

    case KEY_RIGHT:
        inputFlags |= FLAG_TURNRIGHT;
        break;

    case KEY_SPACE:
        inputFlags |= FLAG_FIRE;
        break;

    default:
        break;
}

2. Compilation

The next step was translating the source code into machine code. This is where the Watcom C Compiler came into play.

A typical compilation command looked like this:

wcl -q -ox main.c graphics.c input.c sound.c

-q – Quiet mode

-ox – Maximum optimization

The result was an executable .EXE file ready to run under DOS.

3. Integrating with DOS/4GW

Large games needed more than the 1 MB memory limit imposed by real-mode DOS. To overcome this, the executable was built to work with DOS/4GW, allowing it to switch into 32-bit protected mode.

When the game started, players would see:

DOS/4GW Protected Mode Run-time Version 1.97
Copyright (c) Rational Systems

This step was essential because it enabled games to access significantly more RAM and achieve much better performance.

4. Testing

The developer would then launch the game from the DOS prompt:

C:\GAME>GAME.EXE

Debugging was much more challenging than it is today. Common techniques included:

Using the Watcom Debugger (wdbg)
Printing diagnostic messages to the screen with printf()
Monitoring variable values during execution

Developers also had to test memory usage, performance, and compatibility with different graphics and sound cards.

5. Adding Game Assets

Graphics, music, and sound effects were typically stored in separate files. Larger games often packed these resources into archive formats such as Doom's famous .WAD files.

A typical directory structure looked like this:

GAME/
├─ GRAPHICS/SPRITES.SPR
├─ SOUND/MUSIC.SND
└─ GAME.EXE

The game loaded these assets at runtime as needed.

6. Building the Final Release

After testing was complete, the final distribution package was assembled.

It usually included:

The executable (GAME.EXE)
All required game assets
Sometimes a simple installer, although many games were distributed by simply copying the files onto a hard drive

The player launched the game, saw the familiar DOS/4GW startup screen, and moments later the real adventure began.

7. Fun Facts

• Everything was done "the hard way"—developers manually handled memory, graphics, sound, and user input.
• Watcom C was so fast and reliable that it became the de facto standard compiler for many DOS games.
• DOS/4GW unlocked access to the processor's full 32-bit protected mode, making the ambitious games of the 1990s possible.
• Developing DOS games was far more low-level than modern game development, but it also gave programmers complete control over every aspect of the game. It was the era that produced timeless classics such as Doom, Duke Nukem 3D, and Warcraft II.
*]