“It’s frustrating,” says David Murray, developer of Planet X3, which has raised over $100,000 on Kickstarter.

“You Google [a programming problem], it will pull up some forum that will say ‘here’s how you do that, check this link’. You click the link and it’s dead. It’s probably been dead for 10 years.”

Murray is not in the same boat as most developers: Planet X3 is a strategy game designed for MS-DOS, the operating system that came out in 1981. It’s the sequel to Planet X2, which Murray released last year for the Commodore 64, the 8-bit home computer released in 1982.

Murray self-funded Planet X2 and wound up selling nearly 800 copies of that game, beating his initial order of 500 copies. Now, he’s already pre-sold 2,000 copies of Planet X3 through Kickstarter. Clearly, certain players are hungry for games that run on older hardware. But what are the challenges that come with developing for near 40-year-old systems?

Learning a lost art

Murray says he can’t say how different the process is from making games for modern systems because he’s never developed for them. But he’s following roughly the same process as he did for Planet X2—he writes the code in Notepad and then uses a compiler called A86 to convert the code into something that can run on MS-DOS. He then opens the final version in an emulator to test it, and frequently copies it over to a floppy disk to run it on his Tandy 1000 MS-DOS computer.

It’s working well: he’s about 75 percent complete with the game. But that doesn’t mean it’s been an easy ride. This is his first time programming for MS-DOS, and it’s “really, really difficult” at times. With a lack of a community of developers to reach out to, Murray relies on coaching from Jim Leonard, a well-known coder of games for old systems.

Planet X3, currently in development

“[MS-DOS programming] is a lost art,” Murray says. “If I didn’t have the help of Jim Leonard coaching me I probably wouldn’t have figured out how to do half the things I need to do.”

He’s run into an array of problems, many of which stem from the fact that, as well as a digital download of the game, he plans to sell Planet X3 on both 720K (3.5 inch) and 360K (5.25 inch) floppy disks, on which space is very restricted. He also wants to add VGA graphics support, which will take up more space than the CGA version of the game.

“As it stands right now there’s no way the [VGA version] would fit on the 360K floppy disk, but as a compromise, I’ll just leave off the VGA graphics from it,” he says. “Most of the machines that have 5.25-inch floppy as their only disk drive are not going to have VGA graphics.”

A target mockup of what Planet X3 should look like with VGA graphics

Murray has also had to find other ways to save space. The game’s maps are 32K each uncompressed, but he’s found some open-source compression routines that have got them down to 6K each, allowing him to fit them on the disks.

Adding VGA support could cause a further headache: it requires 64K of video RAM, instead of the 16K he’s currently working with. “I’ll have to move the entire VRAM area to another place in the RAM," he says. "And then all the code sections that reference where the VRAM is will have to be changed.” To avoid complications, Murray will therefore have to complete the code for other video modes before changing it to add VGA support, which will leave him with two source codes.

Working with different video modes, and across lots of different potential machines that can run the game, has also caused some issues with the game’s visuals. When running on the IBM 5150—one of the most popular machines that runs MS-DOS—the CGA composite mode of the game looks fine, “but some of the clone machines, when you pull it up in CGA composite, the colors are wrong,” Murray says. “I couldn’t find any documentation on this online.”

After some experimentation, Murray discovered that the issue could be resolved by cycling the color palette, essentially shifting all the pixels over by one, so he added that option to the game.

“If water is red and grass is blue, you can hit this to cycle the colors and it will look right,” he says. “The emulator doesn’t have this problem, so I wouldn’t have found out if I didn’t test on the real hardware.”

You might think that these issues could’ve been avoided if Murray was just selling a digital download of the final game, rather than a version that could run on near 40-year-old hardware. But having a physical product is a big part of what has drawn in Kickstarter backers, he says, and less than 10 percent of buyers have paid purely for a digital download.

“A lot of people want the physical media and box. Granted, a lot of those people will never use the physical media, they’ll use the digital download and they’ll play it on DOS-BOX, but nevertheless, they want to own it, and that’s part of the appeal of it.”

And far from feeling restricted by the nature of the system and hardware he’s coding for, Murray appreciates the extra RAM he’s able to use compared to when he was making Planet X2. X3 was supposed to be port of the previous game, but the extra RAM has allowed him to change it more fundamentally.

For example, he wanted to build Planet X2 with lots of different building types, but couldn’t because of RAM constraints. He even had to remove a building late in development to make room for enemy AI routines. For Planet X3, he’s been able to create eight buildings, each of which serves a different function.

Murray's Planet X2, released in 2017

He’s also polished the UI and lots of the mechanics. In Planet X2, you couldn’t choose where to build a structure: when you selected a building, your builder unit would place it wherever they were at the time. For X3, players will get a movable outline of the building before they decide where to stick it.

It’s been a long road for Murray. He says he’s tried to develop several games in the past, but none of them stuck because he couldn’t get feedback from would-be players. For Planet X2, he was able to drum up support through his popular YouTube channel, The 8-Bit Guy, which kept him motivated, despite the fact he had to start over three times during the first eight weeks of development because he realized the concept was “fundamentally not going to work”.

Now, he’s three-quarters of the way through a game that has already sold 2,000 copies and—provided he can avoid any further problems—is set to release it in May next year. It’s good to know that whatever type of game players are looking for, for whatever type of system, there will always be a developer willing to put in the hard work to make it come to life.