Town of ZZT, written and published by Tim Sweeney back in 1990, is a masterpiece.
You might be thinking, what? Epic's first official Shareware game is a masterpiece? On the level of other supreme ZZT games, including those that stretched the original engine's limits, brought on much more creativity, and had significantly more involved craftsmanship?
That's right.
When you think of titanic artists such as Leonardo da Vinci, his Mona Lisa immediately pops into your head. But this is to say nothing of all the other equally legendary things he had worked on throughout his illustrious career.
Da Vinci never knew exactly what would be his "top" creation. For a while, it was going to be a horse statue (which never ended up getting finished). He also developed prototypes for siege engines, ideas about building flying vehicles, and even plans for altering the courses of entire rivers. Only plans, but still very impressive.
Sweeney didn't create just the Unreal engine. He creates decent stuff, period.
Town of ZZT was merely the first work that made people pay attention.
For the ZZT modders who eventually went on to MegaZeux, or else designed their own game engines later, they have a common complaint about ZZT. This was that the engine was too limited.
That is, it was too limited for their own liking. But they never had the original source code.
Tim Sweeney, on the other hand, had the source. The engine design, for him, had been tailored as a way to accomplish his own design objectives. So it wasn't limited at all. It was, in fairness, just right.
No one could have known at the outset if ZZT was going to be the "next big thing." But in retrospect, there were small things, key details, that should have clued people in about the designer's superb capabilities and very good judgment for game editor development.
Some of the points of interest can be found in the editor features of ZZT itself, of course. But many other points are found in Town of ZZT, when taken together with the engine itself.
To identify these points, one must really pay attention.
In order to master the pieces properly, I will establish five fundamental lines of reasoning.
I will be drawing from not just the gameplay of Town of ZZT in discussing these reasons, but the entirety of the experience. This includes the period from which you start the program to when you exit it.
It could be argued that the ZZT brand was developed even before you get your hands on it. The name "ZZT" was supposedly picked because it was guaranteed to be last in an alphabetical lineup, so that people who skip straight to the end of a BBS listing would find it.
And, in any case, a nondescript name such as ZZT will entertain the curious.
Beyond the name, though, the look and feel of ZZT is still very distinct. Unlike Kroz, the color schemes are much more vibrant. The protagonist stands out from everything else (white-on-blue filled smiley face), and the built-in objects are instantly recognizable despite their ASCII character limitations.
Even the menus give ZZT a distinct look and feel. With the exception of a few full-page screens like the mouse/keyboard and color/monochrome selections, you have either sidebars containing all information and keyboard codes you need to use the program, or large scroll interfaces that work in a very intuitive way.
Show anyone a screenshot of ZZT who has played it--that person will always identify the game as ZZT, 100% of the time.
The sounds of ZZT are also quite distinct. Musical jingles and drum sounds are strewn through all of Town of ZZT. Audio feedback for individual player actions and board events are instantly recognizable by someone who has played the game before.
Tim Sweeney was never big on Pulitzer Prize-winning scriptwriting, so the plots found in his games tend to be very basic. You don't really need to pay attention to an overarching narrative in his games. This is fine, because many game players don't even care about narratives anyway.
Still, one must storyboard the progression of the game well, even if plot is nonexistent. Here is where the fundamental "board design" system of ZZT is critical.
Call each individual "stage" what you want: a level, a board, a mission, whatever. It is clear that there was a rationale in calling the stages "boards." The board represents a snapshot in time, not unlike an actual storyboard frame drawn out with pencil and paper. In this respect, the time of concept-to-implementation is incredibly low for ZZT.
Starting the ZZT Guy in the center of the town, and allowing free exploration in any of four directions, immediately introduces an open-ended aspect to Town of ZZT and what it can offer in terms of gameplay experience. The player is not forced into a constant progression from one level to the next. The "world" is open, at least within the confines of the boards within the world file.
The text labels in key parts of the boards themselves, while not unique to ZZT, help to set the tone for each board. Is the board a puzzle? Is it action-packed? Is it safe? Is it dangerous? What requirements are there to succeed, like torches for a dark room?
The use of interactive characters in the Armory (Guardian, Vendor), in the Prison (Guards, Bandit) and in the House of Blues (Jazz Man) let you know that the game needs not be 100% action. RPG elements can exist, if they are wanted. Sweeney was clearly experimenting here, in addition to demonstrating the potential of his then-new engine.
Your ultimate objective in Town of ZZT is to make it to the palace, which means, collecting five purple keys. Most adventure-style games require you to collect something to proceed, so this is a staple that gamers will accept at face value. Since you don't know where the keys are, exploration is the most intuitive thing to do. And, given the storyboarding decisions, it is the very thing that Tim Sweeney wanted you to do in the first place.
People tend to develop selective memories about how easy or hard it was to use software applications in the old days. One reason for this is that skill develops over time. When a person becomes accustomed to a user interface that might have serious flaws, it becomes "easy" to the experienced person, while still remaining quite tough for newcomers.
In this respect, it is amazing how well the GUIs for ZZT have aged. Tim Sweeney did not want to leave any control aspect to chance or the haughty philosophy found in a lot of software of the era ("Oh, you need to look up the docs in a text file that you have to quit the application in order to read").
With the exception of a few editor commands and the in-game cheat box, all keyboard controls are identified in the sidebars. More involved help, for both the in-game experience and the editor, is available by pressing "H".
There are very few times in ZZT where you will be saying, "How do I..." for very long. The controls within the game aren't very complicated anyway, so chances are good that someone who doesn't tend to read how to play the game will figure things out on his or her own.
Movement? Cursor direction keys will surprise no one. Firing? Shift key is straightforward. Torch usage? Context-sensitive, but the "T" key leaves nothing to the imagination.
The editor feature, being integrated into the game engine itself, has an amazing guide and reference. It might not have told designers how to do everything, but it was more than enough to get people started.
Although TOWN.ZZT was not originally editable, Sweeney must have figured people would want a sandbox. Hence, DEMO.ZZT provides this sandbox, while TOWN.ZZT serves as the immutable gold standard.
People would have liked to look at how TOWN.ZZT was created (even if they had no intention of overwriting the original). But jailbreaking TOWN.ZZT wasn't necessary for third-party designers, given all the documentation available.
The knowledge-base of ZZT was eventually "expanded" beyond its original charter. Kevin Vance, in particular, worked to reverse-engineer the world file format, allowing access to all files (even the official distributables) and resulting in advanced editors with fewer limitations.
It goes without saying if that the original game and documentation weren't already great, no one would be attempting such knowledge-base expansions.
ZZT was outdated in terms of graphics at the time it was released. But it shines in other areas. Many features of the ZZT game engine work extremely well for what they are worth.
The game was written in Pascal. Pascal would eventually give way to C and C++ within a few years as the premier general-purpose programming language, but throughout the 1980s, Pascal was an ideal choice for MS-DOS applications.
The timing resolution for a ZZT game tick iteration was 9.1 Hz, or half the rate of the default interrupt timer frequency. It was great that this consistent timing was present, because many PC games had the problem of unwitting obsolence created from poor timing implementation (read: Kroz). Having the screen update at this rate was also good for a different reason: average performance expectations.
ZZT was built to the spec of the classic IBM PCs, which might not have EGA or VGA, and might not have a special sound card. The lack of hardware blitting capability drove a humble update rate. The 8086 microprocessor was relatively fast when it was released, but without special blitting hardware, it wasn't wise to expect 60 Hz for either a drawing rate or an update rate. At 9.1 Hz, though, everything works well with minimal slowdown.
Object and memory management weren't completely ideal in ZZT, but they were good enough to move back and forth between multiple game worlds, in both editing mode and playing mode, without the risk of performance degradation or crashes due to unreleased memory. The RAM limitations of the 8086 don't visibly impact Town of ZZT's execution, at least. More ambitious third-party games would eventually tax the limits, but this came from ambition itself--not the original author.
Sound playback in ZZT consists of PC speaker constant tones and Pulse-Width Modulation drum sounds. The normal musical tones, synthesized from stock sound effects or #PLAY statements, remained consistent in spite of CPU speed increases. The drum sounds fared worse (given that they were indeed CPU-dependent), but this only affected how the percussion effects sounded, rather than how the game played.
ZZT-OOP as a language left much to be desired. However, its very simplicity (not unlike assembly instructions) made for easy-to-understand code. The forward-only parsing strategy used when reading a line of code had the effect of making the overall execution process much simpler than if the code were compiled. The execution of ZZT-OOP ended up slower, but the price was well worth the result.
Some ZZT-OOP commands (#PUT, #CHANGE), when run on an 8086, reduce performance to a crawl. Town of ZZT strategically implements such commands when a board-altering event does not require real-time interaction between the player and enemies, or otherwise action that requires consistent movement timing. In particular, the palace entry color change sequence and west corridor overwrite sequence do not hurt performance in a detrimental way when the player can only move in an incidental fashion.
Key aspects of Town of ZZT reflect quality. To find these quality points, one must take a close, appraising look at certain boards in the game.
Armory: Very little is going on in the Armory at first. One vendor is helpful, and the other is very unhelpful. The presence of the key (and treasure to unlock if the key is collected) encourage critical thinking. The room also serves as a hub for secret passages, so clues will reward wall-searching.
The Three Lakes: This is one of many boards that implement the "re-enter when zapped" attribute, which pauses the game and sends the player back to the board's point of entry whenever damage is taken. Town of ZZT has this attribute set for more boards than most other ZZT games, which reflects a more "one-hit-kill" philosophy than the game engine itself normally favors. The zapped attribute, when used in conjunction with arcade-like spinning gun gauntlets and enemy-packed arenas, ends up stopping the player from taking too much damage at once. One should realize the mistake of running into danger too quickly.
The Rube Board: The first few boulder puzzles in ZZT are not punishingly difficult; they just need to introduce the player to this type of pusher-boulder-slider puzzle. Player bullet-firing is restricted as a way of reinforcing the notion that it's one's mind that must be used to solve the puzzle, not one's weapons. Text clues assist the player in solving the puzzles.
Caves: A few torches are found in the opening screen, so the player is not likely to enter the caves completely unprepared. A message informs the user that a torch is needed, which helps for people who have no idea what they are looking at when they see a dark room. More importantly, the player, the exit passage, and all torches are always lit within a dark room even if no torch is activated. Chances are good that a first-time player will figure things out.
Bug Maze: The bug maze is one of the first locations in the Town of ZZT that requires the player to actively shoot targets. Plenty of ammunition is provided right away, and the narrow corridors make centipede targeting very easy and intuitive. Tougher enemies (lions, ruffians, tigers) are introduced much later.
Castle Labyrinth: The multi-room castle dungeons are labeled with the message "Prepare to DIE!" as a way of warding the player from acting recklessly. Even more significantly, the player must progress through multiple successive challenges to get this far, including a spinning gun gauntlet, a troll payment, and a brief skirmish in the anteroom.
House of Blues: The puzzle here has great audio-visual feedback, and the puzzle is not bungled permanently if the sequence is entered incorrectly. The player must listen, remember, and keep trying. This can be done without saving and reloading, so experimentation is encouraged.
Satisfying ending: The endgame portion of Town of ZZT plays a fun victory rap and closes the adventure with a simple and silly summary. It isn't much, but you feel you've reached a true "mission accomplished" moment.
Perhaps the best feature of the original ZZT release, though, was the save feature. You might think this can't be attributed to Town of ZZT specifically, but the nature of Town of ZZT makes the save feature quite important in its implementation.
When you save a game in Town of ZZT, you save the state of the game in real-time. That means the specific board, all the progress in that board (right up to the fraction of a second), and all inventory and world progress will be remembered perfectly. Granted, the "state" that is saved is actually just a glorified copy of the modified world file itself, but it set a standard. This turned out to be a very important standard, which found its way into future engines, such as Unreal.
Often, we forget how inconsistent things had gotten with saving your progress in early PC games. Some games let you save your full progress on the disk, some dealt with only specific savable checkpoints or inventory retention, some used a password system, and some (like roguelikes, or else lazy design) just forced you to play for a long time, because, screw you.
With ZZT, you need not worry--you can save and restore anywhere, anytime. You can leave the Town of ZZT and return any time you want.
Undoubtedly, people would want to counter my points here by mentioning all the areas where quality in ZZT is lacking. Lagging performance, incomplete editor documentation (only a few features weren't documented), artificial editor color attribute limitations, having to end the current game to restore progress, no re-use or additional support for file formats, constraining status element limit per board...you get the idea.
But Tim Sweeney could not have possibly gotten everything perfect.
Still, he came pretty close. He made a gold standard. That is what makes a masterpiece.
Town of ZZT is a masterpiece.
There are no comments for this topic.
To enter a comment, log in using the ZAPTCHA.
