Encomendar um jogo exclusivo para um único mercado: as decisões que a plataforma tem de assumir

Um jogo exclusivo costuma ser encomendado como uma ideia comercial e entregue a uma cadeia de fornecimento. Uma plataforma, agregador ou rede de estúdios decide que falta um título em um mercado, paga por ele e depois descobre que aquilo que agora possui tem de ser fabricado, fornecido, hospedado e publicado por partes cujas posições de licença nunca foram registradas por escrito. É essa lacuna que este artigo aborda. Não é o brief do operador — esse documento está coberto no brief de encomenda de jogo de cassino de marca — é o conjunto de decisões que pertence à parte no meio da cadeia, aquela que compra o título e o repassa.

O motivo pelo qual essas decisões são da plataforma e não do estúdio é simples. Um estúdio pode construir um jogo e um laboratório pode testá-lo. Nenhum dos dois pode decidir quem tem o direito legal de colocar esse software diante dos jogadores em um mercado específico, qual empresa responde pelo comportamento do jogo ou o que a plataforma tem permissão de fazer com o título depois que ele existe. Essas decisões são da plataforma para resolver, e são mais baratas de resolver antes que alguém comece a construir.

Uma plataforma é fornecedora antes de ser um catálogo

A palavra “catálogo” faz uma plataforma soar como uma loja. Na cadeia de fornecimento regulamentada, ela está mais próxima de um fabricante e de um distribuidor, e as regras são escritas para esses papéis.

Na Grã-Bretanha, a condição de licença 2.2.1 é direta quanto a quem pode mexer com software de jogo. Ela se aplica a todas as licenças de cassino remoto, bingo e apostas, exceto licenças auxiliares e licenças de intermediário de apostas remotas (somente sala de negociação), e diz: “All gambling software used by the licensee must have been manufactured by the holder of a gambling software operating licence. All such gambling software must also be supplied to the licensee by a holder of a gambling software operating licence. Such software must only be installed or adapted by the holder of such a licence.”

Essa frase distribui obrigações por todas as partes da cadeia, não apenas pela que escreve código. A orientação da própria Gambling Commission sobre o que conta como software de jogo deixa a distribuição explícita e, para uma plataforma, incômoda: a Commission não espera uma licença de uma empresa cujo único envolvimento é comprar software e revendê-lo “without any involvement itself in its manufacture, adaptation or installation” — mas depois fecha essa porta. “The exception is that the final supplier to a Commission licensed operator will require a gambling software licence as set out in Licence condition 2.2.1, even if they actually perform no development/manufacturing, adaptation or installation activity.”

Leia isso como um comprador-plataforma e a questão deixa de ser técnica. Se a plataforma é a entidade que contrata com o operador licenciado, ela é o fornecedor final, e a resposta a “quem precisa da licença aqui?” pode ser a própria plataforma.

Decida quem detém a licença antes de decidir o que construir

O teste da Commission para saber quem carrega a licença tem a ver com controle, e ela lista os indicadores que procura:

• qual empresa é responsável pelo design e pela funcionalidade do software?
• qual empresa é responsável por aprovar mudanças de design?
• qual empresa é responsável pelos testes de funcionalidade e aceitação?
• qual empresa é responsável pelos testes de garantia de qualidade e conformidade regulatória do produto?
• qual empresa detém a propriedade intelectual do produto?
• o que o contrato diz em termos de responsabilidades e passivos.

A orientação reduz então todo o exercício a uma questão comercial: “we will be looking to determine whether the contract between the parties in essence involves purchase of a product or merely payment for time and expertise.” Comprar um produto coloca a licença sobre o fornecedor; comprar tempo e experiência sob o seu próprio controle a coloca sobre você. Sua ilustração da distinção é exatamente a situação que uma plataforma cria quando encomenda arte ou um tema: “Where the third party is only providing part of a game, such as artwork, under the control and design specifications of Company Y, then this indicates Company Y is in control and is the entity to hold a gambling software licence whereas the third party does not.”

