Endstar

There are 380 million people who log into Roblox every month. Less than 1% of them open the creation tool. That is 376 million kids standing at the edge of the S-Curve every day. They have already chosen the medium. They are already inside the game. They could step onto the curve with a single click. They don't.

We didn't set out to build a game engine. We had to.

When we started running game-making programs, we ran them inside of Unity. Unity is one of the most powerful game engines in history. You can build almost anything you can imagine with it, if only you know how. That is what made it so tantalizing as a pathway for young people to learn the skills that matter. Then we put a teenager in front of it. Unity's introductory online course is eighteen hours long. It requires code. Rotating the screen is hard. Making characters not fall through a floor is hard. The first hour of using Unity is the first hour of failing at Unity. Unity was too hard.

That is not because Unity is bad. It is because Unity is powerful. It was built to be a flexible, efficient tool for professionals. The gap between a teen's entry skill and Unity's expectations is not a curve they step onto. It is a wall they walk away from. The overlap between game engines and education is a very narrow one. Game engines are extraordinary learning tools, but they exclude the vast majority of people. By skill. By age. By gender. By geography. By confidence. Most people cannot just open a professional engine and begin.

We needed something else to serve as our introduction into game making. A tool that would let a student build something compelling within minutes. The games could not be toy games. Teens want to make things that feel alive. There are very few who go from playing Call of Duty to being engaged by building in Scratch. They want to make something real.

But Minecraft is different. A child enters the world, places a block, and understands.

That was the clue, but not the answer. Minecraft proves that a six-year-old can step into a 3D creation tool and start building immediately. What Minecraft does not do is lead anywhere past itself. A kid who masters Minecraft becomes a better Minecraft player. It isn’t a game engine. It doesn’t teach professional skills. We needed something with Minecraft's on-ramp and Unity's ceiling. A tool simple enough that a six-year-old could use, powerful enough that you could build real games, and scaffolded enough that each step taught the underlying skills needed to move into professional tools.

We took our lessons from The Endless Mission and began building the right tool.

The Staircase

We started small. Our goal was to get students off our tool and into Unity as quickly as possible. The premise was simple: place blocks the way you do in Minecraft, and then also place anything else, from enemies to props to weapons, as easily as you place blocks.

That was the first pull. Place a block. Then place a tree. Then place an enemy. Then place a lever. Each placement is a tiny victory, and each tiny victory invites the next one. The thing you are building starts to feel like a game. Not a toy. A game.

Then we added rule blocks. You could control the weather. You could change the behavior of an enemy. You could decide what happens when a player picks up a key. The conceptual leap from "place a block" to "control a system" is small enough that you barely notice you are making it.

Then we built the wiring system. You drag a wire from a lever to a door. When you pull the lever, the door opens. That is the whole interface.

This is where something shifts. Until now, the child has been a builder. Now the child is a systems designer. The wiring system is the first time the kid encounters the idea that things happen because other things happen. Cause and effect. State and trigger. Input and output. They are not learning these words. They are learning to think like a computer. I have watched twelve-year-olds in a school in the Bronx build a bridge of rolling spike traps so surprising that I had to ask them how they built it. I have watched a college student wire a restaurant scene with waves of customers ordering food to teach Spanish vocabulary, with logic deep enough that it looked like a piece of small software. Neither student had written a line of code. Both of them were programming. This is what we mean by an on-ramp.

Almost every modern blockbuster game is multiplayer. Almost no indie game is, because multiplayer is brutally hard to build. We did it anyway, because we knew that the moment a kid is building with their friends, the whole thing changes. They run around the world together placing blocks. They argue about where the castle goes. One of them figures out the wiring system before the others and becomes the teacher. Click play and they are inside the game they just built together.

