Simon Says With An RP2040

The team of [Michael] and [Chimdi] from Cornell’s Designing with Microcontrollers (ECE 4760) Fall 2023 session designed a version of Simon Says on an RP2040 which they call Pico Says. It uses UDP packets over WiFi to communicate between the players, and supports VGA graphics for output. Each player’s hardware consists of a Pico W module plus a control panel containing the four LEDs and buttons ( red, green, yellow, and blue ) plus send and reset buttons.

For purposes of this lab, the modules were build on a solderless breadboard and used perfboard for the control panels. They weren’t entirely happy with their choice of UDP because they experienced frequent datagram dropouts in the noisy environment of the microcontroller lab. They also planned to implement sound effects, but ran out of time after spending too much time on the WiFi implementation, and had to drop that feature. In the end, however, they wrapped up their project and demonstrated a working game. We can only speculate whether this bonus lesson in resource management was intended by [Dr. Hunter Adams] or not.

Two ECE 4760 course references are highlighted in the write-up that helped them jump-start the project: the UDP and VGA examples for the Pico. These are good links to put in your RP2020 toolbox for future projects, in addition to the ECE 4760 course home page itself. We’ve covered several of these projects recently, as well as the curriculum switch from the Microchip PIC32MX-based Microstick II to the RP2040 last Spring.

Continue reading “Simon Says With An RP2040”

Don’t Panic: A Cooperative Bomb Defusing Game

[Heath Paddock] wanted to confound his friends with a game that mimics an escape room in a box. About six months after starting, he had this glorious thing completed. It’s a hardware version of a game called Keep Talking and Nobody Explodes where players have five minutes to defuse a suitcase bomb. This implementation requires at least two players, one with the box-bomb itself, and one who holds all the knowledge but can’t see the box-bomb to defuse it.

The wiring of the Mastermind module.

[Heath]’s version has twice as many modules as the original game, each hand-wired one driven by an Arduino. One of the modules is an LED maze. There are two green anchor LEDs in one of six configurations, and and blue and a red LED.

The object is to move the blue LED next to the red one without touching any walls. Of course, the box-holder can’t see the walls and must describe the configuration of the anchor LEDs to their partner in order to get started.

All of the modules are quite different, which likely makes for an extremely fun and challenging five minutes. [Heath] reports that getting inter-module communication down was a long road. Eventually, [Heath] settled on a mesh network configuration and connected everything in a big loop. Be sure to check out the walk-through video after the break.

This isn’t the first time we’ve seen a hardware implementation of this game. Here’s one that uses a Raspberry Pi.

Continue reading “Don’t Panic: A Cooperative Bomb Defusing Game”

Simulate Running A Small Hardware Business With Hardware Hustle

[Oskitone]’s Hardware Hustle is a printable roll-and-write tabletop game that can be played on a single sheet of paper. It simulates attempting to run a small hardware business sustainably. Buy parts, make products, and sell them without burning yourself out!

If you’re not familiar with roll-and-write games, it’s a genre in which players take turns by rolling dice and then choosing how to assign those values in a game space as they progress from turn to turn. In the case of Hardware Hustle, it’s primarily a resource management game in which a player will be purchasing parts, assembling widgets, selling those widgets, and improving processes all while managing both money and opportunity costs.

The inspiration for Hardware Hustle comes from [Oskitone]’s own experience designing, building, and selling things like open-sourced, hackable synth kits that are known for their thoughtful design and fantastic use of 3D printing.

The game is in open beta-testing mode, so if you’d like to give it a try, head over to the PDF download section of the GitHub repository. Don’t forget to share your thoughts with the feedback form after playing. (If you’re wondering why a printable tabletop game has source code on GitHub, it’s because the game’s printable sheets are generated by JavaScript, making adjustments and tweaks and version control easier.)

Adding AI To NPCs Is Easy, Doing It Well Is Hard

Adding natural language interfaces to software is easier than ever, and that led [creikey] to prototype a game that hinges on communicating with NPCs. The prototype went through multiple iterations during which he mainly discovered things that did not work well. Ultimately, it led to [creikey] settling on a western-themed game called Dante’s Cowboy which he hopes to release as an experiment. He begins talking about the game around the 4:43 mark in the video, which directly precedes a recording of a presentation he gives at as an indie developer.

Games typically revolve around the player manipulating entities in an environment in order to make things happen. This interaction drives engagement and interesting decisions. But while adding natural language AI to NPCs makes them easy to talk with, talking by itself is a shallow interaction. Convincing NPCs to do things? That’s complex and far more difficult to implement. [creikey] realized the limitations large language models (LLMs) had and worked to overcome them to make a unique game experience.

