Making Games in ZZT

For the first time since 2017, I made a little game in ZZT! It's part of the upcoming 2024 Vextro anthology release, so I'll be publishing it in December as always. I was honestly surprised by how much of a delight ZZT was to work with; thanks to advances in tooling and my own knowledge of the scene, I had a better time with it than I did the first go around. I wanted to share a little primer on it in case other folks want to try it out.

Here are the main assets, in my mind, of using ZZT as a dev tool in 2024. 

• Simple top-down "walk around and interact with things to make text boxes pop up" language is cozy, familiar, and endlessly flexible. I'll be comparing ZZT a lot with Bitsy and RPGMaker since I think the three engines offer a similar language with interesting differences in their approach.
• The built-in object programming language is shockingly flexible, giving you much more power over your game logic and world than Bitsy (while still not as much as RPGMaker event scripting, which I'd argue isn't entirely a negative). 
• ASCII art style is attractive without forcing you to make custom assets, and without having the "stock" look you get from using more detailed default assets.
• Light-weight and extremely easy to deploy: thanks to asie's open source Zeta emulator, ZZT runs on all major desktop environments, AND in browser (albeit not on phones like Bitsy or Puzzlescript). All in under a megabyte for each version! And thanks to asie's Reconstruction of ZZT, the core engine is open source as well!

All in all, ZZT has a legitimate niche if you can get a handle on its quirks. It's completely FOSS now and it has a microscopic footprint. It runs in the browser but doesn't require a browser. It's a great tool for making top-down walking sim story games (a genre I really like) that also has the flexibility to incorporate action game setpieces, dungeon crawls, and puzzles. That opens up a ton of possibilities for interesting storytelling.

When I made Atop the Witch's Tower, I did everything in DOSBox with the default ZZT editor. For non-standard colors, this meant importing hex-edited boards into my game and manually copying tiles from them. The ZZT editor also had the nasty habit of wiping object code when I had too many objects on the board at once. Most of the magic of ZZT's language was still present in the original level editor — but it was undeniably a pain in the ass. 

This time I used KevEdit, a tool originally made in the early 2000's to streamline ZZT dev. KevEdit's great! The biggest hurdle for most folks I suspect is that it's keyboard-only, but I enjoyed painting boards with the arrow keys. Beyond that it adds a ton of conveniences that weren't present in the original editor: easily building palettes of non-standard colors, removing boards, the random fill tool, importing and exporting object code for editing in a text editor, and a ton of other niceties. I was intimidated by all the options it offers up front, but I followed along with Dr. Dos's guide on the Museum of ZZT and got a handle on the essentials pretty quick.

I talked about how ZZT's object scripting is powerful, but there's one very interesting, irritating wrinkle to it. You can't take direct control of the player object, the way you can in RPGMaker. You can't move them, and you can't teleport them to a new board programmatically. There are ways around this: the big one is putting the actual player object in a corner and having them "pilot" a fake player object that actually interacts with the game (and CAN be controlled by object code). You can also spawn boulders on top of the player to move them, or something?? Basically the alternatives are weird and annoying, they add extra friction to both dev and to play. (There are tons of great games that make use of these approaches, I'm just relaying my own experiences here.)

Every time I've engaged with ZZT, I bump up against this limitation and grind my teeth. But I vibe with it more when I think of it as a creative challenge. ZZT wants me to make the player an active participant in the story. When I can't pause input and take control of the player, I have to completely rethink how I approach "cutscenes". I think both Atop the Witch's Tower and my new ZZT's story scenes would've been less impactful if ZZT let me take control of the player avatar, because I would've instinctively gone for lazier, less interesting solutions.

Those are my immediate thoughts after slamming out a short game in ZZT for the first time in ages. I'd like to spend more time making games in the tool, as well as more time playing other people's ZZTs. I love the original Town of ZZT and rabbitboots's Faux Amis (pictured below). I'd also like to play more of the classics Dr. Dos has celebrated over the years. I think other dev friends should give it a look — if you enjoy working in high-level tools with cool limitations, tools like Bitsy, RPGMaker, or Puzzlescript, I think you'll find something to connect with with ZZT.