The games are the lesson

The open-engine philosophy

CEMI Fútbol is written to be opened up. It runs directly in the browser as native ES modules — no bundler, no transpiler, no node_modules. Every file is small, single-purpose, and commented so a curious student can follow it.

• Zero-build. The browser loads the modules straight from disk. What you read is exactly what runs.
• Vanilla JS on HTML5 canvas. No hidden magic — the game is drawn one frame at a time with plain <canvas> calls.
• Comments as curriculum. The code explains its own physics, biology and structure in the comments, in plain language.
• A shared engine. Both games sit on the same cemi/ engine, so a lesson learned in one game transfers to the other.

The code map: what each file teaches

The engine lives in cemi/; each of the sixteen games lives in its own folder under games/. Click any path to read it.

Engine — cemi/

Golden Boot — games/golden-boot/

Gorilla on the Pitch — games/gorilla/

Keepy-Uppy Infinito — games/keepy/

Anaconda Soccer — games/anaconda/

Rumble Fútbol — games/rumble/

Elemental League — games/elemental/

Cruce de Tráfico — games/cruce/

Muerto FC — games/muerto/

Dodgeball FC — games/dodgeball/

Gods vs Titans FC — games/gods/

FIREBALL FC — games/fireball/

Béisbol Gol — games/beisbol/

Dolphins vs Sharks — games/dolphins/

Dungeon Striker — games/dungeon/

Endless Striker — games/striker/

Endless Striker 3D — games/striker3d/

Guided code-reading activities

Each activity opens a real file in the source viewer. No editor and no setup needed — reading comes before writing. The first four use Golden Boot and Gorilla; the rest tour the other fourteen games, roughly simplest first.

Defense in depth: four layers against a bad nickname

Players pick their own nicknames, and sooner or later somebody will try to sneak in something offensive. The engine treats that as a small security problem and answers it the way security engineers answer big ones: with defense in depth — several independent layers, each written as if every layer before it had already failed. The whole lesson lives in one small file, cemi/nickname.js, and the four places that use it.

Why one layer is never enough

Layers 1–3 run in the browser — on the player's machine, under the player's control. Anyone can open the developer tools, edit the JavaScript, or skip the app entirely and write to the network with curl. That is why client-side checks are for experience (catch honest mistakes instantly and kindly), while the real rule has to live where nobody can reach it. The one-line summary worth memorizing: client code is a suggestion; the server is the law.

Normalization: seeing through the disguises

A ban list that only matches exact spellings loses on day one to B.A.D.W.O.R.D, b_a_d_w_o_r_d, baaadword and b4dw0rd. So before comparing anything, normalize() in cemi/nickname.js reduces every name to its plainest possible form: lowercase, accents stripped (é becomes e), a leet map applied (0→o, 3→e, $→s...), and every non-letter removed — dots, underscores and spaces simply vanish. A second pass collapses repeated letters (baaad → bad), and the list is checked against both versions. The disguise is undone before the comparison even starts.

The Scunthorpe problem

Now the opposite danger: ban ass as a substring and you have also banned bass, class and passion. This classic false-positive trap is named after the English town of Scunthorpe, whose residents kept getting blocked by early internet filters (the town's name hides a four-letter word). The file's answer is two lists: long, unambiguous terms are matched as substrings anywhere in the name, while short, ambiguous terms only count as a whole word or the whole name.

And when the two goals collide, the filter makes a deliberate, documented choice: strict by default. In a school space a false positive costs one player a "pick another name"; a false negative puts a slur on a classroom leaderboard. Those costs are not symmetrical, so the trade-off isn't either. (Yes, this means the town of Scunthorpe itself is banned as a nickname. The file's header comment apologizes.)

Note: nothing above depends on any particular vendor. Our implementation happens to use Firebase — layer 4 is a ~40-line Cloud Function trigger in functions/index.js watching Firestore writes — but the four-layer pattern applies to any app that accepts text from strangers.

Local-first accounts: one interface, two stores

The other privacy decision is architectural. The player chooses between two modes: local (the default: a nickname on this device, nothing ever sent anywhere) and cloud (sign in, sync progress, join the world leaderboards). The games themselves never know which one is active — and that is the lesson.

• One Store interface. Games call submitScore() and topScores() and nothing else. In cemi/backend.js, getStore() hands back one of two implementations depending on the profile's mode — the textbook shape of polymorphism: same calls, different behavior.
• LocalStore. Keeps boards in localStorage, top 100 per board, on this device only. Erasing the browser erases it — that is the promise of the mode, not a defect. An opt-in toggle can additionally read the world boards: a pure lookup where nothing of the player's is written.
• FirebaseStore extends LocalStore. Every score is written locally first, then pushed to the cloud. If the network fails mid-write, the local copy already exists — offline never loses data, and the class inheritance makes "cloud = local + push" literal.
• The honest merge. On login, syncProfile() reconciles two histories without trusting either: each counter keeps the maximum of the two sides and achievements become a union. Signing in from a new device can only ever add progress, never erase it.
• Local mode never even loads the network SDK. "Nothing is sent" is enforced by code, not by a promise in a privacy policy: init() in cemi/backend.js returns a LocalStore before the network module is ever imported. The cloud library is dynamically loaded only when a cloud feature is actually used.

Clone it and run it

Because there is no build step, running the whole project locally takes three commands. You only need Git and Python 3 (which ships with macOS and Linux, and is a quick install on Windows).

1. Clone the repository:
   git clone https://github.com/<owner>/futbol.git
cd futbol
2. Start the tiny dev server (needed because ES modules require HTTP, not file://):
   python3 scripts/dev-server.py 8321
3. Open it in a browser:
   http://localhost:8321

Note: the source viewer on these pages fetches files over HTTP too, so it works best when the docs are opened through that same local server (or wherever the site is hosted), not from a bare file:// path.