2018 ZZT Project

qrleon's picture
Capture d’écran de 2018-05-27 10-52-58.png

I'm working a lot of graveyard shifts lately, and have found myself turning to ZZT to burn idle time when I'm home and nothing's open. ZZT is technically very simple, but I find myself going OCD messing around with details in KevEdit, and the time just melts away.

I made a handful of draft game/puzzle boards, but I'm lukewarm about the overall story / circumstances I've plotted out. Struggling to make it all fit together. I've sunk too much time into it to stop now, though. The World file is over 100 kilobytes. The recommended safe maximum is about 250KB. I really don't want to split this into two files, so this should be an effective hard limit on what I can put in. I'm going to try and get the game at least mostly laid out by the time I return to day shifts.

I plan to make heavy use of dark rooms for the central hub, and use the black torch/passage effect to highlight contours of what would otherwise be a completely grey screen except for the little torch-carrying player. The problem with dark rooms in ZZT is that torches only last for about 22 seconds, so even if you have a large supply, you have to keep pressing T to light them. So I want dark rooms to play a significant role, but not for the player to be stuck doing too many consecutive tasks at once in the dark.

Indicating all contours in dark rooms is also a potentially dangerous design choice, as it can lull the player into a false sense of security: they may delay lighting a torch because they can "see" the path ahead, even though they may be walking straight into a newly-spawned set of enemies. The solution is likely to make the paths a little more winding within the space between the contours. I'll have to do some tests.


qrleon's picture

Devlog: 28 May

I think I have a story start-to-end that will work. I'm feeling tired, but good!

I'm not sure if big "engine" boards will be appropriate for the tone I'm going for. I need smaller chunks of game that are easier to manage, can be blended together, can be understood without long explanations, and are less prone to elusive ZZT-OOP bugs.

In one case, I had a board that I was pretty proud of that implemented something I wanted to do for a while: direct objects to build components of a small village. You win the board when it contains a certain number of unique structures (house, tower, mill -- really just abstract shapes), a river, a lake, at least one forest tile, etc, and they all fit within an enclosed space. But it was about 19700 bytes in size. If a ZZT board goes over 20000 bytes, things go bad. And if there was a major bug lurking in there that needed more scripting to resolve, it would be almost impossible to fix without cutting things. And what if I needed to add additional game-wide management scripts to every board? It's just not worth it.

I'm also dropping art boards where the player would be put into a box in the corner (see attachments). This is against my nature, as I enjoy losing myself in drawing things, but that's not what I want for this particular project.

Back down to about 75KB now.

ghoul03.png77.4 KB
ghoul02.png58.17 KB
ghoul01.png44.9 KB
qrleon's picture

30 May

I was able to make a smaller and simpler version of that 'build-a-village' board I mentioned cutting. It doesn't fill up a whole screen anymore, and at below 10KB, it leaves far more wiggle room if something major needs to be changed further into development. Maybe I can salvage some other cut boards by simplifying them down as well.

I would like components that don't require too much written explanation, preferably none. I'll need to find some way to let the user know that certain conventions are going to be present across the game, like using a specific symbol for objects that reset a mechanic in a given room.

I'm not sure if this will be 100% possible, but I would like every puzzle to be fully resettable. Unfortunately, ZZT makes it very easy to put itself into a non-winnable state, and then balances this out by allowing the player to save anywhere.

Enemy encounters, if I have them, cannot really be 'reset' in the same way. ZZT is a game where resources are exhausted as the player moves through the world -- ZZT save files are 99.9% the same format as ZZT game files themselves, and you can watch the file sizes of these saves diminish as the player gets closer to completion -- because the objects have been destroyed, items picked up, forest cleared -- the world is just emptier after you've stomped through it.

I'm working myself too hard, need to take a break and relax for a bit. But I have a plot synopsis that I'm OK with, and the overall tone is decided. I should probably take some time to play through recently released ZZT games and see what I've missed.

shapefill-small.png59.08 KB
shapefill-old-solution.png50.57 KB
shapefill-large.png64.96 KB
sergiocornaga's picture


I had no idea ZZT save files functioned that way! Super interesting stuff.

qrleon's picture

For sure, it blew my mind

For sure, it blew my mind when I realized that you could rename save files to .ZZT, open them in KevEdit, and see the exact state of the game frozen in time.

