I made these engines a long time ago, so hopefully I'll remember correctly. I think my game world was lost long ago, so the best I can do is describe them. I had uploaded it to www.zzt.com
at a certain point, but when I checked back later it looked like it had been lost during the transition to z2.
'P' is Pressed
I created two versions of this engine. One of them relied on the fact that the player can move through a transporter without unpausing the game. The second relied on the fact that the clone object doesn't send a #touch message if the player's movement is to unpause the game.
My first implementation used a player object surrounded by pairs of transporters. Each time the player moves through a pair of transporters, a movement message is sent and the player is pushed back into position using boulders which are then removed. Only thing is, when the game is paused, the player is able to move through the transporter and also move an extra space in a given direction. This can be detected by an object.
My second implementation allowed the player to roam around the game world. There was a player clone surrounded by objects. The world was filled with forest. Every time the player moved, the clone objects would detect it and #change forest empty. However, if the movement was to get out of a paused state, then the clone would not #send a touch message, and there would be an empty hanging around for a cycle or so. This could be detected.
1. Enforce a no-pausing portion of a game, by calling #endgame on “pause” event
2. Simply make a comment like, “Welcome Back to the Game”
3. Access a game menu
4. Use “P” keypress for a game function (since it's necessary to move before pressing 'P' is detected, probably want command to be directional- for example, kick <dir>, or throwstar <dir> (see stargun engine), etc.)
'B' is Pressed
This engine exploits a strange quirk in ZZT. Pressing the 'B' button causes player clones to shoot in the current player direction, #taking the appropriate amount of ammo. This engine works by detecting when a clone shoots and then checking to see if the actual player has shot also. If both the player and the clone have shot, then 'spacebar' or 'shift <dir>' has been pressed. If only the clone has shot, then 'b' has been pressed.
One way might to distinguish would be to continually keep the ammo at 2. Then, after a shot has been fired, an object can check whether the ammo is at 0 or 1.
Sadly, the engine can be fooled if a player is attempting to shoot into a wall. In this case, the engine will register a 'b' press when the player has actual hit the fire button. The perfect demo level has no obstacles, plenty of empty space, breakables, gems, and water!
1. Display a message “Sound On” or “Sound Off”
2. Use the 'b' key for a game function (Perfect for a bomb function! Constantly turn empties into gems, and mask gem sounds using theme music, subtract health/score as necessary; when the 'b' button is pressed, the next empty to be uncovered is #changed to a bomb.)
This engine is a gimmick. The player has the option of fighting through a room filled with built-in enemies or he can find his way to the control room and operate a laser gun, systematically zapping the bad guys.
To control the laser gun, the player has to position himself between three control objects. There is a solid line of blinkwall sources, and in front of each of the blinkwall sources, there is a solid object. The laser gun object moves up and down the wall. When the player fires, the gun object places an empty in front of the blinkwall, and then moves out of the way. The blinkwall activates, and if an enemy is in the way, it will kill him.
It's best if the enemies are the same color as the blink wall. Otherwise, after frying a bad guy, the blink wall will sometimes leave an artifact (a dead blink wall). This is especially a problem if the bad guy happens to be right in front of the laser gun, in which case, it may block up the gun object and prevent it from swinging back into position and replacing the solid in front of the blink wall source.
As far as I know, this is a highly specialized gimmick. It's fun nonetheless to control a blink wall gun, and I can see it as being an interesting game board as part of a larger ZZT game.
This is an interesting effect. Detect when the player is energized, and then constantly change bullets into stars. The stars will move away from the player and will destroy breakables. If you want this effect to be continuous, you can continually duplicate energizers onto a player clone. But you'll probably want to repeatedly play a song or something to mask the energizer sound.
I wish I could find this board, because I remember that the engine was able to be used by others without modification or understanding how it worked. The basic idea is simple: you press a direction arrow and the main object moves from the current node to the next one; pressing spacebar teleports you to the selected world.
Modifying Built-In Object Stats During Runtime
When a built-in object moves/is pushed/or is duplicated over an empty with stats, it will take on the stats of the empty. For example, the speed of a pusher can change as it moves past a particular square. Or a bomb can be pushed onto an empty, causing it to explode without any interaction from the player. By the way, I think walking over an empty with stats “kills” it, and replaces it with an ordinary empty, but I'm not sure.
I once tried to make a two player ZZT game, but the problem is that ZZT doesn't do a good job of registering multiple keypresses at the same time.
My game was a racing game in which one player used an arrow key, and one used the space bar. Both tapped as fast as they could repeatedly, each tap causing their respective racer to move forward one increment. I think one player always had the advantage though. But having the players tap repeatedly allows the computer to respond to each key press simultaneously.
Offboard Game Objects:
One day, as I was zapping around a game board (using the zap cheat), I happened to zap into the side panel. I read someone else comment on this once, but he didn't say exactly what happens when you move into the panel.
Once the player gets past the initial edge-of-board objects, he can move somewhat freely inside of the panel. Touching different places in the panel causes a bomb to explode and various other weird things to happen.
So, anyways, I created a ZZT game that had only a title screen. Then I managed to get an object lodged inside the side bar. I think I placed duplicators (their stats specially modified so that they could duplicate deep inside of the side bar) and then zapped and finagled. Next I quit the game, and instantly entered the editor. This allowed me to save the game in the state it was in when I was playing it. When I reloaded the game later, I think the object in the side bar was still functioning (displaying text repeatedly or whatever). But, I can't remember if it still worked when I reloaded ZZT. I don't know too much about the ZZT board format, but I'm wondering if it's possible to store objects off of the screen.
If it were possible to do this, it could make various engines sleeker. Keeping all of your engine objects (including perhaps a clone object positioned where the ZZT smiley face is in the side bar next to the health counter!) would allow more space for the actual game board in any game engine. It would also baffle cheating using zapping or simple approaches to modifying the game.
Platform Game With Player as Game Object
Here's an engine I've thought about recently but haven't actually created. The main idea is that when you jump, gems push up, and when you fall, gems push down. If you're not jumping, you're falling.
If the actual player is the game object, interaction with built-in game enemies and elements is possible, and objects can #seek, check #if aligned, receive touch messages, etc. But there are some difficulties:
1. One difficulty is getting the gems to be #pushed at the right speed. Using an idle in between pushes is way to slow- you can easily overcome the gem stream by moving in whatever direction you want. However, just putting gems constantly without any sort of pause is way to fast- in the blink of an eye you're pushed up to the ceiling if you're jumping. A working solution to the speed problem is to #set and #clear a flag several times or better yet to #zap and #restore a label in between #putting gems. This is a little bit glitchy, but it seems to work OK.
2. Another difficulty is knowing whether you are above or below a platform when you're jumping. You don't want the player to be able to “hang on” to the bottom of a platform while repeatedly pressing the jump button. You should only be able to jump if you are #touching a platform AND above it.
One way to solve this might be to have a track beside the game area, with an object which would move inside it, constantly keeping aligned with the player. Various objects would be beside each track and the track object would sense them using #put and #any to determine which row he was on. It could then activate platforms on a particular row, by #restoring labels or #sending messages. Another way to do this would be to have multiple objects beside the play area on every row that is immediately above a platform. Each one would check #if aligned. Either way, here is how messages would be sent and received: spacebar press detected by shoot detector object surrounding clone → message sent to row detector → row detector sends message → platforms on row + 1 check if #touching the player → if #touching jumping flag is set. Four messages before the jumping flag is #set! There might be a better way...
It would be nice if collision with the bottom of a platform disabled the jumping flag.