encyclopedia?
encyclopedia?
*POW* *CLANK* *PING*
-
- secret sauce
- Posts: 129
- Joined: Sun Feb 22, 2004 10:38 pm
- Location: MO :(
not all doors swing both ways. you just didn't go through all the doors. in the original encyclopedia it was a bunch of examples. I figured there might not be enough new examples but older ones could be organised and revamped with new knowledge making the whole thing double as a resource.
Some of the "more recent" stuff like binders keepers maybe old news too, but it's not really accessible to someone since it's buried.
anyway, less complaining, more submitting.
Some of the "more recent" stuff like binders keepers maybe old news too, but it's not really accessible to someone since it's buried.
anyway, less complaining, more submitting.
*POW* *CLANK* *PING*
- Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
Oh my god commodore please test that your passages work.
Aside from that I support a new encyclopedia.
Have a puzzle I made the engine for but never the actual puzzle. It features a small room in the corner which will let the player store and retrieve any keys they have.
http://zzt.org/dr_dos/Abcd.zzt
![Image](http://zzt.org/dr_dos/img/keyfactory.gif)
Aside from that I support a new encyclopedia.
Have a puzzle I made the engine for but never the actual puzzle. It features a small room in the corner which will let the player store and retrieve any keys they have.
http://zzt.org/dr_dos/Abcd.zzt
![Image](http://zzt.org/dr_dos/img/keyfactory.gif)
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
- Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
Nice job actually making a puzzle out of it though I have yet to try it.
Here's a fun trick Flimsy discovered:
http://zzt.org/dr_dos/Abcd.zzt
Here's a fun trick Flimsy discovered:
http://zzt.org/dr_dos/Abcd.zzt
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
- Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
I had a world of seven engines that I wrote a while ago. I'm not sure if I'm going to be able to find them. So, in the meantime, I'll just post all I can remember that was in the ZZT world as a programming challenge for anyone interested! :-D My first version of the scrolling game engine is uploaded as panning.zzt in the archives (by DarkOktopus). I know for a fact that I've lost some of these boards, sadly...
1. Scrolling Game Engine
(An object moves around an invisible game board mapping its view onto a small object matrix.)
possible features: walls, ladders, background pieces, pushable boulders,...
possible variants: color matrix (orchestrate the objects in the object matrix to #put <color> object in the right way), multi-character tiles (e.g. nice-looking ladders), animated tiles
(Are moving enemies impossible if this scheme could be modified slightly or... radically?- Not sure!)
advantages: different, it scrolls!, allows for otherwise impossible game play (non-blocky background tiles, etc.) because you have complete control over what characters are displayed in the matrix
disadvantages: slow, no shooting, no moving enemies
*2. 'P' is pressed engine
*3. 'B' is pressed engine
4. Laser gun
5. Blinking Star gun
6. Mario Map
*7. built-in object properties changing during run-time (e.g. slime increases in speed incrementally, etc.)
The ones with (*)'s exploit quirks in ZZT.
This just occurred to me recently: has anyone tried creating a side-scroller, where the main guy is actually the player? The rough idea would be that, when jumping, gems would be pushed from the floors and, when falling, gems would be pushed from the ceilings. Since gems can be smashed even by built-in enemies and objects, movement wouldn't have to be restricted. This would allow for the use of the #touch and #seek commands. There are some immediate difficulties, but I think they could be overcome with some ingenuity.
Well, anyways, the last thing is just a crazy idea, but the others I've actually done. So, I hope this interests somebody! The quirks and constraints of ZZT OOP present a unique programming challenge.
1. Scrolling Game Engine
(An object moves around an invisible game board mapping its view onto a small object matrix.)
possible features: walls, ladders, background pieces, pushable boulders,...
possible variants: color matrix (orchestrate the objects in the object matrix to #put <color> object in the right way), multi-character tiles (e.g. nice-looking ladders), animated tiles
(Are moving enemies impossible if this scheme could be modified slightly or... radically?- Not sure!)
advantages: different, it scrolls!, allows for otherwise impossible game play (non-blocky background tiles, etc.) because you have complete control over what characters are displayed in the matrix
disadvantages: slow, no shooting, no moving enemies
*2. 'P' is pressed engine
*3. 'B' is pressed engine
4. Laser gun
5. Blinking Star gun
6. Mario Map
*7. built-in object properties changing during run-time (e.g. slime increases in speed incrementally, etc.)
The ones with (*)'s exploit quirks in ZZT.
This just occurred to me recently: has anyone tried creating a side-scroller, where the main guy is actually the player? The rough idea would be that, when jumping, gems would be pushed from the floors and, when falling, gems would be pushed from the ceilings. Since gems can be smashed even by built-in enemies and objects, movement wouldn't have to be restricted. This would allow for the use of the #touch and #seek commands. There are some immediate difficulties, but I think they could be overcome with some ingenuity.
Well, anyways, the last thing is just a crazy idea, but the others I've actually done. So, I hope this interests somebody! The quirks and constraints of ZZT OOP present a unique programming challenge.
Interesting, the only problem I can think of is figuring out how many gems an object should put (ie height) or resisting the player from fighting the gems. It's also lot of objects with a lot of code, but considering the right limitations maybe...dct4w wrote: This just occurred to me recently: has anyone tried creating a side-scroller, where the main guy is actually the player? The rough idea would be that, when jumping, gems would be pushed from the floors and, when falling, gems would be pushed from the ceilings. Since gems can be smashed even by built-in enemies and objects, movement wouldn't have to be restricted. This would allow for the use of the #touch and #seek commands. There are some immediate difficulties, but I think they could be overcome with some ingenuity.
*POW* *CLANK* *PING*
- Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
SliderNS would be the solution to fighting the gems
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Description of Various Engines
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.
Applications:
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!
Applications:
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.)
Laser Gun
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.
Applications:
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.
Star Gun
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.
Mario Map
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.
Multiplayer:
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.
'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.
Applications:
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!
Applications:
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.)
Laser Gun
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.
Applications:
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.
Star Gun
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.
Mario Map
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.
Multiplayer:
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.
Re: Description of Various Engines
I like this. nice and simple.dct4w wrote:Star Gun - Detect when the player is energized, and then constantly change bullets into stars.
interesting if true. if I remember correctly empties with stats are the black holes you skip over if you try to move over them.dct4w wrote: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.
the sidebar thing is weird, but I'm going to guess it didn't work when you loaded back again.
*POW* *CLANK* *PING*
Oh, yeah, you're right Commodore. I meant that if a built-in object moves over a "black hole" (an empty with stats) it will destroy the black hole after taking on its stats. When the player tries to move over the blackhole, I think you're right that he skips right over top. I think you can specify blackhole stats using Kevedit, but I could be wrong. Oh, and for the 'P' is pressed engine, I meant to say that empties were changed to forest whenever the player moved. Essentially, the forest acted as a green pseudo-fake wall that could track whether or not the player had moved even in the paused state.
Btw, Dr. Dos what was your idea about sliders?
Btw, Dr. Dos what was your idea about sliders?
Last edited by dct4w on Wed Apr 13, 2011 5:00 pm, edited 1 time in total.