The Maths Kids Actually Use to Build a Game: Coordinates, Vectors, Angles and Probability

Tell a parent their child is "just not a numbers person" and the label tends to stick for years. We have heard it in our lobby for eleven years, across 9,500 students, and it has almost never held up. The child was fine. The teaching arrived in the wrong order.

School maths usually hands over the formula first and the reason much later. Building a platformer in Scratch, Roblox or Python flips that sequence. The maths turns up as a problem the child already cares about: the jump feels floaty, so the gravity value is wrong. The turret keeps missing, so the arctangent is off. The hit-box registers a strike before the sprites touch, so the distance formula needs work.

What follows is the specific maths children reach for while building games, where each piece sits in international school syllabuses from Primary through to IGCSE, and why building the formula tends to outlast memorising it.

Table of Contents

• Key Takeaways
• Why a Bad Jump Feels Wrong: Gravity, Velocity, and Acceleration
• Coordinates and the Screen Plane: Geometry Beyond the Textbook
• Vectors and Speed: Fixing the Diagonal Sprint Bug
• Angles and Trigonometry: Aiming Turrets and Circular Motion
• Collision and Geometry: Bounding Boxes and Pythagoras
• Probability and Randomness: Loot Drops and Fair Mechanics
• Percentages, Ratios, and Game Balance
• Grade-Level Syllabus Map: Game Mechanics vs School Maths
• Four Build-Along Mini Projects by Age Group
• How Kidocode Teaches Maths Through Game Building
• Printable Game Maths Debugging Checklist
• Frequently Asked Questions
• References

Key Takeaways

---

Why a Bad Jump Feels Wrong: Gravity, Velocity, and Acceleration

Any child who plays games can tell you when a jump feels wrong. Too floaty, too heavy, weirdly sticky at the top of the arc. What they usually cannot tell you is that the fix is algebra.

A jump in a platformer is not an animation that plays. It is a calculation that runs sixty times a second. So a child cannot simply nudge the vertical position by a fixed number of pixels per frame. Move the character up ten pixels every frame and it rises like a lift, stops dead at the top, then drops like a brick.

Motion that reads as real needs gravity and acceleration in it:

$y_{velocity} = y_{velocity} + gravity$ $y_{position} = y_{position} + y_{velocity}$

graph TD
    A[Press Jump Key] --> B[Set Y-Velocity to -15]
    B --> C[Apply Frame Loop]
    C --> D[Add Gravity +1 to Y-Velocity]
    D --> E[Update Y-Position by Y-Velocity]
    E --> F{Is Character on Ground?}
    F -- No --> C
    F -- Yes --> G[Reset Y-Velocity to 0]

Set the initial impulse to $y_{velocity} = -15$ (negative moves upward on a screen coordinate plane) and gravity adds a positive value such as $+1$ back to the velocity each frame. The rise slows, velocity hits zero at the peak, then the sign flips and the fall accelerates on its own.

Landing feels sluggish? Change the gravity coefficient. Jump feels twitchy? Change the initial velocity. Inside ten minutes of testing, a ten-year-old has run dozens of evaluations of a linear equation and watched rate of change do something visible.

A systematic literature review on constructionist game making synthesized 55 empirical studies across 9,000 students and found that 44% of research focused explicitly on how children develop computational problem-solving strategies through these iterative adjustments ^[1]. Twenty workbook problems produce a ticked page. Twenty variable changes in code produce twenty answers the child can see.

---

Coordinates and the Screen Plane: Geometry Beyond the Textbook

In school geometry, the origin $(0,0)$ sits in the middle or the bottom-left corner of the graph paper. Right increases $x$. Up increases $y$. Nobody questions it.

Then the child opens Pygame, HTML5 Canvas or a JavaScript project and the floor tilts. Scratch keeps the familiar centred origin, but most real 2D graphics frameworks put $(0,0)$ at the top-left corner of the display, with $y$ growing downward.

