A downloadable text

Dedico este texto aos meus amigos Bruno, Henrique e Guilherme, que me deixaram jogar videogame em suas casas quando eu não tinha nenhum. Agradeço ao Alessandro, o compositor da trilha sonora de Bolota Strikes Back, e ao Bruno, que atuou como testador. Sem eles, o projeto não teria acontecido. Agradeço também à minha amiga Isabel pela revisão do texto. Por fim, dedico ao meu melhor amigo, Akamaru, que conheci quando sonhava em ser um desenvolvedor e que fez questão de me acompanhar até que eu me tornasse um.

Introdução

Meu avô trabalhava com serralheria. Desde que eu era pequeno, era comum vê-lo fazer reformas e melhorias em casa. Sempre chamava a minha atenção como ele realizava tudo da melhor maneira possível: ele estudava as soluções, escolhia o melhor material e aplicava tudo do jeito mais efetivo. Não é à toa que existe um banquinho feito por ele que dura há mais de 40 anos. Todo esse primor por excelência me influenciou em tudo que eu faço.

Com desenvolvimento de jogos, não é diferente. Embora serralheria e programação sejam campos distintos, em ambos, se um projeto não for bem concebido, ele pode ficar mal feito ou até mesmo ser perdido. Assim como meu avô me ensinou as melhores técnicas para construir e reformar objetos, de modo que eu conseguisse fazê-los sozinho, espero que este artigo inspire e auxilie outros desenvolvedores a criar jogos com excelência.

Criando Bolota

Antes de falar sobre Bolota Strikes Back, meu segundo jogo, eu gostaria de voltar um pouquinho no tempo e falar sobre Bolota, meu primeiro jogo.

Ao desenvolver um jogo pela primeira vez, é natural que desenvolvedores tenham, no início de sua jornada, protótipos e conceitos que nunca chegam à versão final. É comum que o conhecimento não seja suficiente no princípio, que nem todas as técnicas sejam conhecidas ou que não haja acesso a determinadas ferramentas. Além disso, surgem muitas dúvidas: qual jogo deve ser lançado, quais recursos ele deve ter, se será atrativo o suficiente...

Dito isso, não é incomum que haja frustração nesse período. A solução para esse problema é lançar um jogo. Apesar das inseguranças, é necessário que o desenvolvedor defina como será seu primeiro jogo. Nesse contexto, Bolota surgiu.

Bolota, disponível para Android, é um jogo simples, do gênero arcade, no qual o jogador precisa coletar o maior número de maçãs possível enquanto desvia de inimigos. Semelhante ao clássico Snake, é possível controlar a Bolota nas direções horizontal e vertical. De tempos em tempos, um item aparece para ajudar o jogador a progredir.

Jogabilidade de Bolota, meu primeiro jogo


Embora ainda tenha espaço para várias melhorias, Bolota cumpre seu papel: é meu primeiro jogo, é divertido e foi bem recebido. É bom o bastante para passar um tempo jogando. Mas o mais importante é o que aprendi durante seu desenvolvimento. Além disso, mesmo que de forma simples, o universo de Bolota ganhou suas primeiras características, como seus personagens, inimigos e itens.

Em dezembro de 2021, decidi fazer um novo jogo. Enquanto várias ideias pairavam sobre minha mente, uma coisa era certa: eu gostaria de produzir um jogo cujo gênero fosse bem conhecido e estabelecido. Similar a Bolota, uma vez que os jogadores conhecem o gênero do jogo, não é necessário explicar todas as regras novamente. Não é à toa que muitos jogos dos anos 80 e 90 eram clones de outros mais famosos.

Após pensar um pouco, decidi apostar no gênero infinite runner, que é bem conhecido por jogadores de celular. Jogos como Subway Surfers são exemplos interessantes de que o uso de mecânicas simples pode resultar num jogo com horas de duração. E o celular é um ambiente propício para jogos nesse estilo.


Uma screenshot de Subway Surfers (Android/iOS).

No segundo jogo de Bolota, utilizei a regra mais comum do gênero, que é fazer com que a personagem “corra” por três colunas. Os itens são distribuídos de forma aleatória, e o jogador utiliza seus reflexos para coletar pontos e desviar de coisas que não são boas. Para ter um diferencial, decidi desenvolver uma mecânica de risco e recompensa que não encontrei em jogos do gênero.

