A nova política de preços da Unity: um alerta sobre a importância do open source no desenvolvimento de jogos
(archive.md)- A Unity mudou seu modelo de preços de cobrança por assento para cobrança por instalação (pay per install), aplicando taxas não apenas a instalações pagas, mas a todas as instalações comuns
- No ambiente mobile, em que a receita média por impressão de anúncio é de US$ 0,02, a Unity cobraria US$ 0,20 por instalação após US$ 200.000 de receita anual, exigindo que cada usuário assista a pelo menos 10 anúncios
- A mudança será aplicada retroativamente também a aplicativos existentes, criando ônus até para jogos já lançados
- Jogos passam por um longo processo de desenvolvimento, de meses a anos, e migrar para outro motor é muito difícil; ao contrário de trocar um editor de documentos, é uma questão que ameaça a sobrevivência
- Motores open source sob licença MIT garantem direitos que não podem ser revogados nem alterados, protegendo desenvolvedores contra riscos futuros de mudanças de preço e política
Mudança na política de preços da Unity e seus impactos
- A Unity está mudando seu modelo de preços de cobrança por assento (pay per seat) para cobrança por instalação (pay per install), algo que não se limita a instalações pagas ou a jogadas, mas se aplica a todas as instalações comuns
- Isso traz consequências especialmente graves no ambiente mobile, onde a receita por instalação varia muito
- Segundo a Ironsource, subsidiária da Unity, a receita média por impressão de anúncio é de US$ 0,02
- A Unity pretende cobrar US$ 0,20 por instalação depois que o app tiver gerado US$ 200.000 nos últimos 12 meses
- Como resultado, todos os usuários precisam assistir a pelo menos 10 anúncios após instalar o app para que não haja prejuízo com esse custo
- Esse é um valor médio; em mercados emergentes, onde apps populares costumam ter receita de anúncios menor, o problema se torna muito mais sério
- A mudança será aplicada retroativamente também a aplicativos existentes, piorando ainda mais a situação
Por que uma política assim é possível
- A situação é comparada a a Microsoft cobrar pelo número de pessoas que leem documentos criados no Word; nesse caso, bastaria o usuário migrar para o Google Docs
- Trocar de editor de documentos é apenas inconveniente, não uma questão que ameaça a sobrevivência
- O desenvolvimento de jogos é um processo longo e complexo, que leva de meses a anos, e depois que o trabalho está concluído não é fácil migrar para outro motor
- Exige tempo e custo consideráveis
- Mesmo que a migração seja possível, naquele momento a equipe de desenvolvimento já pode ter sido desfeita
A proteção oferecida pelo open source
- Motores de jogos open source como o Godot engine concedem direitos de uso do motor que não podem ser retirados nem alterados, protegendo o trabalho produzido
- Sob a licença MIT do Godot, todos os usuários obtêm direitos de uso, modificação e distribuição livres
- A única condição é creditar os autores originais e não reivindicar o motor como sua própria criação
- Isso se aplica apenas ao motor; o jogo em si pertence ao desenvolvedor
Por que não migrar para o Unreal engine
- O Unreal engine atualmente não tem termos como os da Unity, mas não há um mecanismo que impeça a adoção de uma política semelhante no futuro
- Se a Unity conseguir levar adiante essa mudança, há possibilidade de o Unreal seguir o mesmo caminho
O papel da Ramatak
- O Ramatak mobile studio adiciona ao Godot engine open source funcionalidades essenciais para jogos mobile, como anúncios, compras dentro do app e analytics
- A Ramatak cobra por esse serviço, mas se os termos se tornarem incômodos, o usuário pode levar seu jogo e migrar para a versão open source
- Perde o acesso a recursos exclusivos da Ramatak, mas o jogo permanece integralmente de propriedade do desenvolvedor
- A primeira publicação do site aborda a relação com os usuários
- Como a migração para a versão open source é muito fácil, é preciso entregar necessariamente o valor que o usuário deseja
Conclusão
- O ambiente de jogos mobile muda constantemente, e é impossível prever qual será a próxima "grande tendência"
- Ao usar um motor open source, qualquer que seja a "próxima coisa", o motor não impedirá seu aproveitamento nem imporá uma estratégia de monetização
- Com o Ramatak mobile studio, é possível obter tanto a liberdade e a estabilidade de um motor open source quanto recursos personalizados avançados necessários para jogos mobile modernos
- Acima de tudo, os termos não podem ser alterados unilateralmente
1 comentários
Opiniões no Hacker News
O argumento de que a Epic e a Unreal Engine fariam algo parecido com a Unity não me convence muito
A Epic opera sua própria loja de jogos e é uma empresa que atrai desenvolvedores de forma ativa com uma divisão de receita generosa; para aceitar essa tese, seria preciso pressupor que ela romperia sua relação com os desenvolvedores em nome de um aumento de receita duvidoso
A Unity parece ter escolhido esse caminho porque não queria parecer que estava quebrando publicamente a promessa feita antes de não haver divisão de receita/royalties e, ironicamente, acabou criando um modelo de cobrança ainda pior
No fim, a Unity cresceu demais em um ambiente em que, depois do IPO, passou a ser avaliada por crescimento, e o ponto central desta situação parece ser que seu quadro de funcionários e seus custos ficaram excessivos. O fato de Epic e Valve serem empresas de capital fechado, e a Unity não, diz muita coisa
Não exatamente. A Unity se fundiu com a ironSource, uma empresa de publicidade mobile, e concorre diretamente com a AppLovin, uma das líderes desse mercado
As condições que a Unity oferece aos desenvolvedores, e os acordos de bastidor, funcionam como uma isenção dessa taxa caso eles usem os produtos de anúncios da Unity em vez da AppLovin. Parece uma tentativa de usar sua posição no mercado de engines de jogos para ampliar sua posição no mercado de publicidade mobile
Vejo isso não como um problema de estrutura societária, mas como uma falha de gestão. Se tivessem ouvido usuários, desenvolvedores internos ou qualquer pessoa com um mínimo de senso de realidade, isso não teria acontecido
Mas, quando se traz um ex-CEO da EA sem experiência de baixo nível na indústria e que deixou o emprego anterior por desempenho financeiro fraco, esse tipo de desastre parece quase inevitável
Isso me faz pensar bastante na diferença entre empresas de capital fechado e aberto. A maioria dos produtos de que gosto vem de empresas de capital fechado, e há algo nos incentivos das empresas de capital aberto que leva a escolhas ruins
Na prática, existem duas fontes de receita: vender produtos/serviços e vender ações, e as duas muitas vezes entram em conflito de forma prejudicial aos clientes. Em empresas de capital fechado, a lealdade ao cliente é mais direta, então o produto precisa ser bom para a empresa continuar existindo
Não quero dizer que empresas de capital aberto não deveriam existir, mas é preciso estruturar as coisas de modo que os incentivos da empresa não se desviem dos clientes que realmente pagam. Por enquanto, focar mais em compartilhamento de lucros e dividendos do que no preço da ação parece um caminho
A questão não é “a Epic faria isso amanhã?”, mas “ela faria isso em algum momento previsível no futuro?”
A diretoria da Epic poderia decidir fazer um IPO esperando ganhar mais dinheiro, a empresa poderia ser vendida a um bilionário endinheirado como Musk, ou uma nova gestão poderia convencer os demais a tomar essa decisão por “motivos empresariais sérios”
Se você cria um jogo com Unreal, no fim está apostando o sucesso comercial futuro no fato de uma empresa com fins lucrativos “continuar sendo menos maligna que a outra”. Agora a escolha da engine não é apenas uma questão de recursos, número de desenvolvedores e estrutura atual de preços; passa a ser também a preocupação de que, algum dia, a empresa mude retroativamente a estrutura de preços e leve seu negócio à ruína
Por outro lado, se você usa Godot ou cria sua própria engine, não precisa se preocupar com isso. Se a indústria de jogos e o público enviarem agora um sinal forte o suficiente à Unity, a chance de outras empresas tentarem esse tipo de coisa no futuro também cairá muito
A licença da Unreal traz um forte fundamento para esse argumento
“7. The Agreement Between You and Epic
a. Amendments
If we make changes to this Agreement, you are not required to accept the amended Agreement, and this Agreement will continue to govern your use of any Licensed Technology you already have access to.
However, if we make changes to this Agreement, you will not be allowed to access certain Epic services or download the Licensed Technology unless you have accepted the amended Agreement. If we make changes, we will provide you with notice, such as by sending an email or giving you notice when you next log into an Epic service.”
Ou seja, mesmo que haja uma isca seguida de mudança nas condições, as versões anteriores da engine às quais você já tem acesso podem continuar sendo usadas sob a licença existente. Em uma época em que quase todas as licenças de usuário final parecem dizer “podemos fazer qualquer coisa a qualquer momento e você não pode fazer nada”, incluir uma cláusula dessas parece uma demonstração considerável de boa-fé
https://www.unrealengine.com/en-US/eula/unreal
Isso deveria servir de alerta também para quem usa ferramentas de código fechado em geral: DynamoDB, MongoDB, Elasticsearch, AWS Lambda, Azure, AWS, Azure Devops, SqlServer, Oracle etc.
Algumas são ferramentas de altíssimo nível, mas são apenas tempo emprestado até o dono mudar as condições, encerrar a oferta ou aumentar o preço a ponto de prejudicar o negócio
Ferramentas de software de código fechado são uma dívida, e muitas vezes os benefícios são pequenos em relação ao risco. Já vi projetos em que várias equipes investiram dezenas de pessoas-ano serem descartados por fim de suporte ou aumentos abusivos de preço
Não sou purista, então uso coisas como JetBrains. Porque, se necessário, dá para trocar facilmente por ferramentas open source sem prejudicar o negócio. Não estou dizendo para criar suas próprias ferramentas, e sim para usar excelentes ferramentas open source como PostgreSQL, Apache, Linux, MariaDB, linguagens open source, Redis, CouchDB
No caso do Unity, o custo de trocar de engine é muito maior. Para a maioria que já concluiu um jogo, nem é realista considerar migrar para Godot ou Unreal, e é por isso que este caso é especialmente grave
Já softwares desenvolvidos internamente muitas vezes acabam sendo reescritos por novos membros da equipe por causa do código deixado por ex-funcionários. É estranho dizer para não usar algo por uma pequena possibilidade de mudança em código fechado e, como alternativa, adotar software interno, cujo problema futuro de manutenção é quase garantido
É preciso trabalhar com fornecedores confiáveis, revisar dependências, definir o nível de risco aceitável e analisar cuidadosamente as licenças usadas. Especialmente quando se trata de algo tão importante para um estúdio de jogos quanto uma engine de jogo
Os três têm empresas por trás, vendas ou restrições, e em geral as restrições miram provedores de nuvem, não a auto-hospedagem. Considerando as versões atuais, vejo todos os três como suficientemente abertos para que o risco de aprisionamento a fornecedor não seja grande
A política de preços do Unity é retroativa no sentido de rastrear até o número de instalações de jogos antigos já lançados. É parecido com o SQL Server mudar para cobrança baseada em GB e dizer que isso se aplica a tudo desde a versão 2005; até governos rejeitariam esse tipo de alteração retroativa
Agora a verdadeira pergunta é se alguém em sã consciência vai criar jogos com Unity daqui para frente
No curto prazo, os lucros podem aumentar, mas em breve o novo desenvolvimento de jogos em Unity vai secar. Porque, mesmo aceitando as condições atuais, ficou claro que a Unity pode mudar as regras a qualquer momento e empurrar os custos para os usuários
A Unity se tornou um risco de responsabilidade em nível existencial para empresas de jogos; quem ousaria se aproximar? Espero que a direção seja expulsa em breve pelos acionistas
É difícil ter certeza de que a direção será expulsa tão rapidamente. Há coisa demais construída sobre Unity
A interpretação mais comum é que a Unity está tentando extrair dinheiro de Genshin Impact, mas há muitos jogos que fizeram sucesso e não podem ser facilmente portados para outra engine, como Among Us ou Untitled Goose Game
Ou seja, ela quer virar a IBM das engines de jogo: uma empresa que busca renda econômica com serviço de baixa qualidade
https://www.sportskeeda.com/esports/will-genshin-impact-affe...
https://www.create-learn.us/blog/top-games-made-with-unity/
É no estilo “depois que eu sair, e depois que você sair”
Os números bons aparecem a tempo do cálculo dos bônus, e os números ruins só vêm à tona depois que os tomadores de decisão já foram para outras empresas. De qualquer forma, eles serão apresentados como as pessoas que dobraram a rentabilidade da Unity, então terão muitas opções
O lamentável é que, na última década, a Unity contribuiu em certa medida para o aumento de jogos no Linux
No Unity, dar suporte a Linux era quase de graça em comparação com muitas outras engines, e se houver menos jogos em Unity, é bem provável que também haja menos jogos para Linux
Isso também será um problema para o Vision Pro. É um pouco surpreendente que a Apple não tenha se manifestado dizendo que isso não se aplica a apps do Vision Pro
Pelo menos dentro da minha experiência limitada de vida corporativa, é muito raro a direção ser mais maligna do que o conselho de administração. Isso é ainda mais verdadeiro em empresas abertas com fins lucrativos, e é ainda mais raro que o conselho não tenha discutido isso com a direção antes do anúncio
Dá até um pouco de pena da Unity. Ela está em uma posição financeira ruim, queimando quase US$ 1 bilhão por ano, sem uma solução clara
Ou aumenta os preços e irrita os clientes, ou reduz custos, como já vinha fazendo com demissões em massa, correndo o risco de ser ultrapassada por outros engines de jogos, como a Unreal
Por anos, o que sustentou a empresa foi, na prática, seu valuation. Enquanto investidores bancavam crescimento e lucros futuros, ela conseguia cobrir prejuízos, mas agora que o crescimento desacelerou e os investidores estão menos generosos com crescimento, não sei o que a Unity pode fazer
Não tem moat, o crescimento desacelerou e ela queima muito caixa. Se o ambiente macro não mudar a seu favor, é difícil ver como ela sai dessa e continua na liderança
Se tivessem atendido principalmente seus clientes centrais, os desenvolvedores indie, com uma equipe menor e um produto mais simples, talvez pudesse ter sido sustentável e lucrativo. Mas parece que tentaram entrar à força no mercado AAA
Esta confusão é resultado de uma política anunciada de forma realmente ruim, de detalhes mal lapidados que deixam desenvolvedores expostos a abusos, e de uma comunidade muito coesa de criadores, que já tem experiência sendo maltratada por pirataria, review bombing, ondas de reembolso etc., reagindo quase como um só corpo
A maioria dos desenvolvedores teria aceitado a divisão de receita, mesmo reclamando. Grandes estúdios como Nintendo e Microsoft também usavam Unity, e é difícil entender se eles realmente acharam que essas empresas aceitariam sem problemas a cobrança sobre vendas retroativas e números de receita
Se a participação de mercado é de cerca de 30%, bastaria capturar menos de 2% do valor criado pelas ferramentas para chegar ao ponto de equilíbrio. Se não conseguem fazer isso, ou se fornecem tecnologia para áreas menos lucrativas que a média, precisam mudar o foco ou cortar custos
Se uma empresa não consegue capturar mais valor do que consome, é natural que o negócio fracasse
Ninguém mandou Riccitiello pisar no acelerador, nem vender ações antes do anúncio desastroso para enriquecer a si mesmo. Foi algo que ele fez por conta própria
Tenho muito mais pena dos milhares de desenvolvedores que ficaram com uma arma metafórica apontada para a cabeça por causa dessa política horrível, e que agora precisam se preocupar em trocar de engine
Eu gosto de código aberto e do engine Godot, mas este caso me parece mais um alerta de que empresas não deveriam poder mudar contratos unilateralmente e de forma retroativa para impor novos custos e descumprir promessas contratuais existentes
Se isso for possível, código aberto também não oferece muita proteção prática
O caso da HashiCorp é um bom exemplo. O Terraform foi bifurcado e continua como sempre, e os usuários não são afetados
Em plataformas de programação como engines de jogos, essa vantagem é ainda maior. Algo como o Terraform talvez pudesse ser reescrito em algumas semanas se os testes estivessem bons, mas em jogos isso é impossível
Ninguém pode tirar os direitos sob a licença MIT, e não há mecanismo legal para isso. Você fica totalmente protegido contra esse tipo de coisa
Algumas licenças de código aberto são fáceis de cumprir e favoráveis a negócios, o que pode ajudar. Por outro lado, os estúdios de jogos que estão reclamando agora também reagiriam fortemente se fossem obrigados a cumprir a GPL e abrir seu código-fonte
Mesmo com licenças permissivas de código aberto, ainda existe o risco de que versões futuras passem a ter uma licença de que você não gosta, como a HashiCorp fez com o Terraform e outros, cortando você de atualizações e correções necessárias. A comunidade pode ou não manter um fork
Se este caso for legal, provavelmente será por causa das regras de licença de usuário final, mas não vou me arriscar a prever se é legal ou não
Termos de serviço muitas vezes não valem nem o papel higiênico em que poderiam ser impressos, mas fico curioso se assinantes antigos, que assinavam desde 2019, agora poderiam processar por quebra de contrato e custos de re-desenvolvimento
Já passei por isso por causa da Steam. Eu tinha jogos antigos, como Half-Life, em um notebook velho; um dia liguei, a Steam atualizou e quebrou tudo, e como o sistema antigo não era mais compatível, os jogos também deixaram de funcionar
Isso não significa necessariamente que tudo precise ser código aberto, mas precisamos possuir o software, não apenas alugá-lo
O Unreal atualmente não tem condições como as da Unity, mas dizer que nada impediria algo parecido e que, se a Unity se safar, ele provavelmente vai seguir o mesmo caminho é uma afirmação que não foi suficientemente investigada
O Unreal tem uma condição segundo a qual é possível usar uma versão específica do engine para sempre, e a Epic não pode revogar essa licença. É verdade que, para versões novas, a Epic pode mudar os termos
Tim Sweeney também deixa isso claro com frequência, e, observando os movimentos para quebrar o monopólio do Google Play/Apple, a direção da Epic Games parece diferente de uma piranha corporativa como a Unity
Ainda assim, dizer sobre o Godot que “por ser open source não há problema” também é simplista. E se os desenvolvedores pararem de dar suporte? Na prática, a ideia de que “a comunidade vai continuar trabalhando” muitas vezes depende de uma ou duas pessoas que realmente fazem o trabalho
Se os desenvolvedores do Godot pararem, você fica preso em um projeto sem suporte e precisa continuar o desenvolvimento do engine em vez de se concentrar no jogo. O mesmo vale para o produto próprio do autor
Na última semana, 32 pessoas fizeram 52 commits no Godot; no último mês, 135 pessoas contribuíram. Não é algo no nível de “uma ou duas pessoas”
Se uma empresa de código fechado parar de desenvolver um produto, você fica preso do mesmo jeito; nesse caso, fica ainda mais preso, porque não tem acesso ao código-fonte para corrigir por conta própria
Mesmo que o desenvolvimento do Godot pare, a versão que você tem continua existindo. Qual é a diferença entre a Epic parar de trabalhar no engine de jogo que você está usando e um projeto open source parar de trabalhar no engine de jogo que você está usando? A diferença é que, com o Godot, você pode trabalhar nele por conta própria se quiser
Ao que parece, a Unity mantinha a licença em um repositório Git para que todos pudessem acompanhar facilmente as mudanças. Pouco antes da alteração da licença, removeu esse repositório e depois o publicou de novo, mas a cláusula que permitia usar versões antigas para sempre sem as novas restrições havia sumido
Eu estava insistindo com um amigo desenvolvedor de jogos que trabalha com Unity C# para ele dar uma olhada em Bevy e Rust. É porque o sistema de tipos do Rust é realmente excelente
Exemplo de código: https://bevyengine.org/learn/book/getting-started/ecs/
A licença é Apache 2.0 ou MIT
Apache 2.0: https://github.com/bevyengine/bevy/blob/main/LICENSE-APACHE
MIT: https://github.com/bevyengine/bevy/blob/main/LICENSE-MIT
Vi esta parte no FAQ da Unity (https://unity.com/pricing-updates) em um comentário do artigo da Ars, e ela continua me incomodando
“Will developers be charged the Unity Runtime Fee for subscription-based games?
No, in this case the developer is not distributing it so we’re not going to invoice the developer on subscription-based games (e.g. Apple Arcade, Xbox Game Pass, PlayStation Plus, Netflix Games, etc.)”
Não consigo acreditar que a direção da Unity acha que isso vai funcionar. Microsoft, Apple e outras provavelmente firmaram contratos com os desenvolvedores garantindo os direitos totais de distribuição dos jogos dentro de uma determinada estrutura de taxas; será que a Unity pretende agora dizer “esse contrato não concede o direito de distribuir a parte que nós possuímos; paguem a nós também”?
Mesmo que isso funcionasse, Microsoft ou Apple poderiam fazer uma cobrança judicial contra o desenvolvedor que garantiu ter cedido os direitos de distribuição do jogo inteiro
Tudo isso parece uma enorme improvisação, e essa pergunta e resposta sobre jogos por assinatura mostra o nível do plano como um todo. É difícil entender se seguiram um capricho do CEO sem revisão jurídica ou se estão tentando deliberadamente levar isso aos tribunais
Virei patrocinador do Bevy. Pretendo tentar convencer nosso estúdio a doar uma porcentagem fixa dos lucros para projetos open source
Por menor que seja a chance de o Bevy realmente se tornar um engine mainstream, vale a pena tentar
A Unity era um sonho, ou uma mentira, de que seria possível criar jogos sem uma equipe de software competente
Agora o texto original deposita esperança em outro sonho, ou mentira: o de que fadas mágicas do open source permitirão continuar seguindo em frente sem uma equipe de software competente. Mas não vai acontecer assim
É preciso encontrar programadores, formar uma equipe, criar uma empresa em que essa equipe possa se estabelecer e ajustar o modelo de negócios para poder pagá-los. Ou seja, é preciso aumentar os preços
Fazer um jogo talvez seja. Um bom jogo, acho que não