Drift Invaders Pipeline Defense

Este case segue uma regra: nada de funcionalidade inventada. O que ainda não está confirmado na implementação aparece marcado como TODO — o estudo de caso evolui junto com o experimento.

Contexto

Depois de dois produtos publicados — Mapa dos Rolezinhos e Nu! Carnaval 2026 —, o Drift Invaders é o espaço de fundamentos da coleção: um experimento em Python, sem prazo de produto, onde o objetivo é raciocínio. O tema vem da própria engenharia: falhas de entrega e drift de configuração viram ondas de invasores, e a defesa do jogador é uma pipeline. Estudar lógica e estudar DevOps no mesmo tabuleiro.

Problema

Há dois problemas aqui, um pedagógico e um técnico. O pedagógico: conceitos como drift, gates e estágios de pipeline parecem abstratos quando vistos só em documentação — dar corpo de mecânica a eles é um jeito de internalizá-los. O técnico: fundamentos de lógica e estruturas de dados exigem prática deliberada fora de tutoriais, e um jogo é um gerador inesgotável de problemas concretos — estado, tempo, colisão, prioridade.

Usuário

Sinceridade primeiro: o usuário número um é o próprio autor — o projeto existe para treinar raciocínio algorítmico em Python com feedback visual imediato. O segundo público é quem estuda DevOps e se beneficia de ver conceitos virarem mecânica. E, sendo um item de portfólio, o terceiro leitor é técnico: alguém avaliando clareza de código e de decisões.

Stack

Python — núcleo de toda a lógica: entidades, ondas, colisões e regras.
TODO Confirmar a camada de interface (Pygame, terminal ou outra) e fixar a versão do Python e as dependências do projeto.

Arquitetura

O desenho persegue uma separação desde o início: a lógica do jogo não deve saber como é desenhada. O ciclo segue o clássico loop de jogo — ler entrada, atualizar estado, renderizar — com o estado da partida (ondas, defesas, pontuação) como estrutura central.

TODO Documentar a organização real dos módulos quando estabilizar.
TODO Definir como fases e tipos de invasor são descritos (dados versionados é a intenção; confirmar o formato).

Funcionalidades

O experimento cobre o ciclo essencial de um jogo de defesa por ondas. Para não vender o que não existe, o estado de cada mecânica fica explícito:

Loop central de partida com ondas de invasores — TODO confirmar o que já está jogável.
Defesas inspiradas em pipeline (testes, scanners, políticas) — TODO listar quais existem além do conceito.
Pontuação e progressão de dificuldade — TODO confirmar implementação.

Decisões técnicas

Python como linguagem do experimento. Sem cerimônia de engine, o foco fica na lógica — e Python é exatamente a língua da evolução planejada do projeto (automação, dados, ML). O código de hoje conversa com o roadmap de amanhã.
Jogo como formato de estudo. Mecânica de jogo obriga a resolver problemas reais de algoritmo: detecção de colisão, fila de eventos, estado consistente a cada frame. E um erro de lógica aparece na tela, na hora.
Tema DevOps de propósito. O vocabulário do jogo é o vocabulário da área — drift, pipeline, gate. Um projeto, dois aprendizados.
Lógica separada da apresentação. É o que permite testar a mecânica de forma automatizada e, no futuro, rodar partidas sem interface (headless) — pré-requisito para treinar um agente. TODO registrar o estado atual dessa separação.

Segurança

A superfície hoje é mínima por natureza: o jogo roda localmente, sem rede e sem dados de usuário. A seção existe pela disciplina da estrutura — e para registrar o compromisso: se o projeto ganhar placar online ou telemetria, autenticação e privacidade entram como requisitos, não como remendo. Até lá, o cuidado real é com a cadeia de dependências Python (versões fixadas e mínimas).

Aprendizados

Um jogo expõe lógica frágil imediatamente: bug de colisão não se esconde em log — ele aparece na tela.
Começar em Python puro, antes de qualquer engine, força a entender o que a engine faria por você — e isso muda como se avalia qualquer ferramenta depois.
Escopo pequeno e tema querido são o que mantém projeto de estudo vivo depois do entusiasmo inicial.
TODO Registrar aprendizados específicos da implementação conforme o experimento avança.

Próximos passos

A razão de ser do projeto é esta rota de evolução, em três degraus:

Automação — testes da mecânica rodando em CI a cada commit; execução e build automatizados.
Dados — registrar eventos de partida (ondas vencidas, acertos, tempo de reação) e analisar as sessões: o jogo vira fonte de dados.
ML — com lógica separada da interface e partidas headless, o jogo se torna um ambiente de treino: um agente aprendendo a jogar, começando por heurísticas simples até aprendizado por reforço.

TODO Definir e datar a próxima entrega jogável.
TODO Publicar o repositório quando o núcleo estabilizar.