qrleon's picture

31 May

Working title: Faux Amis

Early plot drafts involved something absurd happening to the sun. The idea was to have the player fetch six macguffins, one at a time, and sell them to an NPC located on a summit, which has a wide view of the sky. Eight yellow objects clumped together represent the sun, and would travel a few steps West every time an item was delivered, from 6 AM on the right-hand side of the screen, to Noontime at the center.

At noon, something absurd would happen to the sun, like a rocket shooting out of the ground and blowing it to smithereens, or a straw extending from the ground, drinking the sun away like a juice box. The player would then be transported to a dark version of the game world, where torchlight is always needed to see. I dropped the summit and 'sun catastrophe' to focus on other parts of the game, and to condense player travel. I'll still have a dark version of the map, but it'll just take place at midnight.

But I am oh-so-hesitant to cut that sun animation. I tried sticking it into the central plaza area of the game, which has a much smaller view of the sky. It doesn't look right, because clearly the sun is not the area's light source. As a compromise, I'm shoehorning in a false lighting effect where the rooftops of buildings in the area change their shading very slightly as the sun travels westward. It's not perfect, it only affects one screen's worth of the town, and it uses a good chunk of my object budget, but hopefully it works out. This is a bit of a gamble. A GIF of the seven lighting states is attached.

I'd also like to figure out how to add some very small movement to the clouds, but I also don't want to push my luck.

f-a-sun.gif690.44 KB
f-a-title-screen.png53.49 KB
let-off-studios's picture


I was fascinated with the lighting effect on the rooftops. I think you should keep it, for sure.

Have you seen what it looks like without the sun in the sky? I think you're right: the sun is too low in the sky to be the light source for the rooftops, so it seems out of place. I personally think a player will be intelligent enough to see the changes on the roof (and maybe some building shadows on the ground) and that would be enough.

qrleon's picture

Oh good point! I will give

Oh good point! I will give that a try.

SpindleyQ's picture



qrleon's picture

The sun is a set of

The sun is a set of bright-yellow objects travelling over a blue fake floor. When the top or bottom pieces of the sun detect an obstacle perpendicular to them, they toggle from/to #char 32 (solid background color) and #char 219 (solid foreground color). Hidden obstacles are placed next to the grey-on-grey fake floors that are representing the clouds, so that parts of the sun appear to go behind them, and then eventually pop back out. The fake floors where the sun is supposed to be covered must have the same foreground and background color in order for this to work (if a ZZT object is on a fake floor, it will display the same background color as that particular fake).

The sun objects are directed by a separate management object that adds some delay to the movement. The stat order for the sun objects puts the leftmost objects first, so that all objects are able to move together in one tick (otherwise they would bump into each other and break apart).

The edges of the rooftops are made of bright-red-on-dark-red objects, with two labels that set either 'all-background', '50/50', or 'all-foreground' characters. A rooftop controller object sends messages to set the correct characters for a given hour. There are seven main rooftop objects, and the rest are #bind'd to accept the same messages.

The rooftop controller is directed by the object that controls the sun. Both of the controller objects use label zaps to apply the seven states sequentially.

Right now for debugging, the sun manager acts when the player touches it, but eventually there will be a loop checking for flags.

Edit: the GIF is missing the four steps West that the sun takes for every hour that is supposed to pass. Halfway through those steps is when the rooftop objects are updated.

qrleon's picture

2 June

I got my first editor crash yesterday, a celebratory milestone when making mid-to-large-sized ZZT games. KevEdit is a lovely tool, but both it and the ZZT internal editor sometimes corrupt game files, or crash to the command line under certain circumstances. KevEdit mainly seems to crash when rearranging the order of boards on the menu list. Because of that possibility, I make a new file almost every time I go to save. This also means that I have a snapshot of nearly everything I've done on the game with timestamps. I wish I had kept those WIP files from my old projects.

Attached are some screenshots of what I'm going to try with dark boards. Under normal circumstances, a ZZT dark board is covered in a grey fog. Players have to light torches to see a small radius of cells around themselves. As a convenience / mercy, Tim Sweeney opted to make passages to other boards and torch items always be visible on dark boards. If you recolor torches to the same foreground and background color, you can fill in negative space which will be rendered instead of the fog. (You can also use hacked passages (remove them from the stat list) to achieve the same purpose, but this carries the danger of transporting the player to the title screen with no way back, and we don't want that to happen.)

