Doors
The original games. The
.EXE files from thirty years ago, running on your board, in the caller's browser,
with nothing DOS anywhere near your server.
Most DOS doors are drag and drop: unzip
the game into dosdoors/, write a small manifest beside it, press Scan in the
console, add a menu item. Some are fussier, because of how their authors wrote their installers.
This page is for the fussy ones.
Ready to drop in
Each of these is a folder that drops
straight into dosdoors/. Unzip, press Scan in the console, add a menu item, done.
Every package carries a README noting anything specific about that door. You could assemble any
of them yourself; some are just fiddly enough that it seemed kinder not to make you. Usurper in
particular still needs its world built afterward, which
its guide covers.
Gladiatorial combat. One of the great arena doors, and a package that needs nothing from you but a scan.
The fantasy adventure sequel, with its world already built and its paths already straightened out.
Gang wars, dungeon crawls, kings, gods and a town that insults your players by name. The 2015 community release, the last version anyone shipped. Notoriously fussy to assemble by hand, so this is the right way in.
Usurper builds its world before anyone can play, which no package can do for you. The guide walks that step and the daily housekeeping. Read it →
The 2009 release, the last by the original author. Same game to play; take this one if you want it exactly as Jakob Dangarden left it.
The space trading game that defined the genre. It ships as an installer that wants a real DOS machine pointed at a real drive, so this package is the installed game, saving you that.
The manifest names EXTERN as the door's daily maintenance, so on ATDT 1.7.2 and later the universe maintains itself: the first solo caller of the day runs it on the way in, and the console button covers quiet days. Boards on older versions keep running EXTERN by hand.
Install it yourself
Doors that misbehave in a way that is theirs, not yours, collected so nobody debugs them twice.
Drag and drop, with one exception. Version 4.07 has a bug of its own: LORDCFG refuses to start, claiming LORD.EXE is the wrong version. It does the same thing under DOSEMU and OS/2 on plain local hardware, so it is not your files and not ATDT.
The community 4.08 patch fixes it. Patch 4.07 up to 4.08, run LORDCFG, and it works fine. The patch is not hosted here; a search will find it. Versions 4.02a through 4.06 have neither problem and need no patching at all.
One setting matters either way: in LORDCFG, Configure Nodes, set every node to FOSSIL rather than internal com. The full write-up has the reasoning and a manifest worth copying.
Both versions are packaged above, which is the easy road. Assembling one by hand is real work: the archive is a toolbox rather than a door, only eight of its files matter, one of them has to be copied in twice, and you write the control file yourself.
Either way the world has to be built before anyone can play, and the daily housekeeping has its own set of traps. None of it needs DOSBox: it all happens on the door's maintain page in your own browser.
Force your FTP client to binary for the entire door upload. Left on "auto" it will often guess
wrong, and a .EXE or .OVR that came up in ASCII mode is corrupt.
The symptom is a door that ends the moment it starts, with nothing on any screen to explain
why. The Files panel in the console flags it for you: a live file whose size differs from the
one in files/ is the one that got mangled.
The system should run any DOS door, but some need tweaking. If you cannot get one going, email me and I will take a look, and if it needs a package I will build one and put it on this page.
This happens as time permits, but it happens.
ATDT has a native door API as well: one folder, a manifest, and a PHP class with three methods. No DOS involved, and doors written against it run anywhere ATDT does.