UnnyWorld: post-mortem

Após o encerramento do nosso jogo UnnyWorld, muitos desenvolvedores amigos pediram para escrever um post mortem no jogo . Decidi compartilhar exemplos específicos, dos quais uma quantidade decente se acumulou durante o período de desenvolvimento. Haverá erros considerados que cometemos, tentarei dar algumas dicas úteis.



Publiquei anteriormente um artigo “Três anos de desenvolvimento do meu MMO” , que tratava mais da busca por investimentos, da equipe e do nosso caminho para o “sucesso”. Infelizmente (ou felizmente?), O projeto teve que ser encerrado. Neste artigo, tentarei revisar os erros cometidos e, possivelmente, fornecer pelo menos algumas dicas úteis.

Em resumo, sobre o jogo

Convencionalmente, o Unnyworld pode ser dividido em duas partes: City builder e Arena.
A parte sobre o construtor é um certo Clash of Clans. Você tem seu próprio planeta, que precisa equipar. E você pode atacar outros planetas para roubar recursos.



Ataque outros jogadores, você é um dos seus personagens e você o controla.

Arenas - típico MOBA 3v3 com modos diferentes (captura de bandeira, captura de ponto, etc.).



Cada personagem tem seus próprios feitiços, que podem ser combinados com outros jogadores.


Antes da batalha, você pode mudar de feitiço.



O ciclo do jogo como um todo é assim:

1. Para feitiços de bombeamento, são necessários pergaminhos que caem dos baús. Os baús podem ser obtidos de várias maneiras gratuitas (para uma liga, para ganhar o Battle Royal, etc.) ou comprar.
2. Para bombear o feitiço, você precisa construir e melhorar a construção do herói para um determinado nível.
3. Para melhorar a construção do herói, é necessário melhorar outras construções (construção principal, altar, etc.).

Ou seja, tentamos de alguma forma reconciliar o regime do planeta e arenas. Provavelmente fizemos tudo errado.

Falta de um plano e estratégia claros

Sim, muitas coisas eram discutidas constantemente, mas as realizavam fora do lugar, sem analisar completamente o que precisa ser feito em primeiro lugar.

Como resultado, eles tentaram fazer tudo de uma vez. Você precisa de um sistema de guilda quando o jogo tem um usuário e meio? Humm, dificilmente.

Você precisa de um sistema que permita criar uma correspondência personalizada, convidando amigos e co-guilds para lá quando o jogo tiver uma pequena CCU? Não tenho certeza.

Durante o processo de desenvolvimento, tentamos muitas coisas para fazer algo que provavelmente não precisava ser feito naquele estágio. Como resultado, as coisas realmente necessárias não foram implementadas.

Falta de experiência

Porque Antes de trabalharmos principalmente apenas com jogos single-play, entramos em um grande número de rakes ao escolher uma ou outra tecnologia.

Vamos falar um pouco sobre a parte técnica da pergunta.

Seleção de tecnologia

Um pouco de esclarecimento. Na maioria das vezes, somos puramente desenvolvedores de clientes. De toda a equipe, apenas algumas pessoas tiveram experiência em trabalhar com tecnologias de servidor. Sobre a administração, geralmente fico quieto. Vou tentar passar por tecnologias específicas com um pequeno resumo para cada uma.

Qual provedor de nuvem usar? AWS? Azure? Camada macia

Naquela época, não havia diferença fundamental. Além disso, tivemos um empréstimo para o SoftLayer como uma startup.

Oh, boi, se você soubesse o quão ruim as coisas eram:

- O Saport não é particularmente versado no problema. Houve casos em que eu me virei para eles sobre um problema em uma determinada máquina virtual (não consegui conectar, etc.). Para o qual recebi a resposta:

Nós reiniciamos o carro, agora está tudo bem

- Houve casos em que a máquina virtual funcionou por horas . Como você pode ver, esperei 4 horas, mas a máquina virtual nunca foi criada.



- Manutenção frequente.



- Acontece que, sem aviso, um carro será reiniciado ou uma rede privada será cortada.

Como resultado, eles mudaram para o Azure. Não houve tais problemas. O suporte responde rapidamente e sempre ajuda se algo acontecer.

Bom: -

Ruim: eles não analisaram adequadamente todas as opções possíveis. Mas o servidor é a parte mais importante para um jogo online = /

Portanto, você precisa iniciar de alguma forma as instâncias do jogo no servidor, lançá-lo através de um sistema de API após autorizar o jogador à instância desejada. O que vamos fazer? E vamos dar uma solução pronta para uso que gerenciará esse negócio, dependendo da carga. Uau, existe uma coisa chamada Kubernetes. É verdade que ela está na versão beta ... Mas de qualquer forma, vamos tentar!

Se descartarmos o fato de que você precisa de experiência para trabalhar com essa tecnologia, mesmo com a configuração básica desse negócio, ela poderá cair. Alguns serviços caíram, etc.

