Rebecca V.1

Rebecca v.1

v.1 of Rebecca can be played without specialized software. You only need access to a server with the appropriate programming tools. The system is set up so that the players have Read, Write and Execute access to a directory. The start.text is placed in a subdirectory called “startText”. As each player makes a move they must create a new subdirectory with their initials and the number of the move. In that subdirectory they should place their code (move.program) and the output.text. In the game root directory there should be a shared html file called game.html that is used to keep track of the moves and which has links to the moves.

The rules are these:

1. The players choose a start.text and a goal or question.
>> I propose we try a dialogue of Plato’s and have as the goal something like “Can we change the gender of all mentioned characters and gendered entities?” or “Can we create a lexical tagger that will tag each word with its grammatical function?”

2. All moves are made by writing a program in the target programming language that is run on the start.text or any other text that is the result of other moves.
>> I propose we use Ruby as the target language.

3. Players are not allowed to make a move on an output text from a previous move they made. This is to encourage cooperation.

4. Players should, once they make a move, announce it in the appropriate fashion.
>> I propose we do this by just appending text to an html page which is a reverse chronology of moves. When we add text it is in the form of: Date of Move, Name of Move, link to code, and link to output text.

5. Players should justify their moves in comments in the code of their move.program. The programs and the resulting output.text become part of the discourse field and are therefore both available to other players as input.text for future moves.
>> I am not sure if making moves on code makes sense, but it seems right. Ideally we would use literary programming techniques to combine code and justification. Someone could choose to make moves on other people’s justifications – a sort of critical move.

6. The game is over when the players agree that an output text is a suitable response to the question or goal.

7. In general players should avoid moves that insert new text into an output.text. Players should avoid simply replacing an output.text (or the start.text) with an essay written on the question. The idea is to manipulate the start.text or its children output.texts to get an interesting result.

8. In general players should avoid complicated moves that do a number of things that could be considered individual moves. The idea is to make simple moves in collaboration to achieve a goal. Once the game is over, the individual steps can be refined into a more complex program for use elsewhere.

In later versions we could add the following features.

1. The use of a blog to keep track of moves.
2. Some adaptation of a CVS server to handle the moves and their output.
3. A literary programming language such that what you do is write a literary program, test it, and eventually get the output desired at which point you submit the move.
4. A visualization tool that would allow one to see the tree of moves and to navigate them.
5. A slide show that would allow one to see the text changed move after move.
6. A summarizing tool that would take the path of the winning move and recapitulate the code that generated the winning output. This winning path of moves could be then bundled as an abstract tool.

Part of the idea is to use a form of genetic programming where players try things to evolve a path of moves that produces interesting results. Playing then becomes a form of collaborative research programming in humanities computing.