É por isso que uma conversa sobre exclusividade e encomenda que permanece comercial por seis semanas e se torna técnica na última é um caminho ao contrário. A propriedade do design e a propriedade da licença são a mesma decisão vista duas vezes, e um contrato silencioso sobre os indicadores acima deixa a plataforma reconstruir sua posição depois, a partir de uma build que já aceitou. A Commission diz isso mesmo na mesma orientação: “We would expect information about the respective indicators will be contained within a commercial contract.”

O arranjo	Onde está o controle	Quem provavelmente precisará da licença
A plataforma compra um título pronto de um estúdio e o redistribui	O estúdio o projetou e construiu	O estúdio; e o fornecedor final a um operador licenciado também pode precisar de uma
A plataforma especifica o jogo e um estúdio constrói segundo essas especificações	Plataforma	A plataforma, como parte controladora
O estúdio fornece apenas arte ou um tema para a build da própria plataforma	Plataforma	A plataforma
O grupo da plataforma detém a PI, mas o desenvolvedor do grupo a constrói	Depende do arranjo	A Commission pode tratá-los em conjunto sob uma licença guarda-chuva, ou exigir ambas

Nada disso é uma conclusão jurídica, e nada disso pode ser resolvido por um fornecedor. É a forma da pergunta que a plataforma deve apresentar aos seus próprios assessores antes de fazer a encomenda, da mesma maneira que apresentaria a eles uma questão de pagamentos ou de dados. O que uma encomenda pode fazer é tornar a pergunta respondível: nomear a parte controladora, listar as responsabilidades de aceitação e conformidade e registrar quem detém a PI.

Decida se a plataforma também precisa de uma licença de operação

A segunda questão de licença é mais fácil de deixar passar porque soa como algo que só se aplica a operadores. Não é o caso. Uma licença de software de jogo autoriza fabricação, fornecimento, instalação e adaptação; não autoriza oferecer instalações para jogos de azar. A orientação da Commission deixa a consequência clara: “a business that holds a gambling software licence but also hosts a poker network or a games platform will also require a remote casino operating licence as it is responsible for the fairness of the gambling.”

Para uma plataforma que hospeda os jogos que agrega, essa frase é a diferença entre uma entrada de catálogo e uma atividade regulamentada. Se ela se aplica depende do que a plataforma realmente faz — hospedar, operar ou apenas encaminhar software — o que é mais uma razão para responder por escrito no momento da encomenda, e não no lançamento.

Um mercado significa uma única explicação publicada das regras

A razão pela qual uma encomenda específica para um mercado é mais difícil do que uma genérica é que as obrigações de explicação se ligam ao mercado, não ao código. Na Grã-Bretanha, o requisito 3A do RTS 3 declara: “An explanation of the applicable rules must be easily available to the customer before they commit to gamble. The content including artwork and text must be accurate, and sufficient to explain all of the applicable rules and how to participate.” O requisito 3C acrescenta que as informações que permitem ao cliente tomar uma decisão informada sobre suas chances de ganhar — incluindo a vantagem da casa ou margem e o percentual de retorno ao jogador — “must be easily available before the customer commits to gamble”, e o requisito 3D coloca prêmios e pagamentos no mesmo lugar e no mesmo momento.

Duas consequências decorrem disso para a plataforma, e não para o estúdio.

A primeira é que a arte não está isenta. O requisito abrange o conteúdo “including artwork and text”, de modo que um painel de regras decorativo que exibe um conjunto matemático diferente, ou uma tela de ajuda temática que descreve o mundo em vez do jogo, é um artefato inexato com o nome da plataforma na frente. O guia de especificação de regras e o guia de modelo matemático e folha PAR existem para manter essas duas coisas descrevendo o mesmo jogo.

A segunda é que a plataforma, como parte que distribui para um mercado, tem de nomear quem redige e assina a explicação publicada nas línguas desse mercado, e tem de saber qual parte é dona da resposta quando a tabela de pagamentos muda. Um título encomendado cuja página de regras é escrita uma única vez, em uma única língua, e reutilizada entre clientes é um defeito que chega depois da build, não durante ela.

Codifique o mercado; não o pinte

Uma plataforma que distribui para várias marcas clientes esbarra em uma versão mais silenciosa do mesmo problema: o mercado, a língua e a moeda têm todos de ser dados, porque as alternativas são feitas à mão e não escalam.

