Crunchlabs Laser Tag: Build, Aim and Fire

The fifth box of the Hack Pack tries to do something different. Moving away from robotics, the Laser Tag kit combines infrared communication with a lens system and a set of polarized filters to create a simple two-player interaction. In practice, the implementation remains simple. A trigger press sends an infrared signal through a focused lens, and the receiving goggles react by rotating polarized filters to reduce visibility.

CrunchLabs IR Turret: Build, Code, and FireCan a foam-dart turret teach you embedded programming? The CrunchLabs Hack Pack says yes. This hands-on project introduces IR sensors, servo motors, and tidy Arduino codeTechnodabblerAlex Denault

If you want to start at the beginning, the IR Turret is the first build of the series.

This article explores how the Laser Tag Hack Pack is built and how it works in practice. It begins with the components inside the box, then looks at the polarized lens system that defines the experience, before examining the build, the code, and where the design can be taken further.

💡

CrunchLabs has updated the order in which Hack Pack robots are shipped, placing several fan favorites into the first year. This part of an on-going effort to optimize how builders learn and progress. That said, Technodabbler will continue to refer to it as the fifth robot in the series, but new members will receive their Hack Pack projects in a different order. Thanks to Hack Pack Hackers for pointing out the changes in the lineup.

What is Laser Tag?

Laser tag is a game where players aim at each other using devices that send light signals. Despite the name, most systems do not use actual lasers. Instead, they rely on infrared light, similar to a TV remote, because it is safe, inexpensive, and easy to detect with small sensors. Each player carries a transmitter, often shaped like a blaster, and a receiver worn on the body or head. When the transmitter sends a coded infrared pulse and the receiver detects it, the system registers a hit. Commercial systems typically track score, health, and team affiliation, using sound or lights to provide feedback to the player.

A Polish solider, training with MILES, photo credits to Raymond A Banard, Public Domain

The concept has roots in military training systems developed in the late 1970s. Programs like MILES (Multiple Integrated Laser Engagement System) used infrared emitters and sensors mounted on weapons and uniforms to simulate combat without live ammunition. These systems established the basic model of transmitting a signal and registering hits electronically.

Photon, home edition, available with and without helmet.

By the late 1970s and early 1980s, the idea had been adapted for entertainment. Early commercial systems like Photon brought laser tag into arcades and dedicated arenas, and the format expanded through the 1990s with team-based play and scoring systems. As the technology became more affordable, home versions became more common, though their implementations varied widely. Some simplified the design by placing both the emitter and receiver in the blaster, which reduced cost but also limited gameplay. While the technology has evolved, the core idea has remained consistent: a transmitter sends a signal, a receiver detects it, and the system translates that interaction into gameplay.

Inside the Box

The Laser Tag Hack Pack is built from a small set of components that work together to create both the blaster and the goggles. As with previous kits, the core of the system is an Arduino-compatible board mounted on a compact breadboard. It handles input from the trigger, processes incoming infrared signals, and drives the actuator responsible for blinding the player when hit. The layout will feel familiar to anyone who has worked through earlier Hack Pack projects, with clearly labeled power rails and grouped connections for sensors and motors.

All the pieces needed to build the Laser Tag kit.

Infrared communication is handled through a paired emitter and receiver. The blaster uses an IR LED positioned at the front of the barrel to transmit signals, while the goggles carry an IR receiver module mounted above the frame. Each trigger press sends a coded pulse of infrared light, which the receiver interprets as a valid hit when it matches the expected pattern. This approach is consistent with the earlier IR Turret, though here it is used as a game mechanic rather than a control interface.

Left, the IR emitter and on the right, the IR receiver.

A lens mounted in the barrel plays a critical role in how that signal travels. Without it, the IR LED would emit light in a wide cone, limiting the effective range to only a short distance.

The lens found in the barrel and used to focus the IR signal.

