Ciclo de vida de um problema no FIFA - Parte 3

7 de dezembro de 2020

Esta série detalha as fases que um problema no FIFA 21 normalmente atravessa antes de ser corrigido.

Olá, fãs do FIFA.

Meu nome é Joel Doonan, e sou o Chefe de Produção na equipe de Operações com Foco no Jogador, parte da equipe FIFA Ao Vivo.

Esta é a terceira parte de uma série de artigos do Bate-bola focados em analisar detalhadamente o ciclo de vida do problema médio no FIFA 21.

Nesta série, eu cubro os vários passos que um problema geralmente atravessa para ser resolvido e lançado na versão ao vivo do FIFA 21. 

Esta série de 4 partes cobre:

• Parte 1 - Identificação
• Parte 2 - Investigação
• Parte 3 - Resolução (este artigo)
• Parte 4 - Lançamento

Para este artigo, vamos analisar a fase de Resolução do ciclo de vida, que, dependendo do problema, pode ter várias etapas diferentes que precisam ocorrer antes que uma correção ou alteração esteja pronta para ser lançada.

Uma observação antes de começarmos: às vezes, vou usar alguns termos técnicos, mas, quando eu usar um termo que pode não ser claro para aqueles que não estão familiarizados com o desenvolvimento de jogos, haverá uma nota de rodapé para explicar o que significa o termo. Então, vamos começar e analisar como os problemas são resolvidos.

Fazendo alterações

Se chegamos à fase de Resolução do ciclo de vida do problema, isso significa que acreditamos que entendemos a causa-raiz¹ do problema e que estamos prontos para começar a fazer uma alteração em um esforço para resolvê-lo.

Dependendo da causa-raiz e da natureza do problema, a complexidade de fazer essa mudança pode variar drasticamente.

Fazer uma alteração para resolver um problema funcional básico², em que algo não funcionando como esperado de forma óbvia e clara, pode ser razoavelmente simples quando a causa-raiz do problema for identificada. Bem, pelo menos para pessoas com anos de experiência em codificação, é claro.

Identificar a alteração apropriada para resolver um problema mais complexo pode ser muito desafiador, exigindo, às vezes, modificações ou adições às principais tecnologias em que todo o jogo pode estar sendo executado – ou potencialmente alterando vários sistemas que são de propriedade de diferentes equipes.

Se o problema e o design pretendido de sua resolução não forem claros e óbvios, como algo que requer mudanças para ajuste ou equilíbrio, isso também pode ser muito complexo, especialmente quando você precisa garantir que qualquer mudança que você fizer não criará novos problemas em outros lugares.

Considerando o que foi mencionado anteriormente, a amplitude da capacidade potencial necessária para fazer uma alteração é grande. Ela pode ser de algumas horas do tempo de um único Engenheiro de Software (Software Engineer, SE)³ para algo relativamente simples até exigir uma equipe de ataque⁴ de SEs sênior trabalhando por semanas ou meses para identificar uma mudança segura em alguns dos problemas mais complexos.

Independentemente da complexidade da mudança que estão fazendo, durante esse tempo em que os SEs estão trabalhando para fazer a alteração, eles geralmente fazem isso em uma compilação local⁵, uma versão exclusiva do jogo que contém o jogo e qualquer trabalho que está sendo feito para essa mudança. Isso garante que nada entre na compilação principal⁶ do código do cliente⁷ ou do servidor ⁸ até que tenha sido aprovado para verificação, que vamos cobrir em breve.

Após a alteração ter sido feita na compilação do cliente ou servidor local, os SEs trabalharão com Analistas de Verificação de Qualidade integrados⁹ para fazer testes em comparação com a alteração, tanto para confirmar se ela resolve o problema que estava sendo visto quanto para garantir que ela não tenha causado novos erros óbvios, que chamamos de knock-ons¹⁰.

Aqui, dependendo da natureza da alteração, pode haver várias etapas adicionais antes de ser finalizada e continuar para as próximas etapas da fase de Resolução.

