Simple Games From A Simpler Time

Modern video games are nothing short of amazing. My son and I were playing through the one of the latest Zeldas, which involve a mix of combat and puzzle-solving that’s pretty much the hallmark of the franchise. But the most recent open-world Zelda is simply massive. Made by around 1,000 people at a development expense of $150,000,000, it takes probably 60-80 hours to play through if you’re not rushing, and more if you’re taking it easy. It has layers of game mechanics, and worlds in the sky, on land, and underground. It’s big in every way.

Contrast the games of my youth, which were a lot smaller. Written by a pair of people or maybe a handful, with playtimes in the single-digit hours, and of course fitting in the limited computing resources of the time. But the low-stakes nature of the early phases of the industry meant that software developers could take risks, and many of the games were consequently kinda idiosyncratic in this more innocent time.

I think there’s something to be said for small games. They don’t require a lifestyle commitment just to get through. They can still be fun, without taking all of your time. And honestly, when you’re done with a game quickly, you have more time for other stuff. Granted, some of this spirit lives on in the small indie games of today, but even so, game developers have the big studios’ products in the backs of their minds when they are working on their smaller oeuvres.

We were talking about preserving old games for posterity around Hackaday and on the podcast, and our conversations reminded me of a couple of educational games that, despite their rudimentary graphics, are still pretty good today. Both were electronics related, and both are still playable today thanks to efforts on emulation and software preservation. To get a feel for the 1980’s, give Rocky’s Boots a try. (I like the TRS-80 Color Computer version the best, but that may just be nostalgia.) Most of you grownups out there will get through it in an hour or so.

And if you want a challenge, try Rocky’s harder sequel: Robot Odyssey. If you already have a background in digital circuits, you’ll find it doable. Younger me hit a wall about two-thirds of the way through.

Both of these games stick with me because they taught me something, but also because they were simply quirky in a way that a game can only be when it’s written by a small team of folks who are just having fun programming it. If you pitched “a puzzle game about a raccoon who builds logic circuits to activate robot boots”, the boardroom would look at you like you’re out of your mind. But it’s just exactly the quirkiness and individuality of some of these early games that I cherish the most.

If you find yourself knee-deep in an endless modern game, take a side-quest off into a more naive time, and you’ll appreciate why people are putting efforts into archiving them.

Extract 3D Video Game Content By Firing Up Photo Mode

Here’s a pretty clever method [Dung3onlord] used to capture 3D scenes from a PlayStation 5 without needing any specialized software. All that’s needed is a series of high-resolution screenshots, and a few software tools.

The process is essentially photogrammetry, it just uses screenshots as the input instead of photographs.

Instead of sneakily yanking 3D assets from the runtime, he fires up the game’s photo mode on his PS5. By capturing an orbiting video of a static scene (making sure to hide the game’s user interface, something photo mode in games is good for) he ends up with a video file whose content — essentially a series of screenshots — can be used to reconstruct the original 3D scene. The workflow [Dung3onlord] uses has rather more steps, but conceptually that’s all there is to it.

The whole process is remarkably similar to photogrammetry, a method of turning a bunch of photographs from different angles into a 3D point cloud. We’ve seen photogrammetry used to digitize objects because point clouds can be turned into 3D models, essentially allowing one to 3D scan an object using little more than a digital camera.

Continue reading “Extract 3D Video Game Content By Firing Up Photo Mode”

Writing An Open-World Engine For The Nintendo 64

Anyone who has ever played Nintendo 64 games is probably familiar with the ways that large worlds in these games got split up, with many loading zones. Another noticeable aspect is that of the limited drawing distance, which is why even a large open area such as in Ocarina of Time‘s Hyrule Field has many features that limit how far you can actually see, such as hills and a big farming homestead in the center. Yet as [James Lambert] demonstrates in a recent video, it’s actually possible to create an open world on the N64, including large drawing distances.

As explained in the video, the drawing distance is something that the developer controls, and thus may want to restrict to hit certain performance goals. In effect he developer sets where the far clipping plane is set, beyond which items are no longer rendered. Of course, there are issues with just ramping up the distance to the far clipping plane, as the N64 only has a 15-bit Z-buffer, after which you get ‘Z fighting’, where render order becomes an issue as it’s no longer clear what is in front of what.

