The Pro Tools

Professional tools are powerful, almost beyond imagination.

This is especially true of the tools that power the game and film industries. These are the systems used to create the impossible. For Disney's The Lion King from 2019, directors "shot" entirely computer-generated animals using Unity and VR headsets. The Mandalorian, filmed inside massive LED walls powered by Unreal, rendered alien planets in real-time. These tools are the rendering pipelines that produce Pixar-quality animation, with millions of polygons, complex lighting models and hair shaders so subtle they feel alive. They are the simulation systems used to pre-visualize entire films before a camera ever rolls.

Increasingly, these tools are not confined to entertainment.

BMW developed its iX all-electric SUV using Unreal. It recreated its entire G20 3 Series assembly line in virtual reality to test manufacturing processes before building the physical factory. Audi, Volkswagen, and Porsche all use Unreal to create photorealistic showrooms where customers can customize and explore their vehicles. Zaha Hadid Architects designed the Xi'an International Football Center using Unreal's real-time visualization. Hong Kong International Airport built a digital twin in Unity to manage its operations, integrating building information, asset management systems, and geographic data into a navigable 3D model. Medical schools use Unreal to train surgeons in virtual reality, with studies showing VR-trained surgeons acquiring skills 570% faster than traditional training.

Professional game engines are also not just singular tools. They are launching points into entire ecosystems of professional workflows. Learning one naturally pulls you into others: 3D modeling and animation in tools like Blender and Maya, visual effects in Houdini, material creation in Substance Painter, version control in GitHub and Perforce, project management in Jira and Asana, real-time collaboration in tools like Slack and Teams.

Once you understand how code and assets flow through a pipeline, are assembled, collaborated upon and iterated, the skills are fundamentally transferable. Knowing Blender for game assets makes learning Revit for architecture intuitive. Collaborating on the code for a shader in Unreal Engine translates directly to GPU programming for an NVIDIA chip.

This constellation of tools is also where the jobs are. Not just in games or entertainment, but across the entire software economy. But these tools are also hard. They are intimidating. They are dense. They assume background knowledge. They are unforgiving. One wrong click can break everything. One error message can feel like a verdict on who you are and what you're capable of. There is a reason most people never get anywhere near them.

Our role as educators is to prepare young people for the workforce, not just in theory, but in practice. We have to confront this gap directly.

I recently received an email that began: "Learning is no longer text-first. As video, audio, AI, and interactive media become central to how people engage with content, educators and edtech teams are rethinking how learning experiences are designed." But this too is antiquated. Professional learning should be in professional tools.

The conventional wisdom says these tools are too advanced for general education. Most educators assume they can't be taught broadly, that they require specialized degrees, or that students will pick them up on the job. The misconception that these professional tools cannot be taught is leaving hundreds of millions of young people unprepared for a digital economy. We stare at the summit and ask ourselves: How do we get everyone up there?

The problem is not that the summit is too high. It's that the face is too sheer.

Our job is not to lower the mountain. It is to build the route. To chisel handholds. To cut switchbacks. To lay down ropes. To motivate. So that we can bring swarms to the top.

Here is how we bridge the gap between childhood and the tools that power our world.

Godot

When our Endless Access team began running programs in emerging markets, places without gaming laptops or dedicated graphics cards, we needed an alternative. Something lightweight. Something professional, yet highly accessible. The choice was clear: Godot.

Godot is a fully capable professional game engine. It’s light. It runs on a $35 Raspberry Pi. Unity requires a 2 GB download and a dedicated graphics card. Godot is 58 MB and runs on anything. It’s also powerful enough to produce commercial-quality 2D and 3D games. Godot ships with the same core capabilities as any professional engine: physics simulation, advanced rendering, particle systems, animation tools, audio mixing, spatial audio. The difference is in philosophy. Where Unity and Unreal prioritize maximum features, Godot prioritizes clarity and accessibility, which makes it not just easier to run, but easier to learn.

It's also free and unencumbered by licensing constraints. While other engines are free for students, their licensing becomes complicated the moment professionals and students collaborate on the same project, which is foundational to our learning model. With Godot, a professional developer and a twelve-year-old student can work on the same codebase without legal gymnastics. It's also open source. It was a platform we could extend, modify, and build upon without restriction. It was the base for an entire learning ecosystem.

Even with Godot, many challenges remained. The first: it assumes you can code. So we borrowed a powerful idea that allowed Scratch to reach over one hundred million children: block-based programming. We built block coding directly into Godot. It lets students control game logic by simply dragging logic blocks that also teach computational thinking.