Em Bolota Strikes Back, o jogador pode rebater um item que dá pontos, sem obter uma recompensa imediata, para que o número de pontos do item aumente. Quanto mais vezes o jogador rebater o item, mais pontos ele acumula. Se o jogador, então, coletar o item, ele obtém os pontos acumulados; se não o coletar, não obtém nenhum ponto. Com isso, eu consegui abrir espaço para jogadores de estilos variados: alguns podem ser mais conservadores e apenas coletar o item instantaneamente, enquanto outros podem se arriscar e tentar ganhar mais pontos (ou perder tudo).

Jogabilidade de Bolota Strikes Back.

Para os controles do jogo, tentei tirar o máximo proveito de como as pessoas usam o celular. O conceito era semelhante ao que a Nintendo fez com o Wiimote. Diferente de um controle de videogame normal, o Wiimote imita um controle remoto, que é mais habitual e está presente no dia a dia das pessoas (ao menos, em 2006). Não é à toa que o console fez muito sucesso com o público casual. No caso do meu jogo, a minha ideia era que ele pudesse ser jogado com apenas uma mão, com o celular na vertical, usando a parte inferior da tela, onde as pessoas tendem a deixar o polegar.

Essa posição da mão é a mais comum quando se segura um celular

As regras do universo Bolota

Estabelecidas as primeiras bases, era preciso revisitar o primeiro jogo para seguir com as características dele, para não causar estranheza aos jogadores. É muito comum que, em franquias já bem estabelecidas, os itens e ícones sejam repetidos, mesmo que tenham funcionalidades diferentes.

Considere a série Super Mario, por exemplo. Seja qual for o jogo — Super Mario Bros., Mario Odyssey ou Mario Kart —, os jogadores esperam que os cogumelos vermelhos causem um efeito positivo e que os cascos verdes tenham consequências negativas. Mesmo que funcionem de maneiras diferentes em cada jogo, no fim, todos fazem sentido no universo Mario.


Cogumelo da franquia Super Mario Bros. Além da aparência, ele tem um efeito sonoro icônico.

Esse fator foi decisivo para que eu reutilizasse praticamente todos os itens do jogo anterior. Mesmo com uma base inferior de jogadores, se comparado à franquia da Nintendo, eu deveria ser coerente com as regras que eu mesmo estabeleci.

No meu entendimento, itens podem ser utilizados como recursos que dão vantagens ou quebram um pouco as regras do jogo. Um exemplo relevante que gosto de seguir são os itens dos jogos 2D do Sonic. Disponíveis em monitores, existem itens que deixam o jogador super-rápido ou invencível por alguns instantes. Também existem escudos que, além de protegerem o Sonic, fazem com que ele atraia anéis ou impedem que ele se afogue.


Os monitores presentes em Sonic 3 (Mega Drive).

Em Bolota Strikes Back, reaproveitando o que foi utilizado no primeiro jogo, os itens funcionam da seguinte forma:

- Maçã: faz o jogador pontuar;
- Inimigos: fazem o jogador perder vida;
- Relógio: diminui o intervalo entre a queda dos itens;
- Estrela: deixa a Bolota invencível;
- Coração: dá uma vida ao jogador.

Além desses, foram criados dois itens adicionais, que faziam sentido no estilo de jogo proposto:

- Gravidade: diminui a velocidade da queda dos itens;
- Escudo: protege o jogador de um hit dos Inimigos.


Itens disponíveis: Estrela, Escudo, Gravidade, Coração e Relógio.

Dois itens de Bolota não foram incluídos:

- Bota: Este item fazia com que a Bolota se movimentasse mais rápido. Não achei que aumentar a velocidade das colunas daria alguma vantagem. Além disso, jogadores diziam que, depois de uma certa quantidade de Botas, era muito difícil controlar a Bolota.
- Caveira: Este item surgia como um item aleatório que tirava uma vida do jogador. Para os jogadores, era um pouco frustrante quando, depois de sobreviver até o item aparecer, perdiam uma vida ao coletá-lo.

Outro feedback que influenciou a criação de uma nova mecânica tinha a ver com o fato de que os Inimigos em Bolota não podiam ser destruídos nunca. No segundo jogo, a Estrela pode destruir os Inimigos, e os Inimigos também podem ser rebatidos e destruídos depois de três hits. Em compensação, um novo Inimigo, o Inimigo Vermelho, foi criado — esse sim, invencível.