On a screen plane:

• Moving Right increases $x$ ($x + \Delta x$)
• Moving Left decreases $x$ ($x - \Delta x$)
• Moving Down increases $y$ ($y + \Delta y$)
• Moving Up decreases $y$ ($y - \Delta y$)

That single inversion does real work. To make a falling obstacle fall, you add to $y$. Children who have only ever met one orientation of an axis have to notice that the axis was a convention all along, not a law.

Step into Roblox or Unity and a third axis arrives:

$\text{Position} = (x, y, z)$

The academic payoff shows up fast. A study evaluated Ghanaian secondary students learning coordinate geometry through Scratch visual programming and recorded an 83.9% overall situational interest score ^[2]. A coordinate pair that stores where the player is standing, where the waypoint sits, or where the screen ends is no longer a dot on a worksheet.

Parents looking to bridge early spatial skills into structured learning can explore our guide on early math for 5 to 7 year olds without worksheets.

---

Vectors and Speed: Fixing the Diagonal Sprint Bug

Nearly every beginner game ships with the same bug. Pressing 'Right' adds $5$ to $x$. Pressing 'Up' subtracts $5$ from $y$. Press both and the character moves on both axes in the same frame.

The actual shift is not $5$ units. It is the hypotenuse:

$\text{Distance} = \sqrt{5^2 + 5^2} = \sqrt{50} \approx 7.07$

That is over 41% faster on the diagonal than straight along either axis, and players find it in about a minute. Walk sideways and forward at once and nothing can catch you.

The fix is vector normalisation. A velocity vector $\mathbf{v} = (x, y)$ carries a direction and a magnitude, and the magnitude comes straight from Pythagoras:

$\|\mathbf{v}\| = \sqrt{x^2 + y^2}$

Divide each component by that magnitude and the vector keeps its direction but shrinks to length $1$:

$\hat{\mathbf{v}} = \left( \frac{x}{\|\mathbf{v}\|}, \frac{y}{\|\mathbf{v}\|} \right)$

import math

def get_normalized_movement(dx, dy, speed):
    magnitude = math.sqrt(dx**2 + dy**2)
    if magnitude == 0:
        return 0, 0
    
    # Normalize vector and scale by intended movement speed
    normalized_x = (dx / magnitude) * speed
    normalized_y = (dy / magnitude) * speed
    return normalized_x, normalized_y

A thirteen-year-old writing those six lines is doing a topic usually reserved for senior secondary, and doing it because the alternative is a game their friends can cheat.

---

Angles and Trigonometry: Aiming Turrets and Circular Motion

Ask a secondary student which topic they dread and trigonometry comes up early. Sine, cosine and tangent get introduced as ratios belonging to triangles drawn on paper, and there the matter usually rests.

In a game, those same three functions are what make anything rotate, aim or orbit.

1. Aiming at a Target (Inverse Trigonometry)

A player sits at $(x_1, y_1)$ and wants to fire a projectile at an enemy at $(x_2, y_2)$. The turret's rotation angle $\theta$ comes from the inverse tangent ($\arctan$, or atan2):

$\Delta x = x_2 - x_1$ $\Delta y = y_2 - y_1$ $\theta = \arctan\left(\frac{\Delta y}{\Delta x}\right)$

atan2(dy, dx) sorts out negative coordinates in all four quadrants without extra logic, which is why students reach for it once they have watched a turret point backwards.

2. Decomposing Direction into Motion (Sine and Cosine)

Knowing $\theta$ is only half the job. To send the projectile along that angle at a constant speed $S$, the velocity has to be split into horizontal and vertical parts:

$v_x = S \cdot \cos(\theta)$ $v_y = S \cdot \sin(\theta)$

The same pair of functions puts a moon in orbit around a planet. Advance the angle a little each frame and recalculate the position:

