Tetris case study
Tetris where you build the shape and the computer decides where it lands
- My role
- Concept, physical controller, Arduino firmware, serial to Unity
- Built with
- Arduino, Unity, laser cutting, physical computing
- Made with
- Team of three · controller and firmware · Unity collaborator · Demo Day tested
Tetris with the roles swapped
Every decision the computer used to make is now yours, and every decision you used to make belongs to the computer.
In normal Tetris a random generator hands you a shape and you decide where it goes. We flipped that. The computer picks the lane, and you build the tetromino yourself out of four physical cubes on a board. Place a valid shape before the timer runs out and it drops and stacks. Each round the timer gets shorter.
The split is more specific than just taking control away. The player owns what falls, but not where. That moves the game out of speed and reaction and into physical decision making under pressure, and it makes the reversal feel strange rather than simply limiting.
Neither side is fully in charge
Rather than reacting to a shape you were given, you react to a position you did not choose. You have to think about which shape fits the situation the computer just created, then physically build it before time runs out. Agency ends up distributed between human and machine, with both constantly influencing the same game state.
In the group I designed the controller and built the grid, sensing, Arduino, and serial link into Unity. Priyal worked with me on the build: the cubes, fixing magnet issues, and soldering the LEDs. Most of the work was not making something that functions in the end, but finding the smallest technical system that still creates the experience.
Three ways to know where a cube is
Three directions were open: a camera with machine learning reading the shapes, an ESP32 and a battery inside every cube talking to its neighbours through connected magnets, or a board that acts as the brain with the cubes only carrying LEDs. We wanted to avoid heavy calibration, too many sensors and wireless complexity, so we started with two ESP32s to see whether magnets alone could carry a connection.
They could, but the complexity grew faster than the concept. Power, orientation and reliability would not scale to four cubes inside a sprint, and lithium cells are not allowed at our university. An IMU per cube could not give position accurately enough either. Dropping the independent cubes was the right call: it moved the sprint into the interaction instead of into hardware problems.
Four cubes, cut, glued and wired by hand
Each cube is laser-cut acrylic with two magnets in its base and an LED inside. The finger joints hold the shape without a frame, so the cube stays light enough to lift off the board in one motion. Soldering onto magnets turned out to be the most annoying part of the whole build, and there is probably a reason people do not usually use them as contacts.
We wanted RGB feedback, but the magnets only give two connection points, positive and negative, and an RGB LED needs four legs to drive the channels independently. We tested every colour and then had to commit to one per cube.
Ten pins instead of twenty-five
Any cube placed on the board connects exactly one row wire to one column wire through its own electronics, so it sits at a single grid coordinate. Instead of twenty-five separate inputs for a five by five grid we need five rows and five columns, ten pins on the Arduino. That reduction was one of the most useful parts of the design because it lets the board scale without a dedicated input per cell.
Each cube meets the board through two magnets, one for the row and one for the column, with a diode, resistor and LED in between. The scan pulls one row weakly high with INPUT_PULLUP and drives one column low. If a cube sits at that intersection the row reads low, which confirms it is there. Once all occupied positions are known, the arrangement is reconstructed into a tetromino and sent to Unity.
The board started inventing its own tetrominoes
Certain arrangements caused ghosting. Current took side routes through neighbouring cubes and the scan reported pieces that were not there. A diode inside each cube fixed it, turning every cube into a one-way valve. The fault only appeared in specific combinations, which is the useful part: a system can pass every simple test and still break once several interactions happen at once.
The magnets had to hold the cubes and block current where they were not meant to conduct. After reassembly half of them triggered false detections anyway, most likely sanding dust bridging the contacts. A second clean and more tape resolved it.
Once detection was clean the LEDs were barely visible, because each one is only powered for a moment during the scan. Multiplexing solved it: faster switching feels more responsive, slightly longer delays make the feedback readable, so the timing is a balance between the two.
Everyone asked how to move the piece left
We tested with a lot of people on Demo Day. The most common question was how to move the shape sideways, which is now the computer's decision. That discomfort was the clearest confirmation of the concept: players expect spatial control to belong to them, and noticing it is gone takes a moment of readjustment.
They did not stop playing when they got confused. They invented rules instead, predicting where pieces would appear or testing what the system would do. Some leaned into the shape making; others felt stuck because they could not decide where it went. That split is worth designing around more deliberately next time.
Next time: weaker magnets so people fight the game instead of the mechanics, better shape validation in Unity, and a destroy mode that removes a piece rather than adding one. The biggest lesson was knowing when to let an idea go.
Made as a group
A three-person sprint at the UAL Creative Computing Institute. The concept was shared, with the work split across the controller, the game, and the link between them.
Laurens Art Ramsenthaler — controller system and build (grid, cubes + LEDs), sensing, Arduino, serial to Unity. Priyal Patel — co-built controller hardware, cubes, magnet issues, soldering the LEDs. Cat Menzies — code for the Unity game.