The Gamified Universal IDE

It's Not a Tool, it's a Brave New World

Posted Jun 16, 2025 | ~9 minute read

An Integrated Development Environment (IDE) is an app that helps build other apps. An IDE that can rewrite itself while running is called a Universal Integrated Development Environment (UIDE) because you can change it into whatever you need it to be.

Last week, I wrote about the multiverse metaphor for software engineering. Its an abstraction that draws the line between using a UIDE and changing it. Here's a quick refresher:

1. Using a UIDE to build a separate app is like navigating a normal IDE - you're navigating the known universe.
2. Using the UIDE to changing itself is like rewriting the laws of physics. The possibility space changes as you go. You're traveling between all possible universes.

A UIDE lets you explore the multiverse like a starship captain. Pretty cool, right? There's just one problem...

IDE's Aren't Star Trek

When I imagine traveling the multiverse, I don't think about opening a terminal window, installing third party package managers, working around local compatibility issues, and running a ten minute build every time I want to test a change.

In Star Trek, the captain's chair doesn't look like this:

This is not a strange new world. Exploring the multiverse could be a stunning, gratifying experience. We need something immersive. We need a Gamified Universal Integrated Development Environment - a GUIDE.

Adding 💎 Gems 💎 Doesn't Make It Fun

Increasingly, designers are seeing the need for gameplay features in order to add intrinsic value to their applications.

Many serious applications (including workplace applications) now include fictional currency (You just got 10 Gems!, Invite a friend to earn 5 Coins), badges (Top Contributor, 5 Day Streak!) and confetti every time you submit.

Maybe it’s just me, but those things don’t make an app fun on their own. They’re often just band-aids for tedious, sometimes exploitative, user experiences.

My Dream GUIDE

Those things aren't what I crave in a game. It's the story, the characters, the exploration, the creativity, and perhaps even some crazy physics. That's what drew me to the sci-fi classics — Star Trek, Stargate, Star Wars, etc.

Imagine a game that wasn't trying to cover up that it's secretly an IDE as much as it was trying to just be a game. Only, this game lets the community create and play the next version from within the game, without having to close the game.

This concept is a bit like a desktop operating system. You can change the behavior of it from within by adding, modifying and removing files. I'll admit, I get an unusual amount of joy from tinkering with vintage operating systems, but it's still not a video game. Making it a game will encourage a diverse group of contributors to take that game to the next level.

Next-Level Sandbox Game

There are already precedents for turning art, architecture, design and engineering into an engaging and collaborative gameplay experience - exactly what I want my GUIDE to be able to do.

One of my favorite examples is Minecraft. Players break their world into parts and rebuild it however they want. Redstone allows players to create circuits and machines which can automate complex tasks.

Fans of Minecraft have done some amazing things with it. A quick search on YouTube will show you mind-boggling creations, including low-level engineering (like making working computers).

Sandbox games are fun, but you can’t rewrite Minecraft’s code with redstone. As a software architect, what I really want is a game that directly maps its fictional technology and narrative structure to the game's real source code and development methodology - and then lets me engage with those things at native speed.

Dare I say… warp speed.

A Familiar Danger

A good game usually has at least a little bit of danger. In Minecraft, depending on the difficulty, hostile mobs will spawn, attack the player and destroy their hard work.

In general, desktop computer users already know that they shouldn't modify and delete system files unless they know what they're doing. The machine might hang forever, crash, get stuck in a boot loop, or even become a brick.

We could add enemies into the GUIDE, but we don't actually need to. Changing the code of an app while it's still running is like a surgeon operating on themself. The GUIDE is not in danger. It is the danger.

(Thankfully, its just a game.)

Back to the Multiverse

In addition to helping users understand the two kinds of change that can take place in the app, the multiverse metaphor also helps because:

1. The tie-in to fiction is stronger than file folders.

2. The risks and rewards are baked into our cultural consciousness.

3. Its a rich metaphor that begs to be extended.

