encyclopedia?

Housing for low income families.

Moderators: nuero, Ando

User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Re: Description of Various Engines

Post by Dr. Dos »

Okay here I go trying to remember some of ZZT's mechanics at 3:30 in the morning without bothering to load the game~
dct4w wrote: 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 I recall correctly any built-in enemy that would normally #go seek instead does #go opp seek when the player is energized. This may even apply to objects using movement commands.
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.
What actually happens here is based on how ZZT handles stats and tiles. In the board format first are the necessary bytes of data for each tile on the board, followed by each stat. The two are isolated, so an object doesn't have its own code, there's just a stat that looks at what its coordinates correspond to on the board. What happens with this is that you can make a board with two objects one with "#shoot e" as its code and the other with "#shoot w". If you hex edit the file and change the stat coordinates of the first object to match the second and play the world, the first object on the board will do nothing. The second object will shoot east and west in a single cycle. If you really wanted you could have a single object execute dozens of cycle ending commands in a single cycle.

The only problem though is that if the object is told to move, only one stat will update its coordinates properly so it's likely more effort than it's worth.
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.
The spacebar player would have latency since the bullet would need to travel one space. Although I think if an object used #if any bullet to detect it rather than :shot it would work.
Offboard Game Objects:

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.
The objects in the sidebar can't be saved. I believe they're only persistent until you quit whatever world you zapped them in by. I might be wrong on this but I'm pretty sure there's some reason it doesn't work since I remember years and years ago people talking about a possible Global object.
Platform Game With Player as Game Object

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.
Does this work? I know #give/#take can lag a game, but I'm pretty sure it lags the whole game and not just the objects involved. The object that's puts the gems is going to get its cycle, #put a gem, and then lag ZZT but I don't think the graphics will be redrawn until every stat-element on the screen has its cycle, so the multiple gems will still be #put all at once.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: Description of Various Engines

Post by Quantum P. »

Dr. Dos wrote:Okay here I go trying to remember some of ZZT's mechanics at 3:30 in the morning without bothering to load the game~
dct4w wrote: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 I recall correctly any built-in enemy that would normally #go seek instead does #go opp seek when the player is energized. This may even apply to objects using movement commands.
That's correct. Object enemies would have to use #if not energized /seek and #if energized /opp seek.

I like the idea of combining energizers and stars -- I can't remember seeing that before. I could see some interesting puzzle games where you have to "aim" the stars around corners by moving around.
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.
The spacebar player would have latency since the bullet would need to travel one space. Although I think if an object used #if any bullet to detect it rather than :shot it would work.
You can also surround a player clone with breakables, and put objects nearby to check #if blocked <dir> and #put <dir> breakable. If done right, you have no latency.
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Description of Various Engines

Post by Saxxon »

dct4w wrote:'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.)
That is really strange and I didn't even notice this in the assembly. Going to check right now to see why this is.

Edit: When you press B it changes the key currently pressed to Space. The reason the main player doesn't shoot is because this key press is checked after the check for space. This code is run for each player object. All other players will go through the key press check and it'll be space so they'll shoot normally. Also applies to Super ZZT. Thanks for bringing this up :)
wil
GABZABOOLZABBA
Posts: 105
Joined: Mon Mar 15, 2004 6:21 pm
Location: EAST SIDE
Contact:

Re: encyclopedia?

Post by wil »

I made a parallax starfield once. I think it's even in a game somewhere. Here is how:
Create an object with high +x or -x walk offset, like between 2 and 8, and cycle 1. "#walk opp flow" will multiply the run speed by -1 (which retains this high walk speed), so by creating an object with code something like this:

Code: Select all

#cycle 1
#end
:thud
#walk opp flow
#z
:z
#zap z
#char 32
#end
:z
#restore z
#char 249
you have an object that will zip across the screen, disappear, return to the other side of the screen, rinse, repeat.
take care not to let the object run way off into the boonies. I think positions 12,63 through 12,65 result in a crash. Somewhere around there is the secret spot where you can hide an object, too; it will execute its code and not be on the screen. Works with players on title screens too, no empty block.

Just thoughts.
Post Reply