Gamers call this multiplayer. Educators call it collaboration, creativity, and communication. When students build together, they learn from each other. When they contribute to real projects, they learn from people further along than they are. The line between playing and creating blurs. Students are no longer players or builders. They are collaborators. Designers. Teammates. Levels can be strung together, so swarms of teams can collaborate on games far larger than any one classroom could build alone. A game lead sets the vision. Advanced students own systems or levels. Newer students contribute pieces and learn from the leaders ahead of them. The game gets bigger because the community gets bigger. This is the heart of our thesis. Better products get built and better learning happens when people contribute alongside people who are further along.

At the start, we thought that was enough. We were running learning programs almost every week of the year. Classrooms, camps, after-school cohorts, summer intensives. Students were sitting in front of the tool every week, and we were sitting next to them. We could see the exact moment a kid lit up and the exact moment a kid gave up. The tool stopped being something we designed alone in a room. The students started asking for more. More enemies, more game mechanics, more weapons. Cutscene cameras, smarter enemies, underwater worlds, farming, trading, branching dialogue, sound, music. More. We built it.

We paused development for almost a year to build one feature: a full runtime IDE with Lua scripting. An engineer at another studio told us, when he saw it, that this might be the first Unity game to ever embed a full IDE. We are not sure if that is true. We are sure that it was the right thing to build. The wiring system teaches a kid to think in systems. But the moment that kid wants to do something the wiring system cannot do, they hit a ceiling. We want them to always find that there is something upstairs. The IDE is the door to upstairs.

Inside Endstar, a student can open the code that powers any behavior on any object in any game. They can read it. They can change it. They can break it. They can share it with the community so other students can build on top of what they wrote. Coding stops being abstract the moment it is attached to something you built. Something you can walk through, see, touch, break, fix, and share. This is the third pull, and it is the one that matters most. Because once a kid has tasted writing code that makes their game do something new, the entire universe of software is open to them. They have stepped onto the curve.

We did not isolate students from the professional tools. We built a software development kit that walks them into Unity in small, deliberate steps. At first, that means opening Unity to do one focused task. A student drags a texture file into Unity, clicks a button, and has a new block inside Endstar. If they want to create a custom shape, that is one step further into Unity. If they want to design a character in Blender and bring it into the game, the SDK walks them through it. The kit our students use is the same kit our internal professional team uses. It is powerful. But each action is small enough to be learnable. Something subtle happens when a student opens a professional engine for the fifth or tenth time, not to build an entire game, but to complete a single achievable task. The tool stops feeling like a monster. Curiosity replaces fear. Exploration follows. The ceiling has become a staircase.

Then AI Arrived

Then AI arrived, and something strange happened. The same design choices that made Endstar accessible to children made it unusually accessible to AI. AI struggles in unbounded chaos. It thrives in structured systems. Endstar’s world is made of discrete blocks. Its logic is modular. Its behaviors are inspectable. Its scripts are editable. Its assets are swappable. In other words, the platform was not only legible to beginners. It was legible to machines.

We leaned in. We began layering AI into the same tools we had built for students. AI could help draft a Lua script, generate a texture, suggest a quest, modify a behavior, or explain why something had broken. Because the system was structured, the output stayed editable. That is the part that matters. The AI did not produce a sealed black box. It produced something the student could open, inspect, change, break, fix, and make their own.

This is what makes Endstar important to the larger argument of this book. It is not only a game-making tool. It is a training engine for learning how to work with ever-more powerful forms of AI. AI gets you part of the way there, faster. The creator finishes the job.

The dream of AI-generated games is seductive. Say a few words and the game of your dreams appears. Some version of that will exist. I do not think it is what people want. Builders want to build what’s in their head. Players want to play the best possible game. The best games are not prompted into existence. You can use AI to help with art, code, dialogue, levels, testing, and a hundred other things. But the thing you want at the end is not a disposable private world that only you will ever see. Games are social. They are places where friends meet, master the same systems, tell the same stories, and remember the same ridiculous boss fight. A world built only for you is fun for a few minutes. It cannot become ours. So the future I am excited about is not a black box that turns prompts into games. It is AI inside accessible creation tools, accelerating creators without replacing them. It gives you something editable. Something you can craft. Something you can be proud of.