In the past I have used this effect to outline the general shape of an area, but I want to try and take it one step further and make it part of the illustration process.

f-a-dark-outlined.png47.5 KB
f-a-dark-normal.png42.08 KB
f-a-not-dark.png53.52 KB
qrleon's picture

5 June

10-hour night shifts leave me little time after work to sit in front of KevEdit, but a lot of time for 'what if I do XYZ' thoughts to cross my mind. I'm 4 days on, 3 off until July. Those three consecutive days off should be productive. I'm going to try and set a hard finish date for myself on or before July 6.

Current dabbling: I'd like one or two moments where an imposter player passes through an area that the player has either already been to, or will be visiting, and performs some echo of an action that has been done, or will be done. The ZZT player is a white smiley on a blue background, and AFAIK it's the only creature that doesn't change its background color to match fake walls / floors beneath it. For a non-player object to have a blue background, it must either 1) never move, or 2) only ever move over fake walls that have a blue background.

There seems to be a way to make it appear that an object has its own independent background color by using two auxiliary objects. These helpers move along with the main object in parallel, #putting down fakes in front of the object, and then #putting empty cells behind them. The empty cells that the object will walk over must have their background color pre-set. Although empty cells in ZZT are always rendered black, a fortuitous oversight in ZZT-OOP means that if you #put a fake over an empty cell, without specifying a color (ZZT-OOP can only specify bright foreground colors), the empty cell's color information is passed on to the fake.

The order of the objects in the stat listing is also crucial to making it work, to prevent the auxiliary objects from overwriting the imposter player with their #put commands.

@zero: sends movement signal to object @one
@one: lays down a fake wall in front of the imposter player, signals the fake player to move (@two), and also moves itself.
@two: the fake player object signals @three to act, and then moves. @two is capable of moving one step before @three acts, like a fly just barely escaping from a fly swatter.
@three: places an empty cell behind the player so that a trail of blue fake walls is not left, then moves itself.

@oneb and @threeb are a second set of auxiliary objects to follow the fake player in a different direction.

This is all pretty fragile, and vastly unnecessary, but it didn't take too long to put together, and might be fun to stick into a spoopy dark board somewhere.

f-a-fakes-moving.png33.51 KB
f-a-fakes-stat-order.png49.75 KB
f-a-fakes-in-editor.png40.7 KB
qrleon's picture

I made an unnecessary GIF to

I made an unnecessary GIF to demonstrate what is happening in this unnecessary effect. The GIF is missing a couple of details that I'm not sure how to integrate: 1) In ZZT, when an object sends a message to something else, this alone does not cause the sending object to yield processing. A movement command does cause a yield, though. 2) The empty cells in front of the player are tweaked to be blue-on-blue, even though empty cells only render as black.

f-a-gif-contemplation.gif165.15 KB
qrleon's picture

7 June

I planned to have three areas in the game:

1) A surface overworld with dialogue-driven subquests (ostensibly a tutorial)
2) An underworld maze that requires torch lighting
3) Accessed from the underworld, puzzle/treasure rooms with no dialogue at all.

I have a pile of action-puzzle chamber ideas for #3, and a few ideas for #2, but I'm struggling to link them all together. Although #1 is mostly laid out, I'm having difficulty filling it with actual content. I'm going to try and determine a solution to this by end-of-day.

Attached is a stitched-together map of the overworld as it is right now. The bottom three boards will contain one passage each to the underworld.

f-a-overworld-7-jun-2018.png19.64 KB
qrleon's picture

9 June

I think I have a solution to the underground layout.

Divide the underworld into three isolated Zones with two Sectors each: ZASA, ZASB, ZBSA, ZBSB, ZCSA, ZCSB.

The first Sector of each Zone contains a passage to the overworld, and the player may access each of them independently. They also contain a path to their "B" Sector, but they are blocked off at first. Finishing all of the puzzles in the first Sector of a Zone will unlock the Sector B of a different Zone, and open up a shortcut between the first Sectors of both Zones. Once all Sectors are completed, player will have enough funding to move onto the third act.

