By Jeff Richmond

How OpenPlay Football Was Built: Teaching the Game Behind the Game

August 2026

OpenPlay Football started with a question I kept running into as a fan: why is it so hard for a casual viewer to understand why a play worked? Announcers describe outcomes, not decisions. So the product thesis became this — let the user make the call, watch it unfold, and get a plain-language explanation of the read that decided the outcome. That simple loop turned out to require a surprising amount of underlying structure: a simplified but coherent simulation model, an explainer voice that never talks down to the user, a content layer that teaches the vocabulary a beginner is missing, and a schema disciplined enough that it could eventually be published for other developers to build on.

Football play diagram concept art

The Product Idea: Learning Football by Calling It

Most football education content is passive: articles, diagrams, or highlight breakdowns you read after the fact. OpenPlay Football flips that. You pick a matchup, call an offensive play, watch the offense and defense move, make the one decision that actually matters for that snap, and then see why it worked or didn't. The learning happens inside the decision, not after it.

That meant the product couldn't just be a game with a rulebook bolted on, and it couldn't be a quiz with animation bolted on either. The play-call, the animation, the key read, and the explanation all had to come from the same underlying representation of the play — otherwise the explanation would drift from what the user actually watched happen. That constraint shaped almost every architectural decision that followed.

Why AI Sure Tech Built This

OpenPlay Football is a project of AI Sure Tech, the studio behind it, which focuses on educational, AI-powered tools that make complex subjects easier to interact with rather than just easier to read about. The goal with football specifically was to prove the core idea publicly before asking anyone to fund a bigger version of it. Rather than shipping mockups, the studio built a working proof of concept: a full offensive drive, a hidden defensive call that gets revealed, animated assignments, and a real decision point with a real explanation attached.

That proof of concept is what's live today, and it's also the foundation for the Challenge Lab campaign — the funded next phase that turns a single drive into dozens of guided situations.

The Play Loop: Call, Watch, Read, Learn

The core interaction is three steps, and every design decision downstream had to protect the simplicity of those steps.

Pick a matchup. The user chooses two fictional teams, or lets the system choose for them. Keeping the rosters fictional (while player profiles discuss real athletes editorially) removed a whole category of licensing and accuracy problems and let the team focus on the mechanics instead.

Call a play. The user picks from a set of offensive concepts. The defense's call is hidden, the same way it would be on a real field — the user only learns the coverage by watching it react.

See why it worked. After the animation plays out, the user makes one key read: a decision that a quarterback or a coordinator would actually have to make. The result isn't just win or lose — it comes with a clear explanation of what the defense did and why the read went the way it did.

That last step was the hardest to get right. It's easy to build a simulator that produces an outcome. It's much harder to build one that can explain, in a sentence or two a beginner can follow, why that outcome happened. The explanation had to be generated from the same structured play data driving the animation, not written separately — otherwise the two would eventually contradict each other.

The Simulation Layer: A Schema, Not Just a Game

Underneath the animation is what the team calls the OpenPlay Football Demo Schema v0.1 — a structured, versioned representation of a play: formations, assignments, the defensive call, the coverage read, and the resulting outcome, all as data rather than as a hardcoded scene. The site's developer documentation describes the philosophy as "one record, multiple views" — the same play record drives the SVG animation, the result summary, and Coach Grant's explanation, so all three stay consistent by construction instead of by careful maintenance.

Building it this way was slower up front than hand-animating a handful of set-piece plays. But it's what makes the Learn section, the Playbook, and Challenge Lab's planned 40–50 guided scenarios possible without starting over each time — they're all just new records against the same schema.

Coach Grant: Explaining Football in Plain Language

Ask Coach Grant is the product's plain-language layer — a place to ask a general football question or follow up on a play that just happened. The design goal was narrow on purpose: Coach Grant explains and clarifies, it doesn't referee. The simulation determines outcomes; the coach voice interprets them.

Keeping that boundary explicit mattered for trust. A user who just watched a specific defensive read beat their play call needs an explanation that's actually about that read — generic commentary breaks the experience immediately. So Coach Grant's responses are grounded in the same play record the simulation produced, not generated independently of it.

The Content Layer: Playbook, Learn, Players, Football Explained

A play-call simulator is only useful to someone who already knows some football vocabulary. So the product needed a way to backfill that vocabulary without turning the whole site into a textbook. That's the job of a few supporting sections: Learn the Basics covers downs, positions, plays, and coverage for someone starting from zero; the Playbook documents the concepts the user actually calls in a drive; Football Explained covers broader strategy and terminology; and Players uses real athletes, editorially, to make abstract concepts concrete.

The How to Play page ties all of it together as the on-ramp — the page a first-time visitor should read before their first drive, but that a returning user should never have to see again.

Choosing Open: Publishing the Schema

One decision that shaped the whole build was committing early to publish the play schema itself. The developer documentation lays out the intent plainly: the schema, its documentation, and a reference renderer are meant to ship under clearly stated open licenses, separate from the hosted simulation, account services, and commercial tools built on top of it. That separation — open representation, closed (for now) hosted product — is what lets the team keep building a business around OpenPlay Football while still giving educators and other developers something real to inspect and build compatible experiments against.

It's a harder line to hold than it sounds. Every time a new feature wanted a shortcut — a special case that would only make sense inside the hosted app — it had to be weighed against whether it would make the schema harder to document and open later. That discipline is still ongoing as Challenge Lab gets built out.

From Prototype to Challenge Lab

The live site is the proof, not the finished product. Challenge Lab is the funded next phase, live now on Kickstarter, and it's deliberately scoped as the smallest funded release that makes the product meaningfully more useful and replayable: 40–50 guided challenge scenarios, the ability to build custom plays, saved progress, and a more polished simulation reviewed by people who actually know football.

Choosing to launch a working prototype before asking for funding — instead of pitching mockups — was itself a product decision. It meant the roadmap could be shaped by what people actually did with a real drive, not by what they said they'd want in a survey.

What Building It Taught Us

The biggest lesson was that "explain the result" is a much harder product requirement than "produce a result." Any simulator can output a win or a loss. Getting that outcome to be traceable, in plain language, back to a specific defensive read is what actually teaches someone something — and it only works if the explanation, the animation, and the data are three views of one record instead of three separate outputs that have to agree by luck.

The second lesson was about scope discipline. It would have been easy to try to model the complexity of real football from day one. Keeping the simulation intentionally simplified — and saying so directly on the site — made it possible to ship something real, get it in front of football fans and coaches for review, and let the roadmap grow from actual feedback instead of an internal wishlist.

The third lesson was that "open" has to be designed in from the start, not retrofitted. Deciding early which layer (the schema) would eventually be public and which layer (the hosted product) wouldn't made every later feature decision easier, because there was already a line to check new work against.

Conclusion

OpenPlay Football is a small loop — pick a matchup, call a play, make a read, learn why — built on top of a much less small commitment: a structured play schema, a coach voice grounded in that schema, and a content layer that meets beginners where they are. It's live today as a working drive you can run in a few minutes, and it's funding its next phase through Challenge Lab right now.

If you're interested in products that turn a passive subject into something people can actually do, or in the tradeoffs of building open, schema-first tools on top of AI-assisted experiences, reach out through the Contact page.

Related reading: How IdealMatchAI Was Built & How the AI Debate Arena Was Built.