Download#

Tip

To try the game rather than keep it, there is nothing to download at all: play it in the browser. Come back here for a build that saves to a file you own.

Getting the game#

Releases are published on the project’s Releases page. A release carries a build for each platform, and the source:

  • ZangbandTK-<version>-osx.dmg — the macOS disk image, for Apple Silicon: the application, this manual in HTML, and the borg’s documentation.

  • ZangbandTK-<version>-osx-intel.dmg — the same disk image for an Intel Mac. Take this one if your Mac has an Intel processor; see Which Mac build do I want? if you are not sure.

  • ZangbandTK-<version>-osx-terminal.tar.gz — the same game for macOS drawn with characters, to play in Terminal, iTerm2 or over ssh. No window, no tiles, no sound. Apple Silicon. See Playing in a terminal.

  • ZangbandTK-<version>-osx-terminal-intel.tar.gz — the terminal build for an Intel Mac.

  • ZangbandTK-<version>-win64.zip — the Windows build, 64-bit, with the same manual beside it. A single executable: libpng and zlib are linked in, so there are no DLLs to keep track of. Prefer this one.

  • ZangbandTK-<version>-win32.zip — a 32-bit Windows build, for older machines and older Windows. It runs on 64-bit Windows too, and needs the two DLLs beside the executable.

  • ZangbandTK-<version>-linux64.AppImage — the Linux build, 64-bit. One file: make it executable and run it. Carries three front ends, chosen with -m: -msdl2 for tiles, -mx11 for a plain window, and -mgcu to play in a terminal with no display at all.

  • ZangbandTK-<version>-linux64-terminal.tar.gz — the Linux terminal build: the curses front end on its own, with no FUSE and no graphics stack, for a server you reach over ssh. See The Linux terminal build.

  • ZangbandTK-<version>-nintendo.zip — the Nintendo DS ROM and the 3DS build, with the data the card needs. Text mode, no tiles or sound.

  • ZangbandTK-<version>-dos.zip — the DOS build, for a 386 or better with a DPMI host. Text mode, CP437, and the manual as plain text beside it. Needs CWSDPMI.EXE, which is not in the zip; see DOS.

  • ZangbandTK-<version>.tar.gz — the source, with the build system already generated.

Take the newest release on that page. The release log says what each version changed, and the game is moving quickly enough that the difference between two of them is worth reading.

Two notes for anyone reaching for an older one. The first release, 3.1.1 from 18 August 2026, was cut before the Windows builds were packaged, so it carries the disk image and the source archive and nothing else. And for one release after that the 32-bit zip was named -win.zip, before the 64-bit build arrived and both were named for their architecture.

Every release so far is marked a pre-release. CI builds, signs and verifies each one, but no version has been played through before it was tagged: there are known bugs and one milestone’s worth of unfinished features, and the badge on the Releases page says so before you download rather than after.

The Windows, Linux, Nintendo and DOS builds are built, packaged and smoke-tested by CI, but the game is developed and played on macOS here and none of the others is played through before a release is tagged. Read Other platforms before you rely on one.

The rest of this page is macOS. Mount the image and drag ZangbandTK.app wherever you keep applications.

Which Mac build do I want?#

Both processors are supported, and each has its own download rather than sharing one universal file — so an Apple Silicon player does not carry a copy of the game they can never run, and neither does an Intel one.

Your Mac

Take

Apple Silicon (M1 and later)

-osx.dmg, or -osx-terminal.tar.gz. Requires macOS 11 or later.

Intel

-osx-intel.dmg, or -osx-terminal-intel.tar.gz.

If you do not know which you have, open the Apple menu → About This Mac. A line reading Chip: Apple M-something is Apple Silicon; Processor: Intel something is Intel.

Taking the wrong one is not dangerous, just useless: an Intel Mac cannot open the Apple Silicon build at all, and an Apple Silicon Mac will run the Intel build through Rosetta, more slowly and only if Rosetta is installed. There is no reason to do that when the native build is on the same page.

Note

Intel support is new, and arrived after Intel Macs were originally ruled out of this project. Both builds are compiled, packaged and smoke-tested by CI on a machine of the matching architecture — the Intel builds are built on a real Intel runner, not cross-compiled — but the game is developed and played on Apple Silicon here, so that is the build with hours on it.

The first launch#

The first time you open ZangbandTK, macOS will refuse, with words to the effect that it could not verify that ZangbandTK is free of malware that may harm your Mac or compromise your privacy.

That reads as an accusation, and it is not one. macOS is saying it cannot tell who made the application — not that it found anything wrong with it. Apple’s Gatekeeper passes an application without comment only if it was signed with a paid Developer ID certificate and submitted to Apple for notarization. ZangbandTK is signed, but ad-hoc: the signature is valid and proves the bundle has not been altered since it was built, but it carries no registered developer identity, because this project has not bought one.

