Chapter 1: What Makes a Game?

What Makes a Game? 🎮

Think like a developer, not just a player

Before you build your first game, you need to understand what a game actually is. Not just “something fun on a screen.” We’re going to break it down the way a developer does, piece by piece, until you can look at any game, from Pong to the newest release, and see the machinery underneath.

Here’s why that matters. Anyone can say “I want to make a game like Minecraft.” A developer can say “I want a survival loop with block-based building, a day-night cycle that changes the danger level, and a crafting system that rewards exploration.” The second sentence is something you can actually build. This chapter gives you the vocabulary to think that way.

1.1 — What Is a Game, Really? 🧩

Strip away the graphics and the sound, and every game, digital or not, has the same skeleton. Game designers usually describe it with four ingredients:

Ingredient	What It Means	In Chess	In Mario Kart
Goal	What the player is trying to achieve	Checkmate the king	Cross the finish line first
Rules	What the player can and cannot do	How each piece moves	Track boundaries, item rules
Challenge	What makes the goal hard	An opponent thinking against you	Other racers, hazards, corners
Feedback	How the player knows how they’re doing	Captured pieces, check	Position counter, lap timer, sounds

If any one of these is missing, it stops being a game. A toy has no goal. A puzzle with no rules is just a pile of pieces. A goal with no challenge is a chore. And a game with no feedback is a mystery, because you can never tell whether you’re winning.

Digital Games Add Two Things

A video game is a game where a computer enforces the rules and delivers the feedback. That adds two powerful ingredients a board game can’t offer:

Simulation. The computer can track thousands of things at once: physics, enemies, weather, an entire economy. Nobody has to remember whose turn it is.
Instant feedback. The screen and speakers respond in a fraction of a second. That responsiveness is a huge part of why video games feel so satisfying.

The Magic Circle

Designers talk about the magic circle: the invisible line you step across when you start playing. Inside the circle, the game’s rules replace normal rules. Stomping on a turtle is fine in Mario; it is not fine on a sidewalk. Your job as a developer is to build a circle worth stepping into, and to make the rules inside it clear.

1.2 — The Four Pillars of Every Video Game 🏛️

Every video game, from Pong in 1972 to the biggest release this year, is built on four core technical elements. Learn these and you can read any game’s blueprint.

1. The Game Loop

The game loop is the heartbeat of your game. It runs constantly, typically 60 times per second, doing three things in order:

while game_is_running:
    handle_input()    # What did the player do?
    update_state()    # What changed in the game world?
    render_frame()    # Draw the new frame on screen

That’s it. Every game you have ever played is that loop, repeated millions of times. The difference between a simple game and a huge one is what happens inside each step.

2. Player Input

Input is how the player communicates with your game. Different devices offer different inputs, and good games are designed around the one the player actually has:

Input Type	Example
Keyboard	`WASD` to move, `Space` to jump
Mouse	Click to shoot, drag to build
Touch	Tap to jump, swipe to dodge
Controller	Joystick to steer, buttons to attack
Motion / camera	Swing a controller, move in front of a sensor

A design rule to remember: the input should match the action. Swiping to slash feels right. Typing a paragraph to jump does not.

3. Game State

The game state is everything the computer needs to know about your game at this exact moment:

Where is the player? Which direction are they facing?
What’s the score? How much health is left?
Where are the enemies, and what are they doing?
What’s in the inventory? Which doors are unlocked?

If you could freeze a game and write down every number it’s tracking, that list is the game state. Saving a game means writing the state to a file. Loading means reading it back.

4. Rendering

rendering is the process of turning the game state into pixels on the screen. Every frame, the game redraws everything based on the current state. Nothing on screen is permanent. If the state says the player is at position (100, 240), the renderer draws them there. Move the number, and next frame the player has moved.

How the Pillars Work Together

Imagine a single jump in a platformer:

Input: the player presses the jump button.
State: the code sets the player’s upward speed and marks them as “in the air.”
Render: the player sprite is drawn slightly higher than last frame.
Next frame, gravity lowers the upward speed, the state updates, the render shows the character a little higher but slowing down… until they land.

Sixty tiny steps a second, and it looks like a smooth jump.

1.3 — Frames, Pixels, and Performance ⚡

