Game Start

Hey, so, one thing called pandemic happened, you might have heard of it. It is kind of big. Because of that, everything here started going in a different pace. At first glance, it felt it was slower since we were all at home all the time and if we don’t go places things should not happen, right? But that’s not really what happened, things were not slower, not fast either. Just different. I…

Bittersweet Game Design – The How

When fun isn’t enough

This article is based on a talk I presented on the Tehran Game Convention. Slides are available here. Therefore, loss management instead of reward distribution becomes the main attribution of a game designer doing a bittersweet game. It’s a hard job, but a challenging and rewarding one, just like the desired player’s experience. If the game designer’s quest is successful,…

Bittersweet Game Design – What

When fun isn’t enough

This article is based on a talk I presented on the Tehran Game Convention. Slides are available here. 

“Videogames are supposed to be fun”

We pat ourselves in the back in understanding. Finally, some good old sense was spurred in this mad conversation. Tic tac toe comes to mind, duck duck goose, remembrances of the simpler times when we discovered ourselves playing.…

Nos últimos meses, coletei feedback dos leitores, reli e editei os textos, adicionei mais conteúdo e ta-dam! Temos um livro super gracinha para vocês sobre como se manter no foco enquanto desenvolvemos um jogo!

e corta tudo essas bosta

"Foca no jogo, cara!" diz essa linda foca simpática.

Então já falamos de começar o jogo, de definir o leitmotif para seu jogo (ou pilar) e como essa decisão impacta na mecânica, universo, dificuldade e ritmo. Foi uma jornada linda e eu já agradeço todos vocês por chegarem até aqui. Mas esse não é o fim, é só o começo. E não estou falando metaforicamente, que nem aqueles textos bonitos e motivacionais dublados pelo cara do Big Brother. Desenvolver um jogo é difícil pacas, mas talvez mais difícil que todas as etapas de desenvolvimento combinadas é dizer adeus às features que você ama. E você vai ter que dizer.

Algumas situações corriqueiras que levam a cortes são:

Feature creep — Quando, sem querer querendo, você acaba se empolgando nos primeiros passos de desenvolvimento e planejamos muitas outras features, muitas das quais não complementam muito o jogo. Quando feature creep acontece muito cedo no projeto, o impacto pode ainda ser pior pois você já nem sabe mais qual o core do projeto. Corte excesso de documentação e features semelhantes com um lança chamas, sem dó nem piedade.

Tempo de desenvolvimento é diminuído — O dinheiro acaba, eventualmente. E algumas vezes, acaba muito antes do esperado. Quando isso acontece, temos que ou diminuir o número de coisas a ser desenvolvida e assim diminuir o tempo de desenvolvimento ou então achar fontes alternativas de dinheiro. Mesmo que você ache mais dinheiro, corte algumas coisas só para não se permitir ficar dessa situação apertada novamente.

Diminuição da equipe — Pessoas mudam-se e mudam a si mesmas, perdem o interesse em algo que era importante ou simplesmente tem que priorizar outras coisas. Isso acontece, de boa. Mas ter duas mãos a menos no projeto vai impactar o número de coisas que dá para fazer dentro do tempo planejado. Sem falar que algumas vezes, o trabalho feito por essa pessoa não pode ser continuado pelo resto da equipe. Vamos supor que você perde seu principal artista e os demais não conseguem imitar o estilo dela, o que fazer? Mudar o estilo da arte e tentar diminuir ao máximo os assets de arte necessários.

Features que levam tempo demais — Eu nunca, nunca estive em um equipe em que alguém sempre acertava suas estimativas de tempo. Algumas pessoas terminam antes mas em geral a maioria termina depois. Temos a tendência de ser otimistas com o tanto de trabalho que podemos fazer, isso é normal e contornável. Se você acha que vai levar 1x tempo, sempre se prepare para 1,5x. Mas ainda sim, as vezes leva 2x, 3x, 4x ou 10x para chegar no resultado esperado. Sempre que uma feature começar a atrasar, reavalie duas coisas: quanto falta para acabar e a importância dela no projeto. Se é um pequeno atraso e é uma feature importante, vale a pena. Se é um atraso grande e uma feature de pequeno impacto, você corta. Os dois outros casos (feature importante e grande atraso ou features não tão importantes e pequenos atrasos) são os mais difíceis de decidir. Nestes casos, vale a pena conversar com todas as partes envolvidas, arte programação e GD, antes de decidir.

Features que não tem impacto esperado — A feature super foda que ia ser o grande diferencial do jogo foi implementada e na real é uma grande bosta? Acontece. Converse com o pessoal e vejam se não é algo que pode funcionar com alguns ajustes. Se não, corta essa ingrata e de volta para a prancheta.

Mecânica mais legal encontrada — Esse é o problema que todo mundo quer ter. Você pensa em uma forma que as coisas vão funcionar mas sem querer descobre outro que é muito mais legal. Isso geralmente implica em cortar o modo de jogo ou feature originais. Mas hey, você achou algo melhor e é isso que importa.

Mecânica não funciona como o esperado — Às vezes, tudo que foi planejado simplesmente não funciona como deveria. A feature que deveria realçar o gameplay na verdade concorre com ele e tudo fica mais frustrante. Tente alguns ajustes ou novas funcionalidades ouvindo o que o resto do pessoal tem a dizer. Se nem assim funcionar, já sabe: passa a faca.

Levels não se conectam bem — Isso é um erro recorrente em projetos que são feitos com várias pessoas fazendo partes diferentes ao mesmo tempo ou uma única pessoa fazendo partes não conectadas e depois tendo que juntar tudo. Daí acontece de a transição de uma área para outra ficar meio estranha ou algumas partes simplesmente não parecem fazer parte do mesmo universo. Alguém vai ter que passar por um total makeover ou vai ser cortado. Decida baseado no tempo e pessoas disponíveis.

Um parte do jogo não é mais necessária — Se uma parte do jogo não parece estar adicionando à mensagem final ou está atrapalhando o ritmo, não pensem duas vezes. Tesourada.

