Por que a Qualidade do Build é Importante para os Playables
Publicar um jogo nos YouTube Playables não é o mesmo que fazer o upload para outros portais da web. O YouTube executa seu próprio processo de certificação, uma revisão técnica obrigatória que todos os builds devem passar antes de serem publicados. Se o build falhar, ele é devolvido ao desenvolvedor para correções, reenvio e outra rodada de revisão. Cada ciclo custa tempo e esforço.
Na Mediacube, executamos testes de pré-certificação em todos os builds antes que eles cheguem ao YouTube. Nossa equipe de QA revisou centenas de builds em Unity, Cocos, Phaser, Construct e outros motores. Os erros listados neste artigo são os que vemos com mais frequência em estúdios de todos os tamanhos, motores e gêneros de jogos.
A maioria deles pode ser corrigida rapidamente assim que você sabe o que procurar. Leia isso antes de construir, não depois.
Erro #1: A Pausa Não Pausa o Jogo
Como isso parece
Quando um jogador alterna para outra aba, minimiza o aplicativo ou o sistema solicita uma pausa, os YouTube Playables enviam um sinal de pausa para o jogo via SDK. Muitos jogos respondem a esse sinal exibindo o menu de pausa interno, mas o loop de jogo subjacente continua a executar. Física, temporizadores de contagem regressiva, animações continuam. Alguns elementos interativos ainda são clicáveis no estado de pausa.
Outra variante: O jogo congela visualmente, mas fila as entradas durante o congelamento. Quando o jogo volta a ele, executa todas essas ações bufferizadas de uma vez — e um personagem pula três vezes em rápida sucessão, ou atira uma arma que foi pressionada durante a tela de pausa.
Terceira variante (muito frequentemente relatada em nossa pipeline de QA): O jogo exibe corretamente o menu de pausa interno, mas os botões nesse menu são totalmente clicáveis. A pausa oficial dos Playables está em vigor e o jogador pode usar esse tempo para navegar em menus, alterar configurações ou até reiniciar o jogo.
Por que ele falha na certificação
O contrato de pausa do SDK dos Playables é estrito: quando `ytgame.system.onPause()` é acionado, o jogo deve parar completamente e não executar nenhuma animação, nenhuma física, nenhum processamento de entrada e nenhum temporizador. Qualquer desvio disso é sinalizado durante o processo de certificação do YouTube.
O contrato de pausa do SDK dos Playables é estrito: quando `ytgame.system.onPause()` é acionado, o jogo deve parar completamente e não executar nenhuma animação, nenhuma física, nenhum processamento de entrada e nenhum temporizador. Qualquer desvio disso é sinalizado durante o processo de certificação do YouTube.
🛠️ Como Corrigir
Registre o
onPause
callback e certifique-se de que ele interrompe o loop do jogo, silencia todas as animações, desabilita o tratamento de entrada e limpa quaisquer filas de ação pendentes. Em
onResume
, restaure o estado de onde foi congelado: não reproduza entradas bufferizadas. Teste isso explicitamente acionando a pausa por meio do
Playables Test Suite
, e não apenas do botão de pausa dentro do jogo.
⚠️ Erro Comum
Tratar a pausa do SDK do YouTube como equivalente à pressionar o botão de pausa dentro do jogo. Eles não são o mesmo. A pausa do SDK deve interromper tudo dentro do loop do mecanismo de jogo.
Erro #2: O Estado de Silenciamento Não é Persistente
Como ele parece
O YouTube pode silenciar o áudio de um jogo a qualquer momento por meio do SDK, por exemplo, quando o jogador está assistindo a um anúncio, alterna contextos ou tem o dispositivo em modo silencioso. O jogo deve respeitar esse estado de silenciamento e manter o áudio desligado até que o YouTube o desbloqueie explicitamente.
Os modos de falha que vemos com mais frequência:
Reinicialização do silenciamento em eventos internos. O jogo silencia corretamente em resposta ao sinal do SDK, mas se o jogador abrir o menu de configurações do jogo, clicar em um botão de reinicialização ou transitar para um novo nível, o silenciamento é removido. O áudio volta, mesmo que o YouTube ainda tenha o silenciamento ativo.
O silenciamento não sobrevive a uma recarga da página. Se a página for recarregada enquanto o jogo está silenciado (via SDK), o jogo é relançado com o áudio ativado. O estado de silenciamento foi armazenado na memória, não persistido, então a recarga o apaga.
O botão de silenciamento interno anula o silenciamento do SDK. O SDK silencia o jogo, mas o jogador pode pressionar o controle de áudio do jogo para restaurar o som. É o controle interno que está ignorando o comando do SDK externo.
Por que falha na certificação
O SDK Playables fornece `ytgame.system.isAudioEnabled()` para verificar o estado de áudio atual e `ytgame.system.onAudioEnabledChange()` para ouvir as alterações. Os jogos devem confiar nesses em vez de gerenciar seu próprio estado de áudio paralelo que pode sair de sincronia.
🛠️ Como Corrigir
Inicialize o estado de áudio usando
ytgame.system.isAudioEnabled()
no lançamento do jogo, antes de tocar qualquer som. Registre
onAudioEnabledChange
e aplique o novo estado imediatamente e globalmente quando ele for acionado. Mantenha o estado de mute do SDK para que ele sobreviva à recarga da página: escreva-o em
ytgame.game.saveData()
para que o jogo o leia novamente no próximo lançamento. Não permita que os controles de áudio dentro do jogo anulem o estado do SDK; seu botão interno deve funcionar apenas quando o SDK tiver áudio habilitado.
✅ Lista de Verificação de Testes
Teste isso especificamente: mute via o Conjunto de Testes, acione todos os eventos dentro do jogo que você tiver (menus, transições de nível, reinícios, mortes) e confirme que o áudio permanece desligado ao longo do processo. Em seguida, atualize a página e confirme que permanece desligado após a recarga.
Learn more
Pronto para Lançar nos YouTube Playables? Crie sua conta e obtenha tudo o que você precisa para publicar, monetizar e crescer seu jogo globalmente. [Comece agora](https://mcplay.mediacube.io/?utm_source=organic&utm_medium=banner&utm_campaign=blog)
[Comece agora](https://mcplay.mediacube.io/?utm_source=organic&utm_medium=banner&utm_campaign=blog)Erro #3: O Progresso Não É Salvo Entre Sessões
Como ele se parece
O jogador completa os níveis 1 a 5, fecha o navegador, reabre o jogo — e começa novamente no nível 1, ou pior, no tutorial. Nenhum progresso foi salvo. O jogo estava armazenando o estado em localStorage ou em uma variável de sessão, ambos os quais são apagados ao fechar ou estão indisponíveis no ambiente dos Playables.
Por que ele falha na certificação
Os YouTube Playables não permitem que os jogos usem localStorage do navegador ou servidores de salvamento externos. Todos os dados de jogo persistentes devem passar pelo SDK dos Playables: `ytgame.game.saveData()` e `ytgame.game.loadData()`. Jogos que não implementam isso perderão o progresso do jogador em cada sessão, o que é uma bandeira de rejeição imediata.
🛠️ Como Corrigir
Substitua qualquer
localStorage.setItem()
/
getItem()
chamadas com
ytgame.game.saveData()
e
ytgame.game.loadData()
. Esses aceitam uma string serializada de até 3MB — serialize seu estado de save como JSON, carregue-o na inicialização e escreva-o sempre que um progresso significativo for feito (conclusão de nível, checkpoint, conquista significativa). Não espere até o fim da sessão para salvar e usar
onPause
como um gatilho de save adicional, pois o jogo pode ser fechado a partir da pausa.
💡 Dica Profissional
Se o seu jogo foi originalmente construído para mobile ou desktop com um sistema de salvar em nuvem ou armazenamento de dispositivo, dedique tempo para refatorar isso. É uma das fontes mais comuns de atraso na certificação de uma porta móvel no Playables.
Erro #4: O Jogo Tenta Carregar Ativos de URLs Externas
Como isso parece
O jogo falha ao carregar ou carrega parcialmente com música ausente, ativos visuais ausentes ou áudio silencioso quando executado no ambiente do Playables. No console do navegador, você vê erros de rede: solicitações para CDNs externos, servidores de ativos, APIs de música de streaming ou provedores de fontes de terceiros que estão sendo bloqueados.
Às vezes, isso é óbvio (o jogo foi construído para transmitir sua trilha sonora de um serviço externo) e, às vezes, é sutil (uma fonte da web carregada do Google Fonts, um pixel de análise, um atlas de sprites único hospedado em um CDN que nunca foi incorporado ao build).
Por que ele falha na certificação
O YouTube Playables opera em um ambiente isolado. Chamadas de API externas e solicitações para domínios externos não são permitidas. Tudo o que o jogo precisa para executar deve ser incorporado ao build em si. Isso inclui: arquivos de áudio, atlases de textura, fontes, strings de localização, arquivos de configuração e quaisquer scripts de terceiros.
🛠️ Como Corrigir
Antes de enviar, abra a guia "
Rede
" do seu navegador e execute o jogo por completo: tela de carregamento, menu principal, jogo, morte/fim do jogo e transições de nível. Filtrar para quaisquer solicitações que vão para domínios externos. Incorporar esses ativos localmente ou, se forem serviços de terceiros (análise, anúncios que não sejam o SDK do YouTube), removê-los completamente. Execute a mesma verificação após cada atualização do build.
📌 Melhor Prática
O SDK YouTube Playables é a única dependência externa permitida. Tudo o mais deve ser autônomo. Isso inclui música. Se o seu jogo usa uma biblioteca de música de streaming, você precisará embutir os arquivos de áudio diretamente na compilação.
Erro #5: Botões de Anúncios Recompensados Estão Conectados Incorretamente
Como isso parece
O desenvolvedor adicionou um botão de anúncio recompensado, muitas vezes como uma adição tardia especificamente para Playables, porque o jogo original não tinha um mecanismo de recompensa. O botão aparece na interface do usuário, parece correto, mas pressioná-lo não faz nada. Nenhum anúncio é solicitado e nenhuma recompensa é concedida. Às vezes, o botão dispara visualmente (uma animação de toque) mas a chamada `requestRewardedAd()` está faltando, está no ponto de ciclo de vida errado ou a promessa não é tratada.
Uma falha relacionada: o anúncio recompensado é disparado, o usuário assiste ao anúncio, mas a recompensa nunca é entregue de fato — o valor de retorno `isRewardEarned` não é verificado ou o código de entrega da recompensa é escrito, mas nunca conectado ao manipulador do botão.
Por que ele falha na certificação
O conjunto de testes de certificação do Playables verifica explicitamente que as solicitações de anúncios recompensados completem seu ciclo completo: o anúncio é solicitado, exibido e a recompensa é condicionalmente concedida com base no valor de retorno. Um botão que não produz um anúncio quando pressionado é uma falha de certificação.
🛠️ Como Corrigir
Se os anúncios recompensados são novos para a mecânica do seu jogo, não os adicione como um elemento de interface do usuário cosmético e envie. Construa e teste o fluxo completo primeiro. Use o Conjunto de Testes do Playables no modo sandbox para verificar se a solicitação de anúncio é disparada, a promessa é resolvida e a branch de recompensa é executada. Se o seu jogo genuinamente não tem um mecanismo que suporte uma recompensa (nenhum currency consumível, nenhum sistema de vidas, nenhum momento pulável), considere pular anúncios recompensados em vez de implementar um stub quebrado.
🎮 MC Play Insight
Anúncios recompensados adicionados no último minuto especificamente para Playables são a fonte mais comum de integrações de anúncios quebradas que vemos. Se você está adaptando esse recurso, dê a ele a mesma atenção de teste que você daria à jogabilidade principal.
Learn more
Publique seu Jogo no YouTube Publique jogos mais rápido, gerencie a monetização, receba pagamentos rápidos e seguros em todo o mundo e obtenha suporte técnico premium de uma equipe que ajuda os desenvolvedores a crescer globalmente. [Apply Now](https://mediacube.io/en/form?form=cta&page=playables)
[Aplique Agora](https://mediacube.io/en/form?form=cta&page=playables)Erro #6: Alterações de Orientação Quebram o Layout
Como isso parece — duas variantes
Variante A: o conteúdo é cortado. O jogo gira corretamente quando o dispositivo alterna entre retrato e paisagem, mas os elementos próximos às bordas são cortados. A tela do jogo é dimensionada, mas a camada de interface do usuário não é repositionada para combinar, então os botões ficam atrás da área segura, o texto é parcialmente ocultado ou a janela de visualização do jogo corta o conteúdo que estava dentro dos limites antes da rotação.
Variante B: o canvas gira, a interface do usuário não. O jogo adapta seu canvas à nova orientação corretamente, mas ícones, elementos HUD e botões permanecem em suas posições de pixel originais que agora estão erradas para as novas dimensões da tela. Em uma tela móvel pequena ao alternar para o modo retrato, um botão que estava confortavelmente dimensionado no modo paisagem se torna um alvo de toque minúsculo e não responsivo.
Por que isso importa
Os YouTube Playables são executados em uma ampla gama de dispositivos e razões de tela. Os jogadores se movem entre orientações de forma fluida. Um jogo que quebra na alteração de orientação cria uma experiência frustrante e receberá uma pontuação de engajamento mais baixa do algoritmo, o que afeta diretamente a descoberta.
🛠️ Como Corrigir
Use padrões de layout responsivos: fixe os elementos da interface do usuário às bordas da tela usando posicionamento relativo (porcentagens ou flexbox), não valores de pixel absolutos. Teste ambas as orientações explicitamente com as ferramentas de emulação de dispositivos do navegador. Preste atenção às inserções da área segura em dispositivos móveis: o notch e a barra inferior podem alterar o espaço disponível entre as orientações. Se o seu jogo for projetado para apenas uma orientação, bloqueie-o explicitamente e comunique isso na sua submissão de build.
📋 Dica de Teste
O tratamento de orientação é fácil de ser negligenciado durante o desenvolvimento quando você está testando principalmente em um navegador de desktop. Inclua isso em sua lista de verificação de teste padrão.
Erro #7: O Jogo Continua em Execução Durante Anúncios Intersticiais
Como isso parece
Um anúncio intersticial é acionado, a sobreposição do anúncio aparece na tela, mas o jogo continua rodando em segundo plano. O jogador não pode ver o que está acontecendo, mas o loop do jogo ainda está ativo. Em um jogo de puzzle, isso é levemente irritante (o temporizador continua funcionando enquanto o jogador assiste ao anúncio). Em um jogo de ação ou sobrevivência, é um bug que termina a sessão: o personagem sofre dano, os inimigos avançam e, quando o anúncio termina, o jogador está morto sem poder ter reagido.
Por que isso importa
Anúncios intersticiais exigem que a atenção do jogador esteja no anúncio, não no jogo. Um jogo que não pausa durante um anúncio está penalizando o jogador pelo evento de monetização, o que é exatamente o oposto de uma boa experiência do jogador. O YouTube espera que os jogos pausem durante todos os eventos de anúncio.
🛠️ Como Corrigir
Trate uma solicitação de anúncio intersticial da mesma forma que um sinal de pausa. Antes de chamar
requestInterstitialAd()
, salve o estado do jogo e suspenda o loop do jogo. Depois que a promessa for resolvida (seja qual for o resultado, se um anúncio foi exibido ou não), retome. Trate erros com a mesma lógica de retomada — o jogo nunca deve ser deixado em um estado suspenso devido a um erro de anúncio.
O padrão de implementação:
- `pauseGame(); //` pare o loop do jogo e as entradas
- `try { await ytgame.ads.requestInterstitialAd(); } catch (e) { / trate com graça / }`
- `resumeGame(); //` sempre retome, independentemente do resultado
🎮 Dica Específica de Gênero
Isso é especialmente crítico para sobrevivência, corrida infinita, defesa de torre e qualquer gênero em tempo real onde o estado do jogo muda sozinho com o passar do tempo. Se o tipo de jogo se encaixa nessa descrição, teste o fluxo de intersticial explicitamente em condições de jogo.
Erro #8: O Jogo Só Funciona no Modo Tela Cheia
Como ele parece
O jogo renderiza uma tela preta, um loop de carregamento que nunca é concluído ou um layout distorcido quando lançado no player incorporado padrão do Playables. Abrir a mesma compilação no modo tela cheia faz com que tudo funcione corretamente. O jogo foi criado supondo a disponibilidade de tela cheia, e o player do Playables não garante isso.
Isso é comum em compilações portadas de aplicativos móveis que usavam um lançamento forçado em tela cheia, ou de jogos de desktop onde o desenvolvedor sempre testou em uma janela de navegador maximizada.
Por que ele falha na certificação
O YouTube Playables executa jogos em um contêiner incorporado dentro da interface do YouTube. O jogo deve renderizar corretamente em quaisquer dimensões e proporção de tela que o contêiner forneça. O modo tela cheia pode ou não estar disponível dependendo do dispositivo, plataforma e contexto do usuário. Um jogo que exige tela cheia para funcionar não pode passar na certificação.
🛠️ Como Corrigir
Remova qualquer requisito de tela cheia da inicialização do seu jogo. Desenhe o layout para funcionar nas dimensões fornecidas pelo contêiner. Use os eventos de redimensionamento do canvas e de alteração de orientação para se adaptar dinamicamente. Teste seu jogo em uma janela de navegador redimensionável em vários tamanhos. Se a tela cheia for uma funcionalidade que você deseja oferecer (como uma opção, não um requisito), implemente-a como um elemento de interface do usuário opt-in, não como uma dependência de lançamento.
Lista de Verificação Pré-Envio
Antes de enviar sua compilação para nós para pré-certificação, execute essa lista:
Pausar:
Acionar pausa via o Playables Test Suite. Confirmar que o loop do jogo para, as animações congelam, as entradas são bloqueadas e nenhuma ação em fila é executada após a retomada.
Silenciar:
Silenciar via o Test Suite. Abrir todas as telas e acionar todos os eventos do jogo enquanto silenciado. Atualizar a página enquanto silenciado. Confirmar que o áudio permanece desligado ao longo de tudo.
Salvos:
Completar vários níveis, fechar o navegador entirely, reabrir e confirmar que o progresso foi restaurado via ytgame.game.loadData().
Rede:
Abrir a guia Rede do navegador e executar o jogo completo. Zero solicitações para domínios externos (exceto o YouTube SDK). Empacotar tudo localmente.
Anúncios Recompensados:
Se implementado, pressionar todos os botões de anúncios recompensados e confirmar o ciclo completo: anúncio solicitado, anúncio exibido (na sandbox do Test Suite), recompensa entregue.
Orientação:
Testar retrato e paisagem na emulação de dispositivo móvel. Todos os elementos da interface do usuário visíveis, corretamente dimensionados e totalmente táteis em ambas as orientações.
Intersticiais:
Dispare um anúncio intersticial durante a jogabilidade ativa. Confirme se o jogo pausa antes do anúncio e retoma corretamente após.
Tamanho do Contêiner:
Teste em uma janela de navegador não em tela cheia em vários tamanhos. O jogo deve ser renderizado corretamente sem exigir o modo tela cheia.
Como Nós O Helpamos a Atravessar a Certificação Mais Rápido
Quando você publica através da Mediacube, executamos uma passagem de pré-certificação completa usando nossa plataforma interna MC Play antes que sua compilação chegue ao YouTube. Nossa equipe de QA verifica cada item da lista acima e captura problemas antes que se tornem ciclos de rejeição.
Nosso prazo de compilação para lançamento mais rápido é de 2 dias úteis. Uma compilação bem preparada sem problemas de QA geralmente vai ao ar dentro de uma semana. Se problemas forem encontrados durante a pré-certificação, fornecemos um relatório detalhado (bugs específicos, etapas de reprodução e soluções recomendadas) para que sua equipe saiba exatamente o que abordar.
Nós somos um parceiro oficial do YouTube desde 2015 e publicamos em Playables desde setembro de 2025. Todo jogo em nosso portfólio passou por esse processo. Nós sabemos o que a equipe de certificação do YouTube procura e sabemos como passar compilações.
Inicie a conversa e aplique aqui .
