jdfrens / notris Goto Github PK

Representing the thing that falls

I'm going to call the thing that falls a "Notris piece".

Excruciating detail

A Notris.Piece has these attributes:

• shape, [:i, :l, :o, :t, :z]
• points, list of points in 4x4 grid
• location, {row, col}
• mirror, boolean
• rotate, integer
• color, [:red, :blue, :green, ...]

%Notris.Piece{
  shape: :i,
  points: [{2, 1}, {2, 2}, {2, 3}, {2, 4}],
  location: {4, 10},
  mirror: true, # not useful for :i or :t!
  rotate: 90,
  color: :red
}

This is probably useful for debugging. But the shape, mirror, and rotate are only interesting when you start the piece and if you're going to regenerate.

Really lean

I'm not going to call this "really simple". It's lean, but I think it requires more careful thought.

Some fields aren't necessary (but could be useful for debugging).

• shape is only for debugging.
• mirror isn't necessary if one mirrors the raw points.
• rotate isn't necessary if you rotate the raw points.

You can play arithmetic games with location and points. You can store "relative points" or "absolute points". Rotations are relative within a 4x4 grid.

• If you store absolute points (i.e., points for the game board itself), a rotation will be: subtract location to get the relative points, rotate on the relative 4x4 grid, add location to get absolute points again, display those points directly.
• If you store relative points (i.e., offsets from location on a 4x4 grid), a rotation will be: rotate the relative points, add location for absolute points which can be displayed.

What happens more often, rotations or rendering? If you never rotate, absolute points would be great. If you rotate a lot, relative points would be better. I'm not sure where the cutoff between the two lies.

This is undoubtedly a premature optimization. Even in Elixir, these basic integer arithmetic operations are really, really fast. In comparison, user input will be really, really slow. I think we'd be challenged to come up with arithmetic computations for this game that could come close to impacting gameplay.

I think relative points will be easier to implement, certainly when testing.

%Notris.Piece{
  location: {4, 10},
  points: [{1, 2}, {2, 2}, {3, 2}, {4, 2}],
  color: :red
}

This is two things, so maybe it's too much.

Context

At first I thought it would be a good idea for something else to provide a new piece (and location) to a Game when the current piece falls to the bottom. This would allow variants where the next n pieces could be previewed.

This doesn't make for a very good API, though. Do I really want the LiveView layer worrying about picking a new piece and adding (even if the API is as simple as Notris.has_current_piece?, Notris.new_random_piece, Notris.add_piece)?

The more I think about it, I think this queue of pieces could be implemented within the Game pretty easily. LiveView level could choose how many of the queue up pieces are displayed. I believe other variants can be handled the same way (or with plugins or dependency injection or both).

Do This

• When a new game starts, add a random piece above the top of the board in the center (horizontally).
• When a piece hits the bottom and is added, add a new random piece above the top of the board in the center (horizontally).

Things like "center of the board" can be generalized later with dependency inject (i.e., pass in a function to determine the new piece).

A game consists of a board (always) and an optional piece-and-location. The game is in charge of the following:

1. Maybe move the piece left.
2. Maybe move the piece right.
3. Maybe move the piece down.

If the piece cannot be moved left or right, the game remains unchanged. If the piece cannot be moved down, it should be merged into the bottom of the board, and the piece-and-location are nilled.

A board should have boundaries (width and height). It should store the remnants of dropped pieces.

• Don't display random blocks on the board.
• Drop the starting piece four or five or six steps down.
• React to "left" and "right" button events.