Por que a qualidade da construção é importante para os Playables
Publicar um jogo nos Playables do YouTube não é o mesmo que carregá-lo em outros portais da web. O YouTube executa seu próprio processo de certificação, uma revisão técnica obrigatória que toda construção deve passar antes de ir ao ar. Se a construção falhar, ela volta para o desenvolvedor para correções, reenvio e outra rodada de revisão. Cada ciclo custa tempo e esforço.
Na Mediacube, realizamos testes de pré-certificação em cada construção antes que ela chegue ao YouTube. Nosso time de QA revisou centenas de construções em Unity, Cocos, Phaser, Construct e outros motores. Os erros listados neste artigo são os que vemos com mais frequência entre estúdios de todos os tamanhos, motores e gêneros de jogos.
A maioria deles é rapidamente corrigível assim que você souber o que procurar. Leia isso antes de construir, não depois.
Erro #1: O Pause Não Pausa o Jogo
Como é
Quando um jogador muda para outra aba, minimiza o aplicativo ou o sistema solicita uma pausa, os Playables do YouTube enviam um sinal de pausa para o jogo por meio do SDK. Muitos jogos respondem a esse sinal exibindo seu menu de pausa interno, mas o loop principal do jogo continua a ser executado. Os ticks de física, os cronômetros de contagem regressiva continuam a contar, as animações seguem em andamento. Alguns elementos interativos ainda são clicáveis no estado de pausa.
Outra variante: O jogo parece congelar visualmente, mas armazena em buffer as entradas durante o congelamento. Quando o jogo retorna, ele executa todas essas ações armazenadas de uma só vez — e um personagem pula três vezes em sequência rápida, ou dispara uma arma que foi pressionada durante a tela de pausa.
Terceira variante (muito relatada em nossa pipeline de QA): O jogo exibe corretamente o menu de pausa interno, mas os botões desse menu são totalmente clicáveis. A pausa oficial dos Playables está em vigor e o jogador pode usar esse tempo para navegar nos menus, alterar configurações ou até reiniciar o jogo.
Por que falha na certificação
O contrato de pausa do SDK Playables é rigoroso: quando ytgame.system.onPause() é acionado, o jogo deve parar totalmente e não executar nenhuma animação, nenhuma física, nenhum processamento de entrada e nenhum temporizador. Qualquer desvio desse padrão é sinalizado durante o processo de certificação do YouTube.
O contrato de pausa do Playables SDK é rigoroso: quando ytgame.system.onPause() é acionado, o jogo deve parar totalmente e não executar nenhuma animação, física, processamento de entrada ou temporizadores. Qualquer desvio deste padrão é sinalizado durante o processo de certificação do YouTube.
🛠️ Como resolver
Registre o retorno de chamada onPause e certifique-se de que ele pare o loop do jogo, mute todas as animações, desative o tratamento de entrada e limpe todas as filas de ações pendentes. Ao retomar, restaure o estado a partir do ponto em que foi congelado: não repita as entradas bufferizadas. Teste isso explicitamente acionando a pausa por meio do Playables Test Suite, não apenas pelo botão de pausa dentro do jogo.
⚠️ Erro comum
Tratar a pausa do SDK do YouTube como equivalente ao botão de pausa dentro do jogo. Eles não são os mesmos. A pausa do SDK deve parar tudo dentro do loop do motor do jogo.
Erro #2: O Estado de Mudo Não é Persistente
Como é apresentado
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, muda de contexto ou tem o dispositivo em silêncio. O jogo deve respeitar esse estado de silêncio e manter o áudio desativado até que o YouTube o desative explicitamente.
Os principais modos de falha que vemos com mais frequência:
O silêncio é redefinido 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 reiniciar ou transitar para um novo nível, o silêncio é removido. O áudio retorna, mesmo que o YouTube ainda tenha o silêncio ativo.
O silêncio não sobrevive a uma recarga da página. Se a página for recarregada enquanto o jogo está silenciado (por meio do SDK), o jogo reinicia com o áudio ligado. O estado de silêncio foi armazenado na memória, não persistido, então a recarga o apaga.
O botão interno de silêncio substitui o silêncio do SDK. O SDK silencia o jogo, mas o jogador pode pressionar o interruptor de áudio no jogo para recuperar o som. É o controle interno do jogo que está ignorando o comando do SDK externo.
Por que falha na certificação
O Playables SDK fornece ytgame.system.isAudioEnabled() para verificar o estado de áudio atual e ytgame.system.onAudioEnabledChange() para ouvir alterações. Os jogos devem depender desses em vez de gerenciar seu próprio estado paralelo de áudio que pode ficar desincronizado.
🛠️ Como resolver
Inicialize o estado de áudio usando ytgame.system.isAudioEnabled() no início do jogo, antes de reproduzir qualquer som. Registre onAudioEnabledChange e aplique o novo estado imediatamente e globalmente quando for acionado. Persista o estado de mudo do SDK para que ele sobreviva a recarregamentos de página: grave-o em ytgame.game.saveData() para que o jogo o leia novamente na próxima execução. Não permita que os controles de áudio dentro do jogo substituam o estado do SDK; seu botão interno deve funcionar somente quando o SDK tiver o áudio habilitado.
✅ Checklist de Testes
Teste isso especificamente: mute via o Test Suite, dispare todos os eventos do jogo que você tem (menus, transições de nível, reinícios, mortes) e confirme que o áudio permanece desligado durante todo o processo. Em seguida, recarregue a página e confirme que ele permanece desligado após o recarregamento.
Pronto para Lançar nos YouTube Playables?
Crie sua conta e obtenha tudo o que precisa para publicar, monetizar e crescer seu jogo globalmente.
Erro #3: O Progresso Não é Salvo Entre Sessões
Como é
O jogador completa os níveis 1 até 5, fecha o navegador, abre o jogo novamente — 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, ambas as quais são apagadas ao fechar ou não disponíveis no ambiente de Playables.
Por que falha na certificação
O YouTube Playables não permite que os jogos utilizem o localStorage do navegador ou servidores externos de salvamento. Todos os dados persistentes do jogo devem passar pelo SDK Playables: ytgame.game.saveData() e ytgame.game.loadData(). Jogos que não implementarem isso perderão o progresso do jogador em cada sessão, o que é um motivo de rejeição imediato.
🛠️ Como Corrigir
Substitua quaisquer chamadas para localStorage.setItem() / getItem() por ytgame.game.saveData() e ytgame.game.loadData(). Essas aceitam uma string serializada até 3MB — serialize seu estado de salvamento como JSON, carregue-o ao iniciar e escreva-o sempre que houver progresso significativo (conclusão de nível, ponto de verificação, conquista importante). Não espere até o fim da sessão para salvar e use onPause como um gatilho adicional de salvamento, pois o jogo pode ser fechado a partir do modo pausa.
💡 Dica Profissional
Se o seu jogo foi originalmente construído para mobile ou desktop com um sistema de salvamento em nuvem ou armazenamento do dispositivo, dedique tempo para refatorar isso. É uma das fontes mais comuns de atraso no certificação de uma versão móvel em Playables.
Erro #4: O Jogo Tenta Carregar Recursos de URLs Externas
Como é
O jogo falha em carregar ou carrega parcialmente com música ausente, recursos visuais ausentes ou áudio silencioso quando executado no ambiente Playables. No console do navegador, você vê erros de rede: solicitações a CDNs externos, servidores de recursos, APIs de música streaming ou provedores de fontes de terceiros que estão sendo bloqueadas.
Às vezes isso é óbvio (o jogo foi construído para transmitir sua trilha sonora de um serviço externo), e outras vezes é sutil (uma fonte web carregada do Google Fonts, um pixel de análise, uma única atlas de sprites hospedada em um CDN que nunca foi embalada na construção).
Por que falha na certificação
O YouTube Playables opera em um ambiente com sandbox. Chamadas de API externas e solicitações a domínios externos não são permitidas. Tudo o que o jogo precisa para funcionar deve estar embalado na própria construção. Isso inclui: arquivos de áudio, atlas de texturas, fontes, strings de localização, arquivos de configuração e quaisquer scripts de terceiros.
🛠️ Como resolver
Antes de enviar, abra a aba Rede do seu navegador e percorra o jogo completamente: tela de carregamento, menu principal, jogabilidade, morte/fim de jogo e transições de nível. Filtrar quaisquer solicitações que vão para domínios externos. Embale esses recursos localmente, ou se forem serviços de terceiros (análise, anúncios outros que não o SDK do YouTube), remova-os completamente. Execute a mesma verificação após cada atualização de construção.
📌 Boa Prática
O SDK de Playables do YouTube é a única dependência externa permitida. Tudo o restante deve ser autossuficiente. Isso inclui música. Se o seu jogo usar uma biblioteca de música streaming, você precisará embalar os arquivos de áudio diretamente na compilação.
Erro #5: Botões de Anúncio de Recompensa estão Conectados Erroneamente
Como é
O desenvolvedor adicionou um botão de anúncio de recompensa, frequentemente como uma adição tardia especificamente para Playables, porque o jogo original não tinha 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á ausente, colocada no ponto de ciclo de vida errado ou a promessa não é tratada.
Falha relacionada: o anúncio de recompensa é acionado, o usuário assiste ao anúncio, mas a recompensa nunca é realmente entregue — o valor de retorno isRewardEarned não é verificado, ou o código de entrega da recompensa foi escrito, mas nunca conectado ao manipulador do botão.
Por que falha na certificação
O conjunto de testes de certificação de Playables verifica explicitamente que as solicitações de anúncios de recompensa completam seu ciclo completo: o anúncio é solicitado, exibido e a recompensa é concedida condicionalmente com base no valor de retorno. Um botão que não produz um anúncio quando pressionado é uma falha na certificação.
🛠️ Como resolver
Se os anúncios de recompensa forem novos para os mecanismos do seu jogo, não os adicione como um elemento de interface do usuário cosmético e submeta. Construa e teste o fluxo completo primeiro. Use o conjunto de testes de Playables no modo sandbox para verificar se a solicitação do anúncio é acionada, a promessa é resolvida e a ramificação da recompensa é executada. Se o seu jogo realmente não tiver um mecanismo que suporte uma recompensa (nenhuma moeda consumível, nenhum sistema de vidas, nenhum momento skipável), considere pular os anúncios de recompensa em vez de implementar um stub quebrado.
🎮 Insight MC Play
Os anúncios de recompensa adicionados no último momento especificamente para Playables são a fonte mais comum de integrações de anúncios quebradas que vemos. Se você estiver adicionando esse recurso de forma retroativa, dê a ele a mesma atenção de teste que você daria ao gameplay principal.
Publique seu Jogo no YouTube
Publique jogos mais rapidamente, gerencie 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 crescerem globalmente.
Erro #6: Mudanças de Orientação Quebram o Layout
Como é — dois variantes
Variante A: conteúdo é cortado. O jogo gira corretamente quando o dispositivo muda entre paisagem e retrato, mas os elementos próximos às bordas são cortados. A tela do jogo escala, mas a camada de interface não se reposiciona para corresponder, então os botões ficam atrás da área segura, o texto fica parcialmente oculto ou o viewport do jogo corta conteúdo que estava dentro dos limites antes da rotação.
Variante B: a tela gira, a interface não. O jogo adapta sua tela à nova orientação corretamente, mas os ícones, elementos HUD e botões permanecem em suas posições pixelar originais, que agora estão incorretas para as novas dimensões da tela. Em uma tela pequena de celular mudando para modo retrato, um botão que estava confortavelmente dimensionado em paisagem torna-se um pequeno alvo de toque inativo.
Por que importa
YouTube Playables funciona em uma ampla gama de dispositivos e proporções de tela. Os jogadores mudam entre orientações de forma fluida. Um jogo que quebra na mudança 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 resolver
Use padrões de layout responsivo: anexe os elementos da interface às bordas da tela usando posicionamento relativo (porcentagens ou flexbox), não valores absolutos em pixels. Teste ambas as orientações explicitamente com as ferramentas de desenvolvedor do navegador para emular dispositivos. Preste atenção nos insets da área segura em dispositivos móveis: o notch e a barra inferior podem mudar o espaço disponível entre as orientações. Se o seu jogo for projetado para uma única orientação, bloqueie-a explicitamente e comunique isso em sua submissão de build.
📋 Dica de Teste
O tratamento de orientação é fácil de ignorar durante o desenvolvimento quando você está testando principalmente em um navegador de desktop. Inclua-o em sua lista padrão de testes.
Erro #7: O jogo continua rodando durante anúncios intersticiais
O que 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 consegue ver o que está acontecendo, mas o loop do jogo ainda está ativo. Em um jogo de quebra-cabeça, isso é levemente irritante (o temporizador conta enquanto o jogador assiste ao anúncio). Em um jogo de ação ou sobrevivência, é um bug que encerra a sessão: o personagem sofre dano, os inimigos avançam e, quando o anúncio termina, o jogador já está morto e não tem como reagir.
Por que é importante
Anúncios intersticiais exigem que o jogador esteja atento ao anúncio, não ao jogo. Um jogo que não pausa durante um anúncio está punindo 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 resolver
Trate a solicitação de um 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. Após a resolução da promessa (seja ou não exibido um anúncio), retome. Trate erros com a mesma lógica de retomada — o jogo nunca deve ficar em estado suspenso devido a um erro de anúncio.
Padrão de implementação:
- pauseGame(); // para o loop do jogo e as entradas
- try { await ytgame.ads.requestInterstitialAd(); } catch (e) { / trate com elegância / }
- resumeGame(); // sempre retome, independentemente do resultado
🎮 Dica Específica por Gênero
Isso é especialmente crítico para os gêneros de sobrevivência, corrida infinita, defesa de torres e qualquer gênero em tempo real em que o estado do jogo mude sozinho com o tempo. Se o seu jogo se enquadra nessa descrição, teste o fluxo de anúncio intersticial explicitamente sob condições de jogo.
Erro #8: O jogo só funciona no modo de tela cheia
O que parece
O jogo exibe uma tela preta, um loop de carregamento que nunca termina ou um layout distorcido ao ser iniciado no jogador embutido padrão Playables. Abrir a mesma versão no modo de tela cheia faz tudo funcionar corretamente. O jogo foi construído assumindo que a tela cheia estará disponível, e o jogador Playables não garante isso.
Isso é comum em builds transferidos de aplicativos móveis que usavam um lançamento em tela cheia, ou de jogos para desktop onde o desenvolvedor sempre testava em uma janela de navegador maximizada.
Por que falha na certificação
YouTube Playables executa jogos em um contêiner embutido dentro da interface do YouTube. O jogo deve renderizar corretamente com quaisquer dimensões e proporção de aspecto que o contêiner forneça. O modo de 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 pela certificação.
🛠️ Como resolver
Remova qualquer requisito de tela cheia da inicialização do seu jogo. Projete o layout para funcionar com as dimensões fornecidas pelo contêiner. Use os eventos de redimensionamento da tela e mudança 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 um recurso que você deseja oferecer (como uma opção, não como um requisito), implemente-o como um elemento de interface de usuário opcional, não como uma dependência de lançamento.
Checklist Pré-Submissão
Antes de enviar sua build para nós para pré-certificação, percorra esta lista:
Pausa: Ative a pausa por meio do Playables Test Suite. Confirme que o loop do jogo para, as animações congelam, as entradas são bloqueadas e nenhuma ação agendada é disparada ao retomar.
Mudo: Ative o modo mudo por meio do Test Suite. Abra todas as telas e dispare todos os eventos do jogo enquanto está mudo. Atualize a página enquanto está mudo. Confirme que o áudio permanece desligado durante todo o processo.
Salvos: Complete vários níveis, feche o navegador completamente, reabra e confirme que o progresso foi restaurado por meio de ytgame.game.loadData().
Rede: Abra a aba Rede do navegador e execute todo o jogo. Nenhuma solicitação a domínios externos (exceto o SDK do YouTube). Embale tudo localmente.
Anúncios Recompensados: Se implementados, pressione todos os botões de anúncios recompensados e confirme o ciclo completo: solicitação do anúncio, exibição do anúncio (no ambiente de sandbox do Test Suite), entrega da recompensa.
Orientação: Teste retrato e paisagem na emulação de dispositivo móvel. Todos os elementos da interface visíveis, corretamente dimensionados e totalmente toque em ambas as orientações.
Anúncios Intersticiais: Dispare um anúncio intersticial durante o jogo ativo. Confirme que o jogo pausa antes do anúncio e retoma corretamente após.
Tamanho do Container: 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 de tela cheia.
Como Nós Ajudamos Você a Passar pela Certificação Mais Rápido
Quando você publica por meio da Mediacube, executamos uma verificação prévia completa usando nossa plataforma interna MC Play antes que seu build chegue à YouTube. Nosso time de QA verifica cada item da lista acima e identifica problemas antes que se tornem ciclos de rejeição.
Nosso cronograma mais rápido de build para live é de 2 dias úteis. Um build bem preparado sem problemas de QA geralmente fica online dentro de uma semana. Se forem encontrados problemas durante a pré-certificação, nós lhe fornecemos um relatório detalhado (bugs específicos, etapas para reprodução e recomendações de correções) para que seu time saiba exatamente o que resolver.
Nós somos um parceiro oficial da YouTube desde 2015 e temos publicado em Playables desde setembro de 2025. Todos os jogos da nossa carteira passaram por esse processo. Nós sabemos o que a equipe de certificação da YouTube procura, e sabemos como conseguir que os builds passem.
Inicie a conversa esolicite aqui.