One fix is to push the near clipping plane further away from the player, but this comes with its own share of issues. Ergo [James] fixed it by doing two render passes: first all the far-away objects with Z-buffer disabled, and then all the nearby objects. These far-away objects can be rendered back-to-front with low level-of-detail (LoD), so this is relatively fast and also saves a lot of RAM, as the N64 is scraping by in this department at the best of times.

In the video the full details of this rendering approach, as well as a new fog rendering method, are explained, with the code and such available on GitHub for those who wish to tinker with it themselves. [James] and friends intend to develop a full game using this engine as well, so that’s definitely something to look forward to.

Continue reading “Writing An Open-World Engine For The Nintendo 64”

Handheld Steering Wheel Controller Gets Force-Feedback

For a full-fledged, bells-and-whistles driving simulator a number of unique human interface devices are needed, from pedals and shifters to the steering wheel. These steering wheels often have force feedback, with a small motor inside that can provide resistance to a user’s input that feels the same way that a steering wheel on a real car would. Inexpensive or small joysticks often omit this feature, but [Jason] has figured out a way to bring this to even the smallest game controllers.

The mechanism at the center of his controller is a DC motor out of an inkjet printer. Inkjet printers have a lot of these motors paired with rotary encoders for precision control, which is exactly what is needed here. A rotary encoder can determine the precise position of the controller’s wheel, and the motor can provide an appropriate resistive force depending on what is going on in the game. The motors out of a printer aren’t plug-and-play, though. They also need an H-bridge so they can get driven in either direction, and the entire mechanism is connected to an Arduino in the base of the controller to easily communicate with a computer over USB.

In testing the controller does behave like its larger, more expensive cousins, providing feedback to the driver and showing that it’s ready for one’s racing game of choice. It’s an excellent project for those who are space-constrained or who like to game on the go, but if you have more space available you might also want to check out [Jason]’s larger version built from a power drill instead parts from an inkjet.

Continue reading “Handheld Steering Wheel Controller Gets Force-Feedback”

Recreating A Homebrew Game System From 1987

We often take for granted how easy it is to get information in today’s modern, Internet-connected world. Especially around electronics projects, datasheets are generally a few clicks away, as are instructions for building almost anything. Not so in the late 80s where ordering physical catalogs of chips and their datasheets was generally required.

Mastering this landscape took a different skillset and far more determination than today, which is what makes the fact that a Japanese electronics hobbyist built a complete homebrew video game system from scratch in 1987 all the more impressive.[Alex] recently discovered this project and produced a replica of it with a few modern touches.

Continue reading “Recreating A Homebrew Game System From 1987”

What Happened To Running What You Wanted On Your Own Machine?

When the microcomputer first landed in homes some forty years ago, it came with a simple freedom—you could run whatever software you could get your hands on. Floppy disk from a friend? Pop it in. Shareware demo downloaded from a BBS? Go ahead! Dodgy code you wrote yourself at 2 AM? Absolutely. The computer you bought was yours. It would run whatever you told it to run, and ask no questions.

Today, that freedom is dying. What’s worse, is it’s happening so gradually that most people haven’t noticed we’re already halfway into the coffin.

Continue reading “What Happened To Running What You Wanted On Your Own Machine?”

A History Of Pong

Today, creating a ground-breaking video game is akin to making a movie. You need a story, graphic artists, music, and more. But until the middle of the 20th century, there were no video games. While several games can claim to be the “first” electronic or video game, one is cemented in our collective memory as the first one we’d heard of: Pong.

The truth is, Pong wasn’t the first video game. We suspect that many people might have had the idea, but Ralph Baer is most associated with inventing a practical video game. As a young engineer in 1951, he tried to convince his company to invest in games that you could play on your TV set. They didn’t like the idea, but Ralph would remember the concept and act on it over a decade later.

But was it really the first time anyone had thought of it? Perhaps not. Thomas Goldsmith Jr. and Estle Ray Mann filed a patent in 1947 for a game that simulated launching missiles at targets with an oscilloscope display. The box took eight tubes and, being an oscilloscope, was a vector graphic device. The targets were physical dots on a screen overlay. These “amusement devices” were very expensive, and they only produced handmade prototypes.

Continue reading “A History Of Pong”