Header Ads

Paladins Strike - Jogos como Serviço e QA


Olá, pessoal! Foi publicado um artigo no site oficial do Paladins Strike que explica um pouco da relação entre as duas equipes de desenvolvimento (Goblin Network e Hi-Rez Studios), entre os desenvolvedores e a comunidade, e como avaliam o feedback da comunidade e usam isto para melhorar o jogo.


"Olá a todos. Eu gostaria de compartilhar informações sobre como o Paladins Strike é desenvolvido, incluindo respostas a perguntas comuns sobre bugs e o processo de atualização. Isso irá permitir a vocês ficarem mais informados como jogadores sobre o nosso desenvolvimento do jogo, e ajudará a vocês entenderem como nós moldamos os jogos baseado em seu feedback.

Como você deve saber, Paladins Strike é um esforço colaborativo entre Goblin Network (situada na China) e Hi-Rez Studios (situada nos Estados Unidos, Reino Unido e China). Goblin é a desenvolvedora, o que significa que sua responsabilidade primária é o desenvolvimento do software. A Goblin cria o cliente do jogo que você usa e a tecnologia de suporte que implantamos em servidores por todo o mundo. Hi-Rez é a publicadora, o que significa que sua responsabilidade primária é operações em tempo real, distribuição e marketing. A Hi-Rez coloca o jogo na mão dos jogadores, faz a manutenção dos serviços do jogo e apoia a comunidade (incluindo eSports). Goblin e Hi-Rez trabalham juntas em design e prioridades.


Entender essa relação é a chave para uma visão completa de como nós criamos e mantemos Paladins Strike. Por exemplos, vamos assumir que a Ying (um personagem jogável) é considerada muito forte. Essa informação virá primeiro da comunidade, o que vai para a equipe da Hi-Rez. Então, a Hi-Rez irá avaliar a Ying e comparar suas informações com outros Campeões para ver se, de fato, ela está muito forte. Assim que confirmado, a Hi-Rez irá então entrar em contato com a Goblin e explicar que a Ying está com uma performance acima do esperado. A Goblin irá verificar, e então discutir com a Hi-Rez sobre as razões estimadas para sua alta performance.

Ela causa muito dano? Após alguns dias, os dados dizem que sim.
Por que ela está causando muito dano? 250 por ataque é provavelmente muito alto.
Mas e o fato de que os ataques dela atravessam paredes e escudos? Isso é um bug.
Ela continuará muito forte se nós só corrigirmos o bugs? Achamos que sim.
Deveríamos reduzir o dano dela ou realizar uma alteração diferente? Vamos reduzir o dano dela.

Eu fiz a conversa soar mais simplificada do que ela é. Como eu tenho certeza de que você pode ter relacionado, nem todo mundo concorda no balanceamento ou por que algo é forte/fraco entre os jogadores. Isso é verdade entre os desenvolvedores de jogos também. A conversa fica ainda mais interessante quando você considera barreiras culturais e de linguagem. Por exemplo, a maioria da equipe da Goblin fala apenas Mandarim enquanto a maioria da equipe da Hi-Rez fala apenas Inglês. Um benefício é que nós temos uma perspectiva diferente representada em cada discussão. Mas eu estaria mentindo se falasse que isso fez o processo ser mais rápido. Ah, e não se esqueça de que a Goblin e a Hi-Rez estão a 12-13 horas de diferença no fuso horário, o que significa que temos uma sobreposição limitada para discussões se algo leva mais do que um encontro para ser resolvido. Nada disso é um problema, mas isso significa que não podemos nos mover tão rápido como um time que está todo em uma única localização, falando a mesma língua, e com horários cotidianos semelhantes.


OK, vamos voltar ao nosso exemplo. Nós identificamos que a Ying está OP por causa de um bug e de seu dano da arma. O próximo a se fazer é avaliar se a Ying pode ser corrigida sem exportar uma nova compilação (fala de desenvolvedores para uma atualização que você baixa na App Store ou Google Play Store). Uma nova versão irá significar que precisamos passar certificação, o que pode levar 24-48 horas. Contudo, uma alternativa a uma nova compilação é um processo chamado Hotfixing. Quando nós lançamos um Hotfix, nós fazemos modificações simples em dados do jogo que não requerem uma nova compilação. Você não pode resolver todos os problemas com um hotfix, mas às vezes é uma boa solução para balanceamento ou outros erros de configuração.

Para a Ying, Goblin identifica que a correção certa precisará de uma atualização na arte dela (o efeito visual do ataque não entende como não penetrar) e na configuração da arma (reduzir o valor do dano no ataque). Por termos lançado-a rapidamente, a configuração da arma é feita em código (um grande "não", já que isso nos impede de fazer hotfix). Nesse ponto, temos duas opções. A primeira opção é atrasar a próxima atualização com conteúdo, funcionalidades e correções de bugs, a fim de exportar uma nova compilação que corrija a Ying. A segunda opção é deixar a Ying de lado e deixá-la continuar na sua glória OP até a próxima atualização programada. Nós escolhemos a segunda opção. Mas por quê?

