Project Aurora

A oportunidade

Project Aurora nasceu da oportunidade de criar um beat ‘em up contemporâneo em que a identidade brasileira participa do jogo de verdade. Não apenas no cenário ou na estética, mas também nos personagens, regiões, estilos de combate, progressão e narrativa.

O desafio passou a ser transformar essa identidade em sistemas, sem depender apenas de referências visuais.

Meu papel e equipe

Project Aurora é desenvolvido por uma equipe de três pessoas. Atuo como Product Lead & Game Design Lead e concentro as principais decisões sobre visão, sistemas, escopo e priorização.

Meu trabalho é transformar a direção criativa em um produto que a equipe consiga discutir, priorizar e construir. Isso cobre gameplay loop, personagens, combate, progressão, economia, campanha, hub e a definição do que precisa ser confirmado primeiro.

Os dois desenvolvedores são responsáveis pelas decisões de engenharia e pela implementação. Trabalhamos juntos nas discussões de viabilidade, arquitetura e trade-offs técnicos.

A equipe trabalha de forma colaborativa, com ownership dividido por área. Produto e game systems ficam sob minha liderança. Engenharia e implementação ficam com os dois desenvolvedores.

Brasil como sistema

A identidade brasileira influencia diretamente as decisões de design do produto:

A diferenciação não depende apenas de arte ou cenário. Ela está conectada às próprias regras e sistemas do jogo.

De visão a sistema

Uma ideia de jogo ainda não é um produto implementável. Parte do meu trabalho é quebrar a visão em sistemas, comportamentos, prioridades e riscos que a equipe consiga discutir e construir.

Core game loop

O diagrama abaixo representa o target loop da visão de produto, incluindo sistemas ainda em definição como o hub completo e a progressão.

O loop foi desenhado para que cada saída do hub tenha um objetivo claro e cada retorno ofereça uma decisão de progressão.

Três decisões que definem a experiência

Transformar menus em parte do mundo

O jogo precisava conectar seleção de regiões, upgrades, itens, NPCs, narrativa, preparação e progressão. A alternativa mais simples seria uma coleção de menus independentes. A decisão foi centralizar essas funções em um hub diegético, um espaço subterrâneo que pertence ao universo do jogo.

O trade-off é real: mais arte, conteúdo e implementação em troca de maior coerência entre navegação, narrativa e progressão. O hub completo pertence à visão de produto e será construído na fase de produção.

Adicionar profundidade sem perder o ritmo arcade

O produto inclui sistemas planejados de progressão e evolução de personagem. O desafio foi garantir que essas camadas não transformem um beat ‘em up em um RPG pesado ou excessivamente baseado em menus.

Os sistemas de progressão estão planejados e parcialmente definidos. A implementação completa faz parte da fase de Early Production.

Fácil de começar, difícil de dominar

Os personagens compartilham uma base de controles que qualquer jogador consegue aprender rapidamente. A profundidade surge do timing, do posicionamento, das combinações e das diferenças entre estilos de combate.

A base simples permite entrada imediata. Os sistemas mais avançados recompensam quem decide se aprofundar.

Validar o core antes de escalar conteúdo

Antes de produzir personagens, fases e inimigos em escala, precisávamos saber se movimentação e combate sustentavam a experiência.

A PoC foi usada para reduzir risco técnico e de gameplay antes de investir na produção de personagens, regiões, inimigos e campanha. A produção de conteúdo começa com as bases confirmadas.

Onde estamos e onde queremos chegar

Tudo na coluna de visão de produto está definido e planejado. Nenhum desses itens é apresentado aqui como entregue ou implementado.

Mapa de sistemas de produto

Esses sistemas foram pensados como partes de uma mesma experiência. Personagens influenciam combate. O combate alimenta progressão. Progressão e preparação passam pelo hub. Regiões organizam a campanha e a narrativa.

O mapa abaixo representa a visão completa de produto, não o estado atual de implementação.

Da decisão de produto à implementação

Meu papel não termina quando uma mecânica é definida no documento. Ela precisa virar comportamento de sistema que a equipe consiga discutir tecnicamente.

Isso aparece em decisões sobre animação, controles, câmera, estados do personagem, inimigos, HUD e integração entre sistemas. A implementação e as decisões de engenharia pertencem aos desenvolvedores. Minha responsabilidade está na intenção do produto, no comportamento esperado e na priorização.

Próxima fase

Com o core técnico confirmado, o foco agora é transformar essa base em um primeiro recorte completo da experiência.

O que está em andamento ou definido para essa fase:

• consolidação de arquitetura
• refinamento de combate
• sistemas de inimigos
• primeiro conteúdo completo
• refinamento de HUD
• início dos sistemas de progressão
• início dos sistemas de hub

Esses itens representam o caminho de Early Production, não promessas de entrega.

O que ainda precisa ser validado

Algumas hipóteses de produto ainda dependem de playtesting para serem confirmadas. Não são problemas identificados, são perguntas que só o jogo jogável consegue responder.

Quando o primeiro conteúdo completo estiver jogável, será possível avaliar a sensação do combate em sessões mais longas, o pacing geral, a dificuldade, a clareza dos objetivos e como fica a experiência do primeiro recorte completo.

À medida que os sistemas de personagens, progressão e hub entrarem no produto, outras perguntas vão surgir: a variedade entre personagens está legível no combate, a progressão adiciona profundidade sem tirar o foco da ação, o equilíbrio entre arcade e sistemas mais profundos está no lugar certo, e o hub cumpre sua função com clareza.

O que este projeto demonstra