O jogo como máquina de estado: telas e eventos

Cada tela é um estado

Um jogo simples tem um punhado de telas bem distintas. Há o menu, onde você escolhe começar. Há a partida em andamento, o estado jogando, onde o personagem se move e os pontos sobem. Há a pausa, uma parada temporária. E há a tela de fim, com o placar final. Cada uma dessas é um estado, porque o jogo se comporta de um jeito diferente em cada uma. No menu, o toque na tela escolhe uma opção; em jogando, o mesmo toque move o personagem; na pausa, ele nem deveria mexer no jogo. É o estado atual que dá sentido à ação, exatamente como o estado atual dava sentido ao evento no semáforo.

As setas entre as telas são as transições, e cada uma tem um evento claro. Do menu, tocar em jogar leva ao estado jogando. De jogando, apertar pausa leva à pausa; perder toda a vida leva ao fim. Da pausa, tocar em continuar volta a jogando; tocar em sair volta ao menu. Do fim, tocar em jogar de novo recomeça. Desenhar esse mapa antes de programar responde perguntas que, sem ele, viram bug: dá para pausar no menu? Não, porque não há transição de pausa saindo do menu. O jogo pode terminar durante a pausa? Só se você criar essa transição de propósito.

Estado ou transição?

Uma confusão comum é misturar o que é estado com o que é transição. O estado é uma situação que dura: você fica na tela de pausa até fazer algo. A transição, ou o evento que a dispara, é instantânea: apertar pausa acontece num piscar de olhos e o efeito é mudar de estado. Uma pergunta ajuda a separar: isso é um lugar onde o jogo permanece, ou um acontecimento que muda de lugar? Menu, jogando, pausa e fim são lugares onde o jogo fica; tocar em jogar, apertar pausa, perder e continuar são acontecimentos que movem entre esses lugares. Estado é substantivo de situação; evento é verbo de ação.

Fazer essa distinção paga dividendos na hora de codar. Cada estado ganha um trecho que cuida do que desenhar e de quais eventos escutar naquela tela. Uma única variável, a tela atual, comanda tudo: o laço principal do jogo consulta essa variável para decidir o que atualizar e o que mostrar. Em jogando, ele move o personagem e escuta pausa e fim de vida. Na pausa, ele congela o mundo e só escuta continuar e sair. Sem a máquina de estado, esses cuidados viram um bolo de condições, e é assim que nascem bugs como o personagem que continua andando com o jogo pausado.

O modelo que organiza interfaces

Essa forma de pensar não é só para jogos; ela organiza qualquer interface com modos. Um aplicativo de banco tem a tela de login, o painel, a transferência, a confirmação. Um player de música alterna entre tocando, pausado e parado. Um formulário passa por vazio, preenchendo, enviando e enviado, com um estado de erro à espreita. Em todos, o segredo é o mesmo: liste as telas ou modos como estados, guarde qual é o atual numa variável e descreva as transições disparadas por eventos. O botão de enviar só deve funcionar no estado preenchendo e válido, nunca no estado enviando, e é a máquina de estado que garante isso com naturalidade.