Reutilização não significa escrever um sistema genérico antes de conhecer o problema. Significa preservar uma decisão de gameplay enquanto controles, conteúdo, apresentação e plataforma mudam ao redor dela.
Os projetos do portfólio cobrem microfone, touch, teclado, gamepad, multiplayer local, serviços conectados, mobile e PC. A tecnologia varia, mas os sistemas que sobrevivem compartilham um princípio: a regra central não depende de uma única forma de entrada nem de uma única tela para existir.
Separe intenção de dispositivo
O input bruto responde “qual botão, gesto ou frequência apareceu?”. O gameplay responde “qual intenção o jogador expressou?”. Misturar as duas perguntas faz cada nova plataforma contaminar regras que já funcionavam.
Em Radgear, swipes curtos mudam a trajetória do patinador. Em Resonance: The Lost Score, faixas de pitch quebram, movem e transformam obstáculos enquanto teclado ou gamepad continuam responsáveis pela movimentação. São interfaces incomuns, mas ambas se beneficiam da mesma fronteira conceitual:
- capturar e normalizar o sinal;
- convertê-lo em uma intenção estável;
- validar a intenção contra o estado do jogo;
- executar a consequência;
- publicar feedback para jogador e ferramentas.
Essa sequência permite calibrar sensibilidade, trocar dispositivo ou bloquear uma ação sem espalhar condições por animação, UI e regra de partida.
Faça do estado a fonte da verdade
Quando várias telas ou jogadores precisam concordar sobre uma partida, a apresentação não pode ser dona da regra. Ela observa um estado, comunica possibilidades e solicita transições.
Em SLEIGHT, dois papéis assimétricos leem a mesma mansão de maneiras opostas. Multidão, alarmes, pegadas, foco e cooldowns mudam o que cada jogador pode esconder ou confirmar. O sistema permanece compreensível porque essas ferramentas participam da mesma rodada — tempo, papéis e consequências — em vez de operarem como efeitos visuais isolados.
Em produtos conectados, essa fronteira ganha ainda mais importância. CryptoFights combinou combate, matchmaking, inventário e serviços externos; DATA2073 conecta batalha, coleção, tutorial, recompensas, eventos e transações. Quanto mais superfícies existem, maior o custo de deixar cada tela reconstruir sua própria versão do estado.
Trate feedback como parte da API
Um sistema de gameplay não termina quando altera um valor. Ele termina quando outros participantes conseguem reagir à mudança sem conhecer sua implementação interna.
Uma transição importante deveria expor informação suficiente para:
- a apresentação escolher animação, áudio ou câmera;
- a interface explicar disponibilidade e bloqueio;
- ferramentas registrarem sequência e contexto;
- rede ou persistência serializarem apenas o necessário;
- testes manuais reproduzirem a condição.
Isso não exige um evento para cada linha de código. Exige contratos claros nos pontos que têm significado para a experiência: rodada iniciada, objetivo concluído, ação negada, inventário atualizado, sessão interrompida.
Dados devem representar decisões ajustáveis
Mover números para um arquivo não torna um sistema orientado a dados. O ganho aparece quando designers e desenvolvedores conseguem alterar comportamento previsto sem modificar a estrutura da regra.
Velocidade, duração, custo, faixa de pitch, cooldown e composição de conteúdo são bons candidatos quando variam entre personagens, níveis ou plataformas. Referências de cena, dependências de serviço e fluxo de controle normalmente pedem fronteiras mais explícitas.
Uma pergunta útil é: “esta mudança representa balanceamento/conteúdo ou muda a natureza do sistema?”. A primeira tende a ser dado. A segunda merece código e revisão arquitetural.
Planeje falhas como estados válidos
Mobile perde foco. Um controle desconecta. O microfone recebe ruído. Um serviço demora. Uma sessão multiplayer encerra. Se o sistema só conhece o caminho ideal, a plataforma vira uma coleção de exceções.
Trate indisponibilidade, espera, reconexão, cancelamento e retomada como estados nomeados. A UI pode então explicar o que aconteceu, o gameplay pode preservar o que ainda é válido e ferramentas podem distinguir erro real de interrupção esperada.
Essa disciplina também reduz acoplamento: recuperação deixa de ser uma reação improvisada em cada tela e passa a fazer parte do ciclo de vida do sistema.
Extraia depois da segunda variação
Antes da primeira implementação, uma abstração descreve uma hipótese. Depois da segunda variação real, ela pode descrever uma diferença comprovada.
Ao adaptar um sistema, observe o que permaneceu igual e o que precisou mudar. Extraia a fronteira estável; mantenha a variação próxima do contexto que a exige. Reutilização saudável não elimina particularidades — oferece um lugar explícito para elas.
O teste final é simples: uma nova plataforma ou regra deve exigir uma nova implementação de borda, não uma sequência de condicionais dentro do núcleo. Quando isso acontece, o sistema continua específico o suficiente para o jogo e flexível o suficiente para a produção.