Após a revisão de todos esses conceitos, foi criada a primeira versão de Bolota Strikes Back:

Curiosamente, o código e a estrutura da versão final permanecem bem semelhantes, com poucas mudanças feitas após apontamentos dos jogadores, que serão mencionados mais tarde. A adição da arte e dos efeitos visuais fazem parecer que o projeto final é um jogo diferente do protótipo, mas não é o caso.

Dando cor e vida ao universo

Com mecânicas e fluxo de jogo definidos, era hora de caprichar na arte. É nesse momento que o projeto deixa de ser somente um protótipo e se torna um jogo marcante. Pense no seu jogo preferido. Imagine como seria descrever suas melhores partes para alguém. Certamente, além das mecânicas principais e da história, você mencionará os detalhes da animação:

— Olha, se o Sonic ficar parado por alguns segundos, ele vai bater o pé com impaciência!

Ou até mesmo como é gostoso navegar pelos menus:

Persona 5 tem a melhor HUD do mundo! É TÃO divertido mudar as opções!


Persona 5 se destaca por ter uma interface muito divertida, deixando as batalhas e os menus mais agradáveis.

Uma das primeiras mudanças que fiz foi melhorar o design da personagem Bolota. O desenho original tinha os olhos bem separados, com pequenas variações de cores, que não eram muito perceptíveis devido à tela pequena do celular. Além disso, esses efeitos de sombra e brilho poluíam um pouco a aparência da personagem.

No segundo jogo, além de suavizar as bordas, removi o excesso de cores, dando a ela um visual mais limpo. Os olhos ficaram mais próximos um do outro e mais cilíndricos, com um aspecto mais cômico. Com os olhos mais perto do centro e longe da borda, eu pude, inclusive, criar animações melhores, dando a eles um efeito de “gelatina” quando a Bolota se mexe para os lados.


O aspecto visual da Bolota foi simplificado, com uma menor quantidade de cores e os olhos em destaque.

Essa mudança também se refletiu no desenho dos Inimigos.


Os Inimigos também seguiram o mesmo padrão de mudança, embora essa versão tenha sofrido alterações em outras atualizações.

Os itens também passaram por um processo semelhante. Antes eles possuíam um degradê que era quase impossível de notar. O lado bom de simplificar o uso de cores é que não é necessário detalhar muito o desenho para fazer com que ele chame atenção. Veja, por exemplo, as animações dos itens Escudo e Gravidade:


 As animações dos itens procuram um equilíbrio entre dar vida aos itens e não destacá-los muito.

Por falar no Escudo, quando a Bolota está protegida, tentei passar a impressão de que ela está envolvida por uma bolha, desenhando sobre ela um círculo com um reflexo de luz. Essa técnica foi totalmente inspirada nos escudos elétrico e de água usados em Sonic 3 & Knuckles.

 

Sonic, mais uma vez, mostra-se como uma grande influência no quesito animações.

Um dos elementos mais divertidos de trabalhar foi a barra de vida. O objetivo era que os jogadores pudessem visualizar de forma mais fácil e intuitiva quando fossem atingidos pelos Inimigos e quando conseguissem aumentar sua vida. Portanto, segui uma técnica muito utilizada em jogos de luta, nos quais a barra de vida mostra a quantidade de dano que o jogador perdeu antes de ser reduzida.

Para reproduzir esse efeito, foi necessário controlar três barras diferentes: uma amarela (padrão), uma verde e uma vermelha (essas últimas utilizadas no efeito). A princípio, todas as barras têm o mesmo tamanho, sendo sobrepostas pela amarela. Quando o jogador ganha uma vida, a barra verde aumenta, e a cada segundo, a barra amarela aumenta até ficar na mesma medida, dando esse efeito de preenchimento progressivo. Quando o jogador perde uma vida, a lógica é semelhante: a barra amarela diminui de forma imediata, e quem a acompanha pouco a pouco é a vermelha.


 O funcionamento da barra de vida.

Abaixo da barra de vida, também são exibidos os pontos, que aumentam conforme as Maçãs são coletadas. Quando o jogador coleta uma Maçã, os pontos são incrementados, e ao lado aparece um pequeno sinal de mais (+) acompanhado do número de pontos que aumentaram, dando a sensação de que o jogador está colocando os números ali dentro.

            
Animação do ganho de pontos, que enriquece o visual.

