Revision as of 01:43, 24 August 2011 by Dank (Created page with "<pre>Date: Wed, 24 Aug 2011 01:39:15 -0400 From: nick black <email@example.com> To: splinterfags <firstname.lastname@example.org> Subject: [Splinter Faction] game idea th...")
Date: Wed, 24 Aug 2011 01:39:15 -0400 From: nick black <email@example.com> To: splinterfags <firstname.lastname@example.org> 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 <email@example.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."