A resposta curta é que nós acreditamos que a comunidade se beneficiaria mais com a próxima atualização sendo lançada a tempo do que ajustes em um Campeão, o que atrasaria a próxima atualização que continha correções a muitos outros problemas. Agora, eu sei o que você está pensando. 'Espere um pouco, Lionheart, por que você não criou uma atualização que corrige a Ying e inclui quaisquer outras correções que já estavam prontas? Então, você poderia nos dar o resto depois e todos ficariam felizes, certo?' Infelizmente, não é assim que o desenvolvimento funciona. Uma explicação perfeita entraria em detalhes sobre desenvolvimento baseado em tronco, mas a resposta prática é que apressar uma compilação desse jeito iria provavelmente nos levar a mais problemas e iria fazer todos os serviços do jogo para o Paladins Strike caírem. Ninguém quer isso.

Certo, no lado da Ying, eu quero que você imagine o bug mais irritante que você teve que lidar hoje no Paladins Strike ou outro jogo. Imagine esse bug passando pelo mesmo processo. Provavelmente mais frequentemente do que não, o bug pode parecer simples para você e estranho que a equipe de desenvolvimento não corrigiu ele ainda. Mas problemas simples de se entender não necessariamente significam soluções simples de implementar.


Legal, então como esses bugs irritantes aparecem no Paladins Strike pra começar? Em primeiro lugar, nós somos humanos (como você... provavelmente... beep boop). Isso significa que às vezes nós cometemos erros simples que levam a problemas. Um pequeno erro de digitação no código. Esquecer de marcar uma caixa. Você ficaria surpreso em como errinhos pequenininhos podem causar grandes problemas. Eu coloco isso na categoria de dores crescentes para qualquer equipe que está começando a trabalhar junta pela primeira vez. Conforme criamos checklists, documentação e processos, nós também aprendemos com nossos erros e melhoramos. Quando você se importa com um projeto como nós fazemos com Paladins Strike, eu prometo que a pessoa que cometeu o erro está muito mais dura consigo mesma do que você está xingando nas mídias sociais, email, etc. Por favor tente se lembrar disso da próxima vez que algo não for da sua preferência.

Outra forma que bugs entram no Paladins Strike é por restrições de recurso e escalabilidade. Mesmo com uma equipe dedicada de QA, nós não podemos antecipar todas as formas com que você interage com o cliente do jogo. Nós também não podemos testar sob todas as condições de rede que você irá jogar, ou em todos os dispositivos que você pode ter (existem MUITOS telefones por aí). A Goblin é um novo negócio com menos de 50 funcionários. O time de publicação da Hi-Rez para o Paladins Strike são 4 funcionários, e alguns de nós estamos trabalhando em múltiplos projetos. Isso significa que nossos recursos de QA são de alguma forma limitados, pelo bem ou pelo mal, e nós temos que enfrentar nossas batalhas ao testar. Enquanto irrealista da visão de consumidor, existem muitos sistemas que funcionam bem e são geralmente esquecidos atrás do muro de problemas que precisam ser corrigidos. E estes sistemas que funcionam bem são o resultado de um desenvolvimento positivo e processo de QA.

Por último, existem alguns "bugs" que são na verdade desenvolvimento incompleto. Um exemplo disso é o problema associado a compensação de perda de dados. Não existe necessariamente um mau-funcionamento com o Paladins Strike, mas ao invés disso melhorias são necessárias para alcançar nossos objetivos com o jogo. Você pode pensar em um carro que tem 300 cavalos de potência. Não há nada de errado com isso, mas ele provavelmente não irá vencer uma corrida contra outros carros com 600 cavalos com o mesmo peso e aerodinâmica. Dessa forma, você precisará de mais cavalos de potência antes que possa vencer a corrida. Já que você não pode comprar um motor novo, você realiza melhorias no motor que você tem através do tempo. Sabemos que os outros jogos estão rodando em motores com 600 cavalos de potência, e temos planos para melhorar o nosso motor do Paladins Strike para 1000 cavalos. Mas irá levar algum tempo para completar as melhorias.


Espero que essas sejam informações úteis para alguns membros da nossa comunidade que estão curiosos sobre o processo que usamos com o Paladins Strike. Como sempre, se você tem perguntas sinta-se livre para falar comigo no Twitter. Obrigado pela leitura!

Lionheart"

O que acharam dessas informações? Conseguiram entender o processo de correção de bugs e atualizações do Paladins Strike? Ou gostariam de tirar alguma dúvida sobre esse processo? Comente sua opinião!

- Mephistia