Diferente de Persona 5 e Majora’s Mask, Bolota não tem história — é só uma coisa amarela com fome. Para compensar, foquei em outros elementos que deixariam o jogo visualmente mais agradável. O jogo possui uma temática espacial, porque é um tema que eu gosto, é bonito e não faz sentido — e uma coisa amarela comendo maçãs pelo espaço não precisa mesmo fazer sentido.

Para o cenário, criei diferentes estrelas, com animações diferentes, e apliquei uma técnica chamada parallax, pela qual objetos a distâncias diferentes do primeiro plano se movem a velocidades diferentes. Tomei cuidado para que o cenário também não ficasse muito poluído e distraísse o jogador.

O ícone do jogo também recebeu uma atenção especial. Tentei fazer uma referência à mecânica principal, que é rebater as Maçãs, colocando a fruta acima da Bolota. Além de dar um pouco mais de identidade ao ícone, é um pequeno resumo do que é o jogo.


Ícone do atalho do jogo, que destaca sua mecânica principal.

Embora não esteja relacionado ao jogo diretamente, também quis dar uma atenção maior ao menu principal. Seguindo a temática espacial, além do fundo com estrelas, todos os botões na tela se mexem bem devagar, como se estivessem flutuando em gravidade zero. Esse efeito foi um pouco difícil de fazer, pois, em diversos momentos, os botões se mexiam na mesma direção e velocidade, o que resultava num efeito bem artificial. Depois de corrigir botão a botão, cheguei ao efeito desejado.


Os botões flutuando nos menus dão uma sensação de falta de gravidade.

Por fim, as alterações e os trabalhos efetuados na área artística não têm efeito nenhum na jogabilidade; as regras do jogo não sofreram nenhuma alteração após a inclusão dos desenhos e das animações. Todavia, todo esse trabalho tem um impacto enorme na experiência do jogador, tornando o jogo mais proveitoso e prazeroso de jogar. Os jogadores gostam dessa sensação visual, e é por isso que existe, por exemplo, um mercado de dados de RPG personalizados, com diversas cores e efeitos. Todos os dados funcionam da mesma maneira, mas alguns são mais bonitos que outros.

Desafios durante o desenvolvimento

Fazer um jogo tem algumas certezas. Uma delas é que, inevitavelmente, você terá problemas durante a construção do jogo. É claro, existem diversas técnicas e fundamentos que são utilizados para minimizar o risco, mas sempre existirá algum problema que está fora do seu controle.

Durante o desenvolvimento, alguns pacotes da Unity — conjunto de funcionalidades utilizadas para programação ou implantação de recursos — ficaram desatualizados. Se eu os atualizasse para uma nova versão, poderia perder algo no processo, mas, se não fizesse isso, o pacote do jogo não poderia ser gerado. Lembro de ficar bem ansioso enquanto o programa fazia a atualização. Mas, após fazer uma revisão e ajustar alguns códigos, deu tudo certo. Percebi que, se eu tivesse utilizado a versão mais recente de todos os pacotes desde o início, isso não teria acontecido. Faltou um pouco de atenção a essa questão.

Em algum momento do desenvolvimento do jogo, eu e Bruno, o tester nos deparamos com uma situação inusitada: algumas Maçãs davam mais pontos do que o esperado. Ao rebater a Maçã uma vez, em vez de receber dois pontos, o jogador recebia três. Não identificamos nenhuma condição para isso acontecer; na verdade, acontecia pouquíssimas vezes.

Não conseguíamos encontrar um motivo para isso. Reiniciávamos o jogo, rebatíamos a Maçã algumas vezes, e tudo continuava normal. Dias depois, acontecia novamente, sem razão alguma. Em algum momento, desconfiei que eu estava ficando cansado e confuso e, na verdade, os pontos estavam corretos. Infelizmente, não estavam. Para confirmar, fiz o número de pontos aparecer ao lado da Maçã e percebi que o problema de fato existia.

O pior problema que um programador pode encontrar é a intermitência: algo nunca funcionar não é tão ruim quanto funcionar às vezes. Se você trancar uma porta, mas a fechadura não fechar, o problema está na fechadura e trocá-la resolve o problema. Mas se, no mesmo cenário, a fechadura fechar às vezes, não dá para saber se o problema está na fechadura, se é a chave que não encaixa direito ou se é o batente que não está correto. Era assim que eu me sentia com esse bug. Num determinado momento, eu quase considerei deixar isso como um elemento do jogo — aleatoriamente, uma Maçã poderia valer mais pontos. Mas não era isso que eu queria.