The challenges boil down to figuring out how to drive meaningful interaction, aligning AI behavior with the gameplay context, and managing API costs. In his words, “it’s been a learning experience to figure out where [natural language AI] even belongs in a game, if it belongs at all.”

We’ve previously seen ChatGPT used to grant NPCs the ability to communicate naturally which is a fascinating tech demo, but gameplay-wise can boil down to being a complicated alternative to pressing a button. As [creikey] discovered, adding this technology into games in a way that feels meaningful takes a new kind of work.

Continue reading “Adding AI To NPCs Is Easy, Doing It Well Is Hard”

The controller after the rebuild, looking just like the stock controller but with an external antenna attached

An Extensive Walkthrough On Building Your Own KSP Controller

Having a game-tailored controller is a level-up in more ways than one, letting you perform in-game actions quickly and intuitively, instead of trying to map your actions to a clunky combination of keyboard and mouse movements. [abzman] took the Pelco KBD300A, a DVR-intended camera controller panel with a joystick, reverse-engineered it, and then rebuilt it into a Kerbal Space Program controller. What’s more, he documented every detail along the way!

The write-up is so extensive, it’s four separate posts — all of them worth reading without a doubt. In the first post, he describes the original hardware, the process of reverse-engineering it, and a few tips for your own RE journeys. Next, he covers about making his own board, showing all the small decisions he’s had to make, with plenty of KiCad screenshots. If you are on the lookout for designing such a board, there’s plenty to learn!

The original hardware didn’t go down without a fight — the third post talks about taming the seven-segment displays, the onboard joystick, and fighting with the key matrix wired in exactly the way you wouldn’t want. In the end, he shows us how you could tie a controller easily into Kerbal Space Program.

One more piece of hardware liberated, one more win for the hacker world. Whether it’s a Macintosh SE, a classic ThinkPad, or even a generic rotary tool, these upgrades are always a joy to see. If you wanted to learn to do such an upgrade yourself, here’s us showing how you can pull this off with a classic Sony Vaio!

Pinball With No Computers

Pinball machines were the video games of their day. Back when they were king, there were no microcontrollers — everything was electromechanical. We know from experience that fixing these was difficult but we imagine that designing complex play behavior with a bunch of motors, relays, clutches, contacts, and more would have been excruciatingly difficult. [Technology Connections] has several videos about an old Aztec machine and he promises more to come. You can watch the first two below.

To give you an idea of what’s involved, imagine a very simple pinball machine that supports a single player and a handful of targets. When the ball hits a target, that could trigger a micro-switch. The switch closure could trigger a relay that closes a contact for a short period of time. That contact energizes a solenoid that advances the score wheels. So now, when a ball hits a target, the score wheel will spin enough to award ten points. To make sure there is enough time for the score to advance, the relay uses something like a mechanical flip flop.

Sound complicated? That’s nothing. Don’t forget, the machine also has to reset the score at the start of the game, count the ball in play, and end the game when the last ball returns. Then consider a real game. There will be multiple players and fancy sequences (e.g., hit the red target three times to award double scores for other targets).

While we knew a fair bit about the design of pinball machines already, we did learn a lot about their history and where the idea came from. The video also explains why it is called pinball since modern machines don’t really have pins — these were like relay-based computers with strange electromagnetic I/O devices.

While pinball machines were the best example of this sort of thing, there were also things like bowling machines and ladder-logic industrial control systems. We’ve even seen an electromechanical phone answering machine.

Continue reading “Pinball With No Computers”

Gyro-Controlled Labyrinth Game Outputs To VGA

This gesture-controlled labyrinth game using two Raspberry Pi Pico units does a great job of demonstrating how it can sometimes take a lot of work to make something look simple.

To play, one tilts an MPU6050 inertial measurement unit (IMU) attached to one Pico to guide a square through a 2D maze, with the player working through multiple levels of difficulty. A second Pico takes care of displaying the game state on a VGA monitor, and together they work wirelessly to deliver a coherent experience with the right “feel”. This includes low latency, simulating friction appropriately, and more.

Taking a stream of raw sensor readings and turning them into control instructions over UDP in a way that feels intuitive while at the same time generating a VGA display signal has a lot of moving parts, software-wise. The project write-up has a considerable amount of detail on the architecture of the system, and the source code is available on GitHub for those who want a closer look.

We’ve seen gesture controls interfaced to physical marble mazes before, but two Raspberry Pi Picos doing it wirelessly with a VGA monitor for feedback is pretty neat. Watch it in action in the video, embedded just under the page break.

Continue reading “Gyro-Controlled Labyrinth Game Outputs To VGA”