A circular 3D-printed board is shown, with a roughly star-shaped pattern of white LEDs glowing through the surface. Yellow and green LEDs are also visible through the surface at a few points.

Adding Electronics To A Classic Game

Like many classic board games, Ludo offers its players numerous opportunities to inflict frustration on other players. Despite this, [Viktor Takacs] apparently enjoys it, which motivated him to build a thoroughly modernized, LED-based, WiFi-enabled game board for it (GitHub repository).

The new game board is built inside a stylish 3D-printed enclosure with a thin white front face, under which the 115 LEDs sit. Seven LEDs in the center represent a die, and the rest mark out the track around the board and each user’s home row. Up to six people can play on the board, and different colors of the LEDs along the track represent their tokens’ positions. To prevent light leaks, a black plastic barrier surrounds each LED. Each player has one button to control their pieces, with a combination of long and short presses serving to select one of the possible actions.

The electronics themselves are mounted on seven circuit boards, which were divided into sections to reduce their size and therefore their manufacturing cost. For component placement reasons, [Viktor] used a barrel connector instead of USB, but for more general compatibility also created an adapter from USB-C to a barrel plug. The board is controlled by an ESP32-S3, which hosts a server that can be used to set game rules, configure player colors, save and load games, and view statistics for the game (who rolled the most sixes, who sent other players home most often, etc.).

If you prefer your games a bit more complex, we’ve also seen electronics added to Settlers of Catan. On a rather larger scale, there is also this LED-based board game which invites humans onto the board itself. Continue reading “Adding Electronics To A Classic Game”

The Eleven-Faced Die That Emulates Two Six-sided Dice

Rolling two six-sided dice (2d6) gives results from 2 to 12 with a bell curve distribution. Seven being the most common result, two and twelve being the least common. But what if one could do this with a single die?

This eleven-sided die has a distribution matching the results of 2d6.

As part of research Putting Rigid Bodies to Rest, researchers show that a single eleven-sided asymmetric shape can deliver the same results. That is to say, it rolls numbers 2 to 12 in the same distribution as 2d6. It’s actually just one of the oddball dice [Hossein Baktash] and his group designed so if you find yourself intrigued, be sure to check out the 3D models and maybe print your own!

The research behind this is a novel method of figuring out what stable resting states exist for a given rigid body, without resorting to simulations. The method is differentiable, meaning it can be used not just to analyze shapes, but also to design shapes with specific properties.

For example, with a typical three-sided die each die face has an equal chance of coming up. But [Hossein] shows (at 8:05 in the video, embedded below) that it’s possible to design a three-sided die where the faces instead have a 25%-50%-25% distribution.

How well do they perform in practice? [Hossein] has done some physical testing showing results seem to match theory, at least when rolled on a hard surface. But we don’t think anyone has loaded these into an automated dice tester, yet.

Continue reading “The Eleven-Faced Die That Emulates Two Six-sided Dice”

KiDoom Brings Classic Shooter To KiCad

As the saying goes: if it has a processor and a display, it can run DOOM. The corollary here is that if some software displays things, someone will figure out a way to make it render the iconic shooter. Case in point KiDoom by [Mike Ayles], which happily renders DOOM in KiCad at a sedate 10 to 25 frames per second as you blast away at your PCB routing demons.

Obviously, the game isn’t running directly in KiCad, but it does use the doomgeneric DOOM engine in a separate process, with KiCad’s PCB editor handling the rendering. As noted by [Mike], he could have used a Python version of DOOM to target KiCad’s Python API, but that’s left as an exercise for the reader.

Rather than having the engine render directly to a display, [Mike] wrote code to extract the position of sprites and wall segments, which is then sent to KiCad via its Python interface, updating the view and refreshing the ‘PCB’. Controls are as usual, though you’ll be looking at QFP-64 package footprints for enemies, SOIC-8 for decorations and SOT-23-3 packages for health, ammo and keys.

If you’re itching to give it a try, the GitHub project can be found right here. Maybe it’ll bring some relief after a particularly frustrating PCB routing session.

Microsoft Open Sources Zork I, II And III