Bem, o que mais há? Mesosfera e Apache Mesos! Tudo é o mesmo com ele, é difícil sem experiência. Se algo cair, sem um pandeiro você não poderá resolver o problema.

Como resultado, eles escreveram tudo eles mesmos. As instâncias começam com o supervisor, assim como o pequeno gerente acima delas (escrito em Java). O aplicativo Java permite o serviço de descoberta de status (o número de salas livres nas instâncias etc.). Ao autorizar e solicitar a criação de uma sala para a API usando essas informações sobre instâncias, a solicitação vai para o nó direito, que aumenta a sala na instância correta.

I.e. instâncias são sempre pré-executadas. Com a escassez, estamos aumentando um novo VPS.

Bom: analisou as alternativas.

Ruim: passou muito tempo no protótipo. Para a primeira versão, você não precisava pensar nessas coisas, mas simplesmente iniciou as instâncias sem queixas. Foi possível codificar diretamente diretamente os endereços da instância no cliente no protótipo.

Usamos o www.consul.io para o serviço de descoberta, provavelmente uma dessas soluções das quais não lamentamos. É verdade que existem problemas como estes quando a configuração é interrompida durante a reinicialização. Mas isso é raro e com uma reinicialização não planejada do carro. Em geral, durante todo o tempo foi um prazer trabalhar com o cônsul.

Bom: eles criaram uma solução pronta, mas não começaram a enxergar algo.

Para implantação, os scripts bash foram originalmente usados.


Mais tarde, transferi toda a implantação para a Ansible. Eu não consigo o suficiente até hoje. Obviamente, houve problemas a princípio. Mas o sistema é bastante simples de aprender e a documentação em massa.

Bom: escreva rapidamente um script bash, não é necessário nenhum conhecimento especial.

Ruim: ao mudar para um sistema de implantação normal, tive que jogar fora quase tudo o que havia sido escrito anteriormente.

Para comunicação entre seus serviços, tentamos www.rabbitmq.com . Mas ele está tão fora de tópico em alguns dias que pode desmoronar. Como resultado, eles fizeram isso de uma maneira simples - todos os serviços interagem através de soquetes tcp puros ou solicitações http com keep-alive, se você precisar enviar solicitações apenas em uma direção.

Bom: analisou as alternativas. Nós escolhemos uma boa solução.

Ruim: falta de experiência com a tecnologia. Não há necessidade de arrastar coisas para a produção que você não pode corrigir em caso de problemas.

Jogar online significa que você precisa de uma sala de bate-papo. Escreva você mesmo? É improvável que seja escalável. Vamos pegar algo pronto. XMPP? Ejabberd? Parece bom. Em geral, tentamos o ouriço e o MongooseIM, mas finalmente decidimos por um ouriço. Houve alguns problemas em aumentá-lo em seus servidores (batentes com horários em mensagens, falhas, etc.). Decidimos usar a solução em nuvem ejabberd-saas.com . Sim, é pago. Mas funcionou sem problemas.

Bom: analisou as alternativas. Escolha a opção apropriada.

Ruim: em vez de resolver problemas locais, decidimos usar uma solução de nuvem paga. Taxas lá de 200 euros. Tivemos várias regiões de jogos. Para uma equipe independente, isso vem em uma quantia muito substancial, que seria melhor usada em outras coisas.

Inicialmente, geralmente não tínhamos nenhum sistema para coletar métricas em servidores. Por que a solicitação fica mais lenta? O que há de errado com o serviço? Quantos quartos estão disponíveis agora? Sim, não conseguimos ver quantos quartos estão disponíveis no momento!

Mais tarde veio a percepção de que algo precisa ser feito. Tentei usar Graphite + Grafana. Até a imagem pré-docker fez tudo isso: github.com/Suvitruf/docker-grafana-graphite-diamond

Mas não deu certo. Eu não queria gastar tempo com isso, decidimos usar algo pronto. A escolha caiu em www.datadoghq.com

Tudo está ótimo. Medidores, alertas, gráficos. O driver do cliente é quase o mesmo que para grafite. Beleza Mas ... 10 + $ para cada host por mês. III ... sai em 200 + $ por mês.

A constatação de que gastamos muito dinheiro com isso era tarde demais. Decidimos, no entanto, fazer isso em nossos servidores. Configure www.influxdata.com . Como resultado, um carro por algumas dúzias de dólares processa silenciosamente as métricas de dezenas / centenas de carros.

Bom: tentamos rapidamente. Encontrou uma alternativa pronta. Eles perceberam (embora tarde) que a decisão estava errada. Configure um sistema conveniente localmente.

Ruim: não entendi corretamente o problema. Gastou muito dinheiro.

Em relação às métricas, o mesmo problema com o desempenho. Inicialmente, não somos especialmente um cliente nem um servidor em perfis. Como resultado, vazamentos de memória nas instâncias do servidor do jogo foram descobertos tarde demais. Eles não puderam determinar e reparar imediatamente. Como resultado, eles escreveram para que, após criar um certo número de salas, a instância do jogo reinicie.