A identidade de país é um padrão, não uma decisão de design. A ISO 3166 existe para “define internationally recognized codes of letters and/or numbers that we can use when we refer to countries and their subdivisions”, justamente para que um território possa ser nomeado de forma inequívoca sem depender da língua do documento que o nomeia — o que importa quando a mesma concessão tem de ser lida por um cliente em um mercado e por um fornecedor em outro.

A língua é a mesma história. A BCP 47, a norma do IETF Tags for identifying languages, descreve “the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object”. Um registro de catálogo que carrega uma etiqueta de idioma por apresentação pode ser renderizado de forma consistente por todos os clientes; um título que é entregue com texto localizado embutido em uma única build não pode.

Essa é uma restrição de encomenda com um custo visível depois. O guia de arquitetura de localização é onde vive a estrutura para isso; a contribuição da plataforma é exigir as etiquetas e os códigos como campos do registro de catálogo, e não como texto que um artista desenhou.

Registre por escrito o que a concessão permite que a plataforma faça

A página mais valiosa de uma encomenda de plataforma não é o brief nem a especificação. É a concessão — a parte do acordo que diz o que a plataforma pode fazer com o título pelo qual pagou.

A exclusividade do lado do operador é uma questão comercial com vocabulário próprio, e está coberta em outro lugar no brief de encomenda. O que a plataforma tem de acrescentar é a camada de redistribuição, que é um conjunto diferente de perguntas:

• Território. Uma lista de mercados, expressa em códigos, em vez de uma frase como “nossos mercados”. A concessão e a posição de licença têm de nomear os mesmos lugares.
• Subdistribuição. Se a plataforma pode apresentar o título aos seus operadores clientes, sob qual marca, e se esses clientes podem mudar alguma coisa.
• O que um cliente pode reestilizar. Se o título é distribuído para várias marcas, a concessão deve dizer quais superfícies são delas. Uma mudança do lado do cliente nas partes cobertas pelas regras publicadas ou pela build certificada é uma mudança no artefato, não no marketing, e o guia de submissão de certificação é onde o custo disso aparece.
• Prazo e fim do prazo. O que a plataforma pode manter quando o prazo termina, o que ela deve remover e o que acontece com as marcas clientes que adotaram o título nesse meio-tempo.
• Os outros clientes do estúdio. Se o estúdio pode colocar as mesmas mecânicas com uma plataforma concorrente no mesmo mercado, e quão próxima uma variação tem de ser para contar.

Essas são perguntas para a assessoria jurídica da própria plataforma. O trabalho da encomenda é garantir que elas sejam feitas enquanto a resposta ainda vale a pena ser registrada por escrito.

Mantenha o pacote de release e entregue o mesmo a cada cliente

A última decisão é a menos glamourosa e a que determina se o lançamento sobrevive ao seu segundo cliente. Uma plataforma que distribui um título encomendado tem de manter, para a release exata que distribui, o material que descreve o que o jogo é: as regras versionadas, a matemática, a configuração de operação e os resultados dos testes dessa build.

Isso não é burocracia por si só. É o que permite à plataforma responder a uma pergunta de um cliente, a uma consulta de um laboratório ou a um pedido de um regulador sobre um título que ela não escreveu, e o que impede que uma reestilização desvincule silenciosamente a explicação publicada da matemática que ela descreve. O guia de requisitos de integração com o RGS cobre o contrato de integração que produz parte desse pacote; a contribuição da própria plataforma é exigir o pacote como entregável, a cada release, e manter o registro de qual cliente recebeu qual versão.

Para um operador ou uma plataforma que trabalha com um parceiro de estúdio e plataforma, a forma útil desta seção é uma lista curta com um responsável para cada linha, e não uma pasta que é montada no lançamento.

Escreva a comparação antes da encomenda, não depois

Uma encomenda normalmente é justificada com uma meta. “Precisamos de conteúdo exclusivo” é uma meta; ela não pode ser testada e não pode estar errada. Uma comparação é diferente, porque pode estar errada.

