APOSTILA PRÁTICA

Controles Mobile somente

no navegador mobile

Unity 6+ • Input System • Web/itch.io

Material para alunos iniciantes • O arquivo DetectorDispositivo.jslib será importado por Asset Package.

Objetivo Corrigir a exibição dos controles virtuais para que joystick, Pular e Atacar apareçam no navegador mobile, mas permaneçam escondidos no navegador desktop.

Curso Técnico em Jogos Digitais | Professor Camoleze

Legenda dos quadros

	Objetivo o que você vai conseguir fazer		O que mudou? a ideia nova da aula
	Atenção confira antes de continuar		Importante um cuidado para não errar
	Dica do Professor analogias e resumos		Ideia importante o conceito principal
	Hora do teste como verificar se deu certo		Conceitos aprendidos o que você levou da aula

1. Situação do projeto

O jogo já possui joystick virtual, botão Pular e botão Atacar funcionando pelo Input System. O problema aparece depois da publicação: a interface mobile também pode aparecer no navegador desktop quando usamos apenas a presença de touchscreen como critério.

Figura 1 — Antes, os controles de celular apareciam no desktop. Depois, cada dispositivo mostra a interface certa.

O que mudou? Antes perguntávamos se existia uma tela de toque. Agora vamos perguntar diretamente ao navegador se a página está sendo executada como mobile ou desktop.

Resultado esperado

Ambiente	Controles esperados
Unity Editor	Controlados manualmente pelo campo Testar Controles Mobile.
Navegador desktop	Joystick, Pular e Atacar escondidos.
Navegador mobile	Joystick, Pular e Atacar visíveis.

Roteiro desta aula

Vamos resolver o problema em cinco etapas. Use este mapa para saber onde você está.

1 Importar o pacote Seção 2

2 Atualizar o script Seções 3, 4 e 5

3 Configurar o Inspector Seção 6

4 Testar no Editor Seção 7

5 Publicar e testar Seções 9 e 10

Como o jogo decide mostrar os controles?

Logo que o jogo inicia, ele faz uma pergunta simples: “onde estou executando?”. A resposta define se a interface mobile fica ligada ou desligada.

Figura 2 — O caminho de decisão: no Editor vale o campo do Inspector; na Build Web quem responde é o navegador.

Arquitetura da solução

Veja o caminho completo da informação. Cada peça faz apenas uma tarefa e passa o resultado para a próxima.

Figura 3 — Da pergunta ao navegador até as ações do Player: seis peças, cada uma com sua responsabilidade.

2. Importando o Asset Package preparado pelo professor

Para facilitar o trabalho, o professor já preparou um Asset Package com a estrutura Plugins > WebGL e o arquivo DetectorDispositivo.jslib. Assim, ninguém precisa criar o arquivo JavaScript manualmente. Você pode importar o pacote de duas formas — escolha a que achar mais fácil.

Figura 4 — As duas formas de importar o arquivo .unitypackage na Unity.

Opção A — Import Package Com o projeto aberto, clique no menu Assets. Escolha Import Package > Custom Package… Selecione o arquivo .unitypackage fornecido pelo professor. Na janela Import Unity Package, mantenha os arquivos selecionados. Clique em Import.

Opção B — arrastar para Project Localize o arquivo .unitypackage no computador. Arraste o arquivo diretamente para a janela Project da Unity. Quando a janela de importação abrir, confira os arquivos. Clique em Import.

Conferência obrigatória Depois da importação, a pasta Assets deve conter Plugins > WebGL > DetectorDispositivo.jslib. Se essa estrutura não existir, não prossiga para a Build.

Estrutura esperada no Project

Figura 5 — A estrutura de pastas que deve aparecer na janela Project depois da importação.

3. O papel do DetectorDispositivo.jslib

O arquivo .jslib contém uma pequena função JavaScript que pergunta ao navegador se ele está rodando em um dispositivo mobile. Nesta aula, os alunos não precisam editar esse arquivo; ele funciona como uma ferramenta pronta importada pelo pacote.

Figura 6 — O .jslib faz a ponte entre o C# (Unity) e o JavaScript (navegador).

A função que a Unity vai chamar devolve apenas um número:

● ● ● Retorno da função

EhNavegadorMobile() 1 → navegador mobile 0 → navegador desktop

Dica do Professor Pense no .jslib como um tradutor: a Unity “fala” C# e o navegador “fala” JavaScript. O .jslib leva a pergunta de um lado e traz a resposta de volta.

Responsabilidades separadas O JavaScript apenas identifica o tipo de navegador. O Input System continua responsável pelo joystick e pelos botões. O Player continua responsável pelas ações do jogo.

4. Atualizando o GerenciadorControles.cs

Abra GerenciadorControles.cs e substitua a detecção antiga por esta versão simplificada. Ela mantém a possibilidade de testar a interface mobile dentro do Editor e usa o JavaScript somente na Build Web publicada.

● ● ● GerenciadorControles.cs — versão final didática

using UnityEngine; using System.Runtime.InteropServices; public class GerenciadorControles : MonoBehaviour { [Header(“Referências”)] [SerializeField] private GameObject controlesMobile; [Header(“Teste no Editor”)] [SerializeField] private bool testarControlesMobile; #if UNITY_WEBGL && !UNITY_EDITOR // Função disponível no DetectorDispositivo.jslib. [DllImport(“__Internal”)] private static extern int EhNavegadorMobile(); #endif private void Start() { // No Editor, usamos a opção manual do Inspector. bool mostrarControles = testarControlesMobile; #if UNITY_WEBGL && !UNITY_EDITOR // Na Build Web, o navegador decide. mostrarControles = EhNavegadorMobile() == 1; #endif // Ativa ou desativa todo o grupo de controles mobile. controlesMobile.SetActive(mostrarControles); } }

O que cada variável faz?

Elemento	Função
controlesMobile	Referência ao GameObject que contém joystick, Pular e Atacar.
testarControlesMobile	Permite mostrar a UI manualmente durante o desenvolvimento no Editor.
mostrarControles	Guarda a decisão final: true mostra; false esconde.
EhNavegadorMobile()	Pergunta ao navegador se ele é mobile.

Lendo o Start() em três passos

1. Começamos com o valor do Inspector: mostrarControles = testarControlesMobile.
2. Se estamos na Build Web, o navegador decide: EhNavegadorMobile() == 1 vira true no celular e false no computador.
3. Por fim, SetActive(mostrarControles) mostra ou esconde todo o grupo ControlesMobile de uma só vez.

5. Entendendo #if e #endif sem complicar

As diretivas #if e #endif são usadas aqui para diferenciar o código que pode existir no Editor do código que só deve ser usado na Build Web. Elas são avaliadas durante a compilação, ou seja, antes de o jogo rodar.

● ● ● Exemplo

#if UNITY_WEBGL && !UNITY_EDITOR // Este código entra na versão Web publicada. #endif

Figura 7 — A condição do #if decide se o trecho entra ou fica de fora do jogo.

Como ler a condição

Trecho	Leitura simples
UNITY_WEBGL	Estamos preparando/executando a versão Web.
!UNITY_EDITOR	Não estamos dentro do Editor da Unity.
&&	E.
#if … #endif	Inclua este trecho somente quando a condição for válida.

Dica do Professor O #if funciona como uma placa na porta: “só entra quem cumprir a regra”. Se a regra não for verdadeira na hora de compilar, o trecho nem chega a fazer parte do jogo.

Resumo para a turma #if e #endif permitem que o mesmo script use um comportamento durante os testes no Editor e outro comportamento na Build Web publicada.

6. Configurando o objeto no Inspector

1. Selecione GerenciadorControles na Hierarchy.
2. No campo Controles Mobile, arraste o GameObject Canvas > ControlesMobile.
3. Deixe Testar Controles Mobile desmarcado para o teste normal de desktop.
4. Marque Testar Controles Mobile somente quando quiser visualizar joystick e botões dentro do Editor.

Inspector esperado

Figura 8 — A Hierarchy com o grupo ControlesMobile e o Inspector do GerenciadorControles já configurado.

Importante Não coloque joystick, Pular e Atacar como referências separadas. Mantenha todos como filhos de ControlesMobile e ative/desative apenas o objeto pai.

7. Testando dentro do Editor

Antes de publicar, vamos testar os dois cenários dentro da própria Unity.

Teste A — comportamento desktop

1. Desmarque Testar Controles Mobile.
2. Pressione Play.
3. Confirme que joystick, Pular e Atacar estão escondidos.
4. Teste o personagem usando teclado ou gamepad.

Teste B — simulando a interface mobile

1. Pare o Play Mode.
2. Marque Testar Controles Mobile.
3. Pressione Play novamente.
4. Confirme que joystick, Pular e Atacar aparecem.
5. Teste os controles virtuais com o mouse.

Figura 9 — Os dois testes lado a lado: com a caixa desmarcada e com a caixa marcada.

O teste manual é proposital Dentro do Editor não estamos em um navegador mobile real. Por isso usamos a caixa Testar Controles Mobile para poder trabalhar confortavelmente na interface.

8. O Input System não muda

Nenhuma Action precisa ser refeita. O sistema de entrada continua exatamente igual. A alteração serve apenas para decidir se a UI dos controles virtuais deve aparecer.

Figura 10 — Cada controle virtual gera uma entrada de gamepad que o Input System entrega ao Player.

Ideia importante O joystick virtual gera entrada para o Input System. O DetectorDispositivo.jslib não movimenta o jogador; ele apenas decide se a interface mobile será exibida.

9. Criando e publicando uma nova Build Web

Figura 11 — O caminho até a nova versão do jogo: do Editor ao itch.io.

1. Desmarque Testar Controles Mobile.
2. Salve a cena e o projeto.
3. Abra File > Build Profiles.
4. Selecione o perfil Web.
5. Confirme que a cena correta está incluída.
6. Crie uma nova Build.
7. Atualize os arquivos do jogo no itch.io.

Evite testar apenas no Editor A detecção real de navegador mobile acontece na Build Web. Portanto, o teste definitivo deve ser feito depois da publicação.

10. Teste final no itch.io

No navegador desktop

Abra o jogo no Chrome, Edge ou Firefox do computador. O resultado esperado é a UI mobile escondida e o teclado/gamepad funcionando normalmente.

No navegador mobile

Abra a mesma página do itch.io em um celular. O resultado esperado é a interface mobile visível.

Figura 12 — O que acontece por dentro do jogo em cada navegador.

11. Checklist de diagnóstico

Algo deu errado? Procure o sintoma na tabela e confira o que está na coluna da direita.

Problema	O que conferir
Controles continuam no desktop	Veja se a Build nova realmente foi enviada ao itch.io e limpe/recarregue o cache do navegador.
Controles não aparecem no celular	Confirme Assets/Plugins/WebGL/DetectorDispositivo.jslib e faça uma nova Build.
Erro ao compilar	Confira se o arquivo .jslib veio corretamente pelo Asset Package e se o nome da função é EhNavegadorMobile.
Funciona no Editor, mas não na Web	Lembre que Testar Controles Mobile é apenas para o Editor; a Build usa o navegador.
Joystick aparece mas não move	Confira On-Screen Stick, Control Path e o binding da Action Move.
Botões não respondem	Confira On-Screen Button, EventSystem e os bindings Pular/Atacar.

12. Resumo final

Figura 13 — As três ideias que resolvem o problema.

Com essa alteração, a mesma Build Web pode oferecer uma experiência adequada para dois contextos: desktop sem poluição visual e mobile com controles de toque. O Player e o Input System permanecem iguais; apenas a exibição da interface muda conforme o navegador.

Conceitos aprendidos Asset Package • Plugins Web (.jslib) • integração C# ↔ JavaScript • compilação condicional (#if / #endif) • GameObject.SetActive() • Input System e controles On-Screen.

13. Referências oficiais

Referências consultadas para esta versão do material:

Unity 6 — Input System

https://docs.unity3d.com/6000.0/Manual/com.unity.inputsystem.html

Unity — Interaction with browser scripting / JavaScript plugins

https://docs.unity3d.com/Manual/web-interacting-browser-js.html

Unity — Platform dependent compilation

https://docs.unity3d.com/Manual/platform-dependent-compilation.html

Unity — Scripting API

https://docs.unity3d.com/ScriptReference/index.html