Como comparar propostas de jogo personalizado quando ninguém publica preço

Uma proposta de jogo personalizado é a descrição de um sistema, e o número no rodapé está atrelado ao escopo desse sistema. Dois estúdios que orçam o que parece ser o mesmo slot podem estar orçando dois sistemas diferentes, porque os mercados em que o jogo será vendido definem quais componentes, quais relatórios e quais evidências o build precisa carregar.

É por isso que o preço é a primeira coisa errada a comparar, e por que o jogo é a unidade errada. Este artigo apresenta a unidade que de fato é comparável — um sistema certificado por mercado — e as cinco linhas que transformam uma pilha de propostas em uma grade em que a diferença de preço tem nome.

Ninguém publica preço, e esse não é o obstáculo

Nenhum estúdio independente neste mercado publica preço de pacote para um jogo sob encomenda, e esta publicação também não o faz. Um número citado sem base de escopo não é informação; é uma posição inicial em uma negociação que o comprador não consegue avaliar.

A ausência de uma tabela de preços, portanto, não é o problema. O problema é que as propostas são escritas em unidades diferentes. Uma descreve entregáveis, uma descreve fases, uma descreve uma equipe e uma descreve uma mensalidade com uma estimativa de lançamento anexada. Coloque-as lado a lado e o único campo com o mesmo significado nas quatro é o total.

A solução é mecânica: escolha uma unidade, force toda proposta a caber nela e precifique a diferença.

O que a Espanha de fato certifica

O dossiê de homologação espanhol é a declaração publicada mais clara de qual é a unidade de certificação, porque é um documento de inventário e não uma análise de um jogo.

O Anexo III da resolução da DGOJ estabelece uma estrutura de nove seções para o relatório de certificação de funcionalidade definitiva: identificação da certificação, descrição do objeto de certificação, resumo executivo, conformidade em relação a cada requisito técnico, análises específicas, testes de integração, local, equipamentos e datas do trabalho, qualquer ambiente de teste diferente do ambiente de produção do operador e o suporte digital que acompanha o relatório.

A segunda seção é a que muda uma conversa comercial. O objeto de certificação precisa identificar os elementos de software usados no sistema com o fabricante, o nome do produto e a versão de cada um, listar os componentes qualificados como críticos junto com suas impressões digitais, nomear os data centers e listar os canais de acesso certificados. Para uma licença singular, é preciso também nomear os sites certificados e os nomes comerciais, o papel do operador, a oferta de jogos certificada com suas variantes e as tecnologias de acesso.

Nenhum parágrafo dessa lista diz “o jogo”. Diz o sistema, com o jogo dentro dele como um elemento versionado. Um cliente espanhol não está comprando um slot; está comprando um slot que aparece em um inventário aprovado com uma impressão digital, ao lado de um capturador e de um store pertencentes ao sistema de controle interno do operador, que o estúdio não possui.

O sequenciamento agrava isso. A homologação ocorre em duas etapas: um controle prévio documental com relatório preliminar e, depois, concedida a licença, relatórios de certificação definitiva sobre o sistema técnico efetivamente em uso, protocolados em até quatro meses a contar da notificação da concessão — prazo que a resolução classifica como não prorrogável. Uma proposta que precifica um build mas não a produção dessa evidência de segunda etapa está precificando um sistema que não pode ser homologado.

O guia de inventário de componentes percorre toda a estrutura do Anexo III, incluindo os campos da análise de RNG.

Onde você está na cadeia muda o escopo

A Itália faz o mesmo ponto pela direção oposta, e é a pergunta mais útil que se pode fazer a um fornecedor.

O ADM exige que a verificação de conformidade técnica se aplique ao sistema do concessionário em sua totalidade, e não a elementos isolados considerados separadamente. Mas, quando um concessionário usa um sistema de jogo já certificado e disponibilizado por um concessionário prestador de serviços, o organismo de verificação checa apenas a integração desse sistema de jogo com o restante do sistema.

Dessa única exceção decorrem dois produtos comerciais. Um fornecedor que se torna concessionário prestador de serviços certifica um sistema de jogo uma vez e o vende a operadores que depois verificam apenas uma integração — a rota mais barata para o comprador e a mais lenta e intensiva em capital para o fornecedor. Um fornecedor que coloca o seu título dentro do sistema de um operador é passageiro na data de certificação daquele operador.

Portanto, a primeira pergunta sobre qualquer proposta não é o que está incluído. É de que lado dessa linha o estúdio está, porque isso decide se o jogo chega já certificado ou se chega como mais uma coisa que o operador precisa mandar verificar.