Como exemplo de uma dessas possíveis etapas adicionais, se a alteração resultar na realização de novas chamadas de servidor¹¹ em alterações em chamadas de servidor existentes, pode ser necessário executar a alteração no teste de carga¹², onde temos uma configuração do ambiente de servidor exclusivo para simular o que acontece nos servidores quando o jogador estiver jogando o jogo. Esses testes são executados para garantir que a alteração não resulte em problemas de estabilidade devido à possibilidade de maior carga nos servidores ou que cause problemas com a forma como os servidores processam todas as solicitações de jogadores.

Outro exemplo é um passo dado pela equipe de jogabilidade, que tem um conjunto exclusivo de testes que são usados como um "Desafio", que executam suas mudanças para garantir que elas estejam conseguindo o resultado pretendido e não causem problemas em outros sistemas de jogabilidade.

Com todas essas etapas adicionais, pretende-se ganhar o máximo de confiança possível para que a alteração que estamos fazendo corrija o problema que estamos tentando resolver, que ela não apresente knock-ons e e que nos preparemos para uma etapa essencial no ciclo de vida de um problema: verificar a mudança no jogo em preparação para um eventual lançamento do ambiente ao vivo¹³.

Verificação/Revisões do código

Quando o SE considera que tem uma mudança segura pronta, e já passou pelo número de etapas de confiança e verificação necessário, ele está pronto para dar um passo essencial na preparação dessa alteração para eventual lançamento, que é verificar¹⁴ a mudança na compilação principal.

Antes de poder fazer isso, uma revisão da alteração ocorrerá a partir de uma liderança técnica para garantir que eles estejam alinhados com a alteração feita e os resultados dos testes. Às vezes, essa revisão acontece muito mais cedo no processo, mas precisa ocorrer antes da verificação.

Quando a revisão for concluída, a alteração poderá ser verificada na compilação principal, seja ela a compilação principal do código do cliente ou as compilações principais de vários sistemas de servidores. Após a verificação na compilação principal, agora ela é "parte do jogo" internamente, estando pronta para a fase final no ciclo de vida de um problema, a fase de Lançamento, que cobriremos no próximo (e último) artigo desta série.

Obrigado por reservarem um tempo para ler este artigo, e espero que esta série forneça maiores insights sobre o que acontece na resolução dos problemas que vocês podem ter visto ao jogar um videogame.

Joel Doonan e a Equipe FIFA Live

Notas de rodapé

¹: a causa-raiz de um problema é o principal motivo pelo qual o problema está acontecendo, algo identificado durante a fase de Investigação, conforme detalhado no artigo anterior.

²: quando falamos sobre um problema funcional, geralmente estamos falando de um problema que afeta a capacidade de algo funcionar de maneira clara e óbvia como pretendida. Por exemplo, se você tivesse a opção de escolher a cor de uma seta e escolhesse o azul, mas a seta ficasse vermelha, isso seria um exemplo de que o seletor de cores claramente não estava funcionando como pretendido. Coisas como problemas de equilíbrio/ajustes ou feedback qualitativo não são exemplos de problemas funcionais, pois esses geralmente são questões de opinião ou situações em que o problema está relacionado a funcionalidades que não têm uma forma clara e óbvia de funcionar o tempo todo. Por exemplo, uma situação em que o seletor de cores já mencionado tinha uma opção azul, mas o problema relatado é que o azul não foi "azul" o suficiente. Neste caso, quão azul o azul deve ser não é um algo claro e óbvio.

³: um engenheiro de software, ou SE, é alguém que escreve o código que faz o jogo funcionar. Há vários tipos diferentes de engenheiros de software, pois diferentes tipos de trabalho de codificação exigem habilidades diferentes. Por exemplo, fazer trabalhos de codificação para códigos de servidor é muito diferente do que fazer codificação para o jogo.

⁴: uma equipe de ataque, neste contexto, é um conjunto de indivíduos reunidos, geralmente por um período limitado de tempo, para tratar de um problema ou projeto específico. Isso normalmente envolve reunir especialistas de diferentes equipes nesse grupo menor para combinar seus conhecimentos e/ou habilidades. Geralmente, isso ocorre em situações em que o problema ou o projeto são difíceis ou complexos.

