Dude, I fear that you must have way too much free time on your hands...

That said, I think the exercise as a whole might stand a better chance of successful execution (and might even be more amusing) if the participation were more "modular".

Imagine that the goal of the exercise is to build a filter, comprising some finite (pre-established) number of steps, with each step implemented as a subroutine call that takes, say, one or two variable parameters (plus, if you like, one or more literal args), and returns something that can be used as input to a subsequent subroutine.

The first player gets to provide the data input operation, which could include some comment about the expected nature of the input (e.g. "list of English words, one per line"), or could be "self evident" (e.g.  @input = <*.txt>;). The first player could also provide the first filtering step (subroutine call).

Each successive player sees only the previous two lines (sub calls whose return values are assigned to variables), and must add the next filtering step, using one or both of the two variables set by the two visible steps from previous players (along with literal args, if desired).

Names of subs and variables should be "suggestive" (used to "good advantage" in the game, according to each player's understanding of "good"). At the very least, the variable name being assigned the return value from a sub should indicate the nature of the value (array_ref, hash_ref, or whatever).

Code for each subroutine must be provided by the player who adds that sub call to the sequence, and would be known only to the person who adds the sub call.

(A player could re-invoke one of the two subs visible to him/her, providing different input args, but this would usually be considered bad form (i.e. lame), and might run the risk of causing "undefined behavior" -- or a crash -- since that sub's internals are known only to the previous player who first put it in.)

I think games of this sort typically involve two or more rotations, and as many distinct compositions as there are players -- e.g. if there are 6 players, the game begins with each person supplying an input line and an initial sub of their own invention. Each script then rotates around the group, and eventually comes back to the player who started it. If the players are reasonably sober, they might be aware of the point where they are adding to a script that they started, though they might not remember exactly how they started it, and in any case, they don't know what happened to the data during four intervening steps (they only see the lines added by the previous two players).

That said, I think I would respectfully decline the opportunity to play. Just about all my "idle amusement" time (meager amount that it is) is spent on sudokus, crosswords, and SoPW. (Now that I think of it, timing issues might turn out to be a problem in this game...)

Update: Naturally, in the process of adding a given statement to the filter sequence, a player is not constrained to merely assigning the return value of a sub to a variable; any single-line flow control mechanism is fair game, along with using perl built-ins, logical operators/conjunctions, etc, but again, if the player doesn't actually include a sub call of his own (to hide some code from the next players), this could be viewed as a cop-out.