Important

Open it once through System Settings.

  1. Try to open ZangbandTK normally and let it be refused. Click Done. This step is required — macOS does not offer the next one until something has actually been blocked.

  2. Open System Settings → Privacy & Security, and scroll down to Security. There will be a line saying ZangbandTK was blocked.

  3. Click Open Anyway and confirm with Touch ID or your password.

macOS remembers, and afterwards the application opens by double-clicking like any other.

Note

If you have done this on older versions of macOS, you may remember right-clicking the application and choosing Open. Apple removed that shortcut; on current macOS it no longer gets you past this, and System Settings is the way.

If you would rather clear the quarantine flag directly, this does the same job without needing the refused attempt first:

xattr -dr com.apple.quarantine /Applications/ZangbandTK.app

Verifying it, if you would like to#

codesign --verify --strict --verbose=2 /Applications/ZangbandTK.app

That should report valid on disk and satisfies its Designated Requirement. This tells you the bundle is internally consistent and unmodified since it was built. It cannot tell you who built it — which is exactly what a Developer ID would add, and exactly what macOS is complaining about.

The disk image carries a README.txt saying all of this too, for anyone who downloads it without passing through this page.

Playing in a terminal#

ZangbandTK-<version>-osx-terminal.tar.gz is the curses build: the same game, drawn with characters, inside a terminal. It is a separate download from the disk image rather than something hidden inside it, because it is a different executable — there is no application bundle and no window server involved at all, which is what lets it run over ssh.

On an Intel Mac the file is ZangbandTK-<version>-osx-terminal-intel.tar.gz; everything below applies to both, and the unpacked folder is named the same either way.

tar -xzf ZangbandTK-<version>-osx-terminal.tar.gz
cd ZangbandTK-<version>
./zangbandtk

Keep the executable and the lib directory beside it together, and start the game from inside the unpacked folder — that is where it looks for its data.

Quarantine applies here too, and the Open Anyway route above is about applications, so the direct way is the one to use:

xattr -d com.apple.quarantine zangbandtk

Unpacking with tar in a terminal, rather than by double-clicking the archive, usually avoids the mark in the first place.

Important

The terminal build does not share savefiles with the application. Its characters live in ~/.angband/ZangbandTK; the .app’s live in ~/Documents/Angband. This follows from the terminal build using the Unix convention for a user’s data rather than the macOS one, and it means the two can be run side by side without treading on each other — but a character started in one will not appear in the other.

Nothing is written inside the unpacked folder while you play, so it can be deleted or replaced with a newer version without taking your characters with it.

80x24 is the minimum size and is cramped; 100x40 or larger is much better. The front end can split the window into subwindows — ./zangbandtk -mgcu -n2 through -n6 — and ./zangbandtk -h lists the rest. Your terminal must be set to UTF-8, which Terminal.app and iTerm2 both are by default.

Building it from source#

Requirements#

macOS, on Apple Silicon or Intel

Either builds the game for itself. To build for the other one, see Building for the other architecture.

Xcode command line tools

xcode-select --install

CMake

Only to run the test suite. brew install cmake

Python 3.11+

Only for the data conversion tools.

The last two are optional. Building and playing the game needs the first two.

The game#

git clone https://github.com/z88kat/ZangbandTK.git
cd ZangbandTK/src
make -f Makefile.osx -j$(sysctl -n hw.activecpu)

That produces ZangbandTK.app in the repository root. Double-click it, or:

open ZangbandTK.app

The terminal build#

cd ZangbandTK/src
make -f Makefile.osx-tty -j$(sysctl -n hw.activecpu)

That produces src/osx-tty/zangbandtk. It links Apple’s curses in /usr/lib deliberately, not Homebrew’s, so that the executable runs on a machine with no Homebrew on it. Add the dist target to build the tarball that the release carries:

make -f Makefile.osx-tty -j$(sysctl -n hw.activecpu) dist

It has its own object directory because the Cocoa build compiles the same sources with different flags; the two builds do not interfere and can both be present at once.

Building for the other architecture#

Both makefiles build for the machine they are run on. To ask for the other architecture, set ARCHS:

make -f Makefile.osx clean
make -f Makefile.osx ARCHS=x86_64
make -f Makefile.osx-tty clean
make -f Makefile.osx-tty ARCHS=x86_64

ARCHS=arm64 is the default and is what you get without saying anything. The clean matters: object files carry the architecture they were compiled for, and make will happily link a mixture and fail at the last step with a list of undefined symbols that says nothing about why.

Clang cross-compiles between the two without any extra toolchain, so this works from either kind of Mac. What it cannot do is run the result — an Apple Silicon machine needs Rosetta to start an Intel build, and an Intel machine cannot start an arm64 one at all. CI therefore builds each architecture on a runner that matches it, so that the smoke test is a real one.

