Due to the many types of iteration on ZZT itself, it is important to have a good way of ensuring that the words we use mean the same things. As such, this Wiki chooses to classify the various iterations on ZZT as follows:

• A hex edit is defined as a modification or set of modifications made by editing an uncompressed, official ZZT binary in a hex editor or disassembler and building the result back. Note that these are mostly a thing of the past - nowadays, it's preferred to create a fork.
• A fork is defined as a source code (typically the Reconstruction of ZZT)-based modification of ZZT. Notably, the source code must have been just modified - that is to say, one can get from the original source code to the modified source code with a set of patches. If the source code has been reimplemented (for instance, via translation to another language), we classify it as a source port.
• A source port is defined as a source code-based reimplementation of ZZT. For instance, a project which follows the RoZ codebase's structure, but is written in Go, would classify as a source port. The amount of functional changes done to ZZT is irrelevant, here.
• A clone is defined as a reimplementation of ZZT based on reverse engineering techniques which do not seek to mimic the source code exactly. These are, likewise, mostly a thing of the past due to the existence of the Reconstruction.
• A successor is loosely defined as an engine distinct from ZZT, but one which was inspired by it and created in the cultural context of its community. This is a category difficult to formalize, and as such we provide a list of engines considered as successors alongside the Taxonomy.
• A wrapper (or emulator) is defined as software which emulates, virtualizes or wraps a ZZT executable (or hex edit, or fork, but not necessarily a source port or clone) in a way which is in some way distinct from the behaviour of the executable on real hardware execution. This is a fairly small category, and includes things like emulators with extensions (Zeta) or runtime-patching utilities (ZZT Enhancer, some kinds of TSRs).

These are the engines considered as successors by the above definition, and - unless otherwise noted - may be documented as part of this Wiki.

• Super ZZT
• MegaZeux (not covered here, see below)
• ZIG
• PLASTIC

This list is incomplete and may be expanded in the future.

• Super ZZT and the many revisions of ZZT, while counting as Forks, may not be covered in detail by this wiki. The Wiki of ZZT is a better source for information on official Epic releases.
• MegaZeux, while a Successor of ZZT, is not covered by this wiki at all. That is absolutely DigitalMZX territory.

The goal of this Wiki is to provide answers for two categories of users, with their respective defining questions:

1. The Researcher - “What attempts to change, modify and expand upon ZZT were made over the years, and why?”
2. The Developer - “What changes, modifications and expansions to ZZT can I incorporate or consider in my own works? Can I find the source code, patches?”

As such, don't worry about being terse! The subject matter is both vast and niche; at this stage, it's more important to document that a given thing existed and how it operated, rather than focus on making the information particularly easy to digest.

The written content of this wiki is licensed under the terms of the CC BY-SA 4.0 license. However, a notable exception applies to source code snippets/patches embedded in or uploaded to the wiki - we are aiming to make it as re-usable as possible. As such, the following licenses are permitted (and should be clearly marked):

Please note that the following comments on the effects of each license ARE NOT LEGAL ADVICE and that the Wiki's administrator is not a lawyer.

• CC0 - this is our preferred choice for public domain dedications, as it handles the edge cases of (many) countries without a way to dedicate works to the public domain fairly well.
• Zero-clause BSD - if you find the CC0 too wordy, this one's for you! It doesn't act as a public domain dedication, but holds no requirements for source code usage and is straightforward.
• zlib license - This license adds a source attribution requirement. Notably, it doesn't require attribution on binaries.
• MIT, 2-clause and 3-clause BSD licenses - These add varying amounts of binary attribution requirements. 3-clause BSD also adds a clause forbidding usage of the author's name for advertising.

Other licenses may be added to this list on request. Licenses which are functionally equivalent may be considered as if they were allowed, but should ideally be added to this list.

Source code linked to through external sites may be under any license, although it is in good tone to mark the license of the code alongside the link.