Mas mesmo que nenhuma dessas situações seja exatamente o que está se passado no seu projeto, volta e meia você precisa se dar um tempo. Tomar um ar. Jogar o ultimo build. Ver como desconhecidos jogam o último build. E realmente se perguntar: Como podemos melhorar? Como podemos simplicar? Como podemos ter o melhor jogo possível e retirar tudo que não adiciona à experiência?

Isso é às vezes um processo traumático pois com frequência você se vê na situação de ter duas excelentes features que complementam o jogo, mas não há tempo para aperfeiçoar as duas. Os ter as duas deixa o gameplay um pouco confuso. Ou um pouco menos rápido e a agilidade faz parte do seu leitmotif. E essa feature já pode ter sido parcialmente implementada. Ou totalmente implementada. As vezes, ela é parte essencial do seu gameplay, mas a pessoa responsável por colocar ela saiu e ninguém mais sabe como fazer ajustes. E todos esses cortes são um pequeno luto para equipe, todos eles doem. Nós começamos nossos jogos, vemos eles crescer, alimentamos cada nova idéia legal, é um processo cheio de amor.

Um corte errado pode ter um efeito negativo no seu jogo. Cortar uma feature secundária que na verdade era complementar ao gameplay principal e a equipe não percebeu, pode ter um efeito devastador na experiência do jogo. Por isso esteja sempre atento às ramificações de seu gameplay e de preferência conduza alguns A/B testings.

A/B testing funciona assim: você faz duas build em que a única diferença entre elas é a existência da feature que você quer testar. Não precisa ser a feature completa, pode ser só uma parte, mas é importante que todos o resto do jogo esteja exatamente igual. Você pega um grupo homogêneo de pessoas e divide esse grupo em dois menores, randomicamente. Cada um dos grupos vai jogar apenas uma das build e nem sabe que existe outra. No final da jogatina, você recolhe feedbacks dos dois grupos, primeiro de forma geral e depois tentando puxar pro assunto da feature mas sem deixar claro que é isso que você está testando. Talvez até faça algumas perguntas sobre outras features, só para disfarçar. Após esse teste você terá uma idéia mais clara da importância da features inclusive se os dois grupos responderem as mesmas coisas. Pois se isso acontecer, quer dizer que a feature é realmente irrelevante e pode ser removida sem maiores impactos ao jogo.

Um jardim bem podado passa uma mensagem estética mais forte do que um sem podar.

Cortar uma feature pode parecer doer como cortar um dedo ou amputar um membro, dependendo de o quão arraigada ela já está no emocional da equipe, mas na verdade é mais como uma poda de uma árvore ou arbusto. Nada está sendo perdido, o jogo só está ganhando uma forma mais coesa, se aproximando mais do seu objetivo com ele. O corte, na verdade, só te deixa mais próximo do resultado final. Com os cortes seu jogo vai crescer mais saudável e ter uma mensagem mais forte.

O tapifoca veio te desejar uma boa jornada fazendo jogos. E também gritar FOCA NO JOGO. Para tanto, o tapifoca recomenda ler os demais artigos da série Pense Pequeno.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

A linha de sensação do seu jogo

Ritmo em uma música é fácil de definir, fácil de entender ou falar sobre. Parece algo evidente quando falamos de ritmo em música ou filmes, mas não é algo tão comum quando conversamos sobre jogos. Isso precisa mudar pois como qualquer outra experiência artística e cultural, a força de um jogo também depende de seu ritmo.

Mas o ritmo de um jogo depende de muitas mais coisas do que em uma música, afinal é uma experiência com muitos mais elementos. Em um filme, por exemplo, podemos dizer que o ritmo é ditado a velocidade e intensidade em que as coisas acontecem ou são mostradas ao espectador. Quem dita isso é não só o roteiro mas também a edição. 2001: Uma Odisseia no Espaço, um dos filmes mais importantes na história do cinema, é conhecido pelo seu ritmo mais lento, quase arrastado. Isso ajuda a compor a mensagem do filme, que é uma epopeia sobre a evolução humana, a conquista do espaço e a origem da vida (humana e artificial). São temas pesados e Kubrick, o diretor do filme, optou por tratá-los com seriedade e peso. O resultado foi 2001, que para alguns é uma das sete maravilhas do cinema, para outros é um pedaço de bosta lentamente descendo pelo rio. Independentemente de juízos de valor, 2001 é o que é.

Agora, em um jogo temos outras variáveis em questão que não precisam ser pensadas em filmes. E essas variáveis influenciam em muito o ritmo que o jogador vai experienciar. A frequência que determinadas ações ocorrem, seja uma determinada mecânica de gameplay o a interação com um personagem, é uma das variáveis. Se puzzles são parte do meu gameplay mas não a principal mecânica, se eu só uso eles no começo e no fim mas não no meio essa decisão ou falta de atenção vai ter um impacto no ritmo.

A forma que a dificuldade progride, que conversamos sobre no último texto, ou até mesmo como segmentos do plot estão distribuídos durante a experiência também contribuem enormemente para como o ritmo do seu jogo progride.

Antes de seguirmos, é importante avisar que o ritmo ideal NÃO é a experiência mais homogênea possível, não é puzzles perfeitamente espaçados entre si, chefões igualmente distribuídos pela fase e a dificuldade progredindo de forma 100% linear. Vamos voltar para uma mídia que usa só um sentido para entender isso, uma música. Mais especificamente, uma música erudita. Escute a musica no fim desse texto.

Você percebe como o ritmo e intensidade muda com frequência, mas que cada mudança parece fazer sentido? Seu jogo tem que ser assim, tem que ter momentos mais intensos, mais relaxados, mais rápidos e assim vai. Mas essas mudanças tem que fazer sentido dentro de si. Um jogo com todos seus momentos com a mesma intensidade é que nem uma sinfonia com uma nota só. Uma chatice.

Cortes

