A player clone is exactly what it sounds like, a clone of the player object. It reacts to your keystrokes just like the player, except it will adjust only the first player's position on the board. If you surround the clone with objects and press a directional button, it will send the :touch message to whichever object is positioned correctly. Most often this is used for sidescrollers or for sending messages based on which direction you hit last. I use them with the original player to make shooting in those sorts of engines better.
O#O
#X#
O#O
The # are breakables, the clone will shoot in the last direction pressed, and will destroy one of the breakables. The O's are objects in loops that are constantly checking to see if they are not blocked in a certain direction, indicating that a breakable has been shot.
Let's say the top one is shot, the object in the upper-left has code like this:
@checker1
#cycle 1
#If not blocked e #do
#restart
:do
#send guy:shootup
#put e breakable
#restart
It puts another breakable so the process can be repeated.
You can also use clones to teleport around a board, or from board to board. Essentially you do this by having an object do #put player w or something, then have a passage in a duplicator duplicate on where you put the clone. You then go to the passage you duplicated. There are a lot of variations on this. All of them can be found in
Chronos' Encylopaedia.
Also because all the varible counting is done by the player object, having clones on the board will make torches burn out quicker.
To confuse you more, here's nanobot's more technical description:
Controller Elements are elements that react to keystrokes. The player and the monitor are two known Controller Elements. They each have their own set of keys that they react to. By default, the Controller Element that is "meant" to be on the board is listed first in the stat element parameter section of the .ZZT board data. I'll just refer to that as the "board data" when talking about elements that have parameters.
However, Controller Elements work normally no matter where they are in the board data, in terms of their internal functions. You may then ask, "What about player clones? They don't move when you press the directions." True. Internally, they don't cause themselves to move.
Here's what happens when you press a keystoke. Let's say there are 5 players on the board (1 active one (the first element in the board data) and 4 clones). You press up. Every player, in turn, reacts to the keystroke. The first player (the active one) checks to see if it is blocked to the North. It isn't, so it changes the y-coordinate for the first element in the board data (the player) to 1 less than its current y-coordinate and the x-coordinate equal to its current one. That will be updated at the beginning on the following cycle. The next player then does the same thing. It isn't blocked to the North, so it changes the FIRST player's y-coordinate to one less than the SECOND player's y-coordinate and its x-coordinate equal to its own (the second player's). Note that that would place the first player above the second. The third player does it as well, but say it is blocked to the North. It performs the normal function of trying to SEND whatever is to the North of it to TOUCH and doing nothing else. The fourth player operates and isn't blocked, so the coordinates of the first player are set above the fourth player. The fifth player is blocked, and tries to send whatever is above it to TOUCH. The next cycle begins and the first player appears directly to the North of the fourth player (third player clone). It is in the situation we have come to know as "stuck."
In a nutshell, the player always ends up to be the pressed direction of the LAST player in the board data who isn't blocked in that direction. If all player clones happen to be blocked in that direction and the first player (the active one) isn't, it moves in that direction normally.
CHAOS IN MAH SOUL!!!