Learning to Speak Game

Building browser simulators to teach CNC machining, what AI actually contributed, and what a dead leaderboard taught me about my students.

What a bad week looked like

For a while, the shop ran on a bottleneck I couldn't engineer my way out of. It looked like this: one student at the CNC mill, me or my TA standing next to them, walking through the same workflow we'd walked through with the last student an hour earlier. Set the work offset. No, the other corner. Why are we running 400 RPM here and not 4,000? What's the chipload on a two flute in HDPE?

Individually, none of those conversations was a waste. Collectively, they were. We were spending our most limited resource, direct instructor attention, on the most repeatable part of the curriculum. And it wasn't as if the lectures had failed to happen. They had. Students had sat through the speeds and feeds material, nodded in the right places, and then arrived at the machine without the workflow in their hands. They knew the words. They didn't know the sequence, and they had no intuition about which numbers were dangerous.

That gap between knowing and doing is old news in vocational education. What made it acute in a CNC lab is that the feedback loop is expensive. A student who mis-sets a work offset doesn't get a red X on a worksheet. They get a ruined part, or a snapped end mill, or a very bad noise. Machine time is finite, tooling costs money, and the failures that teach the most are exactly the failures you can't afford to let happen very often. So students learn cautiously, which is to say slowly, which is to say they arrive at the real machine having made almost no mistakes and therefore having built almost no judgment.

Why a simulation, and why a game

The move to simulation wasn't a technology decision. It was a decision about where the failures should live.

If the most instructive moments in machining are the failures, and the failures are too expensive to stage on real equipment, then you need somewhere else to put them. Aviation figured this out decades ago and nobody thinks it's exotic anymore. The pedagogical logic is unglamorous. You decouple the cognitive task from the physical task, drill the cognitive part until it's cheap and fast, and hand the student back the physical task with their working memory freed up for the things that actually require a body in the room.

But there was a second reason, and it's the one I'd have been embarrassed to say out loud a year ago. Our biggest degree programs are game art, animation, and game programming. My students are gamers. Not casually. They are studying the thing, taking it apart, building it. They have vocabulary and instincts about progression, feedback, and difficulty curves that I do not have, because I have not played a video game since before most of them were born.

That's an odd position for an instructor. The usual move is to meet students where they are, but where they are is a domain where they outrank me. Building a game for people who study games is not obviously a good idea. I did it anyway, on the theory that a clumsy attempt in their language beats a polished lecture in mine.

So I built two browser games. The first, Chip School, assumes zero prior knowledge and teaches speeds and feeds from scratch across seven levels: what a mill is, surface speed versus RPM, chipload, the two formulas that govern everything (RPM = 3.82 × SFM ÷ diameter, and feed = RPM × chipload × flutes), then diagnosing bad cuts by symptom, then a timed gauntlet. The second, 770M Academy, is the full operator course. Eight levels covering the tool crib, workholding, the touch probe and offsets, G code, and three real projects ending in a 4th axis aluminum capstone.

Two design constraints mattered more than anything else, and both were pedagogical rather than technical.

The first: it had to be the same machine. Not a generic mill, not an abstraction, but the CNC mill sitting in our shop, with our HDPE as the primary stock and its specific failure mode of melting and re-welding chips. Transfer of learning is fragile. Every gap between the simulated environment and the real one is a place where the student's mental model has to be rebuilt at the machine, which defeats the purpose.

The second: it had to run anywhere with no install and no internet. Both games are single HTML files. A student can open one on a Chromebook in a dorm, on a phone on the bus, on a lab machine with locked down permissions. This sounds like an IT detail. It isn't. Practice only compounds if it's frictionless, and every install step is a place where a marginal student quietly drops out of the exercise.

The failures happen live. Chatter, HDPE melt, aluminum chip weld, spindle overload, chip recutting. Alarms fire mid cut and the student has to react. Ignore one too long and the tool snaps. Nobody pays for that end mill.

What AI actually did

I want to be precise here, because the honest version is both less impressive and more interesting than the usual telling.

