zxt:format_specification
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
zxt:format_specification [2021/08/06 08:18] – asie | zxt:format_specification [2021/08/08 18:09] – asie | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== ZXT Extension Format Specification ====== | ====== ZXT Extension Format Specification ====== | ||
- | Version 0.XX | + | Version |
By Adrian " | By Adrian " | ||
- | The specification follows a MAJOR.MINOR numbering scheme. | + | Special thanks: endgame, GreaseMonkey, |
+ | |||
+ | The specification follows a MAJOR.MINOR.PATCH | ||
+ | |||
+ | * Changes to the MAJOR number are expected to introduce breaking changes, resulting in a change of the extension header magic number; | ||
+ | * Changes to the MINOR number are expected to introduce changes which don't break backwards compatibility, | ||
+ | * Changes to the PATCH number are expected to introduce changes which don't impact the meaning of the specification, | ||
+ | |||
+ | For example, a ZXT 1.1.x world which doesn' | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Extending and tweaking the functionality of the ZZT game engines ((ZZT and Super ZZT)) has always been an undercurrent in its world development community. While many games relying on edited executables or TSRs ((Terminate-Stay Resident programs)) have been released in the past, they ran into key problems, keeping their count small and the idea unpopular: | + | Extending and tweaking the functionality of the ZZT game engines ((ZZT and Super ZZT)) has always been an undercurrent in their world development community. While many games relying on edited executables or TSRs ((Terminate-Stay Resident programs)) have been released in the past, they ran into key problems, keeping their count small and the overall |
* The lack of source code greatly increased the difficulty of performing non-trivial modifications. | * The lack of source code greatly increased the difficulty of performing non-trivial modifications. | ||
- | * The requirement for special batch scripts or modified executables, | + | * The requirement for special batch scripts or modified executables, |
* No consistent means of signaling required extensions was devised. For most worlds, this made them indistinguishable from ZZT 3.2-compatible ones for the end user or reimplementations, | * No consistent means of signaling required extensions was devised. For most worlds, this made them indistinguishable from ZZT 3.2-compatible ones for the end user or reimplementations, | ||
Line 40: | Line 48: | ||
Notably, the specification currently does **NOT** cover: | Notably, the specification currently does **NOT** cover: | ||
- | * The format of save (.SAV) files. | + | * The format of save (.SAV) files. |
* The format of board (.BRD) files. This is due to the niche nature of the subject, and is likely to be expanded upon in a future version of the specification. | * The format of board (.BRD) files. This is due to the niche nature of the subject, and is likely to be expanded upon in a future version of the specification. | ||
Line 62: | Line 70: | ||
* **plstring** - a Pascal-style long string; a length u16 (N, of range between 0 and 65535) followed by N characters. | * **plstring** - a Pascal-style long string; a length u16 (N, of range between 0 and 65535) followed by N characters. | ||
- | Things marked "// | + | Where the specification |
===== File Format ===== | ===== File Format ===== | ||
Line 77: | Line 85: | ||
* The intent of .ZAX files is to extend games with additional functionality (keybind shortcuts, metadata, etc.), while preserving compatibility with the ZZT game engine. (They can also serve as patches on top of an otherwise unmodified .ZZT file.) | * The intent of .ZAX files is to extend games with additional functionality (keybind shortcuts, metadata, etc.), while preserving compatibility with the ZZT game engine. (They can also serve as patches on top of an otherwise unmodified .ZZT file.) | ||
* The intent of .ZXT files is to contain a modified ZZT game within one world file. This is especially useful for games which cannot be supported by unmodified versions of the ZZT game engine. | * The intent of .ZXT files is to contain a modified ZZT game within one world file. This is especially useful for games which cannot be supported by unmodified versions of the ZZT game engine. | ||
+ | |||
+ | If a .ZXT file is being loaded, a .ZAX file should be ignored - .ZAX files apply for .ZZT files, not .ZXT files. | ||
+ | |||
+ | The behaviour of multiple concatenated extension headers contained within one .ZXT or .ZAX file is undefined; distributed .ZXT or .ZAX files MUST NOT rely on it. | ||
==== Extension Header ==== | ==== Extension Header ==== | ||
Line 90: | Line 102: | ||
^ Offset ^ Type ^ Name ^ Description ^ | ^ Offset ^ Type ^ Name ^ Description ^ | ||
| 0 | u16 | flags | Extension flags; defined below. | | | 0 | u16 | flags | Extension flags; defined below. | | ||
- | | 2 | u32 | owner_id | Extension owner ID | | + | | 2 | u32 | owner_id | Extension owner ID. | |
- | | 6 | u16 | selector_id | Extension selector ID | | + | | 6 | u16 | selector_id | Extension selector ID. | |
- | | 8 | u8 | reserved_0 | Reserved. | | + | | 8 | u8 | reserved_0 | Reserved; must be set to 0. | |
- | | 9 | u16 | field_length | Field length. | + | | 9 | u16 | field_length | Field length. |
| 11 | u8[field_length] | field_data | Field data. Extension-defined. | | | 11 | u8[field_length] | field_data | Field data. Extension-defined. | | ||
Line 111: | Line 123: | ||
| 8 .. 15 | reserved | Reserved. | If set, an implementation MUST NOT continue parsing of the extension block. | | | | 8 .. 15 | reserved | Reserved. | If set, an implementation MUST NOT continue parsing of the extension block. | | | ||
- | It is important to note that the flags can be distinct from the ID pair; for instance, the same ZZT-OOP extension can be defined as " | + | It is important to note that the flags can be distinct from the ID pair; for instance, the same ZZT-OOP extension can be defined as " |
===== Extension IDs ===== | ===== Extension IDs ===== | ||
- | Extension IDs are allocated on a per-owner ID basis. | + | Extension IDs are allocated on a per-owner ID basis. Within one owner ID, selector IDs SHOULD be used in a "one per extension" |
==== Owner ID Ranges ==== | ==== Owner ID Ranges ==== | ||
- | * The range '' | + | * The range '' |
* The range '' | * The range '' | ||
* The range '' | * The range '' | ||
Line 146: | Line 158: | ||
* ZXT standard compliance concerns only the game engine' | * ZXT standard compliance concerns only the game engine' | ||
- | * An implementation MAY choose to be compatible only with ZXT worlds containing certain extensions. Compatibility with un-extended ZZT worlds is OPTIONAL. | + | * An implementation MAY choose to be compatible only with ZXT worlds containing certain extensions. Compatibility with un-extended ZZT worlds |
==== Engine Accuracy ==== | ==== Engine Accuracy ==== | ||
Line 190: | Line 202: | ||
* Use an ID inside the area of private use extensions while the extension' | * Use an ID inside the area of private use extensions while the extension' | ||
* Mark your public specification as " | * Mark your public specification as " | ||
+ | * If your extension is intended to work only with ZZT or Super ZZT, but not the other, it's a good idea to mention that explicitly in the specification. | ||
==== Engine Developers ==== | ==== Engine Developers ==== | ||
* Not every ZXT-compliant engine implementation must provide every extension! Don't fall neck-deep into code bloat, especially on your first try. Focus on the ones you care about, or which games you enjoy utilize. | * Not every ZXT-compliant engine implementation must provide every extension! Don't fall neck-deep into code bloat, especially on your first try. Focus on the ones you care about, or which games you enjoy utilize. | ||
+ | * Remember that your save files need to be aware of which extensions ought to be enabled in order to correctly restore a gameplay session. An easy way for this is to do what ZZT itself does, and share the code for creating world files and save files. | ||
===== Side Notes ===== | ===== Side Notes ===== | ||
Line 203: | Line 217: | ||
* A string-based ID system would increase implementation difficult, particularly on older compilers; | * A string-based ID system would increase implementation difficult, particularly on older compilers; | ||
* The owner/ | * The owner/ | ||
+ | * Save files are not mandated by the specification for two key reasons: | ||
+ | * Some extensions may require data specific to save files, and implementations may wish to have the freedom to decide how to store them in this case; | ||
+ | * Some implementations may store ZZT data in a custom format internally, and removing this requirement can make their code simpler. | ||
+ | * Multiple concatenated extension headers may be used as a feature in the future - for example, for faciliating multi-patch application for ZZT worlds. | ||
===== Implementations ===== | ===== Implementations ===== | ||
+ | |||
+ | This is not a formal part of the specification. | ||
+ | |||
+ | ==== Libraries ==== | ||
+ | |||
+ | === ZXT 1.0.x === | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | ==== Tools ==== | ||
+ | |||
+ | === ZXT 1.0.x === | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | ==== Engines ==== | ||
TBD | TBD |
zxt/format_specification.txt · Last modified: 2021/08/11 06:21 by zzo38