The released file names follow ARCHS by themselves: an x86_64 build writes ZangbandTK-<version>-osx-intel.dmg and ZangbandTK-<version>-osx-terminal-intel.tar.gz, so building both one after the other in the same tree does not have the second quietly overwrite the first.

Note

Universal binaries are deliberately not built. ARCHS="x86_64 arm64" is what vanilla Angband does and the makefiles would still accept it, but the project ships two thin downloads instead — see DEC-22 in the decision log.

The tests#

cmake -S . -B build -DSUPPORT_TEST_FRONTEND=ON
cmake --build build --parallel
cd build && make alltests

941 unit tests and 5 integration tests. They should all pass; if they do not, that is a bug worth reporting.

Before you start#

Important

Savefiles are not compatible with Angband or Zangband, and never will be. Do not point ZangbandTK at a savefile you care about.

Your character survives an upgrade. A ZangbandTK savefile is written in blocks, each carrying its own version, and the loader keeps a reader for every version it has ever written — so a character saved by an older build loads into a newer one. Things that were renamed are mapped rather than lost, and a shipped corpus of real characters, played and saved by hand across the whole of development, is loaded by the test suite on every change so that a break is noticed before a release rather than after.

Where something has been removed outright rather than renamed, the character comes back without that item rather than not at all. The one thing that will refuse a savefile is a change it cannot honestly read: a caster whose spell list has moved underneath them is turned away rather than handed somebody else’s spells. Content can be dropped; identity is not invented. Four characters out of thirty-five in the corpus are refused on that rule, and each is recorded with its reason.

Everything Zangband is known for is now in the game — the wilderness, the towns, the dungeons, the bestiary, mutations, chaos patrons, the seven realms and pets. Nightmare mode is the one milestone still to come; Features is the honest inventory of what is in and what is not. If you have played Angband before, How Balance Differs is the shortest account of what will kill you that would not have before.

Linux#

The AppImage needs no installation and nothing installed alongside it:

chmod +x ZangbandTK-<version>-linux64.AppImage
./ZangbandTK-<version>-linux64.AppImage

It bundles its own SDL2, X11 and ncurses libraries, so it does not care which distribution it is on, and it is built against an older glibc than the current one deliberately so that it runs on more than just the newest releases. Older distributions may need libfuse2 installed for AppImages to mount; failing that, --appimage-extract unpacks it into a directory you can run from.

Saves go to ~/.angband/ZangbandTK, outside the image, which is read only. That path is inherited from Angband and kept so that nothing has to move later.

There is no 32-bit Linux build. Ubuntu dropped the i386 archive in 19.10, Fedora and Arch dropped 32-bit years ago, and the source archive covers anyone still running it.

The Linux terminal build#

The AppImage above already carries the curses front end — run it with -mgcu — so on a desktop there is nothing else to fetch. -linux64-terminal.tar.gz is for the machines where the AppImage is the wrong shape: FUSE is a package to install before it will mount at all, and the SDL2 and X11 libraries it bundles are most of its size and no use at all without a display.

tar -xzf ZangbandTK-<version>-linux64-terminal.tar.gz
cd ZangbandTK-<version>
./zangbandtk

The executable, its data, and nothing else. Keep the lib directory beside the executable and start the game from inside the unpacked folder — that is where it looks for its data.

x86-64, and glibc 2.35 or newer: Ubuntu 22.04, Debian 12, RHEL 9 and anything after those. Nothing needs to be installed alongside it. ncurses is linked in statically and deliberately: a dynamically linked build does not start at all on a system with no libncursesw.so.6 — a stock Debian container is one — and on the RPM distributions it starts but prints no version information available on every launch, which looks like a fault and is not one. The terminfo database is still read from the system at run time, which is how the game learns what your terminal can do.

Saves go to ~/.angband/ZangbandTK, the same place the AppImage keeps them, so the two share characters and nothing is written inside the unpacked folder.

The terminal size and subwindow notes under Playing in a terminal apply here too, as does the requirement that the terminal be UTF-8 — over ssh that depends on the locale your session picks up at both ends.

Nintendo DS and 3DS#

Yes, really. The DS build is inherited from Angband, and it works well enough to be worth shipping — but it is the least tested build here by a wide margin.

The game reads its data from the card rather than from inside the ROM, so both halves of the zip matter: copy the zangbandtk folder to the root of the SD card, so the data sits at /zangbandtk/lib/, and put the .nds wherever your flashcart keeps its ROMs. On a 3DS the .3dsx goes in /3ds/ for the Homebrew Launcher. A game that starts and then cannot find its files has almost always got that folder one level too deep.