Felizmente, reproduzindo o jogo quadro a quadro, consegui chegar na origem do problema. A Bolota e a Maçã possuem caixas invisíveis ao seu redor, que são os colisores. Quando um objeto encosta no outro, o código faz com que a Maçã suma e o jogador ganhe um ponto ou, se o jogador rebatê-la, faz com que a Maçã suba e adicione um ponto ao seu total. Mas, em nenhum momento, eu verificava se o jogador já havia encostado na Maçã. Isso fazia com que, em alguns quadros, os colisores continuassem a encostar um no outro e, portanto, a fruta continuasse a acumular pontos. Deu uma sensação de alívio gigantesca entender o que estava ocorrendo e corrigir isso.

As linhas verdes em volta dos objetos indicam os seus colisores.

3, 2, 1... Lançar!

Em 15 de setembro de 2022, Bolota Strikes Back foi lançado! Embora a sensação de dever cumprido reinasse, eu também tinha a certeza de que o trabalho com o jogo não acabaria aí. Eu já pensava em realizar atualizações, incluindo novas conquistas ou rankings. Eu também queria receber feedback dos usuários e modificar o que fosse necessário.

Um dos primeiros indicadores de sucesso que tive é que, além dos parabéns, recebia sugestões de como poderia melhorar o jogo. Inclusive, num comentário, recebi 16 sugestões de uma mesma pessoa, e depois de um tempo, ela me mandou mais umas 10. Isso significava que as pessoas estavam baixando e jogando por um tempo, até chegarem à conclusão do que poderia ser modificado. Por fim, as alterações foram tão significativas que eu considero a versão lançada do jogo (1.0) bem diferente da versão mais atualizada (1.7).

Atualizações no visual

Após o lançamento do jogo, alguns jogadores notaram que o Coração e os Inimigos Vermelhos poderiam ser confundidos com as Maçãs, principalmente em alta velocidade. Para corrigir isso, desenhei uma linha branca em volta do Coração e alguns espinhos ao redor dos Inimigos Vermelhos, dando a eles um visual totalmente diferente.



 

Mudanças visuais em relação às versões iniciais.

Essas correções são curiosas, porque esse problema não foi notado durante o desenvolvimento, embora, falando agora, pareça óbvio. Esse tipo de acontecimento é recorrente, pois, quando estamos habituados ao desenvolvimento de um projeto, é comum ficarmos com os olhos “viciados” e não questionarmos o que fizemos. Além disso, punir os jogadores por uma falha de design é muito frustrante. Portanto, era uma das minhas prioridades resolver isso o quanto antes.

Uma alteração no visual que foi divertida de fazer foi criar um feedback da pontuação das Maçãs. Na versão do lançamento, o único jeito de saber se uma Maçã valia mais ou menos pontos era observar a sua velocidade, mas isso era ruim. Além de não ter um indicador preciso, se o jogador pegasse a Gravidade, a Maçã ficaria lenta e ele perderia a contagem.

Para resolver isso, criei um feedback visual para os jogadores. Fiz uma animação de brilho nas Maçãs, seguindo as regras abaixo:

- Mais de 1 ponto: 1 brilho;
- Mais de 5 pontos: 2 brilhos;
- Mais de 10 pontos: 3 brilhos;
- Mais de 20 pontos: 4 brilhos;
- Mais de 30 pontos: 5 brilhos;
- Mais de 50 pontos: Maçã Dourada.


 A diferença visual entre as Maçãs permite que os jogadores identifiquem quais são mais valiosas de forma mais fácil.

Além de ajudar os jogadores a manter o controle, achei que o jogo ficou muito mais chamativo e bonito com essa adição. Outra alteração divertida, que fiz sem contar a ninguém, foi adicionar uma Maçã Dourada, que aparecia quando o jogador atingisse 50 pontos numa mesma Maçã. Foi muito legal receber o retorno dos jogadores que descobriram isso. Foi uma maneira de manter as pessoas interessadas mesmo após o lançamento.

Atualizações na jogabilidade

