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 suspect that’s how many people remember BBS door games.

In our memories, we recall quaint multiplayer, turn-based, text games. They lacked sophisticated graphics, music, and sound effects — significant flaws for most people. What made these games special for most of us were the social interactions they fostered, which was their primary advantage and marketable difference over video games of the 1980s and 90s.

It’s those “flaws” that I’d like to dig deep and consider today. 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 contraints for an author writing a BBS door game:


A 300-baud Hayes Smartmodem. (Michael Pereckas via Wikimedia Commons)

Even into the 1990s, many users were still using 300 to 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.


This screen shot shows the Australia continental map in the game Global War by Joel Bergen. The interface is composed entirely of text. The borders of the countries are double-pipe PC ANSI characters.

Most terminals were text-based, so any in-game “graphics” had to be composed of text (letters, numbers, symbols). North American 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.


This screen recording of a terminal session in SyncTerm captures the ANSI music piece “A bit of Beethoven” by Bob Clarke, featuring artwork by Ebony Eyes.

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 standards 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 implementations remained proprietary. Since no single standard was universally adopted, 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 a console game from Nintendo or a PC game from Apogee.

They attempted to do 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.

This screenshot shows a moment late in the BBS game “Thieves’ Guild” when played using its front-end client. The Thieves’ Guild front-end would display 16-color, 160×100 pixel art images client-side, above text sent from the BBS.

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.

Often, games would advertise the availability of optional front-end clients 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 couple of games, notably Metal Knights, simplified the process by allowing 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 client launched, it was able to communicate directly with the game.


Quite a few BBS games offered front-ends of varying capabilities. A few examples include:

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!