I need some kind of gate structure / junction to accomplish this. Attached is something that might work, though it will need to be much smaller on the final layout.

I found a solution to giving the clouds a tiny bit of motion on the overworld, without breaking the bank: some dithered blocks are objects that shift their dithering pattern slowly, and in a staggered manner. When a ZZT object is set to a slower cycle, ZZT will automatically stagger the processing of those objects across ticks, which is super frustrating if you're trying to build reliable mechanisms, but can be useful for decorative purposes. I also added lapping water to the shoreline and whoops my object limit on the title screen is completely exhausted

f-a-title-anim-crop.gif346.91 KB
f-a-sector-junction.png66.82 KB
f-a-dark-halls-planning.png54.46 KB
let-off-studios's picture


That overworld map looks lovely! Such a nice look for the water. The subtle movements have just enough in them to really bring the scene alive. Nice work!

qrleon's picture

Thank you! This means more

Thank you! This means more hidden objects to keep track of, but I think it was worth it to give a sensation that it's not just a frozen tableau. I'd like to have some animal objects as well, maybe hermit crabs, but they'll have to be placed on the West coast board which still has object resources available.

Lower areas will be more abstract and utilitarian.

let-off-studios's picture


I think having environmental animations in one part, and fauna animations in another, would make both of them unique and memorable, and will do wonders for the game world as a whole. Even if it's like a tree and there are tiny blinking hoot-owl eyes in the hole of a tree trunk. A little sand crab poking its head out from a sand dune would be so great, and definitely a nice touch that sets this apart from other ZZT games.

I completely understand the subterranean areas having much less in terms of animation, but it only serves to amplify the contrast between the two worlds.

I appreciate you sharing your development in these blog entries, by the way. It's been refreshing my own understandings of level and world design. Thank you. :)

qrleon's picture

Thank you! I appreciate your

Thank you! I appreciate your comments.

qrleon's picture

12 June

Came up with some layouts for the Zones and Sectors (attached). The plan is to smash the two Sectors of a Zone into the same set of boards, so that the player can see further challenges before getting to them, I guess as teasers.

The Zone B layout gives me a place to insert that imposter effect I mentioned on 5 June. I'm hoping I can fit it in twice, but it depends on how much else is going on in that board at the same time.

Three puzzles / challenges per sector, two sectors sharing the same boards per zone, three zones = 18 puzzles. The puzzles I have so far are nothing special, but they were fun to implement in ZZT-OOP. How you progress through them is equally as important to their overall quality and stability.

f-a-zone-layouts.png95.15 KB
qrleon's picture

14 June

I got the imposter effect working, two instances in one board, using about 14 objects in a specific order. The effect breaks if running DOSBox at 3000 cycles or lower, with the fake blue walls showing before the imposter object walks on them, but at 9000 cycles it looks fine. I guess ZZT just updates the screen on-demand, no buffer flipping? The imposter object to the south doesn't contain a blue background near the end of its run, because there is a bug in ZZT that prevents the #put command from modifying anything on the bottom-most row. The one on the north looks flawless at a high cycle rate, though. Good enough. Now I just need to not break the effect between now and release.

On a disappointing personal note, I have noticed some truly awful content in my old ZZT games -- projects that were made before I joined Glorious Trainwrecks, and that I haven't really inspected in about ten years. I'd like to make some adjustments to them to reduce the badness. At least one project is patently irredeemable, but at the very least I would like to try and make some corrections to my adventure game Eli's House. If you played this game and were hurt by it, I am sorry.

I'm aiming to release modified versions around the time that Faux Amis is released. This may push back the release date, but it feels imperative.

[edit 20 July 2018: this will have to wait due to lack of time and energy, and some obscure ZZT-OOP object programming and flag checks that I have long lost familiarity with.]

f-a-imposters-working.png89.15 KB
qrleon's picture

20 June

I did a lot of work on the first act, slow and arduous, like carving. I'm teetering around 194KB now, which carries the dual sentiments of "lots of work done, good job" and "uh oh, I could be running out of space soon". It's a strange feeling to be earnestly counting bytes in 2018.

I am now firmly in "I just want to get this done and move on" territory. I'm cutting the puzzle rooms down to six, which is what I had in mind originally. I may need to renege on my goal to keep narration to a minimum, as the environment I've made is not as self-explanatory as I thought it would be. I'll hold off on making that decision until later.

