Project overview
The Porg Shooting Gallery is a laser shooting game in three separate boxes. A printed E-11 blaster, a control case and a target bar talk to each other over ESP-NOW, with no cable between them except the mains lead. Presenting an RFID card to the control case starts a round: ten shots to hit six of the Porgs sitting on the bar.
The targets are Porgs rather than cans or ducks, and the closing message on the display reads that you saved a number of them. The birds stay exactly where they are when hit, which leaves the question of what actually happened to them open — that ambiguity is the joke.
This is the third generation of the machine. The first ran on a Nerf gun. The second used individual satellite targets connected by cable, each with a light sensor chip and a potentiometer that had to be set by hand before a session. This one automates almost all of that and moved to Porgs.
The project is not open source. It was built collaboratively under the Devious City License, and no design files or firmware are published. Star Wars, the Porg and all associated designs are the property of Lucasfilm and The Walt Disney Company; this is a fan-made installation and none of those elements are covered by that licence.
Electronics and control
Three ESP32 boards, one per box, connected only by ESP-NOW. The messages between them are small numeric codes rather than a protocol — a hit, a reset, a set of game parameters — which is all a game with ten shots and six targets needs.
The blaster is a printed E-11. It is battery powered and carries the laser, the trigger, a NeoPixel and a 128 x 32 SSD1306 as its ammunition display. It counts its own shots and reports them, so the round ends correctly even if a shot misses everything.
The control case holds the electronics, the speaker and the operator controls: a 20 x 4 LCD, a DFPlayer for the voice lines, a rotary encoder for volume, a ten-segment Grove LED bar as the shot counter, a reset button, and the MFRC522 whose card starts the game.
The target bar does the measuring. Each Porg has a light sensor on its chest and the sensors are read by two ADS1115 converters at 0x48 and 0x4A, four channels each, so the bar supports up to eight targets. A row of sixteen MAX7219 matrix modules runs the full length of the front as a scrolling display, driven by MD_Parola, and a WS2812B per position marks which Porg is currently active and turns red on a hit.
Hit detection compares the live reading of the active target against a baseline value stored for that target. Above the baseline means the laser is on it.
Mechanical construction
The Porgs and the E-11 blaster were printed in Prusament PLA on a Prusa MK3 and MK4. The Porgs were painted by club members, which is why the five of them do not look identical — that variation is worth more here than five matching birds would have been.
They sit on a dark wooden beam that runs the width of the installation, with all the electronics hidden inside it below the birds. The only visible parts are the sensors on the Porgs and the LED matrix strip along the front face.
Software
The interesting part happens before anyone shoots. At startup the target bar runs a scan across all eight ADC channels. Channels that return an implausible value are treated as empty, and the rest are counted as usable targets and have their baseline recorded. The bar reports how many Porgs it found and plays with that number.
That single routine replaces what the previous generation needed a person for. On generation two, every satellite had a potentiometer that had to be adjusted against the ambient light of the room before play. Here the room is measured instead of compensated for, and adding or removing a Porg needs nothing but plugging it in.
During a round the bar picks an active target, waits for its reading to rise above the recorded baseline, counts the hit, and reports it to the other two boxes. At ten shots the round closes and the display scrolls the result.
Lessons learned
Calibration that a person has to do will eventually not get done. Generation two worked, but only if someone went along the row with a screwdriver first. On an event day that step gets rushed or skipped, and a badly set target either never registers or registers constantly. Moving the calibration into the startup routine removed the failure mode rather than documenting it.
PLA does not survive storage in the sun. The Porgs stood in a living room in direct sunlight between events. After a few weeks they had deformed completely, and the feet under the wooden beam had softened and slumped. Nothing about that happened during use — it happened while the installation was standing still. A prop that lives for years and spends most of that time in storage has to be judged by where it is kept, not by what it does on an event day, and PLA is the wrong material for anything that might end up near a window.
The repair used the same property that caused the damage: the Porgs were reshaped with a heat gun rather than reprinted. A material soft enough to slump in a sunlit room is also soft enough to be pushed back into shape, which made the fix an afternoon instead of a print queue.
Let the hardware report itself. Because the bar detects how many targets are connected instead of being told, a Porg can be left out — damaged, in transport, not enough space on a table — and the game adjusts. The count is not a configuration value anywhere in the firmware.