A rota italiana também fixa a disciplina de código-fonte. O código entregue para inspeção precisa trazer, para cada arquivo, módulo ou função, o seu componente, uma descrição curta e um histórico de alterações, com a versão certificada identificada de forma única pela versão. Arquivos críticos são identificados por digest, e o organismo de verificação precisa conseguir demonstrar que os binários examinados são o resultado da compilação do código-fonte que foi entregue. O guia de prazos italiano cobre a estrutura de prazos e a verificação em produção que ocorre na primeira partida em produção de cada tipo de jogo.

A regra de alteração faz parte do preço

Toda proposta inclui suporte pós-entrega. Pouquíssimas declaram a regra de classificação que decide quanto custa esse suporte, e essa regra varia o suficiente entre mercados para mudar um total.

O Reino Unido enuncia o princípio e depois dá exemplos dos dois lados. Uma atualização maior é qualquer alteração de software que possa afetar a lisura de um jogo, e a lisura é definida como qualquer alteração no gerador de números aleatórios, no escalonamento e no mapeamento, ou nas regras do jogo, incluindo como as regras são processadas pelo software. O exemplo publicado que pega os estúdios é uma reconstrução dos arranjos de símbolos para reduzir carga de CPU: nenhuma regra mudou, mas a implementação das regras mudou, então o caso exige reteste externo. Do outro lado ficam os itens menores — formatos de áudio, a cor de um chapéu, gráficos de fundo substituídos porque uma licença expirou, um diálogo que é renderizado mal em um navegador.

A Espanha opera uma obrigação contínua mais leve, com um fio mais cortante: um procedimento documentado de gestão de mudanças, um relatório trimestral descrevendo as alterações feitas e mantendo atualizada a descrição do sistema, e autorização prévia para modificações substanciais que afetem componentes críticos, podendo o regulador exigir a retirada até que a homologação seja obtida. A Itália estabelece um ciclo de autorização de doze meses e exige certificação de conformidade de uma mudança emergencial em até duas semanas.

Junte as três e “suporte de certificação” deixa de ser um item de linha. É uma capacidade permanente: alguém capaz de classificar uma alteração, produzir o artefato que a classificação exige e repetir o processo no trimestre seguinte. A análise de controle de alterações organiza as superfícies, e o escopo pós-aprovação cobre a versão dessa mesma pergunta no âmbito da revisão de plataforma.

Cinco linhas que tornam as propostas comparáveis

Force toda proposta a caber nestas cinco linhas, e os totais passam a significar a mesma coisa.

Identidades do build. A versão de matemática, a versão de front, o conjunto de RTPs oferecido e a procedência do RNG. A análise de RNG da Espanha pede o fabricante, o nome do produto e a versão, a impressão digital do binário, se é hardware ou software, se é aleatório ou pseudoaleatório e sobre qual fenômeno físico, se a instância é compartilhada e com quais jogos, o algoritmo e as bibliotecas utilizadas, qualquer procedimento de ressemeadura, o comprimento em bits do espaço e os testes estatísticos realizados. Uma proposta que não consegue nomear isso não delimita o build; delimita um demo. A análise de variantes de RTP explica por que cada configuração de retorno é um objeto certificado próprio.

A matriz de mercados e localidades. Uma linha por mercado, uma coluna por localidade e um certificado em cada célula. Um jogo localizado é um build certificado, não uma tradução, então uma proposta que oferece quatro idiomas em três mercados está oferecendo até doze objetos certificados ou uma decisão documentada de entregar menos.

Os artefatos de certificação, e quem é dono de cada um. Quem escreve o relatório técnico, quem o protocola, quem é o requerente formal, se o estúdio é um fornecedor já homologado naquele mercado e quem paga o laboratório de ensaios. A exigência espanhola de identificar o fabricante e a versão de cada elemento de software significa que essa propriedade precisa ser atribuída a uma pessoa, não a um departamento.

A superfície de integração. O RGS, a carteira, o agregador e qualquer reporte para o sistema central. A interface é onde a estimativa de um estúdio é menos confiável, e os testes de integração que um agregador executa são a evidência de aceite dessa linha.

A base de alteração e suporte. A regra de classificação, as janelas de aviso, o custo de reteste por nível e a definição de defeito em oposição a pedido de alteração. É a linha mais frequentemente deixada como uma tabela de tarifas sem classificação por trás.

O que o “não incluído” esconde

As exclusões são onde as propostas mais divergem, e cinco delas movem dinheiro de verdade: taxas de certificação e de laboratório de ensaios; a localização do build certificado; o inventário de componentes e a sua manutenção após a entrega; a integração com um segundo agregador ou uma segunda carteira; e o primeiro lote de alterações pós-lançamento.

Uma disciplina útil é exigir que cada exclusão seja precificada como unidade declarada — por mercado, por localidade, por relatório, por nível de alteração — em vez de ficar como “sob consulta”. Uma exclusão com unidade é uma comparação. Uma exclusão sem unidade é um espaço reservado para a negociação que acontece depois que a campanha de lançamento já foi contratada.