A student's first project might be simple: create a character that jumps when you press spacebar. In blocks, that's intuitive: when key pressed, apply upward force. But behind those blocks, actual GDScript code is running. And at any moment, the student can click a button and see the code they've been writing without knowing it. As students gain confidence, they start editing the code directly. First small changes, tweaking a number, adjusting a speed. Then larger modifications. Eventually, the blocks become unnecessary. They've graduated into text-based coding not through a sudden leap, but through a gradual transition into syntax so smooth they barely noticed it happening.

We also built templates that students could fork and modify. A student might start with a pre-built platformer template, change the jump height, add a double-jump mechanic, swap in art assets, redesign the levels, and publish it as their own. They've just learned forking, modification, and distribution without those concepts ever being explicitly taught.

Then we tackled collaboration, which is often the hardest part of game development. Version control systems like Git are essential in professional workflows, but terrifying to beginners. A single merge conflict can feel like an insurmountable wall. The terminology alone (commits, branches, pull requests, rebases) seems designed to intimidate.

We attacked this problem in two ways:

First, we made it possible for students to collaborate without touching version control at all. We started building real-time, Google-Docs-style collaboration directly into Godot. Students can edit levels together, see their friends’ changes live, roll back mistakes, leave comments, and iterate, all without ever encountering a command line. For simple projects, this is enough. Teams can collaborate the way that we do on the rest of the internet.

But avoidance was never the goal. Real professional work requires version control. Large teams and complex projects depend on Git. So we also built the switchbacks into the professional tools themselves. We introduced students to project management in GitHub. We created simplified task systems where students could complete meaningful work (designing a level, creating character art, writing dialogue) without touching complex code. Each task lives in GitHub's issue tracker. Completing it meant opening a pull request, getting feedback, and merging their non-code work. We mirrored these tasks on our web platform in a simplified design that looks like GitHub. As they become comfortable, we reveal more of the professional interface: the issue tracker, then the pull request system, then finally the full Git workflow.

We removed friction with single sign-on (if you're logged into our platform you are automatically logged into GitHub). Automation scripts handled the brittle technical steps, like the game build. Each experience is manageable on its own, but collectively all of these remove the friction for a scared student to move toward full professional competence.

The result: students who start by editing levels in real-time collaboration eventually find themselves comfortable in GitHub, submitting pull requests, reviewing each other's code.

Gamestar 2.0

One final truth became impossible to ignore. Even with all this scaffolding inside Godot, the first experience inside a professional engine still demands too much hand-holding. That is true of both students and teachers. Scale demands absolute simplicity and certainty. If you want to deploy a learning system across an entire country, you have to know that none of the students will be stuck in a way that any teacher cannot help them. That includes teachers with no technical background, no training and no safety net.

We had seen this problem before. Many years ago, our sister studio E-Line Media launched a learning product called Gamestar Mechanic. Gamestar Mechanic was a game creation tool designed to teach students how to think like game designers. Built during the Flash era, it guided students through 2D game quests that challenged them to deconstruct games, understand mechanics, and reason about player experience. Only then did it gradually unlock a 2D tile-map editor. Students learned by playing, then by creating, then by sharing.

At its peak, learners created more than two million games, generating fifteen million plays. Like Scratch, it could be deployed into any classroom, regardless of a teacher's expertise. It was a hit. The Director of Programs for our foundation joined us in part because she loved Gamestar Mechanic so much when she was a teacher. Teachers didn't need to understand game design to facilitate learning. That was the key.

Godot, even enhanced with all of its structures around the back, cannot be the first step. So we had no choice. We had to build it. We are now building a simplified game-making experience on top of Godot, designed explicitly around the principles that made Gamestar Mechanic work. The premise is simple: The first experience must be so intuitive that every child can succeed. It is web-based. It's as simple as Scratch and Mario Maker. Play, curiosity, and gradual empowerment.

But unlike the past, this experience is not separate from professional tools. It is Godot. Students begin in a friendly, quest-driven environment that feels playful and safe. They design levels using tile-map tools that feel natural. And all the while, they are unknowingly working inside the Godot technology stack itself. By the time they enter Godot "for real," nothing feels foreign. They realize, almost accidentally, that they've been in Godot all along.

Our philosophy at Endless is that if there is a cliff along the journey to the top of the mountain, and if it means that millions of kids can't surmount that critical part of the mountain, and if nobody is solving it, then we have no choice but to solve it. We may solve it in a smaller form than an organization doing it with more resources. But we usually do it. And then, often, we'll go looking for a better home for that solution to live in. We're in the process of hunting for a home for this product. We believe that it has so much potential.

It may end up being that the home is in the open source community. Like a young whip smart engineer for Endless OS that we hired who had learned to code on a One Laptop Per Child laptop, who then helped us build our OS to teach more kids like him, we hope that one day the swarms of students who started with us will join us in building the tools for the cohorts of students climbing up behind them.

After all, what is our goal? To teach people to build professional-grade software in a community. What better thing to build than the tools that help more people on the journey that made you who you are?