There aren't a lot of movies about the risks of importing the wrong third-party SDK into a git repository. There are a lot of movies about playing around with the laws of physics and the dangers of advanced technology.

You Are the Hero

Picture this. You've just arrived at a massive, high-tech research facility. Everybody's glad you're here - they need your help on something big and secretive.

Everything about the facility demands exploration, but your new team is waiting for you in the briefing room. There's an air of mystery and a bit of suspense as you make your way there.

That's where they tell you about the giant, mysterious machine they built. It's a doorway to the multiverse and you're the one that gets to operate it.

Welcome to the Facility

The facility is divided into three sections. You start out in Section 1 - a study area for new hires. Here, you'll prove that you can fix a few broken things and enhance a few other things and you earn your way to Section 2.

Section 2 introduces you to experimental devices that let you to control time and space - within a sandbox. You can go into that sandbox as an avatar, like the Animus in Assassins Creed. The outside world is shielded from the effects of your work, in case you make a mistake.

You make people. You make fictional creatures. You bring historical figures to life. All the while, you hear whispers about the top secret work they're doing in Section 3…

Section 3 - Where The Sky is the Limit

One day you're approached by a mysterious man. It turns out, he's the facilities manager for Section 3. They know about you in Section 3. In fact, you've been recruited for a special project there.

As soon as you arrive, a new world opens up. Banners cover the walls, saying "The sky is the limit!"

To your right you see a 2 acre terrarium filled with dinosaurs.

To your left you see creatures from another world coming through a portal.

Before you know what's going on, a 12-legged robot climbs over the top of you.

"You have to be careful where you're going down here" they say. "After all, the sky is the limit."

You learn to bring your creations out of the sandbox and into the real world. You bring imaginary animals, plants, vehicles and technology out of the sandbox. After you forge your own research office, you move on to having bigger and bigger lab space and more and more dangerous reality-editing tools.

At this point, you're modifying the research facility itself. In regards to the code base of the game, you're replacing the art assets of the facility. You're making your own 3D models, rigs and animations. You're changing where NPCs spawn, making your own trigger volumes, and creating your own particle effects.

In short order, you find yourself in charge. You are now running all of Section 3.

But one thing keeps nagging you and you finally decide to ask the Section 3 facility manager.

"Why do you always say that the sky is the limit?"

He takes you up the elevator back outside the facility. "See the sky up there?" he says. "We have a lot of great technology in Section 3, but we don't have a machine that can change the sky. That machine is in Section 4."

The Growth Never Ends

One of the most important elements of game design is pacing. The difficulty has to ramp up to match the player's growing skills. The same is true about education. In fact, that's what a well-paced game does - it teaches new mechanics.

In the GUIDE, those mechanics are software engineering mechanics. It gives players a ladder to ascend from newbie to journeyman to power user to someone who can change the world.

The Challenge

It may require a little inspiration (and a lot of math) but I believe that creating such a GUIDE is both doable and worth doing.

The biggest challenges of this project are in creating a framework that can match 1:1 all of its actual software components with in-game fictional components and preventing malicious misuse.

For the last three years, I've been researching and developing a quantitative framework that I intend to accomplish exactly this. But it's not easy, and it takes time.

But that's the best part of a UIDE…

The Power of Continuous Improvement

Lets bring back our sad-looking UIDE one more time:

I'll admit, this doesn't look like much, but it might be enough to get the ball rolling.

After all, the whole idea behind a UIDE is that we can instantly start trial-and-error development with it. Just as soon as we have version 1.0.0, we can rapidly prototype version 2.0.0 without closing version 1.0.0.

It will crash. Work will get lost, especially in the early days. The entire code base may need to be refactored again and again before our UIDE becomes a bona fide (fun) GUIDE.

Conclusion

Thanks for reading. My dream is to build tools that make engineering fun and accessible to everyone. I hope these ideas inspire you to explore operating systems, software engineering and gamification. I'm excited to take these metaphors to the next level and I look forward to writing more soon!