Agora vamo falar de coisa boa: mutilar seu jogo. Não sério, por mais que planejamos o ritmo na prancheta, nunca conseguimos prever com exatidão como o ritmo vai evoluir em cada parte. Podemos prever com certa precisão, podemos errar completamente. Esteja pronta para isso, aceite o erro, abrace-o e aprenda para a próxima. Você nunca vai acertar tudo nas previsões de ritmo, mas pelo menos dá para calibrar os sensores para ficarem mais precisos.

Se não dá para planejar o ritmo do jogo antes de fazê-lo, dá para testá-lo enquanto se faz e em especial no fim, quando todas as partes já estão presentes, com (mais provável)ou sem (quase impossível) bugs. Ritmo é algo que você pode sim testar por conta própria, assumindo que você já testou a dificuldade várias vezes com outras pessoas, mas é interessante testar com pelo menos algumas cobaias o ritmo do jogo inteiro, do começo a fim.

Para saber se o ritmo está bom, procure momentos em que você ou as cobaias estão entediadas, seja não prestando atenção seja simplesmente chateados de estar repetindo alguma ação. Caso o seu jogo tenha um foco em história, esse é o momento também de perceber se os personagens estão funcionando, se seus motivos estão claros, se o jogador está entendendo o que está acontecendo e não a furos no roteiro e por fim se o ritmo da própria história está bom e complementa o ritmo do jogo.

Por exemplo, os momentos mais tensos na história ou que vem logo antes de um momento pesado tem que ser tensos também no gameplay e no som (SFX e trilha), para ir aumentando a expectativa. Momentos mais calmos, contemplativos e de construção do personagem em geral combinam mais com gameplays de aprendizado ou tutoriais. Se você tem um bom motivo para não seguir esses padrões, não siga. Eles não são regras escritas em pedra, só uma recomendação que costuma funcionar. Mas sempre que há um bom motivo é importante não seguir as regras.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

Foca no jogo e corta tudo essas bosta

ou o Flow do seu jogo

Falamos rapidinho no último texto sobre a teoria do flow, do Mihaly Csikszentmihalyi, mas não realmente entramos em o que o ele significa.

Para Mihaly, o flow é um estado de espírito no qual o indivíduo, a fazer uma tarefa, se encontra completamente absorvido pela atividade e sente compreendê-la 100%. Sabe quando você está tão absorvido naquela luta com o chefão que a sua casa pode estar pegando fogo que você nem percebe? É isso.

Segundo Mihaly, algumas coisas são necessárias para atingir o flow. São elas:

Objetivos claros — A pessoa sabe exatamente o que tem que fazer e quais as formas de obter sucesso.

Concentração e foco — A concentração se foca completamente na tarefa a frente.

Perda do sentimento de auto-consciência — Não se pára para questionar o futuro, o passado e como a pessoa se sente em relação a eles. Toda sua atenção está na tarefa e assim não há espaço na consciência para nenhum outro pensamento, nem de dúvida.

Sensação de tempo distorcida — A imersão total na tarefa faz a passagem do tempo subjetiva ser muito diferente do tempo real.

Feedback direto e imediato — Todos os pequenos sinais passados pela atividade são percebidos pela pessoa que se adapta conforme o necessário.  

Equilíbrio entre o nível de habilidade e de desafio — a atividade nunca é muito fácil ou muito difícil o nível de dificuldade percebido pela pessoa parece sempre dentro do nível de habilidade que ela possui e dentro do espectro de desafiante.

A sensação de controle pessoal sobre a situação ou a atividade — Com todos eles elementos, a pessoa se sente confiante dentro da atividade, sente-se como "no topo" dela.

A atividade é em si recompensadora, não exigindo esforço algum — Os feedbacks e a sensação de controle passam se ser a recompensa para a própria atividade, nenhuma outra recompensa externa é necessária para deixar a pessoa com a sensação de satisfação.

A pessoa praticamente “se torna parte da atividade” que está praticando — Toda a capacidade de consciência da pessoa se torna a atividade, o mundo de fora cessa de existir durante esse momento e a pessoa se torna tão envolvida com a atividade que se sente parte dela.

Lendo esses requisitos, fica bem claro que o flow é um estado extremamente subjetivo. Depende de pessoa a pessoa e ocorre apenas no indivíduo. Ou seja, não podemos fazer um jogo que seja 100% garantido de causar flow no jogador. O que podemos fazer é entender como o flow funciona e tentar, ao máximo, deixar nosso jogo propício a causá-lo.

Segunda a teoria do Mihaly, dos nove elementos necessários para o flow apenas três podem estar fora do indivíduo, ou seja, na atividade em si. Um deles é o feedback, que falamos no artigo anterior e o segundo é objetivos claros que meio que entra na idéia de leitmotif e core loop. O terceiro é equilíbrio entre nível de habilidade e desafio, é sobre o que vamos falar hoje.

Primeiro de tudo, então, precisamos entender nosso jogador. Cada pessoa é diferente, tem habilidades e gostos diferentes, logo é impossível fazer um jogo que apele a todos os jogadores. Desta forma, uma das suas tarefas mais importantes (e difíceis) é entender qual grupo desses jogadores você vai focar em e tentar fazer o jogo tendo em vista uma média entre esse grupo menor que você selecionou.

O grupo de jogadores que você está focando se chama público-alvo e eu sei que soa como mais uma porcaria de marketing mas é sim muito importante para o desenvolvimento do seu jogo. Às vezes, você nem tá pensando em público-alvo mas acaba sim definindo ele.

Em Oniken, nós focamos (sem querer querendo) em um público que havia jogado os jogos de referência (Ninja Gaiden, Kabuki Quantum Fighter, etc), logo tentamos fazer uma dificuldade e escalamento de dificuldade próxima desses jogos.

Entretanto, esse público não passou os últimos 30 anos em uma caverna só com um NES e um gerador de eletricidade. Eles jogaram jogos recentes, eles se frustram com desafios injustos (quem, embora nossa nostalgia nos impeça de lembrar, estavam presentes aos montes nos jogos da era 8bits). Então, essa é outra coisa que tivemos que levar em consideração.