O que não pode ser comparado

Duas coisas em uma proposta não são comparáveis e não devem ser pontuadas: datas e aprovações.

Nenhum estúdio controla uma fila de revisão de plataforma ou o calendário de um regulador, e qualquer proposta que prometa uma data de lançamento está descrevendo o melhor cenário. O que um estúdio pode assumir é o plano de evidências — qual artefato é produzido por quem, até quando, e o que acontece se uma submissão for rejeitada — e é essa a parte que vale comparar. O plano de lançamento em várias jurisdições apresenta a sequência da qual uma data realista precisa ser derivada.

A mesma contenção vale para resultados. Uma proposta pode enunciar uma hipótese sobre o que um título exclusivo ou de marca deve fazer pelo operador, e a instrumentação que a testaria, sem alegar um efeito medido que não possui. Se um jogo deve ser julgado pelo comportamento entre o cadastro e o primeiro depósito, a proposta pode nomear o evento, a janela de atribuição e a linha de base com a qual ele será lido. O que ela não pode fazer é converter isso em um ganho prometido, porque ninguém rodou o teste controlado ainda. Diga que pode ser testado; não diga que aumenta alguma coisa.

A grade, na prática

Monte uma tabela. As linhas são as cinco linhas, depois as exclusões, depois o plano de evidências. As colunas são as propostas recebidas. Cada célula contém um artefato nomeado ou um “ausente” explícito. A última coluna contém o preço unitário de tudo o que a proposta excluiu.

Uma proposta que sobrevive a esse tratamento é comparável, e a diferença entre totais se transforma em uma lista de coisas que um fornecedor incluiu e outro não. Essa é uma conversa sobre escopo, que é a única conversa que um comprador consegue ganhar.

Se você está montando essa grade e quer as identidades do build, a matriz de mercados e o plano de evidências definidos antes de qualquer número ser citado, peça um orçamento de projeto. O guia de contratação cobre como o briefing é montado, e as verificações do estúdio cobrem as questões de licença, propriedade e entrega que decidem o que sobra quando o projeto termina.

Perguntas que os compradores fazem

Por que os estúdios de jogos personalizados não publicam preços de pacote?

Porque o preço é função do escopo, e o escopo é definido pelos mercados e localidades para os quais o build precisa ser certificado, não pela lista de recursos do jogo. Um preço de pacote publicado teria de pressupor um conjunto de mercados, e qualquer pressuposto preciso estaria errado para a maioria dos compradores. Um orçamento com base de escopo é o documento mais útil: permite ao comprador ver qual unidade puxa o total e remover uma delas.

O que significa “sistema certificado” se estou comprando um jogo?

Significa que o objeto aprovado pelo regulador é maior que o jogo. Na Espanha, o relatório de certificação precisa identificar cada elemento de software com fabricante, nome do produto e versão, e listar os componentes críticos com impressões digitais, de modo que o jogo chega dentro de um inventário aprovado. Na Itália, a verificação se aplica ao sistema do concessionário como um todo e, quando se usa um sistema de jogo pré-certificado, o organismo de verificação checa apenas a sua integração. De qualquer forma, a unidade que você está comprando é um sistema que inclui a sua plataforma.

O suporte de certificação deve ser uma linha separada na proposta?

Sim, e dividido mais do que a maioria dos estúdios oferece. A divisão útil é por artefato — relatório técnico, inventário de componentes, análise de RNG, evidência de teste de integração, o próprio protocolo — com cada artefato atribuído a um responsável e a um mercado. Uma única linha de “suporte de certificação” esconde a parte que mais varia entre fornecedores, que é quem escreve o relatório e quem responde quando o regulador faz uma pergunta.

Como comparo propostas que cobrem listas de mercados diferentes?

Normalize pela interseção primeiro e depois precifique as adições. Pegue o conjunto comum de mercados e localidades, compare o comparável dentro dele e trate cada mercado oferecido por um fornecedor fora da interseção como uma adição opcional com a sua própria lista de artefatos. A mesma regra vale para localidades: uma localidade é um build certificado, então um idioma extra é um objeto de certificação extra, e não uma linha de tradução.

Uma proposta pode se comprometer com uma data de lançamento?

Pode se comprometer com as partes que controla, que são a entrega de um build e das suas evidências, e com uma lista declarada de dependências para as partes que não controla. A revisão de plataforma e a certificação regulatória estão fora do controle de um estúdio, e uma data que pressupõe uma fila de revisão é uma previsão, não um compromisso. Peça a lista de dependências e o plano de evidências, e construa a data a partir deles, não a partir da manchete.