Um pouco sobre soluções conceituais e de DG

Agora não consigo criar a ordem correta a tempo para todos esses eventos, vou citar algumas das principais decisões que tomamos.

Divisão do jogo por região

Os jogadores solicitaram um servidor asiático e um servidor na América do Sul (antes desse servidor estar na Europa e nos EUA). Por que não faz isso, hein? Eles fizeram isso. Como resultado, um usuário e meio se espalhou por 4 regiões. Uma vez que várias regiões, você precisa fazer um sistema de transferência. Isso é lógico? É lógico.

Bom: algumas pessoas melhoraram o ping (｡ • ́︿ • ̀｡)

Ruim: muito tempo gasto na criação de regiões, sistemas de transferência etc.

É necessário ouvir as sugestões / sugestões dos jogadores, mas você não deve fugir imediatamente e perceber tudo isso.

Substituindo uma grade quadrada por hexágonos e refazendo ataques a planetas

Anteriormente, os planetas eram assim:



E os ataques:



Mudar para hexágonos simplificou muitas coisas tecnicamente. Além disso, parecia muito melhor, é mais fácil trabalhar com elementos do jogo.

Sistema de feitiço reformulado

Costumava ficar assim:



A atualização em si foi realizada para pedras que caíam dos baús. Tudo não era óbvio, confuso.

Como resultado, eles substituíram o sistema de pedras por pergaminhos, como no Clash Royale.



Para melhorar o feitiço, você precisa de um certo número de pergaminhos. Tudo é simples e claro.

Bom: eles perceberam um local problemático e o refizeram.

Ruim: inicialmente eles não analisaram como os jogadores o perceberiam. Muitas coisas que são óbvias para os desenvolvedores, os jogadores percebem de uma maneira completamente diferente. Portanto, o feedback deve ser coletado o mais cedo possível, organizar testes, etc.

Compras no Twitch

Chegamos a um acordo com www.twitch.tv para fazer compras no jogo na página do jogo.



Mas desde ninguém transmitiu nosso jogo, então o significado dessa decisão é geralmente zero.

Bom: um local em potencial para a retirada de dinheiro justo dos jogadores.

Ruim: se o seu jogo não for transmitido, então não faz sentido. Apenas perdi tempo.

Modo Battle Royale

Na sequência do hype, eles decidiram cortar esse regime no jogo. Mas desde Havia pouco online no jogo; nesse modo, havia quase apenas bots, o que elimina tudo.

Sobre bugs

Nesse projeto, é difícil não cometer bugs. Havia muitos bugs da GUI relativamente inofensivos.



Havia erros mais sérios, por exemplo, quando jogadores morriam instantaneamente no centro da arena. Não foi possível tentar novamente este bug localmente. Ocasionalmente ocorria com os jogadores, mas não conseguimos consertá-lo.

Um bug engraçado quando, ao mudar de personagem, o modelo do anterior não foi excluído. Como resultado, foi possível organizar uma festa difícil.



Também houve bugs relacionados à plataforma / mecanismo.

Por exemplo, às vezes a GUI inteira pode simplesmente desaparecer. Mas se você entrar na hierarquia de objetos e simplesmente clicar no objeto, ele aparecerá novamente.


Nós relatamos sobre esse problema Unity. Eles responderam que poderiam nos dar um funcionário para ajudar por US $ 10 mil por mês ლ (ಠ_ಠ ლ)

Na plataforma do Facebook, a Gameroom teve um problema com o dimensionamento quando o jogo reagiu ao taquímetro no lugar errado.



Isso, para não mencionar erros em várias bibliotecas. Por exemplo, em algumas máquinas Steamworks.NET, o github.com/rlabrecque/Steamworks.NET/issues/121 pode falhar .

Sumário

Quase não investimos em marketing, esperávamos que houvesse um fluxo orgânico de jogadores. O jogo, como resultado, não atingiu essa massa crítica, após o que os robôs não seriam necessários e haveria um fluxo orgânico de novos jogadores.

Especialmente ninguém estava envolvido no gerenciamento de conteúdo e comunicação com os jogadores, não havia boletins.

Durante o desenvolvimento, muito tempo foi perdido na seleção e teste de várias tecnologias.

Não havia um plano claro para a implementação de recursos / conteúdo.

Em geral, a maioria de todos esses problemas se deve à inexperiência.

O que vem a seguir?

Unnyworld foi fechado. Decidimos diminuir o projeto no quadro das oportunidades atuais.

Um artigo não cobre tudo. E o que eu escrevi sobre, para alguém de fora, pode parecer um conjunto incoerente de fatos. Infelizmente, não é um especialista escrever esses textos.

Se você tiver alguma dúvida, terei prazer em responder nos comentários ou em um novo artigo.