Mesmo após diversos testes antes do lançamento, alguns jogadores fizeram alguns apontamentos sobre o que poderia ser melhorado no fluxo do jogo. Há um conselho no livro Challenges for Game Designers (Desafios para Desenvolvedores de Jogos, em tradução livre), de Brenda Breathwaite, que eu nunca esqueci: se os jogadores apontam que há algo errado, realmente há algo errado — mesmo que eles não apontem uma solução. Portanto, era necessário verificar como eu poderia melhorar o jogo com base nos apontamentos dos jogadores.

Um dos aspectos do jogo que foram melhorados tinha relação com a aleatoriedade dos itens. Curiosamente, passei por um problema semelhante ao da equipe de produção de Diablo III, conforme mencionado no livro Sangue, Suor e Pixels, de Jason Schreier. Josh Mosqueira e sua equipe criaram o sistema Loot 2.0, pois o sistema de aleatoriedade anterior não era gratificante para os jogadores. Havia diversos relatos sobre itens raros e lendários que eram encontrados por personagens que não poderiam usá-los, o que tornava a experiência frustrante. Então, a equipe ajustou a aleatoriedade, de modo que os resultados fossem mais satisfatórios para o jogador. É como trocar um dado de seis lados por um que tenha somente quatro.

Bolota Strikes Back não é Diablo III, mas, ainda assim, aprendi que não posso ser refém dos números. Os itens que apareciam para o jogador eram totalmente aleatórios, o que eu via como justo. Porém, se o jogador possuísse um Escudo e o próximo item também fosse um Escudo, não teria nenhum benefício. Pelo contrário, parecia ser uma punição por ser bom e não ser atingido por nenhum Inimigo.

Outra reclamação tinha relação com o Relógio: embora ele aumentasse o intervalo de tempo em que os itens apareciam na tela, era frustrante quando o próximo item era um Inimigo Vermelho e o jogador tinha que esperar mais alguns segundos para ver o que viria depois (e sim, poderia ser outro Inimigo Vermelho).

Para resolver isso, mexi no sistema de sorteio dos itens. Então, quando o jogador tivesse um Escudo, poderia vir qualquer item — exceto o Escudo. Assim, havia uma sensação de recompensa por mantê-lo e conseguir um item adicional. Além disso, depois de pegar o Relógio, o próximo item a cair seria uma Maçã, assim o jogador poderia rebatê-la e somar mais pontos.

Se, por um lado, a aleatoriedade possa parecer justa — afinal, ninguém controla os dados e resultados —, ela abre brechas para que o jogador se frustre com os resultados, ainda mais porque isso está fora do seu controle. É muito importante que os números sejam bem pensados, pois a sensação de recompensa e crescimento do jogador é bem importante para que ele tenha uma experiência positiva.

Reformulação da HUD

Outra atualização que considerei muito relevante foi a reformulação da barra de vida e da HUD, para mostrarem com clareza tudo que estava acontecendo no jogo. Os problemas da versão inicial foram detectados conforme os jogadores avançavam no jogo. Por exemplo, a barra de vida inicialmente contava até sete, mas se os jogadores acumulassem mais Corações, essa informação sumia da tela.

Outro problema relatado tinha relação com a Estrela e o Escudo: como o dedo do jogador estava quase o tempo todo em cima da Bolota, em alguns momentos, era difícil perceber quando esses efeitos acabavam. Além disso, itens que não possuíssem efeitos visuais muito visíveis, como o Relógio e a Gravidade, muitas vezes passavam despercebidos.

Já que se trata de um jogo de celular, não seria possível colocar muita informação na barra de vida. Não somente por conta do tamanho, mas também para não deixar a tela poluída. Como solução, me inspirei na barra dos chefes de Kingdom Hearts.


A icônica batalha contra Sephiroth em Kingdom Hearts também surpreende pela quantidade de vida do adversário.

Na série, alguns inimigos possuem múltiplas barras de vida. Para facilitar para o jogador, o jogo mostra apenas uma barra, sempre do mesmo tamanho, porém existem indicadores na parte de baixo que mostram quantas barras de vida ainda restam.

Em Bolota Strikes Back, usei um conceito similar. Mantive uma barra de vida única, e caso o jogador acumulasse mais que sete vidas, uma nova barra sobrepunha a atual, com uma cor diferente. Assim o jogador conseguiria ver facilmente a quantidade de vidas que ele possuía, e eu não teria que adicionar informações novas na tela, que poderiam ser mais uma distração.