A partir do momento que você sabe, mesmo que mais ou menos, quem é seu público, você começa a entender como ele pensa e qual o fluxo de aprendizado/habilidade ele tem. E com isso em mente, podemos começar a pensar na distribuição da dificuldade.

Podemos aumentar a dificuldade em um jogo principalmente de três formas:

Adicionando uma nova mecânica ou diferenciação de gameplay. Cada novo inimigo com um diferente ataque, AI ou atributos é um uso dessa forma.

Aumentando a intensidade ou cobrança de mecânicas já existentes. Quando você entra em uma sala cheia de inimigos que você já conhece ou em situações novas.

Uma mistura de 1 e 2. Esse método é mais difícil de balancear e costuma resultar em uma dificuldade maior que os outros dois por si só, tornando-se em geral um desafio. É por isso que geralmente utiliza-se ambos os métodos para chefões para rituais de passagem, um desafio que irá ao mesmo tempo testar o aprendizado do jogador até esse momento e desafiá-lo a mostrar seu melhor desempenho.

Geralmente, a ordem usada para escalar a dificuldade em jogos começa com um 1, passando por 2, passando por uma série de 1s e 2s até chegar no 3.

Por exemplo, se eu estivesse fazendo o level de um FPS eu começaria primeiro colocando o jogador em um lugar "seguro" para primeiro entender como se mover e usar a camera para logo em seguida apresentar o primeiro tipo de inimigo em uma sala (método 1). Em seguida, ele seria obrigado a entrar em um corredor com o mesmo inimigo (método 2, mesmo inimigo mas em um espaço fechado) e então em uma sala com dois ou três desse mesmo inimigo (método 2, aumentando o número de inimigos em um espaço "tranquilo"). Depois disso, eu poderia continuar brincando com variações de espaço e quantidades do primeiro inimigo ou introduzir o próximo inimigo ou mecânica (pense que em Doom você teve que aprender que os barils explodiam e podiam ser usados a seu favor).

Não existe certo ou errado aqui, só leve em consideração que o único motivo pelo qual qualquer pessoa irá jogar seu jogo é porque ela quer continuar entretida, seja por diversão ou qualquer outra emoção. Existe um número limitado de combinações possíveis entre um dado inimigo, espaços e obstáculos, ou seja, com o tempo, não importa o quão criativo você seja você precisa planejar a introdução de coisas novas no seu jogo durante toda a duração dele. Novas mecanicas, novos inimigos, novas coisas a se fazer. Mudar a corzinha e locação do cenário não é suficiente, nunca será suficiente, e você corre o risco de perder seu jogador pelo tédio. Se possível, faça um planejamento de quando cada coisa será introduzida e tente não deixar nenhum espaço muito grande.

Esse planejamento não deve ser escrito em pedra, esteja sempre pronto para calibrá-lo tendo em vista que fluxo de aprendizado do seu público-alvo é sempre diferente do seu. Mesmo porque, como desenvolvedor você está sempre testando seu próprio jogo e sempre adquirindo uma habilidade irreal para alguém que irá jogar seu jogo casualmente. Embora você sempre tente simular essas capacidade é legal sempre aferir suas predições.

O teste local

Fazemos isso assistindo pessoas que são do público jogando o jogo sem interferirmos, de qualquer forma que seja. Não importa o quanto você esteja se coçando para dar uma dica, se você interferir você já não vai ter um resultado objetivo desse teste. O jogo tem que estar claro e não ser muito frustrante, seja por estar muito difícil ou muito fácil. Lembre que como cada pessoa é diferente, mesmo dentro seu público haverá pessoas achando algo fácil e outras difícil, então tente mirar sempre para o meio termo aqui.

Outra coisa, lembre-se que você só consegue a experiência de primeiro contato uma vez com cada pessoa. Então, não teste o jogo com todos seus contatos que fazem parte do público alvo de uma vez. Teste com alguns e vá guardando uns "virgens" para build mais avançadas do projeto. É sempre útil ter pelo menos um par de olhos fresco a cada grande teste.

O teste online

Nem sempre conhecemos ao vivo várias pessoas que fazem parte do nosso público, então por isso as vezes acabamos colocando uma build online e esperando o melhor. Embora com uma build online você consiga atingir muitas mais pessoas, você dificilmente poderá captar a expressão do rosto ou onde a pessoa ficou mais frustrada ou mais impressionada. No melhor dos casos, você vai receber um email detalhado do que a pessoa gostou e do que não; no pior, vai receber uma rating negativa.

No teste online não há muito parâmetro geral para nada. Você pode mandar para alguns amigos e dar instruções gerais de coisas que você quer saber, você pode colocar a build em uma plataforma aberta e pública como o itch.io ou até o twitter e esperar que estranhos anônimos dividam a experiências deles com você ou outro método a sua escolha. O importante é tentar entender por meio de todos esses pedacinhos de feedback se o jogo está causando o flow para uma parte razoável dos jogadores e, se não está, o porquê disso.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

Coloca um tchan nesse jogo

Já sentiu um cheiro que te lembrou de alguma coisa? Você não consegue mais beber vodka depois daqueles porres com Balalaika que você tomou?

Isso vem do nosso grande amigo Pavlov. Talvez você não conheça esse nominho, mas você certamente está familiarizado com as conclusões do trabalho dele sobre a capacidade de associação e reconhecimento de sinais do cérebro.

Os experimentos mais conhecidos de Pavlov eram razoavelmente simples, mas ainda sim bem eficientes. Ele tocava um sino toda vez que alimentava cachorros. Após exposição suficiente a esse "treinamento", apenas ouvir o som do sino era suficiente para fazer os cães salivarem. Sem nenhuma outra referência a comida como ou cheiro ou a visão dela, os cães passaram a associar o som do sino à própria comida.