The lens reshapes that output into a more focused, forward-directed beam, allowing the signal to reach across a room with enough intensity to be detected reliably.

The lens focuses the IR signal.

The polarizing filters are the defining components of this build. Each eye uses two layers of film mounted on separate rotating elements. By changing their relative orientation, the system controls how much light passes through to the user. Unlike earlier kits that rely on movement or sound, this project uses optical behavior as its primary form of feedback.

The servo motor and filters installed in on the goggle.

Actuation is provided by a continuous rotation servo motor. Instead of moving a visible mechanism like a turret or linkage, the servo drives a set of ring gears embedded in the goggle frame. These gears rotate pairs of polarizing filters positioned in front of each eye. The build uses servo homing at startup, forcing the filters to their initial position to determine the current position of the servo.

The servo motor, used to rotate the polarizing filter.

The remaining parts form the structure that supports these components. The goggles use a lightweight frame with mounting points for gears, filters, and the receiver module, along with foam padding and a head strap for wearability. The blaster shell houses the controller, trigger button, IR LED, lens, and battery pack. The enclosure keeps the electronics accessible while maintaining alignment between the emitter and the optical components at the front of the barrel.

The plastic frames for the blaster and the goggles.

Taken individually, none of these components are particularly complex. What stands out is how they are arranged. The kit combines familiar electronic parts with a mechanical system that directly manipulates light, setting up a build where the hardware itself becomes the feedback mechanism.

Polarized Vision

The most distinctive part of the Laser Tag build is the goggles. Instead of signaling a hit with sound or vibration, the system reduces what the player can see using polarized light. The effect is immediate and comes from a simple optical principle.

8 polarized filters used for the build.

A polarizing filter allows light aligned in one direction to pass through. With a single filter, this is not very noticeable. The effect becomes clear when two filters are combined. If both are aligned, light passes through. As one is rotated relative to the other, less light gets through. At ninety degrees, the filters block most of the light, and the view becomes dark.

Viewing an image through a clear filter (1), a polarized (or several aligned) (2) and crossed polarized lens (3). This is a simplification: the way polarized filters block light is a bit more complicated.

The goggles use two filters per eye mounted on separate rotating elements. One remains fixed, while the other is driven by a servo through a set of gears. As the servo turns, it changes the alignment between the filters, reducing the amount of light that reaches the eye.

As the lens rotate, the alignment between the filters change, eventually blocking out light.

Because the filters rotate mechanically, the effect can be controlled. A small rotation dims the view slightly, while a larger rotation blocks most of the light. This makes the blackout both adjustable and repeatable.

Building the Laser Tag Set

The Laser Tag build follows a familiar pattern for anyone who has completed other Hack Pack projects. It combines infrared signaling with servo-driven motion, using a similar breadboard layout and Arduino-compatible controller. The main difference is structural. Instead of a wooden frame with mounted components, this kit relies on lightweight plastic enclosures for both the goggles and the blaster. The result is a build that is simpler and faster to assemble, but also less mechanically involved.

The build starts with assembling the lens. The filters fit into pegs found in specific locations, forcing them into the correct orientation.

The goggles are assembled first, starting with the servo and gear system that drives the polarizing filters. The mechanism itself is simple, but it requires careful alignment. The gears must mesh correctly, and the filters need to be installed with the proper orientation for the dimming effect to work. This part of the build is functional, though not particularly engaging. The foam padding, intended to improve comfort, is mounted using small plastic posts, but it does not stay in place reliably and tends to come loose during handling.

The most frustrating part of the build: the foam padding is always falling.

The blaster is equally direct. The controller, trigger button, IR LED, and lens are mounted inside a two-piece shell that closes around the electronics. Wiring follows the usual breadboard layout, with power rails shared across components. One inconsistency appears in the pin assignments. The printed guide and the manual do not always match, which forces some trial and error when connecting the final wires.

The most challenging task in blaster assembly is routing the different wiring to the ESP board.

