A different way to play: front-ends

This is the first installment in my series “A different way to play” about front-end clients for BBS door games.

Silent. Simple. Social.

I think that’s how most people remember BBS door games. They think of quaint multiplayer, turn-based, text games. The games’ lack of sophisticated graphics, music, and sound effects are probably considered flaws. Their social aspect is remembered fondly — it was door games’ primary advantage and marketable difference over video games in the 1980s and 90s.

Today I’d like to dig deep and consider those “flaws.” How did the limitations of BBS technology shape door games? How did door game authors work around those limitations?


Connecting to a BBS required the use of terminal programs, modems, and telephone lines. These particular technologies resulted in the following limitations for an author writing a BBS door game:


Even into the 1990s, many users had 300-2400 bps modems. At these slow speeds, text would crawl across the screen, sometimes letter-by-letter. This made viewing menus, maps, or interfaces quite frustrating. Further, the latency inherent in modem connections prevented authors from writing action- or arcade-style games that required precise timing. Instead, BBS games tended to toward the strategy or role-playing genres.


Most terminals were text-based, so any in-game “graphics” had to be composed of text (letters, numbers, symbols). Microcomputers of the 1980s offered the standard set of 128 ASCII characters in black-and-white. Many systems also had their own individual extended character sets (“high” ASCII) containing various symbols that could be use for drawing, as well as special terminal codes to enable coloring or animating the text. Examples include Atari’s “ATASCII” character set or Commodore’s “PETSCII.” By the 1990s, the PC DOS/Windows platform had become dominant, and most BBSes employed its extended character set and 16-color mode to make “ANSI art.” Talented artists could use ANSI’s shaded-block and pipe characters to create impressive scrolling screens of text graphics. But ANSI was a very limited medium, and BBS games remained visually inferior to traditional video games.


BBS audio was extremely primitive. Most computer platforms’ character sets included a bell character, such as ASCII code 7, which would trigger the terminal to beep or to ring. BBS games often incorporated this “bell” sound. On the PC, several terminal programs (notably TeleMate, QModem, and BananaCom) came up with their own standard for playing music using ANSI escape sequences. They did this by redefining (some might say breaking) part of the ANSI spec. This “ANSI music” was very simple — you could play notes at various octaves and tempos. But ANSI music remained a proprietary format that wasn’t universally adopted, and game authors couldn’t count on users having compatible terminals.


Many programmers aspired to make BBS door games that offered more than just text. They wanted their games to look and sound as cool as something on Nintendo. To be immersive.

They did this by creating their own terminal programs.

They called these custom terminals by different names: “emulators,” “graphics terminals,” “helpers,” etc. I’m going to refer to them as “front-end clients” or just “front-ends.”

A front-end was designed to work with one specific game, offering extra features such as increased speed, pixel graphics (EGA, VGA, etc), animation, music, sound effects, custom interfaces, or automated scripts/macros.

The front-end would usually be available to download from the file section of a BBS as a ZIP archive. The ZIP would include all media assets necessary: graphics, sprites, music, or sound effects. Some games had so many assets that multiple ZIP files would have to be downloaded, extracted, and assembled together on the user’s computer. Once the user installed the front-end on his or her home computer, the media was installed, too. The assets wouldn’t need to be sent over the modem in real time during gameplay.

Games that had optional front-end clients would advertise their availability in their opening title screens or in their documentation. If a user wanted to obtain the front-end, he’d have to call the game author’s home BBS, or hunt for it in the file sections of local BBSes. A few games, notably Metal Knights, simplified things by prompting the user to download the front-end ZIP file from within the game itself:

The “Metal Knights” main menu has an option to allow the user to download the game’s custom terminal.

Most of these front-ends were not full-featured terminals. In fact, some were designed with the expectation that the user would call a BBS from their usual terminal program, such as Telix or TeleMate. Once connected to the BBS, the user would navigate the board’s menus to find the game and invoke it. Most games would then pause and prompt the user to launch his or her front-end, if they had one. Here is such a prompt from The Pit:

Opening prompt from The Pit, asking users to launch their graphics terminal if they have one.

At this point, the user would have to launch the front-end on his home computer. There were several ways to accomplish this, such as shelling to the DOS command line from the main terminal, finding the front-end, and executing it; or by setting up the front-end as a file transfer protocol in the main terminal. Either way, the modem connection would be maintained. Once the front-end program started, it was able to communicate directly with the game.


Quite a few BBS games offered front-ends of varying capabilities, such as:

So let’s dive in! Click these links and I’ll introduce you to the first four on the list:

I covered the Thieves Guild Emulator in much more detail (see links below), and I plan to write about Metal Knights in a future blog post.

Thieves’ Guild articles:


Did you ever use front-ends in the past (or still today)? What were some of your favorites? Are you familiar with front-ends for BBS games on non-PC platforms? Share your thoughts and questions in the comments.

1 thought on “A different way to play: front-ends

Share your thoughts!