$x = x_{\text{center}} + r \cdot \cos(\text{angle})$ $y = y_{\text{center}} + r \cdot \sin(\text{angle})$

Watching a barrel track a mouse cursor across the screen gives $\sin$ and $\cos$ something to be about.

---

Collision and Geometry: Bounding Boxes and Pythagoras

Something has to decide whether the laser hit the asteroid or the player touched the coin. That decision is computational geometry, every time.

Axis-Aligned Bounding Boxes (AABB)

The cheapest model asks whether two rectangles overlap. For boxes $A$ and $B$, a collision requires four inequalities to hold at once:

$\text{Collision} = (A.x_{\text{max}} \ge B.x_{\text{min}}) \land (A.x_{\text{min}} \le B.x_{\text{max}}) \land (A.y_{\text{max}} \ge B.y_{\text{min}}) \land (A.y_{\text{min}} \le B.y_{\text{max}})$

Compound inequalities and boolean algebra, both squarely on the secondary syllabus, arrive here as a condition in an if statement.

Circular Hit Detection (Distance Formula)

Rectangles betray round sprites. The corners of the box stick out past the art, so the game registers hits on empty space. Circular detection solves it with a distance check straight out of Pythagoras.

Two circles with radii $r_1$ and $r_2$ centred at $(x_1, y_1)$ and $(x_2, y_2)$ collide when the distance $d$ between their centres is no greater than $r_1 + r_2$:

$d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}$ $\text{Collision} \iff d \le r_1 + r_2$

Square roots are expensive when you are running hundreds of these checks per frame, so developers compare squared values instead:

$d^2 = (x_2 - x_1)^2 + (y_2 - y_1)^2$ $\text{Collision} \iff d^2 \le (r_1 + r_2)^2$

A study published in CITE Journal evaluated middle-school students using game mechanics to master mathematical concepts and observed statistically significant improvements on geometry pre-to-post tests ($p < .001$) ^[3]. When the formula is the difference between clearing a level and dying on it, attention is not a problem.

---

Probability and Randomness: Loot Drops and Fair Mechanics

Probability in school arrives as marbles in a bag and a fair six-sided die. The fraction work is sound. The premise rarely holds a room.

In a game, probability decides loot drops, critical hits, terrain generation and what the enemy AI does next.

Weighted Random Distribution

A uniform generator such as random(1, 100) gives every integer a flat 1% chance, which produces a chest where a legendary sword is as common as a stick. To get Common, Rare and Legendary behaving sensibly, the child builds a cumulative distribution:

import random

def get_loot_drop():
    roll = random.randint(1, 100)
    if roll <= 70:
        return "Common Sword"
    elif roll <= 95:
        return "Rare Shield"
    else:
        return "Legendary Helmet"

True Randomness vs Pseudo-Fairness

Then someone playtests it and misses five 80% attacks in a row, which is entirely possible and entirely infuriating.

So the young developer starts bending the odds: pseudo-random systems, or a hit chance that creeps upward after each miss. That is conditional probability and expected value, met from the designer's side, along with the uncomfortable discovery that a model can be tuned to manage how a player feels.

---

Percentages, Ratios, and Game Balance

Balance is where most student games fall apart. Give the boss too much health and nobody finishes the level. Give the sword too much damage and the boss dies in two hits.

Exponential and Linear Damage Curves

Scaling a character across levels means choosing a function and living with it:

• Linear Health Scaling: $\text{Health} = 100 + (\text{Level} \times 20)$
• Exponential Health Scaling: $\text{Health} = 100 \times (1.15)^{\text{Level}}$

$\text{Damage Ratio} = \frac{\text{Weapon Damage}}{\text{Enemy Armor Coefficient}}$

Playtest to level 20 and the exponential curve has run away into numbers nobody can fight, while the linear one has gone flat and boring by level 8. Fixing that is percentages, ratios and algebraic modelling, done because the game demands it.

---

