In gaming, nearly everything is closed off to the end user, and any open access to something is handled through explicitly defined means (like Mario Maker's own editor), or unauthorized modifications to existing code (see: every single Super Mario World romhack). ZZT boasts its editor and even the free shareware version offers no restrictions on making or playing other worlds, but sometimes people did want to restrict others. ZZT offers a few explicit restrictions and combined with more technically inclined folks hex editing and exploiting other bugs in ZZT, we have a surprising number of ways to disable the ability to edit a ZZT world. Kind of. Every single one of these locks can be broken, and even in their heyday word of how break locks spread, but that didn't stop some folks.
So the question is, why would somebody want to lock a ZZT world?
To prevent spoilers - If a world can't be edited, the player is forced to play through the game to actually see how it ends. Additionally, using techniques to detect certain cheats can make it more likely that player makes it to the end the way the author intended.
To prevent cheating - Not only to prevent tampering with anti-cheat
code, but also to prevent things like tossing an object somewhere that runs
#give health 9999.
To prevent theft - ZZT comes with the ability to export and import boards, so lifting something wholesale is very easy to do.
To protect "trade secrets" - If somebody else makes their own amazing Go-Kart RPG battle engine after seeing yours, yours just won't be special anymore.
<blink>All These Reasons Are Bullshit</blink>
Even when locking worlds was at its most prevalent, the vast majority kept themselves unlocked. If somebody wants to look at how a game ends without playing it, that's their call to make, and chances are they're doing it because playing the game is not particularly enjoyable.
Anti-cheat measures are just as annoying, trying to restrict the way people play a single-player experience. Nobody's boasting about beating your ZZT world. (Unless you're Flimsy Parkins and it's Sixteen Easy Pieces).
Board theft? A nearly non-existent problem with how rarely it ever occurred. The more consolidated the ZZT community became (which was well on its way by the time easy to use locking programs came about), the more likely somebody lifting content would be called out. Stolen boards were a good way to instantly lose respect among ZZTers.
And as for protecting code from being understood? That's the worst reason of all. ZZT thrived because of how easy it was to learn, and how tricks and techniques could spread. Countless children learned how to code their ZZT shops by looking at existing ones.
So was there a valid reason to lock a world? ...Yes, but the person who was most justified to do so could've handled it better even then. Back in the dark ages of the 1990s, you were paying money to get Tim Sweeney's registered ZZT worlds, City, Dungeons, and Caves. You got your disk in the mail and if you were a small child and overwrote one of those worlds in a way that broke the game, you were out of luck. There was no Epic Store where your account had a copy of ZZT. (Why isn't ZZT on there anyway?)
Other early ZZT worlds would offer registered versions as well, which had the same issue with difficulties in replacing a modified copy, but by and large ZZT games were readily replaced.
Admittedly, a young me definitely broke a registered copy of Jazz Jackrabbit by dumping the files for the freeware Christmas themed episode right on top of it, and it meant being unable to play the full game for years. It makes some sense for Tim to have protected those worlds (Town is also locked, and that's more questionable since you could get a copy of Town again without money being involved.) Even in this scenario, I think better than a locking system would have been a "read-only" flag that simply prevented the file from being saved with the same name. That would have prevented issues with somebody deleting an object in City, but not from learning how its Elevator board worked.
But we're not here to justify locks, we're here to bust them wide open. So let's smash every lock ZZT has to offer
- Download KevEdit
Ok. Article (mostly) over. You can just use KevEdit (and every other external ZZT editor as well as the Museum's file viewer) to open locked worlds without a care.
Okay, no. Let's smash every lock ZZT has to offer, without third-party tools.
(Normal) Lock
The normal lock (as it tends to be called to avoid confusion with other locks) is Tim Sweeney's deliberate feature to prevent certain ZZT worlds from being edited. Upon trying to open a locked world, the editor instead cancels the operation, and displays a message in the top right corner saying "Can not edit WORLDNAME!". The editor then opens up a new blank world instead.
How It Works
Since this is an intentional feature, the way it works is very straightforward. Town, City, etc. all have a pre-set flag on the world named "SECRET". If ZZT detects this flag, the file will refuse to be opened in the editor under normal circumstances.
Since worlds start with an empty flag list, there needs to be a way to get the flag set on a world to begin with. The cheat prompt can still be opened in the editor allowing ? to open up the cheat prompt and +SECRET to set the flag. Upon saving, the world will be locked. (You can use other cheats to set the player's starting health and ammo to a limited degree as well.)
Circumvention
Oops, you just locked your world to try it out and now you can't unlock it!
Don't bother downloading an unlocking utility, you can get ZZT to skip its
check with ?+DEBUG. Putting ZZT in debug mode persists across worlds. Either
open a game or the editor, put in the cheat, and then load the locked world in
the editor and you're free to edit to your heart's content. You can also
permanently unlock the world with ?-SECRET to clear the flag and then saving
with it removed.
Super Lock
ZZT's most iconic lock is also its most dangerous. The Super Lock was made by Alexis Janson as an irreversible lock that takes advantage of ZZT's pop-up windows sharing code, and corrupting a board.
Running the Super Lock tool on a world is not to be done lightly, as it makes some rather frustrating changes that make things a pain to use even when the lock has been broken. (Spoilers: It is actually easier to get around than a normal lock.) A super lock changes the name of every single board in the game to "!c;LOCKED FILE", with the exception of the final board which is renamed to ":c" and more importantly, forcibly corrupted! The corruption is induced by changing the board size 4 bytes, which lets ZZT read the board's title and nothing more.The documentation warns that a spare board should be added before Super Locking as well as to keep a backup unlocked copy of the world, and it's good advice.
How It Works
The now Super Locked file takes advantage of ZZT's hyperlink functionality. Although it's intended to be used in ZZT-OOP code for scrolls and objects, the board list uses the same pop-up behavior and will respect special formatting like hyperlinks and using a $ to make text appear centered and in white. (More specifically, it uses the parser for help files, so naming a board "#put w red fake" will just name a board that and not actually cause code to try and be executed).
Every board's title is now a hyperlink to a label named "c", which is the corrupt board. Selecting a hyperlinked board _will_ run the hyperlink causing the board list to instead jump to the :c board that it thinks is a label and open it instead! Since it's corrupt, ZZT throws a fit and crashes. It's fool proof.
Circumvention
Press escape instead of enter when selecting the board.
Yeah. That's all there is to it. Escape and enter have the same result when on a non-hyperlink line of text, but escape will let you close a window without activating a hyperlink.
Fortunately for everybody out there who wanted to keep people out of their files, having literally every board with the same name does a pretty good job by virtue of making it a nightmare to follow board links or passages since visually, they all have the same destination. The Museum's file viewer prefaces board titles with the board's number entirely because of the Super Lock.
But breaking it so effortlessly is still very funny. Especially if the world in question is Sivion.
Save Lock
Normal locks are actually kind of a strange thing, since save locks are another inherent lock mechanism to ZZT that work just as well. By taking advantage of ZZT saves being complete states of ZZT worlds, it's pretty straightforward to use the inability to edit saves as a lock mechanism.
How It Works
Once your world is finished and ready for locking, play the world, and immediately save the game. Now, throw out your ZZT world as it's no longer necessary. Instead, rename the SAVE.SAV to WORLD.ZZT and watch as ZZT is none the wiser to the fact that you're trying to "play" a save rather than "restore" it.
Except, of course, you can't edit it because ZZT can tell that the file is actually a save that's been renamed. A single byte is used to distinguish if a file is considered a ZZT world or a ZZT save. As an anti-cheating measure, trying to open a save in the editor will get the renamed file rejected.
Circumvention
Just like a normal lock, the check if a file is actually a save or not can be bypassed by putting ZZT into debug mode. And for the record, if you rename a ZZT world to a SAV file and "restore" it, it plays just fine.
Omega Lock
I'm... very confused about this one honestly, because it seems like it
doesn't work at all. In June 1999 Masamune released this lock, intended to be
combined with a normal or save lock, as a way to defeat the ?+DEBUG trick. Except it doesn't.
How It Works
The Omega Lock isn't a program to be ran on a ZZT world, but rather a pair of
objects to be placed on every single board in the game. These two objects are
identical in code, checking for a flag named DEBUG which is also set when
activating debug mode since the cheat begins with a plus. Once either object
detects the flag's been set, they enter an infinite loop of displaying text.
ZZT eventually runs out of memory doing this and crashes.
Circumvention
The methodology is sound. During gameplay setting the DEBUG flag will cause
a crash every time. I imagine the use of two objects is to make it
significantly harder to find both objects that would need to be destroyed in
order to be able to use +DEBUG.
The board also includes an anti-ZAP object to
prevent players from zapping the omega lock objects. Except while ?+ZAP will
work as a cheat and set a flag named ZAP due to
beginning the cheat with a plus sign, you can also just type ?ZAP without the sign and
bypass that cheat detection. This is strange since there is a way to detect
that the player has used the ZAP cheat by replacing
all the empties on the board with fake walls (black-on-black fakes won't look
any different after all), and then having an object check if there are any
empties on the board. Masamune's fails miserably..
I'm guessing that the Omega Lock hinged on people in 1999 not knowing that you can cheat from the editor. (Though even if you couldn't you can activate debug mode in a different world and the effect will persist as you load others.) The obliviousness is really no different than Alexis Janson not knowing her Super Lock was rendered moot by the escape key. The Omega Lock is a complete flop and I don't think anybody ever actually bothered using it.
Update: After years of appearing to be unused, an instance of a game using the Omega Lock has been found. {% zfl "https://museumofzzt.com/file/view/7142stfl/?file=7142STFL.ZZT&board=8#35,15" " The End of Time - The 7.142 Stinky Flies" %} uses, the lock, though it only does so on a single board for some reason. Still, it means somebody out there was interested.
One month later Masamune went on to release the first version of Tetris for ZZT, so don't get discouraged if your locks are easily broken.