One thing I forgot about, that absolutely I loved working on in ZZT, is threading dialogue with flag checks and label zaps to personalize reactions to the player's behavior. For example, if the player goes into an NPC's house, and immediately starts messing with that NPC's belongings without talking to them first, ZZT-OOP is very capable of catching that and having the NPC say something like "who are you, and why are you messing with my stuff?", and then have that blend back into the main NPC dialogue. Flags permitting, you can reference that behavior further into the game.

qrleon's picture

23 June

I didn't get too much done on my days off between 20 June and now. I wrote dialogue for the story's climax, which felt pretty cathartic -- I've been putting it off, and putting it off. Getting even a rough version of that scene present and accounted for, in the project file, helped clarify the shape and boundaries of the game to me.

I think in the end, I'll be jettisoning the effects that initially spurred my interest in making another ZZT game, including the player imposter effect that I was really proud of.. they just don't fit into the game as it is now, and the target finish date is approaching fast. I'll include them in the world file as extras, if there is space left over.

To help with the dark board layouts, I made a torch radius template that can be copied and pasted in KevEdit, to see what the player would see at a given coordinate. Pasting in KevEdit will overlay the pasted elements, and prompt you to reposition them before committing changes to the board. Pressing ESC will cancel the operation, leaving the board unchanged.

Capture d’écran de 2018-06-23 05-15-00.png60.43 KB
Capture d’écran de 2018-06-23 05-14-35.png50.01 KB
qrleon's picture

27 June

I'm on track to be done next week, assuming no unexpected things come up. I'm going to stop posting updates between now and then, as most of the unsure things that I've been writing about have either become clearer, or have been dropped altogether from the project. I just need to finish implementing the final act and ending, clean up the puzzles, and then go through some playtest-fix-playtest cycles until it's more or less done. It won't be the game I pictured in the beginning, it might not even be all that good, but it'll be something.

Almost there...

Capture d’écran de 2018-06-27 02-28-40.png40.24 KB
qrleon's picture

5 July -- Beta

Attached is a beta version of Faux Amis. If you find any issues or get stuck, just let me know! I'm not sure if certain parts are going to be too vague.

I'm going to sit on this for a week or two in case any major problems are encountered, then probably throw it on Museum of ZZT and itch.io with a walkthrough text file, and that should be a wrap.

You will need ZZT, most likely running within DOSBox to play this. The Museum of ZZT has a guide for setting this up on modern systems. Recommended DOSBox cycles: 9000 or higher.

If you run into any unwinnable state issues, I can modify your save file directly to fix it and then sneak in other changes unique to that save without telling you.

sergiocornaga's picture

Definitely stick it on

Definitely stick it on archive.org too! I think being browser-playable is a pretty big draw for ZZT stuff and probably more people will end up playing it. At least, I get the sense that happened for Atop the Witch's Tower.

qrleon's picture

Oh whoops yeah, I totally

Oh whoops yeah, I totally blanked on archive.org! I'll add it there for sure. I'll have to check if there is any way to set 9000 cycles as part of the configuration, as the game lags on the central plaza area at the default 3000. Too many objects sending messages and changing their characters in a single tick.

Lynx's picture


Been following since your first post and pretty excited to play it!

First thing I'd like to say after playing it is, Great Job!
I really enjoy cohesive Zzt worlds.
The good:
Your color schemes buildings and effects were all on point to create a solid place for puzzles and narration mechanics.
The puzzles I was able to complete took just enough figuring out to not be too entirely tedious.
The great:
I especially liked the color blocks puzzle.
Fitting those shapes in that square took just the right amount of tinkering after I figured out the mechanics, and left me feeling like I had accomplished something.
No time was spared creating the water and particle effects (ship effects).
The bad:
I like your idea of not having to give much explanation, but with several puzzles, no amount of tinkering was enough for me to figure them out.
(the ammo, scroll, boulder puzzles). But I'm not much good at puzzle games I the first place.
It would be nice to have an easy system to know how many Fowe dollars I had, and which kinds.
I'm not sure if you meant to, but I had to go underground and come out to the shopkeeper every time I wanted to exchange dollars. It took me 3 times to get enough gems.
Lastly, I wasn't familiar with the way you used the torches underground, and didn't figure out that I could use one to see better until the end of the game. I'm sure it would be intuitive for some people, but for me it just wasn't. I'm going to replay the entire game in a bit and see what I missed.