It is text mode: no tilesets and no sound, which is why it is a small download where the others are twenty megabytes larger.

The world is smaller here, deliberately. A DS has 4 MB of memory and the desktop world does not fit in it — the game loads, reaches character creation and then runs out of memory generating the surface. So this build ships a 260×260 world with one town, against 2064×2064 and a dozen elsewhere, and a live area of about one screen — which means the surface is rebuilt as you walk. All thirteen dungeons are still placed. The settings live in constants.txt on the card, so anyone who wants to try the full-size world can, without rebuilding anything.

Important

“Unable to access filesystem” is a DLDI problem, not a broken download. Homebrew on a DS needs a driver for the particular card it runs from, written into the ROM — DLDI patching. Flashcarts like the R4, and loaders such as TWiLight Menu++ or the Homebrew Menu, do this for you as they launch, and a DSi or 3DS running from its own SD card does not need it at all. Launching the .nds directly, or in an emulator, generally does: patch it with dlditool <driver>.dldi ZangbandTK.nds, using the driver for the card in question. The README.txt in the zip goes through this.

There is one save slot, at /zangbandtk/lib/save/PLAYER. That is this port’s limitation, not the game’s.

Note

The DS has 4 MB of memory, and ZangbandTK asks more of it than Angband does: 1013 monsters against Angband’s 624 or so. The wilderness is not the problem — the whole world costs about 98 KB, because it is generated from a seed as you walk rather than stored — but the bestiary is real. If memory runs out it will happen while loading, before character creation.

If you have a RAM expansion pak in Slot-2, this port knows how to use it, and that is the first thing to try.

The card path changed from /angband/ to /zangbandtk/ so that a card can hold both games without either finding the other’s saves. A card set up before that needs its folder renamed.

DOS#

A 32-bit protected-mode build, cross-compiled with DJGPP. It wants a 386 or better, and it will run under DOSBox, DOSBox-X, or on the real thing.

Important

The zip does not contain a DPMI host, and the game will not start without one. A DJGPP program runs in protected mode and needs something to put the processor there. Under Windows or on a DOS with a DPMI server already loaded there is nothing to do. Otherwise fetch CWSDPMI.EXE — it is a separate package, from sandmann.dotster.com — and run it once before the game, or leave it in the same directory and it will be found. This is how DJGPP programs have always been distributed; it is not something missing from the build.

Unpack the zip and the game is in a folder called angband, and the executable is ANGBAND.EXE. That is not a mistake: DOS filenames are eight characters and the internal project name is still Angband, the same name that gives the game its data paths on every other platform.

Which is also why the data files are not named quite as they are elsewhere. Anything whose name is too long for DOS is shortened when the archive is built — monster_spell.txt becomes monster2.txt, the Zangband bestiary becomes monster3.txt — and the build asks for the short names to match. Nothing is left out. The manual’s own text files keep their long names, since nothing but a reader ever opens them, so on a filesystem without long filename support expect those to arrive truncated.

Text is CP437, converted when the archive is built, so the box-drawing and the accented letters are the ones the code page actually has.

CI builds this on every push and then plays it: a character is created under DOSBox-X and saved, which proves the build starts, finds its data files and can write to its save directory. Nobody has played it through, and it has not been tried on real hardware — if you do, that is a report worth having.

Other platforms#

macOS is what the game is developed and played on. Windows is built and packaged by CI as well — the mingw cross build, MSBuild, MSYS2 and Cygwin all pass — in both architectures: the 32-bit build cross-compiled with mingw, the 64-bit one on a Windows runner under MSYS2, because the bundled PNG and zlib that the 32-bit build links against are 32-bit binaries with no 64-bit counterpart to hand. Both zips carry a README.txt for SmartScreen, which greets an unsigned executable much as Gatekeeper does above. Linux is packaged the same way, as an AppImage.

The DS and 3DS builds come from Angband’s own ports and are packaged the same way. The DOS build is a DJGPP cross build, smoke-tested under DOSBox-X on every push.

Nobody plays the game on any of them here, though, so all are untested in play: CI proves they build, start and can read their own data, which is not the same as having been played through. Reports from either are especially welcome for that reason.

Licence#

ZangbandTK is available under the Angband licence:

This software may be copied and distributed for educational, research, and not for profit purposes provided that this copyright and statement are included in all such copies. Other copyrights may also apply.

Angband is dual-licensed under the GPL v2 or the Angband licence. Zangband was released under the Angband licence alone, and ZangbandTK incorporates Zangband material, so the Angband licence is the option available here. In practice that means non-commercial distribution — the same terms Zangband itself carried.

See Copying and licence information for the full statement, including the exceptions covering bundled libraries and graphics.

Reporting problems#

Bugs, build failures and questions go to GitHub issues.