Grade-Level Syllabus Map: Game Mechanics vs School Maths

Parents often ask how game building maps onto international school standards such as Cambridge IGCSE, UK National Curriculum, and US Common Core. The table below outlines how common game development tasks correlate directly with academic maths syllabuses across age groups:

---

Four Build-Along Mini Projects by Age Group

Four projects a child can build this month, each aimed at one piece of maths.

Project 1: The Scratch Bouncing Physics Lab (Ages 7–9)

• Primary Focus: Cartesian coordinates, inverse movement, and basic collision geometry.
• The Challenge: Program a sprite to bounce off walls smoothly without sticking to edges.
• Maths in Action:
  • Detect edge bounds ($x > 240$ or $x < -240$).
  • Multiply the directional velocity by $-1$ to reverse vector trajectory: $v_x = v_x \times (-1)$
• Expected Outcome: The child sees a negative number turn a sprite around on a 2D plane.

Project 2: Roblox / Minecraft Gravity and Jump Tuner (Ages 10–12)

• Primary Focus: Rate of change, gravity coefficients, and vertical velocity acceleration.
• The Challenge: Modify Lua scripts in Roblox Studio to make character jumping feel natural across varied gravity fields (e.g., Earth vs. Moon gravity).
• Maths in Action:
  • Adjust upward velocity impulse parameters.
  • Apply linear reduction of vertical position per frame.
  • For further context on how sandbox platforms develop technical skills, read our analysis on how Minecraft coding turns kids into creators.
• Expected Outcome: The child can predict what a change to the gravity constant will do before running the game.

Project 3: Pygame Top-Down Turret Shooter (Ages 13–15)

• Primary Focus: Trigonometry ($\arctan$, $\sin$, $\cos$) and vector decomposition.
• The Challenge: Program a turret to rotate smoothly toward the mouse cursor and fire bullets along that target vector.
• Maths in Action:
  • Calculate aiming angle: $\theta = \text{atan2}(dy, dx)$.
  • Update bullet trajectories each frame using trigonometric components: $x_{\text{new}} = x_{\text{old}} + \text{speed} \times \cos(\theta)$ $y_{\text{new}} = y_{\text{old}} + \text{speed} \times \sin(\theta)$
• Expected Outcome: The student uses sine and cosine as tools for aiming before meeting them again in an exam paper.

Project 4: AI Level Balancer & Loot Distribution Engine (Ages 16–18)

• Primary Focus: Applied statistics, cumulative distribution functions, and algorithmic game balance.
• The Challenge: Build a Python simulation that balances enemy spawn difficulty and loot drops based on player performance metrics.
• Maths in Action:
  • Track player win rates to adjust difficulty coefficients dynamically.
  • Implement weighted sampling logic to maintain fair reward distributions.
  • Explore foundational principles behind machine learning models. You can read more about how AI models process data in our overview on transforming learning models in AI.
• Expected Outcome: The student tunes a live system with statistics rather than guesswork.

---

How Kidocode Teaches Maths Through Game Building

We treat game development as a maths classroom that happens to be fun, and three things shape how we run it.

timeline
    title The Kidocode Learning Journey
    Ages 5 - 7 : Scratch Jr & Visual Logic : Spatial Coordinates & Basic Patterns
    Ages 8 - 12 : Roblox, Minecraft & Python : Vectors, Gravity & Probability
    Ages 13 - 18 : Pygame, Web & AI Engines : Trigonometry, Calculus & Machine Learning

1. AI-Powered Personalised Learning

Every child works alongside a personalised AI tutor platform pitched at their own pace and interests. A student stuck on a vector calculation in Python gets the maths taken apart step by step through the game mechanic in front of them, not through a restated rule.

2. Maths Through Real Construction

No drill sheets, no worksheet stacks. Students cover standard international mathematics, aligned with IGCSE, Cambridge and SPM, by using it inside their own projects. A child who works out coordinate geometry to place a character on screen tends to still have it a year later.

