Como eu arruinei meu próprio jogo (e porque isso não importa) // Vídeo por Fupicat

Introdução

Oi! Eu sou o Fupicat, e eu crio video-games.

Eu já criei muitos tipos de jogos: plataformers, RPGs, puzzles, mas todos eles tinham uma coisa em comum; todos eram completos e perfeitos, sem nenhuma falha. Infelizmente, isso acaba hoje. 💔

Ok, dramas à parte. Nem todo jogo que você faz vai ser um vencedor. Às vezes tem um ou dois detalhes que você não planejou direito e acabam atrapalhando a experiência de todo mundo.

Hoje eu quero mostrar uma vez que isso aconteceu comigo, e algumas coisas que você pode fazer pra não ter os mesmos problemas com o seu jogo!

Contexto: Esse jogo foi criado pra uma competição. A gente tinha 3 dias pra criar um jogo com o tema “Sumonar”. Eu ia programar e fazer a arte, e um amigo meu ia fazer a música.

Eu e ele começamos a discutir ideias, e chegamos nessa aqui: um jogo em que você tem vários carinhas, e você chama (ou melhor, “sumona”) eles pra fazer certas ações pelo mapa. Como se fosse uma versão minificada de um Pikmin, ou um daqueles jogos complexos de estratégia. A ideia é que a quantidade de tarefas que os seus carinhas tem que fazer vai ficando cada vez maior, então você teria que fazer malabarismo com eles pra completar tudo, e também ia poder comprar mais carinhas pra facilitar o trabalho.

Pra combinar ainda mais com o tema, e apresentar uma subversão engraçadinha, a gente também pensou que esses “carinhas” poderiam ser magos, seres conhecidos por sumonar coisas por via da mágica, mas no universo do jogo, eles estão sendo forçados a tomar trabalhos normais, porque a sociedade hoje é tão tecnológica que a magia saiu de moda.

Ok, tendo esse conceito, eu podia começar a programar!

Desenvolvimento

O primeiro passo de qualquer projeto de programação é ver como você pode separá-lo em partes menores. Tem dois “atores” nesse jogo: os magos, e as tarefas, certo? Os magos podem ser controlados pra ir até as tarefas, e chegando lá eles começam a trabalhar ou “atacar”, cada um deles reduzindo a “vida” dessa tarefa até ela ser completa.

Bom, sim! Esse é um bom começo. Daria pra você fazer um jogo assim, em que o mago é um tipo de objeto, a tarefa é outra, cada um com um script, e os dois interagem um com o outro. Porém, desse jeito, a gente tá dando coisas demais pra cada objeto fazer. Pensa que, só o script do mago, vai ser responsável por saber qual tarefa foi selecionada, andar até ela, atacar o alvo, e tocar as animações. A tarefa também é bastante complexa: ela tem que poder ser selecionada, poder direcionar magos pra vir até ela, tem que saber quais são os magos que estão dentro dela, quanta vida a sua tarefa tem, tem que poder levar dano quando os magos atacam ela, e além disso também tocar animações.

Dá pra imaginar que os scripts desses dois objetos podem ficar grandes e bagunçados. Por isso, sempre é uma boa ideia você reduzir a quantidade de coisas que cada objeto faz. O ideal é que cada objeto sirva apenas um único propósito, e seja responsável apenas pelas funções e dados necessários pra esse propósito. Isso é o que nós na indústria chamamos de princípio da responsabilidade única.

Pensando dessa forma, o nosso maguinho pode ser composto de 3 partes: um sistema de movimento, um sistema de ataque, e um sistema de animação. Cada um desses vai ser seu próprio objeto com seu próprio script; ou seja, na Godot Engine, eles vão ser nós. E aí a gente vai criar um script pro mago que vai servir como “cola” pra juntar todos esses componentes. Assim fica muito mais fácil de trabalhar, pois as mudanças feitas em um sistema não vão afetar os outros. Cada um é como se fosse uma “caixa-preta” que o seu mago pode usar, sem se preocupar sobre como ele funciona. Também significa que, se fizermos esses componentes de uma forma genérica o suficiente, podemos copiar e colar eles em projetos futuros, se precisarmos dessa mesma funcionalidade.

A primeira coisa que eu programei foi o movimento. Eu criei um nó super simples chamado Movimento que recebe um ponto no mapa, e anda até ele. Quando chega naquele ponto, ele para. E, se o alvo muda, ele já começa a andar de novo.

Esse nó também emite um sinal toda vez que ele chega no seu ponto alvo, e toda vez que ele muda entre andar e parar. Sinais são a forma principal de comunicação entre nós na Godot, e a gente vai usar eles pra todo tipo de coisa.