Isso acontece porque quando fazemos algo que é prazeroso, seu cérebro recebe um teco de dopamina. E dopamina é um negócio sério para o seu cérebro, ele tenta optimizar o recebimento dela o máximo possível. Então, se algo sempre acontece junto com o recebimento de dopamina, vamos chamar esse algo de estímulo, o cérebro começa a associar essa outra coisa com o prazer da dopamina também. Assim, só perceber receber esse estímulo, o cérebro já começa a liberar dopamina.

De forma semelhante, estímulos podem ser associados a coisas negativas. Pavlov usava choques para tornar estímulos negativos, você usou o vômito e a ressaca para associar reflexos negativos a balalaika. A associação negativa não tem uma reação tão forte no cérebro como a positiva com dopamina, então mesmo que muitas vezes a associação ocorra ela costuma ser menos imprecisa ou menos forte (você continua tomando Smirnoff que eu sei).

É por isso que, se você jogou Super Mario Bros, o som de pegar uma moeda do jogo ainda te faz ter uma sensação boa. Enquanto que o som de morte tráz algo negativo. Claro que a própria composição desses sons foi feita pensando nessas sensações, entretanto todas as milhares de vezes que você jogou Super Mario Bros, ouviu esses sons e imediatamente depois disso sentiu algo (bom ou ruim) conferiu a esses sons o poder de trazer um pouco do sentimento que o seguiu tantas vezes.

Quando estamos no começo de um projeto de jogo, tendemos a pensar que o feedback é algo mais para o final, um polimento a ser adicionado.

Isso é um grande erro. Adicionar informações visuais e sonoras de que o jogador está "fazendo certo" ou "fazendo errado" sem você ter que ficar pulando do lado avisando isso não só essencial para o entendimento básico da mecanica principal. É também um dos motivos para o jogador continuar jogando seu jogo e até, quem sabe, gostar dessa coisa aí que você fez.

Vou chamar esse estímulo de feedback, mas podia chamá-lo de juice ou de "o gostosinho" de jogar o jogo, todos expressões que já ouvi por aí. Prefiro feedback por que é o mesmo termo que o Mihaly Csikszentmihalyi usa para falar dos sinais que as pessoas percebem em uma atividade quando entram no flow. Pode soar um pouco confuso se você está acostumado a pensar em feedback como opinião de pessoas sobre o seu jogo, que é um sentido que eu uso também na vida mas não nesse texto.

Esses estímulos ou feedbacks vão servir para: 1) mostrar que o input que o jogador colocou foi recebido pelo (como o som de passos ou o deslocar do avatar); 2) mostrar o resultado da ação executada por esse input (som de pagar a moeda ou power up); 3) dar sentido a ação executada (sentido positivo ou negativo); 4) estimular a repetição das ações positivas e desestimular as negativas (você salivando pelo barulho do sino).

Então, antes de muita coisa pensa como você vai comunicar para o jogador o que é ~certo~ e o que é ~errado~. Estou colocando entre ~ por que certo e errado são termos muito contextuais, dependem de jogo a jogo ou do momento no jogo ou até o contrário do que deveriam significar para o jogador. Em jogos como Braid e Spec Ops, o jogador é levado a crer que certos comportamentos são ~certos~ quando na real são ~errados~. Mas tenha ciência que isso foi intencional e essa desilusão foi construída para ser assim e revelada apenas no fim. Enquanto no começo do jogo, o jogador é levado a crer que certos comportamentos são realmente certos.

Em jogos de luta, o som e as poses e expressões do personagem são os maiores comunicadores de ~certo~ e ~errado~, mas ao mesmo tempo temos outros estímulos para incentivar o jogador a dar ainda mais valor positivo para o ~certo~, como os combos e a comunicação visual deles.

Caixas de texto, efeitos coloridos e screenshakes são todos excelentes indicações para ajudar seu jogador a 1) entender o que está acontecendo e 2) gostar ou desgostar cada vez mais de fazer certas coisas, mas cuidado! Todos esses estímulos já carregam alguns sentidos, não imagine que você pode empregá-los como bem entender pois eles podem sim ser mal compreendidos por seus jogadores.

Um som que soa meio positivo pode ser problemáticos para passar a sensação de morte (a não ser que a ambiguidade faça parte do seu leitmotif), um feedback positivo vermelho pode não passar imediatamente esse sentido se seu público joga muito FPS. Claro que você pode construir esses sentidos dentro do jogo, mas sempre que possível tente tirar vantagem do que já é consenso entre seu público pois facilita a compreensão.

O screenshake é um dos meus feedbacks favoritos por que não é inerentemente nem bom nem ruim atualmente; há jogos que usam para comunicar desempenho positivo e outros para negativo. Não importa para qual você use, apenas use de forma consistente. Pavlov teve que repetir o estímulo junto com a recompensa diversas vezes até os cachorros associarem os dois, você deve fazer o mesmo com o seu jogador. E faça o máximo para não fazer estímulos que signifiquem coisas diferentes serem semelhantes (novamente, a não ser que a ambiguidade faça parte do seu leitmotif), caso contrário você corre o risco de só ser confuso pacas.

Agora, para balancear o número de feedbacks e a sua intensidade não tem muita regra. Imagine que você é dono de uma caixinha de luzinhas ou de carimbinhos de "legal" e "tente melhorar"; com qual frequência você deve usar cada um deles depende muito do feel do seu jogo e do ritmo que você quer passar. Jogos como Dark Souls tem muitos feedbacks de erro e acerto, mas não muitos para incentivar que o jogador continue acertando. Faz sentido no mundo de Dark Souls, que tem um ambiente austero e quer passar um feel de que tudo a ser feito no jogo requer trabalho e habilidade. Já jogos como Candy Crush dependem fortemente em seu feedback não só para comunicar erros e acertos, mas também para manter os jogadores interessados em jogar.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

Ou como criar atmosfera e mundo sem ficar louco no processo

Já passamos por bastante coisa na nossa busca por simplicidade no game design, já decidimos o leitmotif do jogo e já entendemos a mecânica principal e core loop dele. Está na hora de expandir o projeto e entender o que realmente esse jogo será sobre e como isso vai acontecer.