I had the problem and I had the fix. The curriculum was mine, built out of shop time and a course I'd already structured across fifteen weeks, with a clear sense of which concepts students reliably stumble over and in what order. The scoring model was mine: accuracy weighted at 50%, efficiency at 30%, speed at 20%, because I wanted students optimizing for correctness first and pace last. The checksum locked score codes were mine, born from the unromantic reality that anything a student submits by copy and paste will eventually be edited by a student.

What AI did was the tedium. Once I'd outlined the thing, it handled the implementation: the state management, the localStorage persistence, the leaderboard builder, the hundreds of small decisions that stand between a design and a working artifact. That's not a small contribution. It's the entire reason this exists rather than sitting in a notebook next to the other good ideas I've never had three months to build.

The claim I'd resist is that AI made me a better teacher. It didn't. It shortened the distance between having a teaching idea and putting it in a student's hands, from hire a developer or become one down to a few evenings. For an instructor at a small private university with no software budget, that's the whole ballgame. The bar for "worth building" drops, and things that were never viable as products become viable as one off tools for thirty students on one specific machine.

It also let me build in a medium I have no fluency in. I could not have written this by hand. I don't know the idioms, I don't know the conventions, and I certainly don't have the taste that my game programming students have. AI gave me a passable accent in a language I don't speak.

There's a version of this worth naming as a risk. The same collapse in cost means I can now build something badly and deploy it fast. The constraint that used to force ideas to be good, the sheer expense of building them, is gone. What replaces it has to be my own judgment about pedagogy, which means the AI raised the stakes on the part I'm actually responsible for.

What students did, and what surprised me

It's early. I want to be careful not to oversell what is still a small sample and a partial term.

The clearest result is the one I hoped for. Students arrive at the machine understanding substantially more about what they're doing. The one on one triage has dropped. Conversations at the CNC mill have shifted from "what does this button do" toward questions that are actually worth an instructor's time.

The surprise was what didn't happen. I'd built a competitive layer, star tiers, ranks running from Trainee up to 770M Legend, an instructor leaderboard, on the assumption that a room full of game programming majors would grind for three stars out of sheer reflex. They mostly haven't. The scoreboard has been close to inert.

That's the part I've been sitting with, because it's the exact place where my students knew something I didn't. I designed for the student I imagined a gamer to be: engaged, a little cocky, motivated by public ranking. The students I actually have are quieter than that and, I suspect, somewhat wary of visible performance. Competition creates an audience, and an audience is the thing they were already avoiding. Being fluent in games apparently does not mean wanting to be ranked in front of your classmates. I'd confused the genre with the motivation.

Which is the more useful finding. It suggests the sim isn't working because it gamified the material. It's working because it privatized the failure. A student can snap a virtual end mill at 11pm with nobody watching, and that's the whole feature. I built a leaderboard and accidentally built a room with the door closed.

Searching for my students' interests

Here's what I keep turning over.

Our students are visibly more comfortable in a chat window than in a lecture hall, and more comfortable in a game than in a chat window. When I lecture, I'm addressing a room that has learned to perform attentiveness. When they play, they're doing the thing.

So: is this how I connect with students now? Simulators, small games, custom plug ins built for one machine and one cohort, with lecture reduced to something closer to a framing device than a delivery mechanism?

I'm suspicious of my own enthusiasm here. Some of what a lecture does isn't information transfer at all. It's modeling how an experienced person thinks out loud, hesitations included. It's the shared reference point that lets thirty people have the same conversation. And there's something in shop education that I don't believe survives the move to a browser: the sound a cut makes when it's wrong, the feel of a part that isn't seated, the specific humility of standing next to a machine that could hurt you.

What I'm less sure about is whether I've been defending lecture because it's pedagogically necessary or because it's what I know how to do. The tooling has gotten cheap enough that I can now test that question instead of arguing about it.

I don't have the answer. But for the first time, finding out doesn't require anyone's permission or budget. Just a weekend, and a willingness to watch what students actually do rather than what I assumed they would.