This is what AI inside the S-Curve looks like. It does not lift the kid off the curve and hand them a finished thing. It lowers the floor. It pulls them up the curve faster. But the kid is still doing the climbing.

The Hole In The Market

Years after we began building Endstar, Epic released Unreal Editor for Fortnite. When I saw it, I felt two things at once. The first was relief. UEFN validated everything. It did, in many ways, what we had built Endstar to do. It bridged a playful, social world and a professional engine. It made obvious that the missing layer existed. The second feeling was harder. If UEFN had existed when we started Endstar, we probably never would have built Endstar. We would have used Epic's tool and saved ourselves many years and millions of dollars.

But once we had started, Endstar became something UEFN could not be. UEFN validated the missing layer. It proved that the space between playing games and professional game engines was real. But as someone on the UEFN team told me, UEFN is about Fortnite. Endstar is about the learner. That sounds like a small difference. It is not. It changes every design decision: the first five minutes, the classroom workflow, identity, permissions, moderation, progression, curriculum, contribution, and the bridge into professional tools.

We started by trying to solve a problem of ours. Today, the gap in the market is obvious. Minecraft enables 100% of players to be creators, but they are mostly just building terrain. Roblox lets you build real games (there are almost 50 million Roblox experiences), but less than 1% of its players build in Roblox Studio. And UEFN is just creating Fortnite levels. We now see that what started as filling a gap in our learning programs had become an opportunity to do something really important: To let everyone create real games.

A generation of Minecraft, Roblox, and Fortnite kids are asking themselves, “now what?”

Years ago, I would have much rather been able to take a product off the shelf. It’s been an incredible amount of work and money. Now that I know what the best educational gaming on-ramp looks like, and how powerful it is when you have it, gosh I’m glad that we did it.

The Games I Am Excited About

The mistake is to think the point of Endstar is Endstar. It isn’t. The point is the kind of game that becomes possible when thousands of people can help build it.

There are games that require thousands of levels. Thousands of quests. Thousands of conversations. Thousands of tiny human touches. Games where the content is not a side problem. It is the whole problem. Those are the games we want to make, and we do not believe they can be built the old way.

The Department of Culture and Tourism in the UAE hired us to build a collection of games that help young people experience Emirati culture. That is not one polished demo. It is worlds, characters, stories, artifacts, environments, dialogue, quests, and mechanics that bring the various aspects of their culture to life. It requires professional direction. It also creates the perfect opportunity for students and community members to contribute. One group builds a village. Another writes dialogue. Another designs a quest. Another tests and improves. The game becomes better because more people can touch it.

The same is true of language learning. To really learn a language, you have to speak it. You have to listen. You have to order food, ask for directions, make friends, misunderstand people, try again, and slowly build confidence. A game can create those situations. Adventure quests, narrative, AI characters, voice, and fun gameplay can combine into an immersive world that teaches you to speak a language by needing to use it. A game like that requires an absurd amount of content. Neighborhoods, homes, shops, characters, quests, jokes, mistakes, dialects. Countless moments of practice. That is exactly the kind of game Endstar was built to make.

There is a whole collection of games like this in my head. Games about science. About history. About the built world. Games where students walk through the bloodstream, build a city, run a farm, explore a civilization, or learn how an economy works by living inside one. Not educational games in the old sense, where you take a worksheet and wrap it in points. Worlds. Places students want to enter, where the learning is embedded in the doing.

One day, we will even build The Endless Mission on top of this tool. That has been the dream all along.

Endstar is not a game engine. It is a software curriculum hiding in plain sight, made to delight. It starts with the simplest possible action, placing a block, and then opens deeper and deeper doors. Into gameplay. Into logic. Into code. Into art. Into Unity. Into AI. Into the hard, messy, beautiful work of building real things with other people.

We did not set out to build a game engine. We set out to help young people step onto the curve. 376 million kids are standing at the edge, needing a way on.

Endstar is the step. The kids will do the rest.