Overall I give the game a 4 out of 5 in its current state. Very well done.
Grrr… I'm going to have to make something now. Too bad Zzt is so funly frusterating.

qrleon's picture

Thanks, hope it's

Thanks, hope it's interesting! I've caught one flag bug so far, but it was only a cosmetic issue.

I ended up compressing flags Nightmare-style, but during testing I found that I had missed some of the checks at some points causing unwinnable states (!). Every time I thought I caught them all, another one seemed to pop up.

qrleon's picture

Thank you for playing

Thank you for playing through it! It sounds like some more explanation is needed in some spots, particularly with the robot scripting room. Maybe an underground companion that provides hints would be good for that.

When you received gold dollars, were you contained within a room with a passage that forces you to warp to the pawn shop? if you had to walk all the way back out, then something's definitely broken.

Do you feel that the shape puzzle would be better if the layouts of each block were shown in a message box upon first touching them, or is that overdoing it?

Lynx's picture

shapes or no shapes?

It took me about 5 min of poking around and shooting things till I realized the were making shapes, and reverted if there wasn't enough room.
That Aha! moment set it apart from the other puzzles in terms of enjoyability. I think it's the most balanced puzzle of the bunch. And with my puzzle solving skills, lacking as they are, most players should be able to figure it out.

qrleon's picture

I really appreciate your

I really appreciate your feedback and perspective. I've been staring at this too long, seeing the MS-DOS dithered patterns when I close my eyes haha.

I'm going to make some adjustments on my next break that should hopefully cut down on potential confusion in the labyrinth.

Lynx's picture

Do over?

One of the other great things I forgot to mention is the resettable nature of your puzzles. I think you nailed it.
I think that your game deserves a playthrough by anyone currently interested in Zzt, oldbie or newbie.

qrleon's picture

Will put up a final release

Will put up a final release this Saturday.


* The passages behind the red gates have been replaced with direct board links to the Dark Halls Labyrinth. whoops this was already done im losing my mind
* Force additional "Room is dark - need to light a torch!" messages when first encountering dark boards with black-on-black torch masks.
* Various cosmetic bug fixes, and compressed flag errors fixed.
* Remove branching paths from the labyrinth, making the player unlock all red gates in order to finish the game. The branching paths were from a time when I imagined that the labyrinth would be more like a standard video game dungeon, but as-is, they are just pretty conduits that lead to the puzzle boards.
* Red gates are locked up after their two puzzle boards are completed.
* Protocol board: the first object will default to having a script that causes it to move in a horseshoe pattern.
* Major oversights in the distribution of gems to the player from the pawn shop have been corrected.
* Most importantly, recoloured the "X" on the title screen to red.

Edit: It's up now.

zzt_000.png4.47 KB
sergiocornaga's picture

I'm enjoying this a lot, but

I'm enjoying this a lot, but I think I got the tombstones puzzle into an unwinnable state and can't see any way of progressing other than to reset the game?

qrleon's picture

Uh oh. Could you attach a

Uh oh. Could you attach a copy of your save file? I'll jump in and take a look!

Edit: If you're playing on archive.org and can't get the save file, as a workaround, you can use the zap cheat code to remove the four fake floors in the northern chamber. This will complete the subquest. If the tombstones or filing cabinets are in the way, it's safe to zap them. Amy Undertaker should not be zapped though.

To zap, press Shift + /, type 'zap' into the cheat prompt, and press enter.

Edit2: Looking at the board, I found a couple of possible unwinnable states. Attached is a change that I believe should prevent it from happening in a future version. I can tweak your save file to fix those stuck tombstone objects if you'd like.

kevedit_001.png1.86 KB
qrleon's picture

20 July - v1.01

I've released an updated version on itch / archive.org / Museum of ZZT to fix the tombstone puzzle, and remedy some additional unwinnable state issues found during Dr. Dos's livestream of the game.

Unfortunately, save files of the earlier version cannot be migrated to v1.01 due to the nature of how ZZT handles saving.