Magicomancy

The cover image :D
A game in progress
The editor to create and test spells
The academy to learn more math and get better at the game

Inspiration

I do mock interviews for a lot of college kids looking to get into Oxbridge, where a large part of what gets asked is graph sketching. Teaching this conventionally is not very interesting and I wanted to have a fun framework set up where they could experiment with seeing how different graphs would work, but in a genuinely interesting setting. I saw GraphWars 2 and was really inspired, but it's only Cartesian graphs and is turn-based so it gives you time to plot. I wanted something more dynamic and fast paced, where you can feel like you're pulling spelsl you're creating out of your spellbook on the go.

What it does

Magicometry is a real-time PVP/PVE wizard duel where every spell is formed by a mathematical function.

Two players move, aim, and cast simultaneously in a wrapped arena. Players can use Cartesian coordinates such as x(t) and y(t), or polar coordinates such as r(t) and θ(t), to define how their projectiles travel.

The game includes:

A safe expression editor with simple and LaTeX-style input
Two AIs (if you wanna play yourself) with some seriously funky spells that can be surprisingly capable
Live trajectory and damage previews
Starter spells for players who do not want to begin from scratch
Time-varying barriers that fade between solid and intangible
Destructible terrain that retains spell-created craters during the round
Health, mana, cooldowns, animated wizards, and visible combat feedback
A built-in syntax guide and personal spellbook
Currently working on Supabase authentication, cloud saves, and caching for online multiplayer.

How we built it

I built Magicometry as a browser game using Next.js, React, TypeScript, Tailwind CSS, and the Canvas 2D API. Online multiplayer is handled by websockets using Digital Ocean. At its core is a custom tokenizer, parser, and bounded abstract syntax tree evaluator. Player-written equations are parsed once and evaluated during a deterministic 60 Hz simulation loop. Terrain collision and cratering use deterministic masks, while projectiles wrap continuously across the arena’s edges. I began by giving Codex the game concept and asking it to turn the idea into a detailed product requirements document and milestone-based implementation brief. That gave me a shared specification covering the expression language, combat rules, safety limits, accessibility, and future scope. GPT‑5.6 was especially useful when a task crossed several disciplines at once e.g. reasoning about mathematical expression safety, toroidal collision detection, game balance, and interface clarity together. Codex then translated those decisions into working code, tests, and documentation.

Several important decisions emerged through iterative conversations with GPT‑5.6 and experiments performed by Codex:

Build a constrained expression language instead of using eval. Codex helped design a custom parser with limits on source length, AST size, numerical range, and evaluation work.
Use deterministic simulation. A fixed 60 Hz update loop made collision behavior reproducible and created a foundation for future replays and networking.
Use one evaluator everywhere. Live spells, previews, paired-coordinate expressions, and barriers share the same mathematical engine, preventing the preview from disagreeing with gameplay.
Avoid unnecessary game-engine dependencies. Canvas 2D and native browser APIs were sufficient for the prototype, keeping the implementation understandable and portable.
Make creativity competitively neutral. Every valid equation has the same mana cost and cooldown. Players are encouraged to explore complex mathematics without being punished for it.
Stay local-first. The duel and saved spellbooks work without an account or network connection; Supabase features activate only when configured.

Challenges we ran into

The hardest challenge was allowing open-ended mathematical creativity without letting one unusual expression freeze the game or become an unbeatable exploit. I introduced limits on expression size, AST complexity, numerical range, projectile speed, and summation work, while still supporting a broad and expressive mathematical vocabulary. Combat balance was another challenge. A spell’s damage could not simply increase with speed, because that would reward trivial straight-line attacks. It also could not reward slow or stationary projectiles, which could become invisible traps. I developed a damage model based on sustained recent speed, with protections against stationary and discontinuous trajectories. Wrapped coordinates made collision detection more complicated, especially when a projectile crossed an arena seam. Destructible, time-varying barriers added another layer: their visuals, solidity, collision mask, and accumulated craters all had to remain synchronized. Finally, I had to make equation editing practical during real-time play. Clear errors, starter spells, previews, keyboard controls, and a visible syntax reference were essential to keeping the mathematics approachable.

Accomplishments that we're proud of

I feel like Magicometry is becoming a genuinely fun game which was the most important part. I'm also really happy with how we managed destructible terrain without overloading on computational complexity.

What we learned

Visual feedback is crucial when mathematics becomes interactive. Trails, previews, impact effects, barrier warnings, and concise error messages help players build intuition much faster than written explanations alone. On the development side, deterministic systems and pure, testable modules paid off quickly. Separating expression parsing, spell evaluation, collision rules, and terrain deformation made unusual edge cases easier to reproduce and fix.