Comece pensando pelo tempo que você tem. É sério, comece pensando quantas horas por dias você vai poder dedicar a esse jogo. E quantas horas as demais pessoas da equipe vão poder. Sejam honestões, nada de ~se eu dormir 4 horas por noite~, isso é inviável a longo prazo.

O tempo que vocês vão ter vai depender muito das obrigações que você tem na vida. Você estuda? É algo que vai consumir entre 30 e 60h da sua semana. Trabalha? entre 20h e 44h. Tem filhos, família? No mínimo, 10h por semana com eles. Animais? São menos exigentes que filhos mas ainda sim vai quase 10h por semana.

Eu não estou pedindo para você considerar isso porque acredito que essas atividades e criaturas são obstáculos no caminho de você fazer um jogo. Muito pelo contrário, eles são parte de quem você é e se são importantes para você e te fazem felizes (ou se pagam suas contas, no caso do emprego) você deve dedicar tempo a eles. Entretanto, é importante que você mantenha essa matemática em mente quando está estimando quanto tempo vai ter para fazer o jogo.

Mesmo que você esteja em tempo integral dedicado ao jogo, existe um prazo limite para fazê-lo. Seja o tempo que você vai conseguir manter sua atenção nesse projeto, seja o tempo que a grana vai durar (e se você acha que é um ano, considere que seja seis meses. Imprevistos acontecem, conte com eles com certeza).

Colocando o tempo semanal de desenvolvimento esperado e/ou a deadline em mente, você irá sentir uma leve (esmagadora) pressão. Não se desespere, esse é o momento idéia de pensar no universo e escopo do seu jogo!

Agora que você está sentindo o peso do tempo, se cerque de referências que você acredita que irão complementar o seu leitmotif e sua mecânica principal. Evite usar só jogos, pense em filmes, quadros, livros, lugares, sensações, pessoas… Tente absorver o máximo possível, vivenciar cada momento em cada referência, mas só registrar o que realmente te marcar.

Eu pessoalmente gosto de ir anotando coisas que eu acho interessante em uma folha qualquer. Depois, eu passo elas a limpo tentando juntar elas em categorias. Decadência vai ser um tema na arte, mas não da história. A história vai ser um arco clássico falando sobre vingança. Acho que vou colocar um personagem em vários momentos da vida dele para mostrar isso. Esse tipo de categorização, nada muito sério nem muito específico. Mas a forma de registro é outra coisa bem pessoal, veja como funciona melhor pra ti.

Um mundo coeso e rico nasce de apenas umas poucas diretrizes. Ele vai ficar mais complexo e cheio de detalhes conforme o jogo vai se desenvolvendo,mas a princípio você realmente só quer definir algumas diretrizes principais. Caso contrário, você irá engessar muito o conceito.

Imagine o processo de construção do universo como se fosse uma árvore, para usar a metáfora que a game design foda Maíra Testa me emprestou. O que você vai fazer no começo do projeto é definir o formato do tronco, de onde vai sair os principais galhos e onde ficam as raízes. Você precisa entender as regras fundamentais do seu universo, mas não cada detalhe dele. Você precisa deixar espaço para o crescimento dos galhos, se não vai sufocar a sua árvore antes mesmo dela crescer.

Olha só, abriu um espaço para te lembrar mais uma vez de não deixar as coisas muito específicas agora no começo. Especificar muito não só te faz gastar muito tempo em coisas sem muito retorno para o começo do desenvolvimento (é melhor ter uma build funcionando toda torta do que 30 páginas de lore sem nada jogável), como também pode se tornar um obstáculo para o crescimento orgânico de temas e mecânicas conforme o jogo vai sendo desenvolvido.

Crescimento orgânico de um jogo é quando, conforme você vai fazendo as coisas que estão planejadas, uma idéia muito loka aparece e ela é melhor do que os planos. Isso sempre acontece, mas se você definir tudo no começo é mais difícil de achar um espacinho para idéia orgânica quando ela aparece. O crescimento orgânico é uma das coisas mais legais de se fazer jogos e algumas das partes mais interessantes de jogos que amamos surgiu dele. Dá uma chance para ele crescer, deixa uns espaços a serem definidos com o tempo.

Durante o desenvolvimento, você vai ter que fazer várias coisas que não estão previstas e mudar outras que pareciam certas para ter um melhor design. Com o mundo muito detalhado logo no começo, essas mudanças ficam mais difíceis. Você pode até acabar aceitando um design menos interessante só para não ter que mudar muita coisa no lore. Isso é inaceitável. A linguagem do jogo é a experiência que o jogador terá nele, nada deve ficar no caminho da melhor experiência possível, nem os seus devaneios com o mundo do jogo.

Fora essas sugestões, eu não tenho nenhum método ou processo especial para criar o universo do seu jogo. O mundo, os personagens, as cores, as inspirações, as formas, as sensações… Nenhuma forma de se fazer coisas é melhor que a outra. E se alguém disser que é, já grita na cara dele que ele tá falando bosta.

Aliás, essa dica de sentir o peso do tempo, colocar-se em tensão e partir para tentar relaxar com as referências e partir para a delimitação das diretrizes do seu universo é, na verdade, mais uma dica do que qualquer outra coisa. Costuma funcionar comigo, definir o macro e depois pensar no micro, sem se preocupar mais com nada.

Mas se não funcionar com você, faz outra coisa, ué. Esse é o momento mais pessoal e único da criação do jogo. É quando a mágica acontece. Manda bala, anjo.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

A base do seu jogo

Você já deve ter ouvido falar de core loop. Se não ouviu, ainda dá tempo de fingir o contrário. De qualquer forma, core loop é o fluxo de ações principal que compõe um jogo. É o que você vai fazer do começo ao fim do jogo, com algumas variações. Se você realmente procurou por core loop no google, deve ter visto vários exemplos de cow clickers com plantar recurso > esperar tempo > recolher recurso > comprar mais recurso > plantar recurso e deve estar pensando "que bosta de conceito, só serve pra esses jogos bosta" e é aí que você se engana: o core loop está em todo lugar.

