Purposes of this assignment

• To give you some experience with Elm
• To introduce the concept of functional reactive programming (FRP)

General idea of the assignment

Elm comes with a variety of examples. The "mario" example responds to three signal types: (1) the dimensions of the window, (2) a time signal, occurring 30 times a second (sometimes referred to as a "heartbeat), and (3) keystroke signals for the arrow keys (up, left, and right--it ignores the down arrow).

Your task is to transform this example into a simple game. There will be a red ball, which you control with arrow keys, and seven blue balls, which you have to chase down. When your red ball collides with a blue ball, the blue ball "freezes" (stops moving). When all blue balls are frozen, the game is over, and you've won.

Ideally, the game should display a score, either continuously or when the game ends. The best scoring method is simply the time taken to freeze all the balls (shorter times are better).

Initial setup

1. Get rid of the "Mario" image.
2. Get rid of the green "ground."
3. Rename the mario variable, which represents the model, to model.
4. Add (a list of) seven blue balls, moving in random directions and at random speeds (dx and dy in the range -3 to +3, but excluding 0). These balls should bounce off the "walls."
5. Add a red ball, initially stationary, in the center of the screen.

Movement details

20x20 is a good size for the balls. For a more challenging game, make them 10x10.

The position of a ball is given by its x y coordinates, but its velocity is given by dx dy -- the amount to add to x and to y for each new frame. These numbers should be in the range -3 to 3, excluding zero (we don't want a stationary ball or one moving perfectly vertically or horizontally). The red ball can move slightly faster, -4 to 4, and zero is allowable.

The red ball starts out stationary in the center of the screen. Each click of an arrow key adds or subtracts 1 from its dx or dy (the right arrow adds 1 to dx, etc.), but clicks that would take dx or dy outside the range -4 to 4 are ignored.

The blue balls start out in random locations and with random speeds (dx and dy in the range -3 to 3, excluding 0).

The red ball collides with a blue ball when the distance between them is less than or equal to the width of the ball.

Blue balls just pass through one another, without colliding.

All balls bounce off the walls. When adding dx to a balls x position, if the result is less than zero or greater than the width of the window, change the sign of dx and add it again (to cancel out the effect of the ball going "into" the wall). Similarly, the balls bounce off the "floor" and "ceiling" of the window.

"Random" values do not exist in a functional language, of course. Find Random in the Elm core language to find out how to deal with this. It's okay to copy code from there.

Due date