Com o movimento pronto, eu já fui começar a trabalhar nas tarefas também. Afinal, os magos precisam de algum lugar pra ir. Eu criei um nó chamado Alvo, ele é uma área que você pode clicar com o mouse e o único trabalho dele é ser selecionado, e retornar um ponto aleatório dentro da sua área onde um mago pode ir.

Também criei um objeto “global” pra tomar conta de todo o jogo, que ouve todos os alvos do mapa pra saber qual deles tá selecionado através de um sinal.

Agora, eu preciso poder selecionar um alvo pra ser o início, da onde os magos vem, e um alvo pra ser o fim, onde os magos daquele alvo vão. Então eu tive que começar a pensar em como esse jogo ia controlar. E foi aqui que eu cometi meu primeiro erro.

Controles confusos

Eu precisava de um jeito de mover os magos de um alvo para outro, de preferência, usando só o mouse. O jeito mais fácil de fazer isso seria só, clicar em um alvo pra selecionar o início, e clicar em outro alvo pra mandar um mago pra lá. Porém, isso significa que eu teria que clicar no alvo inicial toda vez que quisesse mandar um mago, e considerando quantos magos você pode ter no jogo, isso ficaria muito cansativo; eu queria poder selecionar um início e mandar os magos de lá pra vários lugares. Um jeito de fazer isso seria adicionando dois modos, um modo de seleção, e um de movimento; aí você mudaria de modo clicando em um botão. Mas eu também não gostei muito dessa opção porque eu ia precisar ficar mexendo o mouse entre os botões e os alvos, ou seria obrigado a usar o teclado, o que eu não queria.

Eventualmente, eu decidi usar o botão esquerdo e o direito do mouse pra ações diferentes. Meu pensamento é que o botão esquerdo do mouse devia ser usado pra função mais frequente do jogo, já que a gente já tá muito mais acostumado a clicar um monte com ele, e eu não gostava da ideia de ter que spammar o botão direito caso precisasse mandar um monte de magos pra um lugar. Portanto, eu decidi que eu ia usar o clique DIREITO pra selecionar um alvo, e o clique ESQUERDO pra mandar um mago pra outro lugar.

Eu sabia que esses controles eram confusos. Eu ia ter que explicar muito bem nas instruções, mas pensei que assim que os jogadores se acostumassem, eles iam concordar comigo que esse estilo de controle era o melhor.

Ehrg… claro que não. Os controles confusos foram, de longe, a reclamação mais frequente sobre o jogo. E eu não posso culpar os jogadores. Por mais que eu explicasse nas instruções do jogo, selecionar usando o botão direito vai contra tudo que você sabe como usuário de computador. E ainda por cima, selecionar um alvo é a primeira coisa que você tem que fazer pra começar o jogo, então os primeiros momentos são desperdiçados nessa confusão, que podia ter sido evitada se eu só tivesse escolhido controles mais normais.

O que eu não sabia, é que esse era um problema resolvido. Esse esquema de controle é muito comum em jogos de estratégia em tempo real (RTS), como Age of Empires, e lá, você seleciona com o botão esquerdo, e move com o botão direito. Um dos meus amigos até me disse que jogadores de RTS adoram spammar o botão direito, então pelo visto ninguém se importa com isso além de mim!

Ou seja, se você estiver com problemas numa questão de game design, e tiver tempo suficiente, é uma boa ideia você pesquisar sobre como outros jogos solucionaram o mesmo problema.

Mecânicas escondidas

Agora que eu já tinha o sistema de movimento pronto, podia começar a trabalhar nos… trabalhos. Para isso eu vou precisar de dois novos nós: o Emprego, e o Trabalhador.

O Emprego vai ter um valor de vida e um limite de tempo. Quando um emprego for ativado, esse tempo vai começar a rodar, e o jogador tem que completar o emprego, ou seja, diminuir a vida dele pra zero, até o timer acabar. Importante notar que esse nó não faz nada sozinho, ele só fornece funções que outros nós podem usar. Isso me dá mais liberdade pra decidir depois como os empregos vão funcionar, quando eles vão ser liberados, etc, através do código de “cola”.

O nó do Trabalhador pode receber um Emprego, e dar dano nele. Só isso. De novo, o script do Trabalhador não faz nada sozinho. Ele só sabe o mínimo possível pra fazer a sua função.

E agora que eu criei todas as partes necessárias pros componentes do jogo, podemos juntá-las! Vou juntar o nó de movimento e o nó trabalhador para formar uma cena chamada Mago, e juntar o nó de alvo e o nó de emprego pra formar uma cena chamada Quest. Essas duas cenas, são as peças que eu vou usar para criar o conteúdo do jogo. Porém, como eu disse, os nós por si só não fazem nada. Então agora é hora de escrever aquele código de “cola” que eu tava falando!