Para exibir informações do Escudo e da Estrela, aproveitei que há um coração na barra de vida e fiz alterações nele de acordo com o item sob efeito. Caso o jogador consiga um Escudo, o coração fica com um aspecto metálico. Caso consiga uma Estrela, o coração recebe um efeito de estrelas.


 Resumir toda a informação de maneira simples é essencial para evitar explicações desnecessárias aos jogadores.

No caso da Gravidade e do Relógio, tive que adicionar informações novas (a contragosto, confesso). Nesse caso, fiz com que o nome do item adquirido fosse exibido por alguns segundos na parte superior da tela. Também coloquei a quantidade de Maçãs adquiridas e Inimigos destruídos, uma vez que existem conquistas que são baseadas nesses números.

A reformulação da HUD foi bem satisfatória de fazer. Não só melhorou visualmente o jogo, mas consegui concentrar toda a informação útil e necessária para o jogador num só lugar, sem utilizar grandes mensagens de texto e sem a necessidade de pausar o jogo. Quando o jogador não precisa parar o jogo para interpretar uma informação importante, a sua experiência fica melhor. Inclusive, existem jogos que apresentam tudo isso tão bem que algumas pessoas gostam de jogar sem HUD. Fiz isso em Zelda: Tears of the Kingdom, e foi absurdamente divertido!

Sistema de salvamento

Após três meses do lançamento, alguns jogadores ficaram bons. Tão bons que começaram a enfrentar um problema: em algum momento, eles precisavam fechar o jogo, e o progresso era perdido. Simplesmente não tinham tempo o suficiente para continuá-lo.

Pensei em criar um sistema de salvamento, embora ficasse um pouco receoso com a dificuldade da implementação. Afinal, embora não pareça, guardar o progresso do jogo mudou muito a direção de como os jogos eram criados e jogados. Décadas atrás, os jogos eram curtos e, para que parecessem ter mais conteúdo, eram extremamente difíceis e não guardavam o progresso do jogador — não só por ausência de tecnologia, mas também para gerar mais lucro. Não dá para esperar que um fliperama gere dinheiro se ele salva o progresso de todos que jogam. A criação desse tipo de ferramenta, além de facilitar e oferecer uma experiência mais prazerosa para os jogadores, permitiu também que os desenvolvedores criassem jogos maiores.

Registrar o status do jogo, como se fosse uma fotografia, é inviável. Diversas coisas acontecem ao mesmo tempo na tela, e é extremamente complexo guardar o estado de tudo: a posição dos objetos na cena, as linhas de código em execução, o tempo da música, o quadro da animação de um personagem e assim por diante. Todavia, existem meios de armazenar informações que são relevantes para o progresso do jogador.

No caso de Bolota Strikes Back, as variáveis responsáveis pelo funcionamento do jogo são:

- Quantidade de vidas;
- Velocidade da queda dos itens;
- Intervalo entre a queda dos itens;
- Se Bolota está com Escudo ou Estrela (e quanto tempo resta para acabar);
- Pontuação do jogador.

Quando o jogador sai de um jogo em progresso, essas informações são salvas e, ao iniciar o jogo, são carregadas novamente. Basicamente, o jogo carregado nada mais é que um novo jogo, porém com informações inseridas.

Conclusão

Fazer jogos definitivamente não é fácil. Fazer um bom jogo dá mais trabalho ainda. Não é necessário somente conhecimento teórico, mas também experiência com diversos tipos de jogos. Assim o desenvolvedor consegue ter ideias do que fazer (e do que não fazer) para atingir seu objetivo.

Para quem quer criar jogos, essa é a dica que deixo. Jogue todos os jogos. Os que você gosta, os que você não gosta. Procure informações a respeito dos desenvolvedores por trás dos jogos. Entenda a razão por trás das mecânicas, do desenho das fases e das músicas. Todo esse material será valioso para que bons jogos sejam produzidos. No meio de tantas opções disponíveis, espero que Bolota Strikes Back seja uma influência na sua jornada de aprendizagem.



StatusReleased
CategoryBook
Rating
Rated 5.0 out of 5 stars
(1 total ratings)
AuthorSailor Knight
Tagsarticle, devlog, gamedesign, gamedev, leveldesign

Comments

Log in with itch.io to leave a comment.

Um orgulho imensurável de ter feito parte dessa história! Foi uma jornada extremamente divertida e enriquecedora atuar como jogador e tester do bolota strikes back!