If you are comparing different approaches to math education, explore our comparative analysis on Kumon and abacus versus learning math by building.

3. Bundled Coding & Multi-Track Expertise

Coding itself is now easy to come by, so we bundle it free across our programmes. What we charge for is computational thinking, logic and mathematical modelling.

Students can explore six technical tracks, including Python, Web Development, Mobile Apps, Game Development, Electronics, and 3D Modelling, across five physical campuses in Klang Valley (Solaris Mont Kiara flagship, Sunway Nexis) and Penang (Q2 Waterfront, Vantage Tanjung Tokong, Icon City Bukit Mertajam), as well as through our live online classes.

---

Free printable

Printable Game Maths Debugging Checklist

Print this and keep it next to the keyboard. Most maths bugs in a student game are on it.

• Coordinate Axis Check: Is the $y$-axis origin located at the top-left (Canvas/Pygame) or center (Scratch)? Check if upward movement requires subtracting $y$.
• Diagonal Speed Normalisation: Does moving diagonally make the character run faster? Verify if the movement vector is normalized ($\text{magnitude} = 1$).
• Jump Impulse Calibration: Is vertical movement linear instead of curved? Ensure gravity adds to velocity each frame before updating position.
• Rotation Angle Quadrant: Is the turret rotating incorrectly when aiming left or down? Use atan2(dy, dx) instead of standard atan(dy/dx) to support all four quadrants.

Continue reading — get the full printable PDF (free)

Designed, ready to print and sign. We email it to you together with a 5% discount on your next registration.

Frequently Asked Questions

References

1. Kafai, Y. B., & Burke, Q. (2016). Constructionist Gaming: Understanding the Benefits of Making Games for Learning. Educational Psychologist, 50(4), 313–334. https://pmc.ncbi.nlm.nih.gov/articles/PMC4784508/
2. Taley, I. B., Amponsah, A., & Kpai, H. (2024). Exploring the Factors that Influence Students' Interest in Using Scratch to Learn Coordinate Geometry. Journal of ICT in Education (JICTIE), 11(1), 28–42. https://ejournal.upsi.edu.my/JICTIE/article/download/9165/4999/45918
3. Smith, H., Closser, A. H., Ottmar, E., & Arroyo, I. (2020). Developing Mathematics Knowledge and Computational Thinking Through Game Play and Design. Contemporary Issues in Technology and Teacher Education (CITE Journal), 20(4). https://citejournal.org/volume-20/issue-4-20/mathematics/developing-mathematics-knowledge-and-computational-thinking-through-game-play-and-design-a-professional-development-program/
4. Yulianto, D., Situmeang, M. S., Astari, & Nurcahyo, R. (2026). Digital Game-Based Learning in Primary Mathematics Education: A Systematic Literature Review and Meta-Analysis. Range: Jurnal Pendidikan Matematika, 7(2). https://jurnal.unimor.ac.id/JPM/article/download/10225/2682
5. Duarte, C., Pais, S., & Hall, A. (2026). Designing Mathematical Games in Middle School: An Exploratory Case Study. Education Sciences, 16(1), 71. https://www.mdpi.com/2227-7102/16/1/71
6. Munusamy, I., Lee Abdullah, M. F. N., & Mohamad, S. A. (2025). Educational Games in Mathematics Learning: A Review of Literature. International Journal of Research and Innovation in Social Science (IJRISS), 9(27), 28–34. https://rsisinternational.org/journals/ijriss/uploads/vol9-iss27-pg28-34-202511_pdf.pdf
7. WIPO Academy / World Intellectual Property Organization. (2024). Good Practices in STEM Education: Malaysia Report. https://dacatalogue.wipo.int/projectfiles/DA_1_3_10_19_30_01/Malaysia_Report%202/EN/MALAYSIA_Report%202_GoodPracticesin%20STEM%20Education_English.pdf