metaplan.org

guidelines

• The tests should focus only on behavior, and avoid overtly influencing implementation decisions.
• The tests should guide the student to consider different scenarios before settling on a design.
• As a by-product of implementing the protocol game, will incrementally develop a recursive descent parser for the test language.
• The test runner should enable students to visualize the state of their program.
• As each test is introduced, all the old tests continue to run, unless explicitly removed.

notes from <basic game idea>

• student must look slightly further ahead when parsing to distinguish ? xx yy and ? s
• clearing the board clears the score
• 999,999 is the highest possible tetris score.

notes on <line clearing>

• demonstrate a scenario in which the ‘list of tetraminos’ is not useful
• introduce the concept of tick as unit of time, and step (s) as the command to cause it
  • if students clear the line without waiting for the s command, it causes a regression in the previous test
  • the ui should not mention this up front. it’s better for students to learn to value feedback from tests.
• introduces the concept of state in the parser ( ! s vs s )

the tetraminos

• these are chosen random, so we need to set them
• capital letters
• math = tetromino or tetramino, like domino. The Tetris Company calls them Tetriminos™
• introduce t and ;
• students will have to map the tetraminos to their proper colors colors
• the grid sizes are different because of rotation
  • these are the Super Rotation System (SRS) spawn states
  • but do thing at a time
• spawns in a 4 x 4 grid:

Introduce multiple commands on one line.

discuss rotation systems (and the SRS in particular)

reference http://tetrisconcept.net/wiki/SRS

generate the correct test syntax from this file

I want it to be as easy as possible to implement the protocol.

These tests show the > but it’s not actually a prompt, and comments (# to end of line) are not actually sent.

The tests should never send bad input, because this is about testing the game, no the protocol implementation.

invariants (tests that always run)

before each test

• subprocess must have launched correctly

after each test

• no further output on stdout

summary of the command language

(upper case letters are stand for numbers)

cmd	args
?n	read num lines
?s	read score
c	clear
g	given
p	print
q	quit
s	step
t	show falling tetramino

– advanced stuff / maybe later ——————————

;	separate commands
! XX YY C	set (x,y) to color

establish a way to set an individual cell

This test does a couple things.

• establishes the coordinate system
• nudges student to consider the matrix as a random-access array of color values

  (From what I can tell, students are often taught to think of classes and objects before simple data types, and tend to want to implement the state of the game as a container for tetramino objects, but this will lead to complications later on.)

• establishes the palette

.	empty
r	red
g	green
b	blue
o	orange
c	cyan
m	magenta
y	yellow

• student must figure out how to parse a decimal number

> ! 00 00 r
> ! 09 00 g
> ! 00 21 b
> ! 09 21 o
> ! 06 11 y
> ! 05 11 c
> ! 04 11 m
> p
r . . . . . . . . g #  0
. . . . . . . . . . #  1
. . . . . . . . . . #  2
. . . . . . . . . . #  3
. . . . . . . . . . #  4
. . . . . . . . . . #  5
. . . . . . . . . . #  6
. . . . . . . . . . #  7
. . . . . . . . . . #  8
. . . . . . . . . . #  9
. . . . . . . . . . # 10
. . . . m c y . . . # 11
. . . . . . . . . . # 12
. . . . . . . . . . # 13
. . . . . . . . . . # 14
. . . . . . . . . . # 15
. . . . . . . . . . # 16
. . . . . . . . . . # 17
. . . . . . . . . . # 18
. . . . . . . . . . # 19
. . . . . . . . . . # 20
b . . . . . . . . o # 21
> q

explicitly set registers

> !s 9999999
> ?s
9999999
> q

> !s 9999999
> c
> ?s
0
> q

legal issues

• they like to send DCMA notices apparently… http://en.wikipedia.org/wiki/The_Tetris_Company
• but that’s for a market where games are actually sold.