A comparação que uma plataforma realmente pode fazer é sobre o catálogo, não sobre o jogo ser bom: quantos títulos no catálogo do mercado-alvo carregam a língua, a apresentação de moeda e o conteúdo de regras de que esse mercado precisa, contados antes da encomenda e de novo depois que o título está no ar, segundo a mesma medição. Esse número descreve cobertura, que é o que uma encomenda de conteúdo muda. Ele não descreve valor para o jogador, retenção ou receita, e um lançamento que relata isso como efeito de um título encomendado publicou uma conclusão que não comprou.

Duas disciplinas fazem a diferença. Escreva a medição — o mercado, o catálogo, a definição de título qualificado — antes de a encomenda ser feita, porque uma comparação escolhida depois é uma história. E mantenha a afirmação proporcional: um título pode plausivelmente mudar o que um catálogo oferece; se ele mudou alguma coisa nos jogadores é uma questão separada que exige um desenho que o lançamento não tem por si só.

O contexto de jogo responsável pertence ao mesmo plano, e não a uma nota de rodapé, porque publicar conteúdo em um mercado não é neutro: seja qual for a parte que carrega as obrigações de design responsável do produto para esse mercado, ela as carrega no lançamento, e os requisitos de design responsável do produto são onde vive a versão específica de cada mercado desse trabalho.

Perguntas que as plataformas fazem

A plataforma precisa de uma licença de software de jogo se um estúdio fez o jogo?

Pode precisar, e a resposta não depende de quem escreveu o código. Na Grã-Bretanha, a condição 2.2.1 do LCCP exige que o software de jogo usado por um operador licenciado tenha sido fabricado, fornecido, instalado ou adaptado pelo titular de uma licença de operação de software de jogo, e a orientação da Commission afirma que o fornecedor final a um operador licenciado precisa de uma licença mesmo sem realizar qualquer atividade de desenvolvimento, adaptação ou instalação. Onde a plataforma compra um produto, a posição do estúdio importa; onde a plataforma controla o design, a posição dela é que importa. Leve a pergunta aos seus próprios assessores com o contrato à frente.

Quem decide qual parte está “no controle” da build?

A Commission lista os indicadores: quem é responsável pelo design e pela funcionalidade, quem aprova as mudanças de design, quem executa os testes de funcionalidade e aceitação, quem executa os testes de garantia de qualidade e conformidade, quem detém a propriedade intelectual e o que o contrato diz sobre responsabilidades e passivos. Seu próprio resumo do teste é se o contrato é, na prática, uma compra de um produto ou um pagamento por tempo e experiência. Essa é uma pergunta que o contrato da encomenda pode responder com antecedência, ou deixar para ser reconstruída depois da entrega.

Um operador cliente pode reestilizar um título exclusivo?

Apenas dentro das superfícies que a concessão e as regras publicadas permitem. Um nome temático ou um mosaico de lobby é um detalhe de distribuição; uma mudança nas partes cobertas pela explicação publicada das regras, ou na build que foi testada, altera o artefato que o operador está apresentando. Se o título deve atender várias marcas, escreva o limite de reestilização na concessão antes da build, e verifique-o contra os requisitos de certificação do mercado.

O que tem de ser publicado para um título exclusivo de um único mercado?

Na Grã-Bretanha, o RTS 3 exige que uma explicação das regras aplicáveis esteja facilmente disponível antes de o cliente se comprometer a jogar, com conteúdo que inclui arte e texto que devem ser exatos e suficientes para explicar todas as regras aplicáveis e como participar; informações que sustentem uma decisão informada sobre as chances de ganhar, incluindo a vantagem da casa ou margem e o percentual de retorno ao jogador; e conteúdo que descreva os prêmios e pagamentos ou como são determinados. Outros mercados estabelecem seus próprios requisitos. A decisão de encomenda é nomear quem redige e assina cada um desses itens em cada língua de lançamento.

Como a plataforma deve provar que valeu a pena fazer a encomenda?

Medindo o catálogo em relação ao requisito do mercado, não medindo o jogo. Conte os títulos que carregam a língua, a apresentação de moeda e o conteúdo de regras do mercado antes da encomenda e de novo depois que o título está no ar, usando a mesma definição de título qualificado, e registre essa definição por escrito primeiro. Isso produz algo verificável sobre cobertura de conteúdo. Afirmações sobre retenção, valor para o jogador ou receita exigem uma comparação controlada que o lançamento não cria por si só, então relate-as como observações, e não como resultados.