One limitation of the build is that it offers little feedback during assembly. Most Hack Pack projects allow partial testing as subsystems come together, whether through motion, sound, or visible output. Here, the system only becomes meaningful once both the blaster and goggles are complete and connected. Until then, there is little indication that the build is progressing correctly.

The final step in blaster assembly is velcro-ing the battery to the top of the blaster. Seems like a lost opportunity to have the battery part of the handle.

Once assembled, the interaction is minimal. Pressing the trigger sends an infrared signal, and the goggles respond by rotating the filters. The system works as intended, but the behavior is simple and lacks the mechanical presence of earlier builds. There is no continuous motion, no visible mechanism beyond the lenses, and no intermediate states during operation. Compared to other kits in the series, the build feels more like a demonstration of a concept than a machine with evolving behavior.

The Code

The Laser Tag code is a sharp contrast to more complex projects like the Sand Garden. There is no coordinated motion system or layered control logic: the entire program can be read and understood in a single sitting. The concept is built around a small event loop, not unlike those found in games. Each pass through loop() does only two things: it checks the trigger state and it checks whether an infrared message has been received.

void loop() {
  unsigned long currentMillis = millis();

  handleTrigger(currentMillis);
  handleIRReception();
}

The main loop, monitors the trigger and checks the receiver.

The trigger uses INPUT_PULLUP, so the button reads high when idle and low when pressed. The ReadTriggerButton() function applies a short debounce delay to filter out noise, and the code tracks whether the button has been released since the last shot. This prevents continuous firing when the trigger is held. A shot is only sent when the button is newly pressed and the cooldown period has elapsed.

void handleTrigger(unsigned long currentMillis) {
  if (ReadTriggerButton() && buttonWasReleased && currentMillis - previousTriggerMillis >= TRIGGER_COOLDOWN) {
    previousTriggerMillis = currentMillis;
    buttonWasReleased = false;

    sendIR_Pulse();
  } else if (!ReadTriggerButton()) {
    buttonWasReleased = true;
  } else {
  }
}

void sendIR_Pulse() {
  Serial.flush();
  IrSender.sendNEC(0x00, sCommand, 3);
  delay(10);
}

Checks if the trigger was pressed, and fire an IR signal. Lost of precaution as taken to make sure the trigger is properly pressed and detect if its held down.

Firing itself is straightforward: the sendIR_Pulse() function sends a short NEC infrared command using IrSender.sendNEC(0x00, sCommand, 3). The actual command depends on the selected team, with each team assigned its own byte value. On startup, the code reads three jumper pins to determine which team the blaster belongs to, then assigns one command for transmission and two valid enemy commands for reception. That is how the stock game prevents friendly fire without requiring any more complicated identification scheme.

  if (digitalRead(TEAM1_PIN) == LOW) {
    team = 1;
  } else if (digitalRead(TEAM2_PIN) == LOW) {
    team = 2;
  } else if (digitalRead(TEAM3_PIN) == LOW) {
    team = 3;
  }

  if (team == 1) {
    sCommand = 0x34;
    rcvCommand1 = 0x35;
    rcvCommand2 = 0x36;
  } else if (team == 2) {
    sCommand = 0x35;
    rcvCommand1 = 0x34;
    rcvCommand2 = 0x36;
  } else {
    sCommand = 0x36;
    rcvCommand1 = 0x34;
    rcvCommand2 = 0x35;
  }

At initialization, the build determines the team of the player and assigns which signals are friendly.

Incoming IR traffic is handled just as simply. If IrReceiver.decode() succeeds, the code checks whether the received command belongs to one of the opposing teams. If it does, and the player is not already in a timeout period, markHit() is called. There is no health counter or accumulation of damage. A valid enemy signal immediately triggers the hit behavior.

void handleIRReception() {
  if (IrReceiver.decode()) {
    checkPlayerHit();
    IrReceiver.resume(); // Ensure IR receiver is reset
  }
}