Players complain about “lag” and “low FPS” all the time. Developers have to understand what those words actually mean.

Frames Per Second

Each trip through the game loop produces one frame, a single still picture. FPS is how many frames the game draws each second. At 60 FPS, each frame has about 16 milliseconds to finish everything: input, state, rendering. If the code takes longer, the frame is late, the next one is skipped, and the player sees a stutter.

FPS	How It Feels
60+	Smooth and responsive; the standard target
30	Playable; common on older consoles and big 3D games
Under 20	Choppy; input feels delayed; players call it “lag”

Resolution and Pixels

A 1080p screen is 1920 pixels wide and 1080 tall: over two million pixels, each needing a color, sixty times a second. That’s why 3D games work the graphics card so hard. Pixel-art games choose a tiny resolution (say 320 by 180) on purpose. It looks retro, and it’s also thousands of times less work to draw, which is one reason indie developers love it.

Why Games Lag

A frame runs late for a few common reasons, and each one is something a developer can fix:

Too much to draw. Thousands of particles or high-detail models. Fix: simplify, or draw fewer things at once.
Too much to compute. Checking every enemy against every bullet every frame. Fix: smarter checks, only nearby objects.
Waiting on the network. In online games, your frame can’t finish until it hears from the server. Fix: predict locally, correct later.
Weak hardware. The player’s device is slower than yours. Fix: settings that lower detail.

Notice that “add a faster computer” is only one of four answers. Most performance work is design work.

1.4 — Who Makes Games? 🧑‍💻

Games look like they come from a single genius, but even small games are team efforts, and big games have hundreds of people. Knowing the roles helps you see which one fits you.

Role	What They Do
Game designer	Decides the rules, the goals, the levels, and what makes it fun
Programmer	Writes the code that makes the loop, the physics, and the enemies work
Artist	Draws characters, environments, animations, and interface
Sound designer / composer	Creates sound effects and music
Writer	Story, dialogue, world lore
QA tester	Plays the game on purpose to break it and report bugs
Producer	Keeps the schedule, the budget, and the team on track

Indie vs. Studio

An indie developer might do all of those jobs alone or with two friends. Stardew Valley was made by one person over four years. A large studio may have 500 people and a budget of hundreds of millions of dollars. Neither is “better.” Indies move fast and take risks; studios build things no small team could.

Game Engines

Almost nobody writes a game loop from scratch anymore. A game engine supplies the loop, rendering, physics, input, and sound, so you focus on the game itself.

Engine	Good For	Cost
GDevelop	Beginners, 2D games, no typing required	Free
Scratch	First projects, block-based logic	Free
Godot	2D and 3D, open-source, real scripting	Free
Unity	2D and 3D, huge community, mobile games	Free to start
Unreal	High-end 3D graphics	Free to start

In this book you’ll use GDevelop. Its game loop, rendering, and input handling are built in. You’ll focus on defining the game state and the rules, and the engine handles the rest.

Chapter 1 Activity: Reverse-Engineer a Game 🔍

Your Mission: Pick one game you know well and take it apart like a developer. Write your answers on paper or in a document.

Part 1: The Four Ingredients

Name the game’s goal, three of its rules, its main challenge, and three kinds of feedback (visual, sound, numbers). Then answer: which ingredient is the strongest, and which is the weakest?

Part 2: The Four Pillars

List every input the game uses. Write down ten pieces of game state you can see on screen and three you can’t. Describe one thing the renderer draws differently from frame to frame while you stand still (a flickering torch, a blinking cursor, an idle animation).

Part 3: Performance Detective

Find a moment where the game slows down, stutters, or loads. Using section 1.3, write your best guess for why, and what a developer could change to fix it.

Part 4: The Credits

Watch or look up the game’s credits. Count how many roles you can find from the table in 1.4. Was it made by an indie or a studio? Which role would you want, and why?

Key Concepts Checklist

I can define a game as goal, rules, challenge, and feedback
I can explain what the magic circle is
I can name the four pillars of a video game
I can describe what the game loop does each frame
I know the difference between game state and rendering
I can explain what FPS means and why frames run late
I can identify input types in games I play
I can name five roles on a game team and what an engine does