The Game

Date: Wed, 24 Aug 2011 01:39:15 -0400
From: nick black <dankamongmen@gmail.com>
To: splinterfags <splinterfaction@googlegroups.com>
Subject: [Splinter Faction] game idea

the objective is to write some program (prove some theorem? generate some
string?) using a highly formalized, small language, and cards representing
base lexemes.

the objective is to compile a working program for each round's required task.
the tasks can be randomly parameterized, as can the cards, so there's no need
to worry about replay value. average complexity of an orthodox problem solution
ought not be more than 20 cards. a hand will take about 10--15 minutes for
2--4 intelligent players. less intelligent players might never complete a
hand, pseudorandomized program construction being rather a losing game.

cards have things like loops, constants, operators, variables, all kinds
of shit which you can arrange to make a program. take it up a notch: definable
"primitive recursive function", "curry", "monad" etc. preferably make some
friendly isomorphism or something so people don't know they're programming.

cards are sorted according to a random total ordering, aka shuffled. each
player gets 7 cards. the rest are enqueued face-down. the discard stack is
initialized empty.

each turn you MUST draw one card and MAY play one card.

drawing:
 - you may either dequeue a face-down card from the bottom of the queue, or
 - pop a face-up card from the stack

playing:
 - you may either move a card from your hand to your program, or
 - moving a card from your program to the discard pile, or
 - trojan an opponent's program with one of your hand's cards.

your program may be disconnected up until "compile time"; you cannot compile
a disconnected program! connection of program fragments, however, is restricted
to those generating valid subprograms (hence desirability of a true CFL). this
is true for trojaning as well as your own program's construction.

it is not allowed to refrain from drawing a card, nor to push a card from your
hand onto the discard stack, because these are useless acts. your hand is
unbounded, and new cards can be trivially pseudorandomly generated.

all program specs ought probably be purely functional -- perhaps restricted to
functions on n-ary integers returning integers? don't want a type system.
might or might not want state.

if the language made it impossible to generate invalid programs at any point
(could be enforced by, for instance, cuts in the cards needing be paired up),
that would be lovely -- attackers could modify your program's syntax or
semantics, but not make it invalid in either sense, requiring huge fixups

i'd buy it and play it

--
                                         nick black <nblack@nvidia.com>
"A main cause of the Roman Empire's fall was that–lacking zero–they had
       no way to indicate successful termination of their C programs."