Um exemplo simples de core loop é Shadow of the Colossus: Procurar monstro>achar monstro>matar monstro>procurar monstro de novo. Ou o de um RTS padrão, que é coletar recursos>construir unidades e bases>fazer upgrades nas unidades e bases>aumentar área de controle>coletar recursos.

O core loop é a unidade básica de qualquer jogo e ele precisa representar oleitmotif do mesmo. Se o jogo visa ser divertido, o core loop precisa ser divertido. Se o jogo deve ser trágico, algo no core loop tem que remeter a essa tragicidade. Um bom exemplo de core loop trágico pode ser visto em This War of Mine, onde toda gameplay é baseado em fazer escolhas de gerenciamento para evitar perdas. Entretanto, elas sempre acontecem, pois essa é a mêcanica do jogo. Ao basear o funcionamento principal em uma mecânica de perda, o jogo enfatiza ainda mais para os jogadores a sensação lúgubre e trágica do jogo.

Um jogo precisa ter um core loop que o complemente, faça sentido e seja atraente e divertido o suficiente para o jogador continuar fazendo-o o jogo inteiro. Logo, não saia criando o lore, a história do mundo em cinco gerações pra trás ou todo o sistema de upgrades antes de ter um core loop que funcione. Por isso, mais uma vez: faça um protótipo do core loop. Já fez? Faça mais um, pro santo, pra dar sorte, pra exu, pra crom, pra sagan ou seja o que for que você acredite.

Agora pense no seu jogo. Pense no seu leitmotif. Pense em o que você quer que o jogador faça no jogo. O core loop está enfatizando a sensação que o leitmotif quer passar? Se você não tem certeza absoluta, faça um protótipo. Se você tem certeza absoluta que passa, faça dois protótipos. É sério, não é que eu não confio em você; o que eu não confio é na sua capacidade de julgamento em relação a algo que você está tão apaixonado sobre. E você também não devia.

Vamos falar mais sobre protótipos mais para frente, mas, no momento, pense nele como uma prova que o seu core loop funciona. Da mesma forma, não saia pensando ou fazendo todo o resto do jogo antes de ter feito as decisões relevantes ao core loop. Criar conteúdo ou sistemas antes de fechar essas coisas leva apenas a duas coisas: trabalho jogado fora e a evitar fazer mudanças necessárias por medo do trabalho que vai ser jogado fora. Ou seja, duplo trabalho jogado fora.

Claro, problemas podem ser descobertos a qualquer momento do desenvolvimento, e trabalho vai ser jogado fora em qualquer jogo, mas se temos a possibilidade de diminuir esse desperdicio, por que não?

Muitas coisas podem acontecer assim que você montar o protótipo. Pode não estar ótimo, mas com melhorias fáceis de visualizar. Pode estar estranho, precisando ganhar ou perder parte das funcionalidades. Pode estar um lixo completo que precisa ser repensado do zero.

O que ele nunca, nunca, nunquinha vai estar na primeira implementação é perfeito. Se você acha que está, teste com outras pessoas. Nenhum protótipo nunca estará, em sua primeira implementação, tão bom que não possa melhorar.

Após algumas modificações, pegue o protótipo do core loop, jogue-o. Ele passa seu leitmotif e ao mesmo tempo está interessante? Faz você querer continuar jogando? Se não, volte a fazer algumas mudanças. Se sim, dê para mais pessoas jogarem e perguntem para elas o que elas acharam, como elas se sentiram, como o jogo pareceu para elas. Tente passar o mínimo de informações sobre seu objetivo para o jogo nessa conversa pois você pode acabar contaminando as impressões da sua cobaia/jogador. Você quer saber das primeiras impressões do jogador de forma neutra e não ter as suas impressões repetidas a você por um terceiro.

Não limite iterações e mudanças no protótipo. Não controle sua vontade de testar as coisas mais loucas. Essa é a hora de testar coisas loucas, essa é a hora de mudar e testar várias coisas diferentes. No desenvolvimento, com parte do jogo mesmo pronto, você não tem essa liberdade de mudar de direção ou jogar partes do jogo fora porque muitas horas já foram gastas implementando-as.

No final desse processo, você deve deve ter uma boa idéia de qual é seu core loop, o que funciona com ele e o que pode ser jogado fora. Tente sempre tentar se limitar ao básico, ao essencial para realçar o seu leitmotif. Não importa que a história ou a arte vão falar disso também, seu jogo é um jogo. Se ele tem uma mensagem, ela tem que estar presente também nas mecânicas do jogo.

O core loop é o que resta quando você limpa todos os shennenigans de arte e mecânica, é a base do seu jogo. Dessa forma, você precisa ter um bom entendimento dessa base para tomar suas decisões sobre o que realmente é importante no futuro com mais clareza e serenidade.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

ou Keep It Simple, Stupid

Um jogo é um objeto que cria uma experiência. Cada jogador vai ter sua própria experiência resultante dele, é claro, cada uma delas vai ser única. Mas todas essas manifestações do jogo são criadas pelo sistema de regras e acontecimentos do jogo. Tudo que o jogador passa no jogo foi de alguma forma colocado no jogo pelos desenvolvedores, seja de forma intencional ou não. Um item, por exemplo, serve para função X, foi colocado pelos desenvolvedores por motivo X e resultará no efeito Y para o jogador.

Y é decorrente do X que você planejou, mas ainda é Y e não X.

Nem sempre a interpretação é tão direta quanto esperamos e muitos elementos podem não funcionar como o esperado. Daí, para garantir, pensamos em adicionar os itens B, E e S para aumentar a experiência Y. E já que estamos nessa, implementar os sistemas T e A que você viu naquele jogo legal e O só por que foi uma idéia bem legal que alguém deu e todo mundo gostou. Também tem a área S que já estava pronta mesmo então seria um desperdício não colocar (só que você não esperava que ela ia precisar de mais dois meses para funcionar com os novos sistemas). Daí um projeto de 4 meses e 3 pessoas vira uma quimera de 3 anos e 12 pessoas que nunca é terminada e todos se odeiam quando enfim tudo acaba.

