Saltar para o conteúdo
Iris Edge StudiosEstúdio de jogos independente

Iris Edge Studios/ Guias/Design

Design

Porque é que a palavra de amanhã não está no seu telemóvel

Um puzzle diário tem um problema de calendário que a maioria resolve mal, e que não é óbvio até alguém o apontar.

O erro que quase toda a gente comete

A forma natural de construir um jogo de palavras diário é enviar a lista de respostas dentro da aplicação e escolher a palavra do dia com uma função da data. É simples, funciona offline e não precisa de servidor nenhum. É também o momento em que entrega a cada jogador todas as respostas futuras.

Qualquer pessoa consegue abrir um pacote de aplicação. Assim que a lista e a função estão ambas no dispositivo, todo o calendário futuro fica legível, para sempre. Nenhuma ofuscação resolve isto, porque o dispositivo tem de conseguir calcular a resposta, o que significa que a resposta está lá.

A única solução real

Não enviar o calendário. O Pinteza pede a um pequeno servidor a palavra de um único dia, e o servidor recusa qualquer data posterior ao seu próprio relógio. Essa verificação de data é toda a fronteira de segurança; o resto é detalhe.

Confiar na data do cliente tornaria tudo isto teatro, porque adiantar o relógio do dispositivo é exatamente o ataque. Por isso a verificação corre no servidor, contra o relógio do servidor.

Dois pormenores fáceis de errar

Fusos horários. O jogo usa a data local do jogador, e a Nova Zelândia chega a um determinado dia cerca de treze horas antes da meia-noite UTC. Exigir uma data exata bloqueia toda a gente a leste de UTC durante parte do seu dia. A tolerância é hoje mais um, o que custa que o atacante mais dedicado veja a palavra de amanhã um pouco mais cedo, uma fuga muitíssimo menor do que todo o calendário futuro.

O passado é a outra metade da fronteira. Deixar as datas passadas abertas torna o limite futuro decorativo. Se o calendário de uma rotação é um array indexado pelo número do dia, quem possa pedir datas passadas arbitrárias consegue percorrer o array para trás, reconstruí-lo por ordem e calcular a partir dele todas as respostas futuras. Uns minutos de script. As respostas passadas serem «já públicas» é verdade uma a uma e falso em massa. O Pinteza permite três dias para trás, o suficiente para absorver desvios de relógio e um dispositivo atrasado um dia, e mais nada.

O incidente que ensinou o resto

As palavras vivem num armazenamento chave-valor na edge, carregado a partir do repositório do jogo. A certa altura foram removidas trinta e duas respostas por questões de conteúdo, o cliente foi reconstruído, e o carregamento nunca foi repetido. O servidor continuou a agendar as palavras removidas como diários futuros enquanto o script de verificação, que só lê o repositório, ia alegremente escrevendo PASS.

Voltar a carregar também não teria bastado. As respostas ficam em cache na edge durante uma semana, por isso as palavras antigas continuariam a ser servidas de qualquer maneira. A solução é uma constante DATA_VERSION que faz parte da chave de cache: bastar incrementá-la para retirar de circulação, de uma vez, todas as respostas em cache. Sem algo assim não há forma de invalidar sem uma limpeza manual.

O que custa

Um pedido por jogador por dia, em cache na edge porque a resposta depende apenas da data e da rotação. O modo diário precisa de ligação; todos os outros modos continuam a funcionar offline. É essa a troca, e para um jogo cuja premissa é que toda a gente joga a mesma palavra no mesmo dia, vale a pena.


Mais guias