A década passada produziu pesquisas substanciais para verificar o que não é de surpreender: os desenvolvedores querem se divertir. Embora também precisemos de nossos salários, os salários por si só não nos incentivarão a desenvolvedores que, na maioria dos casos, entraram em um campo para fazer o que amamos: envolver-se na solução de problemas. Nós gostamos de competição. Nós gostamos de ganhar. Gostamos de receber prêmios por ganhar. Para ser produtivo, precisamos de satisfação no trabalho. E a satisfação no trabalho só pode ser alcançada se nos divertirmos usando as habilidades que fomos contratados para usar.
Queríamos manter os desenvolvedores de back-end desafiados e entretidos, cuja idéia básica foi adaptada, um jogo de negociação.
O jogo da negociação:
Pechinchar consiste em rodadas de negociações entre pares de jogadores. O objetivo de cada par é maximizar a pontuação da seguinte maneira:
Digamos que há óculos de sol, dois ingressos e três xícaras na mesa. Ambos os jogadores precisam concordar em como dividir esses objetos entre eles. Por um lado, os óculos de sol podem valer $ 400, uma bola $ 20 e os ingressos não valem nada. O oponente pode valorizar os mesmos objetos de maneira diferente; enquanto o valor total de todos os objetos é o mesmo para os dois jogadores, a avaliação deles é mantida em segredo
Ambos os jogadores se revezam fazendo ofertas uns aos outros sobre como dividir as mercadorias. Uma divisão proposta deve distribuir todos os objetos entre parceiros, para que nenhum item seja deixado na tabela. Em cada turno, é possível aceitar uma oferta ou fazer uma contraproposta. Se, após 9 ofertas, for alcançado um acordo, todo jogador receberá a quantia que sua parte da mercadoria vale, de acordo com os valores atribuídos. Se ainda não houver acordo após o último turno, os dois jogadores não receberão pontos.
O Objeto do Jogo:
Escreva o código para obter uma coleção de itens com o maior valor negociando itens com um jogador adversário.
Experiência de usuário:
Queríamos que fosse o mais fácil possível para os jogadores enviarem, jogarem e testarem seu código.
Portanto, decidimos manter o código do jogador simples - sem depender de bibliotecas de terceiros.
Para fazer isso, criamos um aplicativo da Web simples para testar e enviar código, fornecendo a um espaço reservado o método “accept” - o código que precisa ser implementado pelos diferentes participantes. O método "aceitar" descreve uma iteração única dentro da negociação, na qual cada jogador deve decidir se aceitará a oferta que lhe foi dada (retornando a oferta nula ou recebida) - ou devolva uma contraproposta.
Para ajudar na verificação da estratégia dos jogadores, adicionamos um recurso de teste que permite que os jogadores executem seu código contra algum jogador aleatório. Os desenvolvedores puderam brincar com ele, reimplementando o código antes do envio real.
Exemplo de código Java:
Teste seu código e envie on-line:
Torneio e placar:
Os torneios de treinamento ocorreram continuamente por duas semanas, levando em consideração todos os jogadores submetidos e permitindo que os desenvolvedores vissem sua classificação. Durante esse período, os concorrentes puderam editar seu código. Portanto, havia muito tempo para aprender e melhorar.
Também fornecemos análises para todos os jogadores. Os desenvolvedores foram capazes de analisar e melhorar sua estratégia.
No final das duas semanas, declaramos um congelamento do código e o torneio real ocorreu. A pontuação final dos jogadores foi determinada apenas a partir dos resultados do torneio real, não dos torneios de treino.
Execução e pontuação do jogo:
Executamos o torneio usando vários agentes - cada um dos agentes foi denunciado a Kibana:
O Back-Stage:
Onde armazenamos o código dos jogadores?
Decidimos armazenar o código de todos os jogadores no S3 da AWS para evitar revelar o código a outros jogadores.
Quais idiomas foram suportados?
Começamos apenas com Java, mas os jogadores também demonstraram interesse em usar o Scala e o Kotlin. Por isso, demos liberdade a esses desenvolvedores para adicionar suporte a esses idiomas, que analisamos antes de integrar no código base. Por fim, os desenvolvedores puderam jogar nos três idiomas.
Qual era a escala de Haggling?
No torneio final, 91 jogadores competiram em 164 milhões de rodadas, nas quais 1,14 bilhão de "aceitos" foram convocados. O torneio foi executado em 45 servidores, com 360 núcleos e usando 225G de memória.
A maior vantagem de nossa abordagem foi nossa decisão de usar o Kubernetes, permitindo adicionar mais nós, além de ajustar seus núcleos e requisitos de memória. Desnecessário dizer que não havia problema em se livrar de todas essas máquinas quando o período do jogo terminasse
Como o torneio progrediu?
O torneio foi tenso e vimos muita interação com o jogo nas duas semanas.
O jogador na posição vencedora mudava todos os dias, e o vencedor final não era aparente até muito perto do fim (e mesmo assim ficamos surpresos!).
Vimos uma variedade de estratégias para um jogador com cálculos sofisticados e diferentes abordagens à jogabilidade.
Além disso, em contraste com o jogo original, permitimos gangues: grupos de jogadores pertencentes a um único time que podem “ajudar” um ao outro a vencer.
Então, como você ganha em pechinchar?
A estratégia vencedora foi colaborativa - a equipe vencedora criou dois tipos de jogadores: o "Overlord", que jogava para vencer, e vários "Minions", cujo trabalho era dar pontos ao Overlord e bloquear outros jogadores. O Overlord e os Minions se reconheceram usando um protocolo de handshake triplo, baseado em cálculos matemáticos dos parâmetros do jogo. Além disso, a equipe empregou uma estratégia psicológica humana - escondendo a força do Overlord, garantindo que, durante a maior parte do período de desenvolvimento, o Overlord não fosse superior ao terceiro lugar. Eles povoaram o jogo com “células adormecidas” - jogadores com estratégias básicas prontas para se transformar em lacaios no momento certo. A revolta ocorreu na hora final do jogo, quando todos os dormentes foram convertidos em lacaios.
O gráfico mostra o número de confirmações na última hora antes do congelamento do código:
Tirando o chapéu para o hacker: quem tirou o melhor de nós?
Durante as duas semanas, notamos várias tentativas de invasão. A intenção do hacker não era travar o jogo, mas provar que é possível e fazer uma lição dele.
Embora não fosse nossa intenção inicial, decidimos fazer do hacking parte do desafio e recompensar o hacker por habilidades e criatividade demonstradas.
Na manhã de 7 de novembro, chegamos ao escritório e fomos confrontados com o seguinte gráfico dos resultados:
O jogo foi hackeado! Como pode ser visto no gráfico, um jogador estava alcançando uma taxa de sucesso impossível. O que descobrimos foi o seguinte: o mapa de hash somente leitura que fornecemos como argumento do método para os jogadores foi escrito em Kotlin; mas, quando os jogadores converteram o mapa para jogar em Java ou Scala, a conversão resultante renderizou um mapa de hash mutável, e foi assim que um dos jogadores conseguiu modificar o mapa de hash. Falhamos na validação das preferências, garantindo que os valores de hashmap que os jogadores entregaram usassem os mesmos valores que o original.
Em conclusão, esse é exatamente o tipo de experiência em sandbox que nos torna desenvolvedores melhores, mais seguros e inteligentes. Nós abraçamos o desafio.
Quer jogar com a gente? Junte-se ao Avance Network e desafie-se.
