Caso esta seja a primeira vez que você lê conteúdos de nossa série, não perca a oportunidade de conhecer mais sobre nossa jornada de aprendizados no mundo do desenvolvimento de jogos digitais.
Por meio da elaboração de divertidos projetos práticos de programação de games, estamos aprendendo sobre as inúmeras possibilidades que ferramentas como o Unity nos oferecem para tirarmos do papel jogos dos mais diversos estilos gráficos e de gameplay.
A partir do primeiro texto da série, os passos necessários para o processo de desenvolvimento de um jogo são abordados, incluindo a instalação e a configuração da ferramenta Unity em nossos computadores, a definição de regras e objetivos de uma aventura virtual, a configuração e o posicionamento de elementos multimídias nos cenários do jogo, a codificação de comportamentos e das interações entre os diferentes elementos de uma fase, além da criação de menus, aplicação de regras de física e muito mais.
À primeira vista, tudo pode parecer muito complexo para quem não teve a oportunidade prévia de aprender programação de jogos ou mesmo de sistemas, entretanto, nossa série é desenvolvida justamente para auxiliar a quem tem a vontade de ver seus jogos se tornando realidade e ainda nem sabe bem ao certo por onde começar. Para isso, todas as decisões e passos que tomamos durante a concepção dos jogos são explicadas de forma a permitir que possamos aplicar os mesmos conceitos vistos nos exemplos em nossos projetos pessoais.
No momento, estamos trabalhando no desenvolvimento do game Consultório do Dr. Tratanildo. Trata-se de um puzzle inspirado em clássicos dos videogames e dos arcades, como Pac-Man (Namco, 1980) e Dr. Mario (Nintendo, 1990), porém com ambientação atualizada aos “novos tempos”, em um interessante (e excêntrico) consultório médico tridimensional.
Vale a pena conferir, por meio do índice disponibilizado no primeiro texto da série, os passos que estamos trilhando para desenvolver o jogo, além de descobrir como os outros dois jogos de nossa série, Forest Ping Pong e Motorista da Pesada, foram concebidos.
Dito isso, que tal aprendermos juntos a como trazer à vida aqueles projetos que habitam a sua mente há tanto tempo? Se gostou da ideia, não perca mais tempo e junte-se a nós em uma trilha de aprendizados repleta de novos conhecimentos e de muita diversão!
Ocultando a barra inferior da tela de game over
Ao finalizarmos a construção da ligação entre os componentes responsáveis pela passagem sequencial entre as fases, pudemos perceber que, apesar de termos construído uma interessante integração entre os módulos, teremos um bocado de trabalho pela frente para aparar as arestas de nosso game antes de prosseguirmos com a implantação de novas funcionalidades.
Na indústria de jogos, uma das profissões mais importantes é a de game tester. Seu papel é o de descobrir comportamentos indesejados em situações não triviais de jogo, permitindo que a equipe de programadores possa corrigir eventuais erros de programação ou de configuração antes de lançar um jogo ao público (ou mesmo após o lançamento, por meio de patches e atualizações).
Como estamos aprendendo a tirar do papel nossos próprios games e, ao menos por enquanto, não temos à disposição uma equipe grande de testers para nos auxiliar, é importante realizarmos por conta própria determinadas verificações para sabermos se as funcionalidades de nosso game estão aptas para serem jogadas sem sustos pelos gamers.
Precisaremos ajustar, por exemplo, certas situações envolvendo a exibição da mensagem de game over, tais como a presença de elementos indesejados da barra inferior do Canvas após o fim do tempo de tratamento, como pudemos perceber durante os testes finais de execução de nosso último encontro.
Para iniciarmos nossas intervenções de hoje, vamos abrir o projeto para edição. No Unity Hub, clique duas vezes sobre o item referente a ele. Na interface inicial do editor, na aba Project, abra a pasta Assets, Scenes e, por fim, clique duas vezes no ícone da cena ConsultorioScene.
Dentro do bloco de código correspondente às condições que serão executadas quando tempoRestante for menor do que zero, logo após o comando de desativação de visualizacaoLabirinto, acrescente a seguinte linha de comando:
FindObjectOfType<ConcedePilula>().barraInferior.gameObject.SetActive(false);
- Localizou-se um objeto ativo em cena com um componente de tipo ConcedePilula atrelado a si, por meio da função FindObjectOfType;
- Como, nas variáveis pertencentes à ConcedePilula, existe uma referência à barra inferior do Canvas (por meio da variável barraInferior), conseguiu-se desabilitar o objeto representante dessa barra, desativando-o pelo comando SetActive(false).
Salve o script, minimize o Visual Studio e realize uma simulação de execução para notar que, ao término do tempo de tratamento, já não há mais a presença da barra inferior no momento em que o jogador é derrotado:
Quando a derrota acontece longe do leito
Dando sequência ao nosso “momento game tester”, realize nova simulação de execução do jogo e experimente observar o que ocorre com o game ao se esgotar o tempo previsto para tratamento enquanto Tratanildo Doencita está transitando por seu consultório:
Pela simulação, podemos perceber que o módulo de controle da movimentação do médico pelo cenário permanece ativo mesmo após a determinação do game over, o que não é um comportamento esperado.
Para corrigirmos esse comportamento, interrompa a simulação da execução do jogo e volte ao Visual Studio. Logo após o código que inserimos agora há pouco no bloco de código da função Update, insira a seguinte linha de comandos:
FindObjectOfType<ControllerMov_Tank>(true).enabled = false;
Na nova linha de códigos acrescentada, logo após a definição do tipo de parâmetro a ser localizado, informamos o valor booleano true entre parênteses. Para essa função em específico, o valor true indica ao comando para que seja retornado um objeto ativo ou inativo que tenha o componente atrelado a si.
O comportamento padrão de FindObjectOfType é o de retornar apenas objetos ativos, o que nesse caso em específico não seria o suficiente, visto que o GameObject com esse tipo de script atrelado a si nem sempre está ativo em cena (DoutorCenario), o que representaria em um erro de execução ao não termos um objeto para desativar o componente.
No caso anterior, referente ao ConcedePilula, o GameObject do cenário que tem esse esse componente atrelado a si é JoystickLeito, sempre ativo em cena, independentemente do momento do tratamento.
Outra particularidade da nova linha acrescentada é a de que estamos desativando apenas o componente, e não o objeto inteiro, por meio do comando enabled = false. Essa desativação ocorre para que não haja um "sumiço" do doutor no cenário quando acabar o tempo de tratamento, ele apenas não irá se deslocar mais pelo cenário.
Salve o script, minimize o Visual Studio e, no editor do Unity, simule novamente a execução do game para notarmos o que mudou depois das intervenções realizadas.
Andando ou parado?
De fato, nosso querido médico parou de se movimentar pelo cenário, porém, pelo visto, ainda falta combinarmos essa parada com suas pernas e seus braços! Para que a animação dos membros de Tratanildo seja interrompida, teremos de realizar uma breve intervenção no conteúdo do script controlador de movimentos do personagem principal de nosso game.
No editor do Visual Studio, interrompa a simulação de execução do jogo. Em seguida, via aba Project, abra para edição o script de nome ControllerMov_Tank, clicando duas vezes sobre seu ícone.
Insira o seguinte bloco de códigos logo após o fechamento de chaves da função Start:
private void OnDisable()
{
personagemAnim.SetFloat("Passo_caminhada", 0);
}
Salve o script, feche o Visual Studio e retorne ao editor do Unity para experimentarmos novamente a simulação da execução de nosso jogo:
Próximos passos
Iniciamos nossa sequência de caça aos bugs corrigindo situações relacionadas ao momento do game over. Após realizarmos modificações importantes, ocultando elementos visuais indesejados e desabilitando os controles do personagem principal após o momento da derrota, prosseguiremos ajustando determinados aspectos de gameplay nos próximos encontros, permitindo que, futuramente, possamos finalizar as integrações entre os módulos do projeto.
Nosso próximo encontro será no dia 15 de fevereiro. Até mais! Fique sempre ligado nas novidades do GameBlast!
Revisão: Ives Boitano