void checkPlayerHit() {
  if (IrReceiver.decodedIRData.command == rcvCommand1 || IrReceiver.decodedIRData.command == rcvCommand2) {
    if (millis() - timeoutStartTime > HIT_TIMEOUT + 1000) {
      markHit();
    }
  }
}

Check the IR receiver if the player was hit.

That response highlights an important limitation. The code does not multitask, largely because the microcontroller cannot reliably handle simultaneous IR decoding and servo control with precise timing. When markHit() runs, it records the current time, attaches the servo, and rotates the goggles to the hit position. During this time, the goggles are darkened by rotating the servo and no new inputs are processed. The trigger is ignored, and incoming IR signals are not decoded. Near the end of the timeout, the code moves the servo back toward its starting position so the goggles begin to clear before control returns to the main loop.

void markHit() {

  timeoutStartTime = millis(); // get current time

  // move goggles to darken
  myservo.attach(SERVO_PIN);
  myservo.write(SERVO_HIT_POS);

  while (millis() - timeoutStartTime < HIT_TIMEOUT) {

    // In last 20% of timeout, begin to move servo towards starting position
    int timeVal = (millis() - timeoutStartTime) / 100;
    if (millis() > timeoutStartTime + (HIT_TIMEOUT * (4.0 / 5.0))) {
      myservo.write(SERVO_INITIAL_POS);
    }
  }
  myservo.detach();
}

If the player was hit, the build rotates the lens. Note that the build cannot fire or receive an IR signal while the lens are turning.

This design keeps the implementation simple. The program moves between short, isolated states rather than reacting continuously. Compared to earlier Hack Pack builds, the focus here is on enforcing a small set of rules.

Beyond the Design

This Hack Pack naturally branches in two directions, one in software and one in hardware. On the software side, the simplest path is to expand the gameplay. The stock implementation treats every hit the same way, but the structure of the code makes it easy to introduce variation. A player could be given multiple lives, with each hit progressively reducing visibility instead of triggering a full blackout. The firing system could also be extended with limited ammunition, reload delays, or different shot behaviors. These changes build directly on the existing timing and state logic, and they add depth without requiring major architectural changes.

Nathan's Iron Man project, filtting the build hardware into a glove.

On the hardware side, the design invites modification. Both the blaster and the goggles are simple enclosures, and 3D printable replacements are already available online. This opens the door to more ergonomic designs, improved lens alignment, or entirely different form factors. Additional elements can also be layered onto the system, such as visual indicators for ammunition or targeting, force feedback on hit, or expanded blaster components like barrels and stocks. One more creative 3D print hack from Nathan on the Hack Pack Discord, integrating the blaster into an Iron Man glove.

Final Thoughts

The Laser Tag Hack Pack is one of the simplest builds in the series, and it shows. It introduces few new concepts and leans heavily on ideas already covered, making it feel out of place this late in the program. This would have been a better fit as an earlier kit, where its simplicity could serve as an introduction rather than a regression. The foam constantly falling from the goggles makes the kit feel less than premium.

Both sets of blaster and goggles, fully assembled.

The project also marks a shift in design. It is the first build to rely mostly on plastic, and the absence of the wooden structure reduces the mechanical presence that defined earlier kits. Combined with the limited interaction, press a button, send IR, rotate lenses, it lacks much of the robotics and evolving behavior seen in previous builds. The versus concept is interesting, and reminiscent of the Coin Flipper from the Build Box series, but it is not developed far enough to carry the experience. Overall, this feels like the weakest kit in the first year of the Hack Pack. That is not entirely surprising given that it has since been removed from the lineup.

If you have worked through this Hack Pack, does it feel like a useful step in the progression, or more like a detour from the earlier builds? For a retro look at another take on head-mounted hardware, visit our Oculus Rift DK2 VR Review, which explores a very different approach to immersive design.

                        Learn more