Pra começar, o Mago precisa saber em que Quest ele tá, pra poder ir até lá e trabalhar no emprego certo. Também precisa de uma função para mudar de Quest, que vai ser chamada quando o jogador quiser mandar um Mago pra outro lugar. Adicionei um timer que vai fazer o Trabalhador atacar automaticamente, uma vez a cada segundo, e fiz uma função pra mudar o sprite do mago. Aqui, também já aproveitei pra criar o script de animação, que ouve os sinais de movimento e ataque do mago e toca as animações certas.

A Quest é provavelmente a cena mais complexa do jogo inteiro. Muitas mecânicas são definidas aqui. Por exemplo: O jogo vai ter uns 10 empregos, mas eu não quero que todos eles apareçam ao mesmo tempo pro jogador não ficar sobrecarregado. Portanto, todos eles começam bloqueados, e, depois de um tempo, desbloqueia. Aí, de tempos em tempos, o emprego abre de novo. Além disso, cada um deles tem um valor de vida diferente, e uma quantia de dinheiro que eles dão quando forem completos, que você pode usar pra comprar mais magos.

Também adicionei uma quest “especial” no meio do mapa: a torrinha, que é onde os Magos começam quando nascem. E, de tempos em tempos, de acordo com mais um timer, ela é invadida por demônios com muita vida que matam seus Magos cada poucos segundos, pra forçar você a trazer todos os seus magos de volta pro centro pra derrotar eles.

Eu nem te culpo se você se perdeu nessa explicação, porque esse sem dúvida é o jogo mais cheio de números e stats e coisos que eu já fiz. A quantidade obcena de timers e valores diferentes me fez ter dificuldade de mostrar essas informações pro jogador de um jeito organizado, o que acabou causando a segunda maior falha do meu jogo, pois todas essas mecânicas escondidas fizeram ele parecer muito mais complexo do que realmente é. Você não tinha como saber quantos magos precisava pra completar cada quest a tempo, nem quanto dinheiro ia ganhar de cada uma delas, e portanto não tinha bem como planejar ou criar estratégias.

Eu até pensei em usar barras pra representar o progresso de cada timer e da vida de cada emprego, mas aí sim o jogo ia ficar muito poluído, e só ia fazer ele parecer ainda mais complicado.

Sem falar na outra dificuldade que vem com essa grande variedade de números, que é balancear tudo!

Curva de dificuldade invertida

Eu descobri tarde demais que escolher os valores certos pra cada timer, e vida, e dinheiro, e custo de magos, pro jogo não ficar tão fácil, nem tão difícil, é… difícil!

Depois de umas rodadas jogando, eu percebi que o jogo tava impossível com a primeira configuração que eu fiz, aí eu tentei só ir ajustando pra que pelo menos eu conseguisse zerar o jogo facilmente antes de publicar. Porém, sem perceber, eu acabei criando uma curva de dificuldade invertida pro resto dos jogadores.

Sabe como a maioria dos jogos começam fáceis, e vão ficando cada vez mais difíceis com o tempo pra acompanhar a habilidade do jogador? Então, o meu é o contrário. O jogo começa difícil, porque nos primeiros 15 segundos você tá completamente perdido, apertando os botões errados e perdendo quase imediatamente pros demônios. Aí, depois que você entende as mecânicas, o jogo fica fácil, porque é só você comprar o máximo de magos que puder e espalhar bem pelo mapa. Zero pensamento necessário. Basicamente, a única dificuldade do jogo é descobrir o que que você tem que fazer.

Conteúdo

Ok, todas as mecânicas prontas, agora era hora de criar o conteúdo do jogo! Eu tinha que desenhar, animar e balancear 10 empregos diferentes, então só fui desenhando qualquer tarefa mundana que vinha na minha cabeça pros magos fazerem. Desentupir um vaso, limpar um aquário, acobertar um assassinato, fazer o imposto de renda, essas coisas.

Pra comportar tantos empregos, eu também criei um controle de câmera simples, que te deixa dar zoom e mover a sua visão com a rodinha do mouse. Na verdade, essa foi uma das primeiras coisas que eu programei! Eu imaginei que poderia ser divertido se o mapa fosse bem grande, e o jogador tivesse que tomar conta de vários empregos que estão fora da tela e ficar indo pra lá e pra cá, sabe, adicionar um pouco de caos.