Por isso, a melhor forma começar a fazer um jogo é, antes de qualquer coisa, saber qual é que é desse jogo. Seu leitmotif, sua mensagem. O porquê ele existe. E se você está em um equipe, quanto antes todo mundo concordar com essa mensagem, mais rápido vocês vão começar a realmente trabalhar nesse projeto.

Eu gosto de pensar que todo jogo pode ser resumido em uma palavra, mas você não precisa ser tão reducionista. Uma frase é mais que o suficiente para entender qual o motivo guia do seu jogo.

Super Mário tematicamente é sobre um encanador se divertindo em uma terra mágica. Todo o clima do jogo é leve e divertido, o sequestro de Peach é só um plot device como qualquer outro e em nenhum momento impacta de forma séria ou negativa no jogo. Mas um jogo não é apenas temático, é também jogável. Mecanicamente, Super Mário é um jogo sobre pulos. Pare para pensar: tudo que você consegue fazer em Super Mário é, de alguma forma, relacionado a pulos e sua precisão em executá-los. E isso fica claro logo na primeira fase. Dessa forma, toda a estrutura de levels de Super Mário foi pensada para explorar ao máximo a mecânica do pulo, enquanto que toda a sua arte (visual e sonora) ressalta a leveza e diversão desse mundo. Um belo sanduíche de leitmotif.

Alien Isolation tematicamente é sobre sobrevivência em um ambiente hostil e futurista, e essa filosofia está tanto na tematica como no gameplay. Tudo no gameplay no jogo reverte para essa tensão, para a falta de segurança e poder dentro desse mundo que te quer morto. O jogo nem permite ao jogador usar o craft dentro de esconderijos: o jogador deve se sentir vulnerável enquanto faz algo de útil e quando se esconde é obrigado a ficar sempre prestando atenção no exterior. Um sanduíche de ansiedade, mas um sanduíche intencionalmente servido assim.

Em Odallus queríamos fazer um jogo de exploração plataforma clássico, mas que também fosse simples o suficiente para não precisar de mapa para os levels. Essa simplicidade nos levou ao sistema de fases. A "classicidade" do gameplay nos levou a um tipo de história também clássica, sobre busca por poder e vingança, mas também nos levou a estrutura comum em lendas que se baseia na circularidade da história. Todos os personagens do jogo são egoístas e só se importam com seu próprio benefício, o gameplay permite que o jogador acumule poder, upgrade por upgrade. O fim de Odallus é muito próximo do começo de Odallus, trazendo a circularidade de volta.

Em Rainy Day, o leitmotif era só um: passar ao jogador a sensação de viver com ansiedade e depressão. Isso guiou todas as escolhas, de tema a gameplay e arte. Eu explico isso mais a fundo aqui.

Se você definir exatamente qual o objetivo do jogo antes de qualquer outra coisa, o porquê ele existe e qual as sensações que você quer passar, você terá a semente para o seu projeto. Não desmereça essa tarefa ou ache que está levando tempo demais: é melhor gastar tempo definindo os limites no começo, quando ainda se pode tudo, no que no meio, quando redefinir coisas significa jogar fora muito trabalho que já foi feito. Ter as bases definidas no começo não só é uma mão na roda para evitar que o projeto fique grande demais e perca o escopo, mas também resulta em um jogo com uma mensagem bem mais clara para o jogador.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo

e termine essa droga desse jogo.

Todos nós temos nossas diretrizes de design. Aquela voz no fundo da sua cabeça que toda vez que você está criando algo dá direções para a maioria das suas decisões. Ela está lá dentro, sutil, como um eco influenciando tudo o que você faz. Mas justamente por conta dessa natureza fulgaz, você acha que outras pessoas não compartilham desse direcionamento. Que é uma coisa sua, um fetiche de desenvolvimento seu.

Há alguns meses, aconteceu a Global Game Jam e com elas várioscompilados de dicas sobre desenvolver jogos em prazos curtos foram publicados. Tendo reunido também uma seleção dessas dicas de desenvolvedores, fiquei surpresa com a recorrência de uma sugestão em particular, que coincidentemente é uma das minhas diretrizes pessoais de design.

Pense pequeno e termine o jogo

Na verdade, aproximadamente 1/3 das dicas se resumiam nessa sugestão em particular. Isso mostra o quanto reduzir o escopo do seu jogo não só é importante para de fato completar o projeto, mas também indica o quão frequentemente desenvolvedores, mesmo os experientes, não acabam caindo nessa armadilha de acreditar que possuem um projeto "simples" nas mãos mas acabam subestimando-os.

É comum acreditar que quanto maior melhor, quanto mais conteúdo e informações, quanto mais mecânicas e gráficos, melhor um jogo vai ser. Afinal, é o que a indústria AAA anda fazendo nas últimas duas décadas e todos os lançamentos vem com anúncios contando números de polígonos, horas de gameplay, quantidades de mapas, tipos de gameplay, etc.

Mas a verdade é que embora esses aditivos podem aumentar o tempo gasto pelo jogador, não tornam nenhum jogo melhor.

A partir de hoje, vou fazer uma série de posts sobre pensar pequeno na hora de desenvolver um jogo. Vem comigo.

Série Pense Pequeno

Pense pequeno: e termine essa droga desse jogo.

Entendendo o leitmotif do seu jogo ou Keep It Simple, Stupid

Mecânicas principais e core loop: A base do seu jogo

Seu universo em uma noz: Como criar atmosfera e mundo sem ficar louco no processo

Feedback, feedback e FEEDBACK: Coloca um tchan nesse jogo

Escalando Dificuldade ou o Flow do seu jogo

Ritmo: A linha de sensação do seu jogo