Drift Invaders Pipeline Defense

This case follows one rule: no invented features. Anything not yet confirmed in the implementation is marked as TODO — the case study evolves together with the experiment.

Context

After two shipped products — Mapa dos Rolezinhos and Nu! Carnaval 2026 — Drift Invaders is the fundamentals corner of the collection: a Python experiment, free of product deadlines, where the goal is reasoning. The theme comes from engineering itself: delivery failures and configuration drift become invader waves, and the player’s defense is a pipeline. Studying logic and studying DevOps on the same board.

Problem

There are two problems here, one pedagogical and one technical. The pedagogical one: concepts like drift, gates, and pipeline stages feel abstract when seen only in documentation — giving them a body as game mechanics is a way to internalize them. The technical one: logic and data-structure fundamentals demand deliberate practice outside tutorials, and a game is an endless generator of concrete problems — state, timing, collision, priority.

User

Honesty first: user number one is the author himself — the project exists to train algorithmic reasoning in Python with immediate visual feedback. The second audience is anyone studying DevOps who benefits from seeing concepts become mechanics. And, as a portfolio piece, the third reader is technical: someone evaluating clarity of code and decisions.

Stack

• Python — the core of all the logic: entities, waves, collisions, and rules.
• TODO Confirm the interface layer (Pygame, terminal, or other) and pin the Python version and project dependencies.

Architecture

The design pursues one separation from the start: game logic should not know how it is drawn. The cycle follows the classic game loop — read input, update state, render — with the match state (waves, defenses, score) as the central structure.

• TODO Document the actual module organization once it stabilizes.
• TODO Define how levels and invader types are described (versioned data is the intent; confirm the format).

Features

The experiment covers the essential cycle of a wave-defense game. To avoid selling what does not exist, the status of each mechanic is explicit:

• Core match loop with invader waves — TODO confirm what is already playable.
• Pipeline-inspired defenses (tests, scanners, policies) — TODO list which exist beyond the concept.
• Scoring and difficulty progression — TODO confirm implementation.

Technical decisions

• Python as the experiment’s language. With no engine ceremony, the focus stays on logic — and Python is exactly the language of the project’s planned evolution (automation, data, ML). Today’s code speaks tomorrow’s roadmap.
• A game as the study format. Game mechanics force real algorithmic problems: collision detection, event queues, state kept consistent every frame. And a logic error shows up on screen, immediately.
• A DevOps theme on purpose. The game’s vocabulary is the field’s vocabulary — drift, pipeline, gate. One project, two curricula.
• Logic separated from presentation. This is what allows the mechanics to be tested automatically and, later, matches to run without an interface (headless) — a prerequisite for training an agent. TODO record the current state of this separation.

Security

Today’s surface is minimal by nature: the game runs locally, with no network and no user data. The section exists out of structural discipline — and to record the commitment: if the project gains an online leaderboard or telemetry, authentication and privacy enter as requirements, not as patches. Until then, the real care is the Python dependency chain (pinned, minimal versions).

Lessons learned

• A game exposes fragile logic immediately: a collision bug does not hide in a log — it shows up on screen.
• Starting in pure Python, before any engine, forces you to understand what the engine would do for you — and that changes how you evaluate any tool afterwards.
• Small scope and a beloved theme are what keep a study project alive after the initial enthusiasm.
• TODO Record implementation-specific lessons as the experiment moves forward.

Next steps

The project’s reason for existing is this evolution route, in three steps:

1. Automation — mechanics tests running in CI on every commit; automated builds and runs.
2. Data — recording match events (waves cleared, hits, reaction time) and analyzing sessions: the game becomes a data source.
3. ML — with logic separated from the interface and headless matches, the game becomes a training environment: an agent learning to play, starting with simple heuristics up to reinforcement learning.

• TODO Define and date the next playable milestone.
• TODO Publish the repository once the core stabilizes.