RacketGO é um jogo hyper-casual para Android construído em Unity e C#. Em uma semana, o projeto chegou a um loop jogável, identidade própria, recorde persistente, conquistas, leaderboard e integração com Google Play Games. A lista de recursos pode fazer a entrega parecer uma história sobre velocidade. O aprendizado mais útil, porém, está na ordem em que as incertezas foram fechadas.
O prazo curto não permitia que todas as frentes crescessem ao mesmo tempo. Primeiro, o gesto precisava produzir uma resposta legível. Depois, essa resposta precisava sustentar repetição. Só então fazia sentido conectar competição, continuidade e serviços mobile ao que já funcionava.
A semana como restrição de produto
A proposta de RacketGO pode ser resumida em três batidas: um gesto, um ponto, mais uma partida. Isso funciona como uma fronteira de escopo. Cada decisão precisa ajudar o jogador a executar o gesto, entender a consequência ou encontrar um motivo para tentar novamente.
Em um projeto curto, escopo não é apenas quantidade de features. É também a distância entre uma ação e sua confirmação. Quanto mais telas, regras ou dependências existirem entre tocar a raquete e perceber o resultado, mais estados precisam ser implementados, comunicados e corrigidos.
RacketGO reduziu essa distância. O formato vertical mantém bola, raquete e placar no mesmo eixo de atenção. O tutorial original resume a instrução a “HOLD” e duas setas direcionais; a ação central não depende de uma combinação de comandos. O primeiro risco de produto, portanto, não era volume de conteúdo: era tornar causa e efeito imediatamente reconhecíveis.
Feche o menor loop verificável
O núcleo pode ser descrito como uma cadeia curta: input, contato, trajetória, pontuação e retorno. Cada elo resolve uma pergunta diferente:
- o input move a raquete de forma responsiva;
- o contato deixa clara a relação entre gesto e bola;
- a trajetória permite antecipar a próxima resposta;
- a pontuação registra o resultado da tentativa;
- o retorno recoloca o jogador diante da mesma decisão.
Se um desses elos falha, adicionar conteúdo apenas amplia um problema ainda aberto. Se todos funcionam juntos, já existe uma fatia vertical honesta: curta, mas completa o suficiente para ser repetida e avaliada.
O loop foi tratado como uma cadeia verificável, não como uma coleção de telas.
Essa diferença importa porque “pequeno” e “incompleto” não são sinônimos. Um protótipo pode ter poucos elementos e ainda fechar entrada, ação, resposta, resultado e recomeço. É esse fechamento que permite descobrir se a interação merece receber uma camada de produto.
Faça a leitura sobreviver à repetição
A primeira rebatida não basta. Em um loop de pontuação, a composição precisa continuar legível quando a bola muda de altura, a raquete se desloca e o placar acumula resultados.
Os frames preservados de RacketGO registram o primeiro, o quarto, o sexto e o oitavo ponto. Eles mostram a mesma hierarquia ao longo da sequência: a bola continua destacada sobre o campo azul, a raquete ocupa uma zona previsível e o HUD separa o recorde da pontuação atual. No vídeo original, essa composição acompanha nove pontos consecutivos e o retorno ao menu em menos de 14 segundos. A apresentação não compete com a mecânica; ela protege sua leitura.
Por isso, feedback não entrou como decoração ao final. Contraste, movimento e placar fazem parte do instrumento de teste. Antes de perguntar se o jogador quer repetir, o jogo precisa tornar visível o que ele acabou de fazer.
Metagame só depois do gesto
Um loop hyper-casual pode terminar em uma única tentativa descartável. RacketGO adicionou uma camada de continuidade, mas cada sistema responde a uma intenção que já nasce na partida:
- o par best/current transforma cada sessão em uma tentativa de superar o próprio recorde;
- as conquistas transformam eventos do loop em objetivos, da primeira partida a novos patamares de pontuação;
- o leaderboard transforma pontuação em comparação com outros jogadores;
- o Google Play Games conecta recordes e conquistas aos serviços da plataforma.
Essa sequência evita construir motivação ao redor de uma ação que ainda não se sustenta. Um leaderboard não corrige uma rebatida confusa. Uma conquista não torna a trajetória legível. Persistência não substitui feedback. O metagame ganha valor quando amplia uma razão para continuar que o loop já conseguiu criar.
O critério, então, não é “quantos sistemas cabem em sete dias?”, mas “qual é a próxima camada que fecha uma promessa já visível?”. Essa pergunta reduz retrabalho porque cada nova dependência entra sobre um estado que pode ser observado.
Leia a semana pelas cinco etapas
Os artefatos preservados não registram um diário preciso de cada dia da produção. Inventar esse cronograma criaria uma precisão que o projeto não documenta. A reconstrução mais honesta usa as cinco etapas como uma leitura das decisões, não como um calendário rígido. Em uma semana, elas se comprimem, se sobrepõem e retornam quando o teste pede:
- Idealização / Concept: resumir a promessa em um gesto, um ponto e mais uma partida;
- Protótipo / Playtest: fechar o menor loop jogável e repeti-lo;
- Validação: confirmar em jogo se gesto, trajetória, feedback e placar continuavam legíveis;
- Polish: refinar contraste, identidade e apresentação mobile;
- Ship: consolidar persistência, competição e serviços da plataforma em uma entrega Android completa.
Idealização, protótipo, validação, polish e ship tornam visível a ordem das decisões.
As etapas deixam as dependências explícitas. O placar depende de um ponto confiável; a progressão depende de um resultado persistente; a integração de plataforma depende de estados que possam ser reconciliados. Elas não formam uma linha reta: um teste pode devolver a produção ao protótipo antes que a build avance novamente. Trabalhar nessa ordem é mais importante do que atribuir artificialmente uma feature a cada dia.
PROCESSO 01—05 · Ver o fluxo completo — da ideia ao lançamento
O que uma semana realmente comprova
A entrega demonstra que um recorte mobile pode sair do gesto e chegar a uma experiência estruturada dentro de um prazo radicalmente curto. Também demonstra disciplina de escopo: uma interação principal, um quadro vertical reconhecível e sistemas de continuidade ligados à mesma promessa.
Uma semana, sozinha, não comprova retenção, escala, receita ou validação de mercado. Esses resultados exigiriam métricas e operação que não fazem parte deste case. A evidência aqui é outra: foi possível fechar um produto jogável sem confundir completude com volume.
Essa fronteira torna o case mais forte. Velocidade deixa de ser uma afirmação abstrata e passa a ser observável na relação entre prazo, escopo e estado final da build.
Velocidade é uma decisão de ordem
Antes de iniciar um protótipo mobile com prazo curto, vale responder:
- qual ação precisa ser compreendida sem explicação longa;
- qual cadeia mínima transforma input em resultado;
- qual feedback torna cada transição legível;
- qual estado precisa sobreviver à próxima tentativa;
- qual camada de continuidade dá sentido à repetição;
- o que pode ficar claramente fora desta entrega.
RacketGO não ensina a comprimir qualquer jogo em sete dias. Ele ensina algo mais útil: quando o prazo é pequeno, cada sistema precisa fechar a mesma promessa. A velocidade aparece quando a produção reduz incerteza na ordem certa — primeiro o gesto, depois o ponto, então mais uma partida.