⁵: uma compilação local, do cliente⁷ ou servidor⁸, é uma versão interna do código de jogo usada para trabalhar em novas mudanças. É uma combinação do jogo normal, além de qualquer trabalho de codificação que foi realizado por um indivíduo ou grupo, geralmente focada em uma área específica. Isso é usado para fazer alguns testes e revisões iniciais de uma alteração antes dela ser levada à versão principal⁶ do jogo.

⁶: compilações principais são o lugar em que todas as porções de vários trabalhos individuais de codificação e desenvolvimento acabam depois da verificação e, por fim, de onde vêm as versões finais do código do cliente e do servidor para o jogo. Se alguma coisa estiver em uma compilação principal quando um lançamento é criado, isso significa que ela geralmente fará parte desse lançamento por padrão.

⁷: o cliente é essencialmente o conjunto das informações que estão no disco ou, no caso de uma versão digital do jogo, o que você baixa em seu console ou PC antes de poder jogar o jogo.

⁸: quando alguma coisa está no lado do servidor, isso significa que ela não está no disco, mas, sim, em código ou informações que provêm de um servidor e são entregues por meio da sua conexão online a esse servidor. Há muitos tipos diferentes de informações de servidor e, no FIFA 21, há vários sistemas de servidores diferentes com os quais você se comunica, dependendo de qual parte do jogo está jogando.

⁹: um Analista de Verificação de Qualidade (QV) incorporado é alguém da nossa organização de verificação de qualidade que trabalha diretamente com Engenheiros de Software. Eles testam a funcionalidade de mudanças específicas e tentam identificar problemas com essas mudanças como parte do processo de desenvolvimento.

¹⁰: um knock-on é um problema que é criado por outra mudança, quase sempre algo que não seria intencional. Isso pode acontecer em situações em que fazer uma alteração em uma área afeta as funcionalidades de outra área, devido a algumas dependências ou código/tecnologia compartilhado.

¹¹: uma chamada de servidor é quando o cliente faz uma solicitação ao servidor, geralmente para receber novas informações ou para validar as informações existentes. Por exemplo, ao fazer login no FUT, há muitas chamadas de servidor que ocorrem para buscar todas as informações sobre seu Clube do FUT, como quais itens você possui, qual seu status nos vários modos de jogo do FUT e quais itens você listou no Mercado de Transferências do FUT.

¹²: o teste de carga é o ato de medir o desempenho e a estabilidade de um ambiente de servidor simulando as ações de muitas pessoas, todas de uma vez, como se estivessem jogando o jogo, realizando um monte de ações dentro do jogo e fazendo várias chamadas para os servidores. O objetivo é garantir que tudo funcione corretamente quando milhares, ou milhões, de jogadores estão jogando o jogo ao mesmo tempo.

¹³: o ambiente ao vivo, também conhecido como ambiente de produção ou de varejo, é onde os nossos jogadores podem jogar a versão atualizada do jogo. Também temos vários ambientes geralmente apenas internos, como nossos ambientes de teste, em que as versões de pré-lançamento do jogo são testadas antes de serem lançadas.

¹⁴: a verificação de uma alteração significa que você está comprometendo essa mudança em uma compilação. No contexto deste artigo, queremos dizer que ela está sendo verificada nas compilações principais para o cliente e servidor. Quando uma alteração for verificada, isso significa que ela está presente nessas compilações e, potencialmente, pode ser incluída em um lançamento futuro.

Para mais artigos detalhados escritos pela equipe de jogo, confira página Bate-bola.

Observação: este artigo descreve em termos gerais no que os times de desenvolvedores estão trabalhando. Estamos procurando melhorar constantemente a experiência no FIFA para todos. Por isso, este artigo poderá ficar desatualizado à medida que fizermos ajustes para manter o nosso jogo divertido para todos.

Fique por dentro de tudo sobre o FIFA curtindo nossa página no Facebook, seguindo o nosso Twitter oficial e Instagram, o twitter da nossa Equipe de Desenvolvimento @EAFIFADirect, o EA Sports FIFA Tracker e participando dos Fóruns FIFA oficiais . Inscreva-se para receber e-mails sobre o EA SPORTS FIFA e produtos, novidades, eventos e promoções da EA.