The history of the game Zork is a long and winding one, starting with MUDs and kin on university mainframes – where students entertained themselves in between their studies – and ending with the game being ported to home computers. These being pathetically undersized compared to even a PDP-10 meant that Zork got put to the axe, producing Zork I through III. Originally distributed by Infocom, eventually the process of Microsoft gobbling up game distributors and studios alike meant that Microsoft came to hold the license to these games. Games which are now open source as explained on the Microsoft Open Source blog.

Although the source had found its way onto the Internet previously, it’s now officially distributed under the MIT license, along with accompanying developer documentation. The source code for the three games can be found on GitHub, in separate repositories for Zork I, Zork II and Zork III.

We previously covered Zork’s journey from large systems to home computers, which was helped immensely by the Z-machine platform that the game’s code was ported to. Sadly the original games’s MDL code was a bit much for 8-bit home computers. Regardless of whether you prefer the original PDP-10 or the Z-machine version on a home computer system, both versions are now open sourced, which is a marvelous thing indeed.

Commodore’s Most Popular Computer Gets DOOM-style Shooter

When people talk about the lack of a DOOM being the doom Commodore home computers, they aren’t talking about the C64, which was deep into obsolescence when demon-slaying suddenly became the minimal requirement for all computing devices. That didn’t stop [Kamil Wolnikowski] and [Piotr Kózka] from hacking together Grey a ray-cast first-person shooter for the Commodore 64.

Grey bares more than a passing resemblance to id-software’s most-ported project. It apparently runs at 16 frames per second on a vanilla C64 — no super CPU required. The secret to the speedy game play is the engine’s clever use of the system’s color mapping functionality: updating color maps is faster than redrawing the screen. Yeah, that makes for rather “blockier” graphics than DOOM, but this is running on a Commodore 64, not a 386 with 4 MB of RAM. Allowances must be made. Come to think of it, we don’t recall DOOM running this smooth on the minimum required hardware — check out the demo video below and let us know what you think.

The four-level demo currently available is about 175 kB, which certainly seems within the realms of possibility for disk games using the trusty 1541. Of course nowadays we do have easier ways to get games onto our vintage computers.

If you’re thinking about Commodore’s other home computer, it did eventually get a DOOM-clone. Continue reading “Commodore’s Most Popular Computer Gets DOOM-style Shooter”

Diskette Game Floppy Flopper Is Certainly No Flop

There’s a tactile joy to the humble 3.5″ floppy that no USB stick will ever match. It’s not just the way they thunk into place in a well-made drive, the eject button, too, is a tactile experience not to be missed. If you were a child in disk-drive days, you may have popped a disk in-and-out repeatedly just for the fun of it — and if you weren’t a child, and did it anyway, we’re not going to judge. [igor] has come up with a physical game called “Floppy Flopper” that provides an excuse to do just that en masse, and it looks like lots of fun.

It consists of nine working floppy drives in a 3×3 grid, all mounted on a hefty welded-steel frame. Each drive has an RGB LED above it. The name of the game is to swap floppies as quickly as possible so that the color of the floppy in the drive matches the color flashing above it. Each successful insertion is worth thirteen points, tracked on a lovely matrix display. Each round is faster than the last, until you miss the window or mix up colors in haste. That might make more sense if you watch the demo video below.

Continue reading “Diskette Game Floppy Flopper Is Certainly No Flop”

Pong Gets The Boot

You might be surprised to find out that [Akshat Joshi’s] Pong game that fits in a 512-byte boot sector isn’t the first of its kind. But that doesn’t mean it isn’t an accomplishment to shoehorn useful code in that little bitty space.

As you might expect, a game like this uses assembly language. It also can’t use any libraries or operating system functions because there aren’t any at that particular time of the computer startup sequence. Once you remember that the bootloader has to end with two magic bytes (0x55 0xAA), you know you have to get it all done in 510 bytes or less.

This version of Pong uses 80×25 text mode and writes straight into video memory. You can find the code in a single file on GitHub. In the old days, getting something like this working was painful because you had little choice but reboot your computer to test it and hope it went well. Now you can run it in a virtual machine like QEMU and even use that to debug problems in ways that would have made a developer from the 1990s offer up their life savings.

We’ve seen this before, but we still appreciate the challenge. We wonder if you could write Pong in BootBasic?