http://qs321.pair.com?node_id=723303


in reply to [Fun] Exquisite Corpse in Perl?

I don't believe programs can handle as much randomness as you're suggesting...

Perhaps an alternative scheme;
  1. Predefined functions Munge() and MungeConsistently() will be available.
    • Munge calls MungeConsistently, but passes in the count of how many calls to Munge have already been made, so it is essentially random but still reproducible.
    • MungeConsistently takes a number as its first parameter, which will be used to pick the sub to call.
  2. Everybody is given a random number from 0..1, indicating their position in the program. (so that early code can do more input, and late code can do more output)
  3. PASS 1: Everybody then submits a small block of code that does something "useful", PLUS a small subroutine to be included in the Munges
  4. PASS 2: Each person is given the task of gluing together two adjacent pieces of code, NOT including their own. (One player is chosen to glue the command line to the first block by choosing the input parameters, so there are N glues for N players)
The second pass to glue things together should change the result from a twitching mass of random code to something that at least runs to completion. (I hope)

Replies are listed 'Best First'.
Re^2: [Fun] Exquisite Corpse in Perl?
by blazar (Canon) on Nov 13, 2008 at 12:16 UTC
    I don't believe programs can handle as much randomness as you're suggesting... [...] The second pass to glue things together should change the result from a twitching mass of random code to something that at least runs to completion.

    I personally believe that... whoa! what you describe is an entirely different game altogether: which is not to say it wouldn't be interesting or fun. But I explained the goals of the game as I see them in my reply to graff's comment, which expressed similar concerns as yours: to be fair I'm specifically interested and I think that people who would like to play an autenthically "Exquisite Corpse" version of the game should be specifically interested in the "twitching mass of random code" getting out of it! (Thank you for contributing this very illuminating expression!)

    Since both you and graff, reasonably, point at subs, I recognize that as an alternative to the "last statement rule" a player may give a sub call of a sub he didn't include in his portion of the script, for the next one to write one. But I wonder if that couldn't be too restrictive of his freedom of could turn the game, if all players choose to handle "continuations" that way into a boring series of nested sub calls... Perhaps a restriction should be imposed to the effect that this kind of continuation can not be given for more than one turn. Thus a player writing the "requested" sub may or may not actually end it or leave it open, and write further code beyond it or not: scary! ;)

    --
    If you can't understand the incipit, then please check the IPB Campaign.