Every game you have ever played, from a text-based number guessing challenge to a sprawling open-world adventure, runs on the same foundational principle: a loop that reads input, updates state, and renders output. Python makes that principle visible. Its readable syntax strips away the noise so you can focus on the logic itself, and that is exactly why it remains a go-to language for learning game architecture and rapid prototyping in 2026.
Game logic is the set of rules, systems, and structures that determine what happens in a game and when it happens. It is separate from graphics, separate from audio, and separate from networking. You could swap out every visual asset in a game and the logic would still function. Understanding this distinction is what separates someone who copies tutorials from someone who can design original game mechanics from scratch.
This article walks through the core architectural patterns that power Python games. Every code example is self-contained and runnable, so you can experiment with each concept independently before combining them into something larger.
The Game Loop: Your Engine's Heartbeat
The game loop is the single structure that keeps a game alive. It cycles continuously, performing three jobs on every pass: process input from the player, update the game state based on that input and any automated rules, then render the current state to the screen. When the loop stops, the game ends.
At its simplest, a game loop in pure Python looks like this:
def init():
"""Initialize the game state."""
return {
"running": True,
"score": 0,
"player_x": 0,
"player_y": 0,
}
def process_input(state):
"""Read and interpret player commands."""
command = input("Enter command (w/a/s/d/q): ").strip().lower()
if command == "q":
state["running"] = False
return command
def update(state, command):
"""Apply rules and modify the game state."""
moves = {
"w": (0, 1),
"s": (0, -1),
"a": (-1, 0),
"d": (1, 0),
}
if command in moves:
dx, dy = moves[command]
state["player_x"] += dx
state["player_y"] += dy
state["score"] += 1
def render(state):
"""Display the current state to the player."""
x, y = state["player_x"], state["player_y"]
print(f"Position: ({x}, {y}) | Score: {state['score']}")
def run():
"""The game loop."""
state = init()
while state["running"]:
command = process_input(state)
update(state, command)
render(state)
print("Game over.")
run()Notice how each function has a single responsibility. The process_input function knows nothing about how the game world works. The update function has no idea how the state gets displayed. This separation is not just good style. It makes every piece testable, replaceable, and easier to reason about when the codebase grows.
In real-time games using Pygame or similar frameworks, the loop runs continuously without waiting for input. A clock object controls the frame rate, typically targeting 60 frames per second, so the loop executes roughly every 16 milliseconds regardless of whether the player pressed anything.
Fixed vs. Variable Time Steps
One critical decision in game loop design is how you handle time. A fixed time step means the game logic updates at a constant interval, say every 16 ms, regardless of how fast the rendering runs. A variable time step scales movement and physics by the elapsed time since the last frame. Fixed steps produce deterministic, reproducible behavior, which matters for multiplayer synchronization and replay systems. Variable steps feel smoother on varying hardware but can introduce subtle bugs in physics calculations.
import time
class GameClock:
def __init__(self, target_fps=60):
self.target_fps = target_fps
self.frame_duration = 1.0 / target_fps
self.last_time = time.time()
self.delta_time = 0.0
self.accumulator = 0.0
def tick(self):
"""Calculate delta time and return it."""
current_time = time.time()
self.delta_time = current_time - self.last_time
self.last_time = current_time
return self.delta_time
def should_update(self):
"""For fixed time step: accumulate and drain."""
self.accumulator += self.delta_time
if self.accumulator >= self.frame_duration:
self.accumulator -= self.frame_duration
return True
return FalseThe GameClock class above supports both approaches. Call tick() every frame to get the raw delta, or use should_update() inside the loop to enforce a fixed update rate while rendering as fast as the system allows.
State Machines: Controlling the Flow
Games are not a single continuous experience. They transition between distinct phases: a title screen, a gameplay phase, a pause menu, a game-over screen. Each phase has its own rules, its own input handling, and its own rendering behavior. A finite state machine (FSM) is the pattern that manages these transitions cleanly.
In an FSM, the game exists in exactly one state at any given moment. Each state defines what inputs are valid, how the game world changes, and what gets drawn. Transitions between states are triggered by specific events, like pressing Escape to pause or a player's health reaching zero.
from enum import Enum, auto
class GameState(Enum):
MAIN_MENU = auto()
PLAYING = auto()
PAUSED = auto()
GAME_OVER = auto()
class Game:
def __init__(self):
self.state = GameState.MAIN_MENU
self.score = 0
self.health = 100
def handle_input(self, action):
if self.state == GameState.MAIN_MENU:
if action == "start":
self.state = GameState.PLAYING
self.score = 0
self.health = 100
print("Game started.")
elif self.state == GameState.PLAYING:
if action == "pause":
self.state = GameState.PAUSED
print("Game paused.")
elif action == "hit":
self.health -= 25
print(f"Hit! Health: {self.health}")
if self.health <= 0:
self.state = GameState.GAME_OVER
print(f"Game over. Final score: {self.score}")
elif action == "score":
self.score += 10
print(f"Score: {self.score}")
elif self.state == GameState.PAUSED:
if action == "resume":
self.state = GameState.PLAYING
print("Resumed.")
elif action == "quit":
self.state = GameState.MAIN_MENU
print("Returned to menu.")
elif self.state == GameState.GAME_OVER:
if action == "restart":
self.state = GameState.PLAYING
self.score = 0
self.health = 100
print("Restarting.")
elif action == "menu":
self.state = GameState.MAIN_MENU
print("Back to menu.")The Enum class makes each state explicit and type-safe. There is no risk of a typo silently creating an invalid state because GameState.PLYING would immediately raise an error. The handle_input method acts as a dispatcher: the same action can have completely different effects depending on which state the game is in. Pressing a key that means "jump" during gameplay means nothing on the pause screen.
For larger games, consider replacing the if/elif chain with a dictionary that maps each state to a dedicated handler class. Each class implements its own handle_input(), update(), and render() methods. This is the State design pattern, and it scales far better than conditional branching as the number of states grows.
Hierarchical and Pushdown State Machines
Flat state machines work well when the number of states is small, but games often need nested behavior. A character might be in a "combat" state that itself contains sub-states like "attacking," "blocking," and "dodging." Hierarchical state machines handle this by allowing states to contain child states. If the child does not handle an input, the parent gets a chance to respond.
A pushdown automaton adds memory. Instead of replacing the current state, it pushes a new state onto a stack. When that state finishes, it pops off and the previous state resumes exactly where it left off. This is how pause menus, dialog boxes, and inventory screens typically work: they interrupt the game without destroying it.
class StateStack:
def __init__(self):
self._stack = []
def push(self, state):
"""Pause the current state and activate a new one."""
self._stack.append(state)
def pop(self):
"""Remove the current state, resuming the previous."""
if self._stack:
return self._stack.pop()
@property
def current(self):
"""Return the active state without removing it."""
return self._stack[-1] if self._stack else None
def handle_input(self, action):
if self.current:
self.current.handle_input(action)
def update(self):
if self.current:
self.current.update()Collision Detection and Physics
Collision detection answers one question: are two game objects overlapping? The answer drives everything from a bullet hitting an enemy to a character landing on a platform. In 2D Python games, the two approaches you will encounter everywhere are axis-aligned bounding box (AABB) checks and circle-based distance checks.
class Rect:
"""Axis-aligned bounding box for 2D collision."""
def __init__(self, x, y, width, height):
self.x = x
self.y = y
self.width = width
self.height = height
def collides_with(self, other):
"""Return True if this rect overlaps another."""
return (
self.x < other.x + other.width
and self.x + self.width > other.x
and self.y < other.y + other.height
and self.y + self.height > other.y
)
class Circle:
"""Circle-based collision using distance."""
def __init__(self, cx, cy, radius):
self.cx = cx
self.cy = cy
self.radius = radius
def collides_with(self, other):
"""Return True if this circle overlaps another."""
dx = self.cx - other.cx
dy = self.cy - other.cy
distance_sq = dx * dx + dy * dy
radius_sum = self.radius + other.radius
return distance_sq <= radius_sum * radius_sumThe AABB check compares four edges. If all four conditions are true, the rectangles overlap. The circle check compares the squared distance between centers to the squared sum of radii. The squared comparison avoids a costly square root operation, which matters when checking hundreds of objects per frame.
Checking every object against every other object is an O(n2) operation. For games with more than a few dozen moving entities, use spatial partitioning techniques like quadtrees or spatial hashing to reduce the number of comparisons dramatically.
Simple Gravity and Movement
Physics in game logic does not need to be realistic. It needs to feel right. A simple gravity system applies a constant downward acceleration to a character's vertical velocity each frame, then checks whether the character has hit the ground.
class Entity:
def __init__(self, x, y):
self.x = x
self.y = y
self.vx = 0.0
self.vy = 0.0
self.on_ground = False
def apply_gravity(self, gravity=0.5):
if not self.on_ground:
self.vy += gravity
def update(self, ground_level=400):
self.x += self.vx
self.y += self.vy
if self.y >= ground_level:
self.y = ground_level
self.vy = 0
self.on_ground = True
def jump(self, strength=-10):
if self.on_ground:
self.vy = strength
self.on_ground = FalseThe apply_gravity method increases the downward velocity every frame. The update method clamps the position when it reaches the ground level and resets the velocity. The jump method only fires when the entity is grounded, preventing infinite mid-air jumps. This basic system is the foundation of every side-scroller and platformer.
Event-Driven Architecture
As games grow more complex, direct method calls between systems become brittle. If the scoring system needs to know when an enemy dies, and the sound system also needs to know, and the particle system does too, the enemy class ends up importing and calling everything. Event-driven architecture solves this by decoupling the thing that happens from the things that respond to it.
class EventBus:
"""A publish-subscribe event system."""
def __init__(self):
self._listeners = {}
def subscribe(self, event_type, callback):
"""Register a callback for a specific event type."""
if event_type not in self._listeners:
self._listeners[event_type] = []
self._listeners[event_type].append(callback)
def unsubscribe(self, event_type, callback):
"""Remove a callback from an event type."""
if event_type in self._listeners:
self._listeners[event_type].remove(callback)
def publish(self, event_type, **data):
"""Notify all listeners of an event."""
for callback in self._listeners.get(event_type, []):
callback(**data)
# Usage
bus = EventBus()
def on_enemy_defeated(enemy_name, points):
print(f"Score +{points} for defeating {enemy_name}")
def on_enemy_defeated_sound(enemy_name, **kwargs):
print(f"Playing defeat sound for {enemy_name}")
bus.subscribe("enemy_defeated", on_enemy_defeated)
bus.subscribe("enemy_defeated", on_enemy_defeated_sound)
# When an enemy is defeated anywhere in the code:
bus.publish("enemy_defeated", enemy_name="Goblin", points=50)The EventBus class acts as a central message broker. Systems register interest in specific event types, and when those events occur, every registered callback fires. The enemy code only needs to call bus.publish(). It has no knowledge of what systems are listening or how they respond. Adding a new system that reacts to enemy defeats requires zero changes to existing code.
This pattern is standard practice in modern game architecture. It makes systems modular, testable in isolation, and trivially extensible. If you later want to add an achievement system that tracks total enemies defeated, you subscribe one more callback. Nothing else changes.
Scoring, Progression, and Win Conditions
Game logic is not just about movement and collisions. It also governs the abstract systems that give a game its structure: how points accumulate, how difficulty escalates, and what conditions trigger victory or defeat.
class ProgressionSystem:
def __init__(self):
self.score = 0
self.level = 1
self.enemies_defeated = 0
self.level_thresholds = [0, 100, 300, 600, 1000]
def add_score(self, points):
"""Add points and check for level advancement."""
self.score += points
self.enemies_defeated += 1
new_level = self._calculate_level()
if new_level > self.level:
self.level = new_level
return f"Level up! Now level {self.level}"
return None
def _calculate_level(self):
"""Determine the current level based on score."""
for i in range(len(self.level_thresholds) - 1, -1, -1):
if self.score >= self.level_thresholds[i]:
return i + 1
return 1
def get_difficulty_multiplier(self):
"""Scale enemy stats based on current level."""
return 1.0 + (self.level - 1) * 0.25
def check_win_condition(self, target_score=1000):
"""Return True if the player has met the win goal."""
return self.score >= target_scoreThe ProgressionSystem encapsulates all the rules about how the player advances. The _calculate_level method walks the threshold list backwards to find the highest level the current score qualifies for. The get_difficulty_multiplier method returns a scaling factor that other systems can use to make enemies tougher, items rarer, or timers shorter as the game progresses.
Store your level thresholds, difficulty curves, and win conditions in external data files (JSON or YAML) rather than hardcoding them. This lets you tweak game balance without touching the logic code, and it makes it far easier for non-programmers on a team to adjust gameplay feel during testing.
Putting It All Together
Individual patterns become powerful when they work in concert. Here is a minimal but complete game structure that combines the game loop, state management, collision detection, event bus, and scoring into a cohesive system:
from enum import Enum, auto
class State(Enum):
MENU = auto()
PLAYING = auto()
GAME_OVER = auto()
class MiniGame:
def __init__(self):
self.state = State.MENU
self.bus = EventBus()
self.progression = ProgressionSystem()
self.player = Entity(50, 400)
self.enemies = []
self._setup_events()
def _setup_events(self):
self.bus.subscribe("enemy_defeated", self._on_defeat)
def _on_defeat(self, points=10, **kwargs):
result = self.progression.add_score(points)
if result:
print(result)
if self.progression.check_win_condition():
self.state = State.GAME_OVER
print(f"You win! Score: {self.progression.score}")
def run(self):
while True:
if self.state == State.MENU:
action = input("Press 's' to start: ").strip()
if action == "s":
self.state = State.PLAYING
elif self.state == State.PLAYING:
action = input("(a)ttack / (j)ump / (q)uit: ").strip()
if action == "a":
self.bus.publish("enemy_defeated", points=50)
elif action == "j":
self.player.jump()
self.player.apply_gravity()
self.player.update()
print(f"Player Y: {self.player.y}")
elif action == "q":
break
elif self.state == State.GAME_OVER:
print("Thanks for playing.")
break
MiniGame().run()This example is intentionally simple, but it demonstrates the architecture that scales. Each system (events, progression, physics, state management) is a separate, composable piece. When you are ready to add graphics with Pygame, networking with sockets, or AI with pathfinding algorithms, each of those integrations plugs into this same structure without rewriting what already works.
Key Takeaways
- The game loop is everything: Every game runs on a cycle of input, update, and render. Understanding this pattern means you can build a game in any language and any framework, because the structure never changes.
- State machines prevent chaos: Without explicit state management, games devolve into tangled conditional logic. Finite state machines, and their more advanced variants like pushdown automata, give you clean, predictable control flow.
- Separate your systems: Collision detection, scoring, event handling, and rendering should each live in their own module. The event bus pattern lets these systems communicate without directly depending on each other, which makes your codebase maintainable as it grows.
- Start with logic, add visuals later: Every example in this article runs in a terminal. That is deliberate. The logic is the hard part. Once it works, connecting it to Pygame, Arcade, or any other rendering library is straightforward because the architecture is already sound.
- Python is the right tool for learning this: Python's readability lets you focus on the concepts rather than the syntax. Once you internalize these patterns, porting them to C#, C++, or any other language is a matter of translation, not reinvention.
Game logic is where creativity meets engineering. The patterns covered here, the game loop, state machines, collision detection, event-driven architecture, and progression systems, form the skeleton of every game ever built. Master them in Python, and you have a transferable skill set that applies to any engine, any platform, and any genre. Build something small, iterate, and let the logic guide you.