Lesson 1 of 22, in world 1: Foundations
What Makes a Game
Before writing any code, it helps to know what we are building. A game is not just graphics that move — it’s a set of rules that create interesting decisions, wrapped in a program that runs in real time.
Toy vs. game
A ball you can bounce is a toy. Add a goal (“get it in the hoop”), a challenge(a defender, a clock), feedback (the swish) and a reward (points), and it becomes a game. Try it yourself:
Move the mouse over the canvas. With everything off it's a toy: fun to poke, but nothing to achieve. Switch the ingredients on one by one and feel when it turns into a game.
The core loop
Every game has a core loop: the small cycle of actions the player repeats over and over. In Mario: run → jump → avoid/stomp → reach flag. In the demo above: chase → catch → score → chase. If the core loop isn’t fun for 30 seconds, no amount of content will save it — which is why game developers prototype the core loop first, with plain rectangles.
Mechanics → Dynamics → Aesthetics
A popular framework (MDA) splits a game into three layers. Mechanics are the rules and code you write (“the star flees when you’re within 140 px”). Dynamics are the behaviour that emerges when a player meets those rules (“I learn to corner the star against a wall”). Aesthetics are the feelings that result (“tension, then satisfaction”). You only control the mechanics directly — so you tune numbers, playtest, and watch what players feel.
What a game program is made of
- The game loop — the heartbeat that runs every frame (next lesson).
- State — positions, velocities, health, score: the data that describes the world right now.
- Systems — input, physics, collisions, AI, animation, audio: code that changes state every frame.
- Rendering — turning state into pixels.
- Assets — images, sounds, levels: data authored by artists and designers.
A game engine (Godot, Unity, Unreal) provides the loop, rendering, physics, audio and an editor for you. We’ll build tiny versions of each piece by hand in the browser so you understand what the engine is doing, then map every concept to Godot at the end.
Key takeaways
- A game = rules that create interesting decisions + feedback + goals, running in real time.
- The core loop is the repeated cycle of play. Prototype and test it first with simple shapes.
- You write mechanics; players experience dynamics and aesthetics. Tuning numbers is design.
- Games are continuous simulations, not request/response programs.
Check yourself
Q1. You built a bouncing ball you can flick around. What turns it into a game?
Q2. In MDA, which layer do you directly write as code?
Q3. How is a game different from a typical web server?
Exercises
- Pick a game you love and write its core loop in one line (verb → verb → verb).
- In the demo, turn on only Goal + Reward. Is it fun? What does the Challenge toggle add?
- Name one mechanic, the dynamic it causes, and the feeling (aesthetic) it creates in a game you know.