Porém, depois de desenhar e configurar todo o mapa com as quests bem espalhadas, eu tentei jogar desse jeito, e descobri que ficar mexendo a câmera o tempo todo na verdade era um saco! Só deixava o jogo claustrofóbico e me fazia ficar com cãibra na mão. Além disso, era difícil saber em que ponto do mapa tinha emprego pra fazer, porque eles abriam e fechavam o tempo todo fora da tela. Eu até tentei programar um ícone de alerta que ficava nos cantos da tela mostrando a direção que tinha coisa pra fazer, mas eu só não consegui. Nhé.

No fim eu decidi só deixar a câmera mais afastada pra dar pra ver todo o mapa… exceto pelo troféu, que é o último emprego que você tem que completar pra vencer o jogo, que eu resolvi colocar lá na pqp, porque eu achei que seria engraçado, eu acho. Então ficou só esse único apêndice pra fora do mapa, como uma ferida aberta, infeccionando, e me julgando.

🙃

Eu desperdicei horas preciosas com essas mecânicas que eu nem usei, mas no fim foi melhor eu ter feito esses ajustes de última hora porque estraçalhar as mãos dos seus jogadores nunca é uma boa ideia. Se eu tivesse testado essa ideia da câmera antes de praticamente terminar o jogo inteiro, eu podia ter cortado ela bem antes, feito um mapa que realmente coubesse na tela, e economizado umas horas.

Conclusão

Em resumo, o que eu aprendi de toda essa experiência:

O principal, sem dúvida, é que eu não quero mais fazer jogos que eu precise balancear stats! Honestamente essa é sempre a parte mais chata de fazer qualquer jogo, e o máximo que eu puder eu vou evitar. É fácil demais você estragar o equilíbrio do seu jogo e ele ficar sem graça.

Além disso, eu também devo sempre pensar no conteúdo do jogo antes de programar as mecânicas! Isso é, fazer concept art, ver como ficaria a tela, planejar quantos níveis vai ter, é, planejar melhor no geral. Todos os meus jogos de jam mais coerentes só ficaram assim porque foram bem planejados. É só bom saber desde o início exatamente quais mecânicas você vai precisar programar e não ter que jogar fora um monte de coisa.

O que REALMENTE aprendemos

Ok, então, todo o roteiro até esse ponto foi escrito antes dos resultados da Ludum Dare saírem. Claramente, eu não tava com altas esperanças, já que pra mim todo aspecto do meu jogo tinha alguma falha. Inclusive, o título desse vídeo ia ser só “Como eu arruinei o meu próprio jogo”. Imagine a minha surpresa quando eu abro os resultados, e eu vejo, uhhhhhh…

Se você não tá ligado, essas são colocações excelentes. Tipo, nos 8 eventos passados, eu só consegui notas melhores do que essas uma vez. 13º lugar em geral, e 9º lugar em humor, quando eu tava competindo contra mais de 1000 jogos, é… insano.

Então… mesmo com todos esses problemas, mesmo eu tendo “arruinado” o meu jogo, falhado no planejamento e criado um produto final tão bagunçado, nada disso importa? É!!

Não me leve a mal. Evoluir é importante. MAS!! Importante também é você descobrir que diversão pode vir de qualquer lugar. Por mais que o meu jogo não esteja tinindo de polido, essas notas e os comentários que eu recebi, inclusive os críticos, mostram que o pessoal ainda conseguiu se divertir muito! E claro, eu mesmo me diverti fazendo ele, o jogo não se leva muito a sério em nenhum momento.

Então, na verdade, a coisa mais importante que eu aprendi com esse jogo foi só: relaxa, calma, tá tudo certo. Mesmo que você não tenha ficado 100% feliz com produto final, é só um projeto de muitos que ainda vão vir. Aprende com ele, e continua. Se tu se divertiu fazendo o jogo, vai dar pra ver no produto final, e olha que eu já me diverti MUITO com jogos bem mais cagados. Eles têm um charme impossível de replicar.

• Super Mario Maker - Create SMB3 Underground
• Rhythm Heaven Fever - Try Again
• Club Penguin - Patrick's Jig
• BFB - hush
• WarioWare DIY - AI Assembly Screen Trigger
• BFB - Widge
• Cobalt Core - Rezz
• The Sims 3 World Adventures - Skylines In Sand
• Doki Doki Literature Club! - I Still Love You
• Vim! - from mars.mod
• The Sims 3 Ambitions - Buy Me The Sweet Life
• Vim! - a z thing (zed).mod
• Wario Ware D.I.Y - Graphics Creation Screen
• Portal - 4000 Degrees Kelvin
• Club Penguin - Flipper Jig
• Yakuza 5 - Bakamitai Jazz