Você está na página 1de 53

Pense Pequeno e

Termine seu
primeiro
videogame
Thais Weiller
Pense Pequeno e

Termine seu
primeiro
videogame

Thais Weiller

Ilustração de capa por @bakudas, que é uma parte do jogo Soulstice


(https://midipixel.itch.io/soulstice  ) um jogo de @ysperanza,
@w_werther e @bakudas

Primeira edição, 2017



Pense Pequeno ...................................................4

Menos é mais ............................................................................................................5


O faz um jogo bom...................................................................................................6

Entendendo a essência ....................................8

Leitmotif .....................................................................................................................9
Entendendo a essência........................................................................................... 9

Mecânicas principais e core loop ................12

Reforçando sensações, enfatizando a mensagem........................................ 15


Tomadas de decisão sobre o protótipo ............................................................ 16

Seu universo em uma noz .............................18

Colhendo Referências ..........................................................................................19


Condense as referências em diretrizes ............................................................ 20
Fecha tudo ..............................................................................................................22

Feedback, feedback e FEEDBACK! ............24

Escalando Dificuldade ...................................30

Teste com frequência .....................................36

Antes de tudo, bug hunt ......................................................................................36


O teste local ............................................................................................................38
O teste online .........................................................................................................39
A/B testing ..............................................................................................................40
Ouvindo o que seu jogador tem a dizer ...........................................................41

Ritmo ...................................................................43

Cortes .......................................................................................................................45

Foca no jogo ......................................................48

Situações corriqueiras que levam a cortes ..................................................... 48


O corte como escolha estilística ........................................................................51

Fechando esse jogo ........................................53

Sucesso ....................................................................................................................53
1.
Pense Pequeno

E termine essa droga desse jogo

Jogos parecem mágica. Uma coisa de outro mundo.

Um mundo melhor, que foi concedido a nós, meros mortais, por pura
sorte. E por termos eles em tão alta estima como jogadores, acabamos
nos empolgando um pouco na hora de mudar de lado e começar a
desenvolver jogos.

É por isso que eu gosto de me inspirar no desenvolvimento de jams. Se


você não sabe, jams são eventos que dão um limite de tempo (em geral
48 horas) para grupos de desenvolvedores de jogos (ou devs) criarem
um jogo, anunciando o tema só minutos antes da jam de fato começar. É
muito interessante ver as criações que saem desses eventos, a maioria
meio maluca, meio mal acabada, mas sempre interessante. Muitos jogos
famosos e bem sucedidos de hoje têm sua origem em jams passadas, em
especial à Global Game Jam, a maior jam do mundo que ocorre todo
começo de ano.

Próximo de toda Global Game Jam pipocam  vários compilados  de


dicas sobre desenvolver jogos. Não importa se vai ser sua primeira jam
ou sua centésima, é sempre interessante ler essas dicas para poder
entender um pouquinho melhor como outros desenvolvedores se
preparam para fazer jogos e quais etapas eles costumam seguir.

Esse conjunto de etapas se chama processo criativo. Cada um tem o seu,


é inútil tentar copiar o dos outros, mas sempre podemos aprender
novas partes ou métodos para testar colocar no nosso.
Como desculpa para entender o processo criativo dos outros devs e
para me intrometer mesmo e saber como eles estavam se preparando
para a Global Game Jam de uns anos atrás, saí pedindo dicas para
montar um artigo sobre isso. Consegui uma gama enorme de respostas
tocando os mais diversos temas, desde engines à alimentação e higiene
pessoal nos dias que se passam a jam, mas o mais surpreendente foi a
recorrência de uma sugestão em particular:

Pensei tão pequeno que até copiei o comentário para nomear o livro.

Aproximadamente 1/3 das dicas se resumiam em reduzir seu jogo ao


essencial a fim de terminá-lo de forma satisfatória e ainda ter tempo
para algum polimento. Isso mostra o quanto  reduzir o escopo do seu
jogo não só para fazer o jogo mas, em especial, para de fato completar o
projeto.

Mas essa recorrência, sem quer querendo, também mostra outra coisa:
o quão frequentemente devs, mesmo os experientes, acabam caindo
nessa armadilha de acreditar que possuem um projeto "simples" nas
mãos. Mas não, subestimaram o levitam e agora deu merda.

Menos é mais

(pelo menos no seu primeiro jogo)

É 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.
Seus lançamentos vem com anúncios contando números de polígonos,
horas de gameplay, quantidades de mapas, tipos de mecânicas
diferentes, quantos personagens destraváveis, modos diferentes de
campanha etc.
Mas a verdade é que, embora esses aditivos podem aumentar o tempo
gasto pelo jogador em um jogo, não tornam nenhum jogo mais
completo como jogo. Ter 50 chapéus destraváveis, multiplayer e co-op
pode até ser dahora, mas não vai tornar seu jogo necessariamente
melhor.

O faz um jogo bom

ou o que não te atrapalha no processo de fazer um

Todos nós temos nossos ideais de o que faz um bom jogo. Aquela voz no
fundo da sua cabeça que direciona suas decisões quando você está
criando algo. Ela está lá dentro, sutil, como um eco influenciando tudo o
que você faz.

Essa voz é sua filosofia de criação ou processo criativo, mas enquanto ela
mantém sua natureza fulgaz, só dentro da sua cabecinha, você pode
parar de ouví-la em algum momento do desenvolvimento e nem se dar
conta. E aí, você pode empacar em uma certa área do desenvolvimento
ou ainda passar meses em uma mesma feature só para se dar conta que
ela não funciona muito bem com o resto do seu jogo. Isso é perder o
escopo, ou perder a noção da importância de cada coisa dentro do todo
que é o jogo.

Quanto mais jogos você faz, mais forte fica essa voz que te lembra de
voltar ao essencial, mas isso não significa que ela se torna invencível.
Perder o foco do jogo não é exclusividade de novatos, muita gente com
anos de indústria as vezes acaba caindo nessa e, sem querer querendo,
perde meses e meses de desenvolvimento em coisas que acabam se
tornando inúteis. Vide quantos veteranos recomendaram Pensa
Pequeno na minha humilde pesquisa.

Nesse livro, eu vou ser essa voz para você.

Eu vou sussurrar nos seus ouvidos (por meio dos seus olhos) para você
parar de perder tempo com certas coisas e se focar em outras. Vou
bater na sua mão (figurativamente, queridinha) e suspender essa
feature nova que você ia começar a implementar antes de implementar
a mecânica principal. E você vai me odiar.
Mas tudo bem, você não será o primeiro e eu estou aqui para isso
mesmo. O importante é que você termine seu jogo no final. Fim.

Esse livro segue a ordem comum de etapas no desenvolvimento de um


jogo. Cada capítulo é, de forma bem geral, sobre uma dessas etapas.
Claro, há muitas mais etapas e nem todo tipo de jogo segue exatamente
essa ordem. Mas a verdade é que o mesmo conselho que eu estou te
dando eu estou seguindo para mim: pensar pequeno.

A idéia é te dar uma visão geral, simplificada, das fases do


desenvolvimento, das armadilhas que elas trazem para a continuação
do desenvolvimento e como evitá-las. Eu confio em você para pegar
essa visão geral e adaptá-la para sua necessidade da melhor forma
possível.

Você é esperto, você faz jogos.



2.
Entendendo a essência

ou a razão de existir do seu jogo

Um jogo é um objeto que cria uma experiência. Cada jogador vai ter sua
própria experiência resultante dele e ela será única dependendo no
momento em que foi jogado, do passado do jogador e suas habilidades.
Mas todas essas manifestações do jogo são criadas pelo sistema de
regras e acontecimentos do próprio 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, que serve para função X e foi colocado pelos
desenvolvedores por motivo X, não vai resultar em X para o jogador.
Para o jogador, ele resultará no efeito Y. O Y é decorrente do X que
você planejou, mas Y ainda não é X.

Devido a natureza interativa dos jogos e somando-se a ela a bagagem


pessoal de cada jogador, seu estado emocional e cognitivo no momento
que ele joga e até o ruído do ambiente (se há barulho, se há muita luz
refletindo na tela, etc), muito dificilmente a interpretação do jogador
será tão direta quanto esperamos. Muitos elementos podem não
funcionar como o esperado, aquele pedaço de informação no
background pode passar despercebido, a cena mais emocionante do
jogo acaba causando impacto nenhum, a mecânica não é tão fácil de
dominar como previsto. Daí, para garantir que a experiência Y seja o
mais próximo possível do X, você adiciona os itens B, E e S. 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 (você não esperava que ela ia precisar
de mais dois meses para funcionar com os novos sistemas, mas foi o que
acabou acontecendo). 
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, é
acaba todas as condições de continuar o desenvolvimento e ninguém
mais está trabalhando no projeto.

Por isso, a melhor forma começar a fazer um jogo é, antes de qualquer


coisa, saber qual é que é desse jogo, sua mensagem.

Leitmotif

Ou, o porquê de existir do jogo. 

Se você está sozinho ou em uma equipe, não importa. Quanto antes


todo mundo envolvido com o jogo concordar com o motivo de existir do
jogo, mais rápido vocês vão começar a realmente trabalhar nesse
projeto. E sério, não adianta conversar uma vez e acreditar que todo
mundo está com a mesma visão.

Não acontece assim. Cada pessoa parte de sua própria vivência, das
experiências e referencias que teve durante sua existência. Quando eu
digo qualquer palavra, como por exemplo “ação”, ela vai evocar idéias e
sensações completamente diferentes dependendo da pessoa. É preciso
muita conversa, esboço, exemplos, imagens até todo mundo estar com a
mesma idéia, indo para a mesma direção.

E mesmo se você está trabalhando sozinho, definir claramente qual o


propósito do seu jogo vai poupar muito trabalho extra no futuro.

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

O leitmotif é o que sobra quando todo o resto do seu jogo vai ter que ser
cortado por uma diminuição do orçamento. Ele é o que seu jogador
lembra com carinho, anos depois de ter jogado seu jogo. Vamos falar do
leitmotif de alguns jogos para entender melhor esse conceito.

Entendendo a essência

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. 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 descompromissado e feliz belo sanduíche
de leitmotif.

Tematicamente, Alien Isolation é sobre sobrevivência em um ambiente


hostil e futurista. Mas não é só no tema que esses pontos são
reforçados. Tudo no gameplay do jogo converte 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, enquanto
que quando ele 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, a gameplay permite que o jogador acumule poder,
upgrade por upgrade. O fim de Odallus é muito próximo do começo,
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.

Definindo 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 um projeto saudável.

Só não regue demais essa semente. Nem de menos. Nem deixe ela
fritando no sol. Ou seja, ainda tem várias coisas que podem dar errado,
mas você já começou bem.

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 (e para a equipe desenvolvendo!).

3.
Mecânicas principais e
core loop

A base do seu jogo

Você já deve ter ouvido falar de core loop.

Se não ouviu, ainda dá tempo de buscar na internes e de fingir que sabe.

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:

E deve estar pensando "que bosta de conceito, só serve pra esses jogos
bosta”. É aí que você se engana: o  core loop  está em todo lugar. Um
exemplo simples de core loop é Shadow of the Colossus:
Ou o de um RTS genérico:
Como é um loop, a ação inicial é também a final, o que forma um circulo.
A idéia é que o loop irá acontecer várias vezes durante o jogo, mas a
cada repetição irá causar uma diferenciação que irá mudar levemente o
funcionamento do loop. Por exemplo, tanto no cow clicker quanto no
RTS, a cada repetição o jogador terá muitos mais recursos para manejar
e, dessa forma, decisões diferentes se tornam possíveis. No caso de
Shadow of the Colossus, o jogador terá mais conhecimento do mapa,
das mecânicas e talvez até novos itens.
O  core loop é a unidade básica de qualquer jogo e ele precisa
representar o leitmotif do mesmo. Se o seu objetivo com o jogo é fazê-
lo divertido, o core loop precisa ser divertido. Se o jogo deve ser trágico,
algo no core loop tem que remeter a essa tragicidade enquanto ainda é
cativante ou desafiante de se jogar. Um bom exemplo de  core
loop trágico pode ser visto em This War of Mine, onde toda gameplay é
baseada em fazer escolhas de gerenciamento para evitar perdas. Ainda
sim, perdas ocorrem o tempo todo pois essa é a mêcanica principal 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 de seu leitmotif e se torna não um jogo de evitar perdas, mas de
minimiza-las, já que você vai perder de qualquer forma.

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 e pra frente ou todo o sistema de upgrades
antes de ter um core loop que funcione.

Reforçando sensações, enfatizando a


mensagem

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 desperdício, por que não
utilizá-la?

Muitas coisas podem acontecer assim que você montar o protótipo.


Pode não estar ótimo, mas está fácil de diagnosticar melhorias
possíveis. 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 ele não precisa de
nenhuma melhoria, teste com outras pessoas.

Nenhum protótipo estará, em sua primeira


implementação, tão bom que não possa melhorar.
Nunca. Nunquinha. Mesmo.

Tomadas de decisão sobre o protótipo

Após algumas modificações, pegue o protótipo do core loop e jogue da


forma mais imparcial, mais descompromissada que você conseguir.

Ele passa seu leitmotif e ao mesmo tempo está interessante?

Faz você querer continuar jogando?

Se a resposta foi não a qualquer uma dessas perguntas, volte a fazer


algumas mudanças. Se você respondeu sim a todas elas, 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 com 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 expectativas
repetidas a você por um terceiro.

Não limite alteraçõ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 tratar disso,
seu jogo é um jogo. Se ele tem uma mensagem, ela tem que estar
presente também nas mecânicas do jogo.

Reforçando 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.

O core loop é o que resta quando você limpa todos os embelezamentos


de arte, história e mecânica. É a base do seu jogo. Por isso, você precisa
entender muito bem essa base para 1)expandir o jogo em cima dela e
não contra ela e 2) tomar as futuras decisões sobre o jogo e o que
realmente é importante para ele com mais clareza e serenidade. Essa é
mais uma das etapas do desenvolvimento que você tem que levar o
tempo necessário para se sentir seguro com suas decisões.

Não siga adiante se o você não sente confiança no seu core loop.

4.
Seu universo em uma noz

Criando 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. Está na hora de expandir o projeto e usar
o que esse jogo será sobre para definir como ele 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. Não
espere como viável a longo prazo coisas que comprometam a saúde da
equipe, física e mental, pois isso só vai aumentar o stress, a insatisfação
e a qualidade geral de vida das pessoas. Vocês são melhores que isso.

O tempo que vocês vão ter vai depender muito das obrigações que
vocês têm 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, 20h por semana com eles. Animais? São menos exigentes que
filhos mas ainda sim vai quase 10h por semana com passeios ou
limpando caixas de areia.

Isso não quer dizer 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, você e sua equipe precisam ser realistas em quanto tempo


investem em familia, emprego, estudos, animais etc. E mantenham essa
matemática em mente quando estiverem estimando quanto tempo
terão para fazer o jogo.
Mesmo que você esteja em tempo integral dedicado ao jogo,
geralmente existe um prazo limite para terminá-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 preocupe, era exatamente isso que eu queria. Com esse peso
pairando sobre a sua mente, esse o momento perfeito para pensar no
universo e escopo do seu jogo!

Colhendo Referências

Agora que você está sentindo o peso do tempo é quando você tem mais
clareza sobre suas limitações de desenvolvimento.

Cerque-se de referências que você acredita que irão complementar o


seu leitmotif e sua mecânica principal e tente se imergir nesse mundinho
que você está criando. Leia livros que se passam em universos
parecidos, veja filmes que tenham visuais ou estruturas que você
pretende usar, vá a exposições que passem o feel que você quer. Tente
chegar o mais próximo possível de uma total imersão mesmo, evite ver,
ler, ouvir obras que não adicionem a esse universo.

Claro que você vai ter que quebrar essa imersão aqui e ali para sair com
os amigos ou a família para ver algo que eles querem, mas tente deixar
claro para seu cérebro que isso é externo ao trabalho. Parece bobo, mas
costuma funcionar bem para evitar contaminação (e até costuma te
deixar mais relaxado e aproveitando mais a companhia dos outros).

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ó registre o que realmente te marcar.


E registre de uma forma que faça sentido para você, a equipe e o
projeto. Poder ser só uma anotação ou uma polaroid da referencia,
pode ser um sketch ou modo board. O importante é registrar de
maneira concisa, de forma que só de bater o olho dê para refrescar na
mente o que aquilo significa.

Isso também te permite esquecer e abandonar o que não adiciona ao


seu mundo. Nem tudo que você ver nesse período e acha que é uma boa
adição de fato irá adicionar ao seu jogo. Também sinta-se livre para
remover registros, caso depois de algum tempo eles não parecem mais
fazer sentido coma direção que o projeto está tomando. Isso ocorre
com frequência.

Eu gosto de ir anotando coisas que eu acho interessante na minha


agenda. Nada formal, apenas um apanhado de informações, rabiscos,
frases. Depois, eu passo a limpo tentando juntar esses pensamentos e
idéias 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 não é nada muito sério nem muito


específico, mas te permite fazer novas conexões entre esses micro-
temas. Referências que você pegou para os inimigos podem servir para
o cenário ou até para o protagonista, ideias de cor podem influenciar o
tom que você escolheu para avançar na história, uma das musicas de
referencia pode te dar uma idéias de gameplay.

Mas isso é o que funciona comigo. A forma de registro é uma coisa bem
pessoal, de pessoa a pessoa e de equipe para equipe. Veja como
funciona melhor pra ti.

Condense as referências em diretrizes

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. Você


não precisa definir cada detalhe dele.

É preciso deixar espaço para o crescimento dos galhos, se não você vai
sufocar a sua árvore antes mesmo dela crescer.

Esse é seu jogo pronto, não tem pressa para chegar lá, não queime etapas (e não
comece um desastre ambiental).

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 orientações principais. Caso contrário, você vai deixar o
conceito muito engessado.
Lembre-se 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 o que já havia sido planejado. Isso sempre acontece, mas
se você definir tudo no começo é muito mais difícil achar um espacinho
para a nova idéia.

O crescimento orgânico é uma das coisas mais legais de se fazer jogos e


algumas das partes mais interessantes de jogos que amamos surgiram
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, tudo tendo em
vista o melhor design possível. Essas mudanças necessárias ficam mais
difíceis de serem feitas se o seu mundo está muito detalhado logo no
começo do desenvolvimento.

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.

Fecha tudo

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 só


então partir para tentar relaxar com as referências e delimitar das
diretrizes do seu universo é, na verdade, mais uma dica do que qualquer
outra coisa.

Costuma funcionar comigo, definir o macro, o que dá para ser feito, 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.
5.
Feedback, feedback e
FEEDBACK!

Coloca um tchan nesse jogo

Já sentiu um cheiro que te lembrou de alguém, mesmo essa pessoa não


estando lá no momento? Você não consegue mais beber vodka depois
daquele porre com Balalaika? Ouvir o som usado de sinal no seu colégio
ainda te trás um embrulho no estômago? O gosto de uma certa comida
te faz lembrar da infância?

Agradeça nosso grande amigo Pavlov. Não é que ele te fez ter essas
associações, na real elas vêm do seu cérebro e do cérebro de quase
todos animais complexos, mas o Pavlov foi quem descobriu, testou e
documentou esse padrão.

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 padrões pelo cérebro. Na psicologia,
essa teoria é conhecida como análise do comportamento ou behaviorismo.

Os experimentos mais conhecidos de Pavlov eram razoavelmente


simples, mas ainda sim bem eficientes. Ele tocava um sino toda vez que
alimentava um grupo de 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, afinal, ele evoluiu para conseguir o máximo de
dopamina possível em qualquer situação. Ele tenta optimizar o
recebimento dela o máximo possível. Desta forma, se algo sempre
acontece junto com o recebimento de dopamina (vamos chamar esse
algo de estímulo), o cérebro começa a associar esse estímulo com o
prazer da dopamina também. Com o passar do tempo, só perceber
receber esse estímulo, o cérebro já começa a liberar dopamina.

Gráfico exemplifica quando a dopamina é liberada em relação ao tempo conforme a


associação vai acontecendo.

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 à Balalaika. A
associação negativa não tem uma reação tão forte no cérebro quanto a
positiva com dopamina, então mesmo que a associação ocorra, ela
costuma ser mais 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 te trás algo negativo. Claro que a própria composição desses
sons foi feita pensando nessas sensações, mas não podemos esquecer
todas as milhares de vezes que você jogou Super Mario Bros.,  ouviu
esses sons e imediatamente depois disso sentiu algo (bom ou ruim).
Essa associação conferiu a esses sons o poder de trazer um pouco do
sentimento original que os seguiram 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 é apenas essencial para o
entendimento básico da mecânica principal (e um descanso para suas
pernas saltantes). É também um dos principais motivos para o jogador
continuar jogando seu jogo e até, quem sabe, gostar dessa coisa aí que
você fez. Os feedbacks não só ensinam ao jogador mais ou menos o que
ele tem que fazer e o quão bem ele está fazendo, mas também torna
todo esse processo mais prazeiroso e compreensível.

Vamos 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 livro.

Esses estímulos ou feedbacks vão servir para:

1) mostrar que o input que o jogador colocou foi


recebido pelo jogador (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 continuar, pensa bem 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 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ático 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 já
que facilita a compreensão. Você não tem que construir todo o sentido
por meio de estímulos, você já aproveita metade do sentido que vem do
consenso.

O  screenshake  é um dos meus feedbacks favoritos por que não é


inerentemente nem bom nem ruim no momento: há jogos que usam
para comunicar desempenho positivo e outros para negativo. Não
importa para qual sentido 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, caso contrário você
corre o risco de só ser confuso pacas e deixar seu jogador em um
grande estado de confusão mental.

A não ser, é claro, que a ambiguidade faça parte do seu leitmotif. Jogos


como Braid e Spec Ops, o jogador é levado a crer que certos
comportamentos são ~certos~ quando na real são ~errados~. Ou, pelo
menos, moralmente questionáveis.

Mas tenha ciência que essa mudança foi intencional e que é algo
complexo de se construir. No começo do jogo, o jogador é levado a crer
que certos comportamentos são realmente certos e essa ilusão é
mantida o máximo de tempo possível em cada jogo. Apenas para ser
destruídas no fim.

Também leve em consideração que não só a desilusão é algo difícil de se


construir, mas também diminui em muito a replayability do jogo. Você
furou a bola do jogador no fim do jogo, há grandes chances de que ele
vão vai começar a jogar de novo se sabe que você vai fazer isso no fim.
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 “apenas melhore”. A frequência que você
deve usar cada um desses carimbos depende muito do leitmotif do seu
jogo, do ritmo que você quer passar e até de quem é seu público alvo.

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. De novo, volta pro seu leitmotif e tenta
entender como usar os feedbacks a favor dele.
6.
Escalando Dificuldade

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 ela 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 perde um


segundo para se 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, em
especial nem para o 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 esses elementos, a pessoa se sente confiante dentro da
atividade, sente-se "detonando" ela.

• 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.

A sensação de que o desafio está sempre dentro da capacidade da pessoa é uma das
maiores características do Flow.

Acho que lendo esses requisitos, dá para perceber 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, 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, o que torna
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 satisfazer em relação à
dificuldade e progressão.

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.
Trabalhos manuais são atividade que mais comumente resultam em flow. Se você
lembra de uma atividade em que experienciou o flow, tente passar por ela
novamente e tentar entender como você chegou nesse estado, o que é importante
para se manter nele e como você se sente.

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, uma TV de tubo e um gerador de eletricidade.
Eles jogaram jogos recentes, eles se frustram com desafios injustos
(que, embora nossa nostalgia nos impeça de lembrar, estavam
presentes aos montes nos jogos da era 8-bits). 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:

1. Adicionando uma nova mecânica ou diferenciação de gameplay.


Cada novo inimigo com um diferente ataque, AI ou atributos é um
uso dessa forma.

2. 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.

3. 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 e 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


spawnando o jogador em um lugar "seguro" para primeiro ele se sentir
livre para explorar e entender como se mover e usar a camera, e logo
em seguida, apresentaria o primeiro tipo de inimigo em uma sala
(método 1). Daí, 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 barris
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 mecânicas, 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.
Exemplo de planejamento de introdução de novos elementos. É muito legal fazer
uma planilha dessa antes de começar a fazer o level design para você se situar onde
vai entrar o que, mas nunca troque ela pelo seu feel. Se você decidir enquanto faz o
jogo que algumas coisas ficariam melhores em outros momentos e tem um bom
motivo para isso, siga sua intuição.

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 ou
pela primeira vez. Embora você sempre tente simular essas capacidade
é legal sempre aferir suas predições.

7.
Teste com frequência

O outro feedback que não íamos falar sobre

Quantas pessoas fazem parte da sua equipe? Você… e mais quantos?


Image que esse número de pessoas, seja você ou você e mais alguns, são
as pessoas que mais vão ter contato com o seu jogo e, por
consequência, as que mais irão decidir coisas a respeito dele. O
leitmotif, os feedbacks, a forma que a dificuldade irá mudar. E não só
isso, como vocês estão em constante contato com o jogo, vocês vão
acabar ficando dessensibilizados por ele. Isso quer dizer que os eventos
do jogo não vão ter o mesmo impacto e que vocês vão se acostumar
tanto com os desafios dele que quase todo level parece fácil.

Mas vem cá, para quantas pessoas você espera vender esse jogo? Só
pras pessoas da sua equipe? Uma a sete vendas paga todos os custos de
produção do seu jogo? Acho que, não né? Acho que você espera vender
para bem mais pessoas, bem mais mesmo. E antes que alguns de vocês,
mais soltos em relação a dinheiro, digam que não vão vender esse jogo,
deixa eu mudar a pergunta: quantas pessoas você espera que joguem o
seu jogo e tenham uma boa experiência com ele? Quantas pessoas vão
curtir o resultado de todas essas suas horas de trabalho?

É uma diferença expressiva do número de pessoas no desenvolvimento


e quantas pessoas você espera que joguem seu jogo, não? Então por
que vocês ainda só tão testando entre vocês mesmos?

Antes de tudo, bug hunt

Alguém já te disse que bug é algo que se corrige no fim do projeto? Não
escute essa pessoa, bugs devem ser corrigidos durante todo o
desenvolvimento. Claro, não dá para parar todo o desenvolvimento
toda vez que a gente acha um bug, mas uma boa pedida é ir anotando os
que aparecem até juntar o suficiente para passar um dia todo
corrigindo, ou uma semana toda. Se você não achou muitos bugs ainda,
pode ter certeza que eles estão aí e você só não encontrou. Reserve um
tempo para você e o resto da equipe jogar o jogo de forma exaustiva,
fazendo os comportamentos mais loucos e não esperados. Você pode
não acreditar, mas seu jogador vai tentar fazer isso e o ideal é que o
jogo não feche na cara dele. Conforme vocês vão anotando, sempre
priorize esses bugs entre os mais e menos críticos. E resolva os mais
críticos primeiro.

Bug crítico é todo e qualquer bug que impeça o funcionamento de um


sistema crucial no gameplay do seu jogo. Um bug que, de alguma forma
estraga, a experiência enquanto o jogador circula no core loop é um bug
crítico e precisa ser resolvido primeiro. Alguns exemplos são bugs na
mecânica de movimentação, bugs que quebrem o sistema de batalha ou
bugs que levam a freezes ou crashs. Mas isso pode mudar se o bug em
questão é de muita baixa reprodutibilidade, ou seja, seja quase
impossível de acontecer. Um bug que faz o jogo fechar mas que só
acontece se o jogador entra dentro de um arbusto e faz uma dança não
precisa ser crítico mesmo impedindo o jogo de ser jogado. Mas se o
mesmo bug ocorre em uma área inicial do jogo em que há grandes
chances do jogador passar, é crítico sim.

Bugs que desbalanceiam o jogo podem ou não ser críticos, dependendo


de quanto eles impactam no gameplay principal. A maioria dos bugs de
camera, de shaders e de assets não é crítico e, embora deixam o jogo
menos agradável, não exatamente destroem a experiência.

Claro que as vezes tem aquele shader que tá deixando a tela toda preta
ou aquela camera que entra atrás de um objeto e não sai mais ou
aqueles em que os assets perdem a textura e o protagonista morre por
colisões que ele não consegue ver, e em todos esses casos são bugs
críticos, por que impedem o jogador de jogar o jogo direito.
Em vez de procurar uma tabelinha de o que é bug crítico e o que não é,
quando encontrar um bugs coloque duas notas nele de 1 a 10:

1. O quanto ele atrapalha o gameplay principal ou o gameplay a ser


testado;

2. O quão possível é do jogar encontrar esse bug, qual a


reprodutibilidade dele.

Quanto mais alto a notas nesses dois aspectos, mais crítico o bug é e
quanto mais cedo você corrigi-lo, melhor.

Se vocês tornarem esse dia ou semana de destruição de bugs algo


recorrente, ao final desse período possivelmente vão terminar com
uma build jogável, estável e pronta para o próximo passo. Aliás, sempre
mantenham uma dessas a disposição, eventos e publishers tem a
terrível tendência de pedir builds bem quando você está
implementando aquele sistema novo e o jogo tá todo zoado por conta
dele. Mantendo uma build estável na manga, mesmo que um pouco
desatualizada, você diminui muito as chances de precisar resolver tudo
de ultima hora ou, pior ainda, perder essa oportunidade.

Agora, pega essa build estável, chama umas pessoas que fazem parte do
seu público para uma tarde de salgadinhos, curtição e games e abra o
coração para ser dilacerado. Vamos falar de alguns métodos de
dilacerar seu coração testar seu jogo.

O teste local

Fazemos isso assistindo a 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. Claro, se você está com um
projeto muito insipiente, talvez não tenha como ele ser entendido sem
algumas orientações antes. Mas ainda sim, tente ser o mais breve
possível. Se der, faça um roteiro de informações que são necessárias e
não saia dele. Não fale nada que não esteja nele. Fim.
O jogo tem que estar claro e não ser muito frustrante, seja por estar
muito difícil ou muito fácil. É especialmente importante que o jogo não
tenha bugs críticos nessa build de teste, imagine que vexame se um bug
surgir e você não pode nem e desculpar por ele já que você não pode
falar.

Lembre-se que, como cada pessoa é diferente, mesmo dentro seu


público haverá pessoas achando algo fácil enquanto outras acham
difícil, então tente mirar sempre para o meio termo dentro desses dois
perfis.

E não se esqueça 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 builds mais avançadas do
projeto. É sempre útil ter pelo menos um par de olhos fresco a cada
grande teste e não existe nada de mal em ter outros que já são mais
experientes.

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.
A/B testing

Esse é o teste perfeito quando você não precisa testar a qualidade geral
do seu jogo, mas sim responder uma perguntam bouleana a respeito
dele. Essa feature entra ou sai? Esse cenário fica melhor com essa luz ou
com essa? Qual dessas duas versões da mecânica principal está mais
legal? Toda vez que você estiver em uma encruzilhada, recorra ao 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 ou da pergunta que você
quer responder. Não precisa ser a feature completa, pode ser só uma
parte, mas é importante que a parte implementada dela faça sentido
com o jogo como um todo e que todos os demais elementos do jogo
estejam exatamente iguais. Daí você pega um grupo homogêneo de
pessoas e divide esse grupo em dois menores, randomicamente.

Cada jogador vai jogar sozinho a sua vez, mas cada grupo vai jogar
apenas uma das build, e apenas essa, acreditando ser a única build e
desconhecendo a existência da outra. No final da jogatina, você recolhe
feedbacks da mesma forma, de forma geral, tentando entender como
cada jogador apreciou o jogo. É legal tentar entender qual foi a
sensação geral, por que até uma pequena feature ou a existência ou não
de um feedback pode sim fazer o jogo causar uma experiencia mais ou
menos positiva.

Depois, tente puxar pro assunto da feature, mas sem deixar claro que é
disso que você quer saber na real.  Pergunte sobre coisas indiretas a
feature ou variáveis relacionadas a ela mas que não dizem respeito
diretamente a ela. Faça algumas perguntas sobre outras features, só
para disfarçar.
Depois de falar com todos separadamente, separa os resultados
individuais por grupo que a pessoa fazia parte e tenta entender como e
quando as experiências de cada jogador foram diferentes dependendo
da build jogada. Após esse teste você terá uma idéia mais clara da
importância da features ou mudança em questão. Mesmo que se as
respostas dos dois grupos forem muito próximas, pois isso quer dizer
que a feature é realmente irrelevante e pode ser removida sem maiores
impactos ao jogo.

Ouvindo o que seu jogador tem a dizer

o outro feedback que não íamos falar sobre.

Se você está prestando atenção até aqui, você observou e mediu todas
as reações possíveis de serem captadas no seu jogador enquanto ele
jogava, sem nem uma palavra dele. Parabéns, você merece, não é fácil se
por no papel de espectador.

Mais agora tá na hora de assumir outro papel bem difícil, o de ouvinte.


Escute o que seu jogador tem a dizer sobre seu jogo, nos mínimos
detalhes. O que o empolgou, o que o frustrou. Faça perguntas também
sobre determinadas partes que você não está certo, pergunte sobre o
que ele acha dos seus próximos passos, as opiniões dele a respeito de
momentos específicos do seu jogo.

É importante que você tome cuidado para não guiar


seu jogador, ou seja, leva-lo a responder o que você
quer ouvir. Fazemos isso sem querer, em especial em
projetos que amamos.

Se, em vez de perguntar “o que você achou desse inimigo?”, dizer “tá
foda esse inimigo, hein?”, você já está colocando o jogador a lembrar de
todas as experiências ruins em relação ao inimigo em questão. Isso faz o
jogador dar ênfase a essa experiências negativas em vez de pensar mais
imparcialmente e te dar uma resposta mais equilibrada e próxima da
real experiência dele. Lembre-se que nossas memórias não são físicas,
não estão escritas em pedras e são levemente mudadas toda vez que
lembramos delas. É muito fácil conduzir alguém a lembrar coisas que
não necessariamente aconteceram exatamente assim.
Essa parcialidade na comunicação é uma coisa que todos nós temos e
quase nunca percebemos, mas na hora de conversar com um tester
você tem que fazer o máximo de esforço para evitar isso.

Não se esqueça que a maioria dos seus jogadores não tem o


treinamento em game design que você tem e por isso eles podem te dar
feedbacks imprecisos. Eles podem ter uma experiência ruim em uma
área e atribuir a uma coisa específica, quando pode ser na verdade
outra coisa o problema.

Por isso, escute tudo o que o jogador fala e acredite em tudo em relação
ao que ele sentiu, onde e como, mas leve as sugestões de mudança com
um pouco mais de ceticismo. Escute, pense nelas e veja se façam
sentido mesmo. Podem fazer, mas também podem não fazer, e quem vai
gastar tempo implementando uma feature flopada é você.
8.
Ritmo

A linha de sensação do seu jogo

Ritmo sonoro é 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 pela


velocidade e intensidade em que as coisas acontecem ou são mostradas
ao espectador. Quem dita isso não é apenas o roteiro mas também a
edição.  Em 2001: Uma Odisseia no Espaço, um dos filmes mais
importantes na história do cinema, podemos sentir um ritmo mais
lento, quase arrastado. Isso, em vez de atrapalhar, 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, artificial e até outros
tipos).

São temas pesados e Kubrick, o diretor do filme, optou por tratá-los


com seriedade e peso. O resultado 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 é.

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 ter.
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.

Até a dificuldade e a intensidade de alguns momentos irão afetar em


muito o ritmo resultante.

Ou seja, o ritmo de um jogo não depende apenas da suas decisões como


designer, como um filme ou uma música que vão ser passados sempre
da mesma forma. Depende também de como o jogador entende o jogo e
quão fácil ou difícil é seu progresso.

Não é você como designer que dá a última palavra no


ritmo do seu jogo. O ritmo resultante é uma co-
autoria sua com o seu jogador.

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, o som. Mais
especificamente, uma música erudita. Escute essa música.

Você percebe como a velocidade e intensidade mudam com frequência,


mas que cada mudança parece fazer sentido? Cada mudança parece
conduzir a um novo estado de espírito, um novo momento nessa
jornada. Cada momento pode ser um pouco mais contemplativo ou um
pouco mais ativo, vigoroso, ou mais calmo, mas cada momento levando
ao outro de forma graciosa.

É assim que seu jogo deve ser. Tem que ter momentos mais intensos,
mais relaxados, mais rápidos e assim por diante. Mas essas mudanças
tem que fazer sentido dentro de si e sentido com o leitmotif do seu jogo.
Se você tem como objetivo fazer um jogo rápido de ação, momentos
contemplativos podem não adicionar nada a experiência. Mas talvez um
momento de intensa discussão combine bem para adicionar um
momento crítico sem perder a dinâmica do jogo.
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. Ou com a maioria dos jogadores.

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 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 do desenvolvimento. Não
importa se 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 jogadores o ritmo do jogo inteiro, do começo a fim.
Corta tudo sem dó, mas com amor.

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 nenhum gameplay
em especial.

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, siga seu
coração e não às regras.

Entretanto, não se esqueça de testar com outras pessoas se funciona ou


não!

Talvez você queira que a gameplay passe uma sensação completamente


oposta à história ou a outros elementos do jogo, seja por ironia ou por
que isso faz parte da sensação que você que o jogador sinta. Isso é
ótimo também, desde a) você esteja fazendo isso conscientemente e b)
o jogador ou entenda isso ou sinta a sensação que você queria passar.
Às vezes, mesmo com nossos melhores esforços e conceitualizações,
uma passagem não passa o que queríamos que passasse.

Daí, de novo, bola pra frente, aceita o erro e ou corta essa parte ou
simplifica. Sem apego. 
Seu jogo só é tão bom quanto a experiência que o
jogador tem, não importa o quão foda ele é na sua
cabeça. Vamos falar mais disso na semana que vem.
9.
Foca no jogo

E corta essas bosta tudo

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,
testes e ritmo. Parece que cobrimos tudo necessário para se fazer um
jogo. 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 Pedro Bial. 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.

Situações corriqueiras que levam a


cortes

Uma delas pode acontecer contigo… ou todas.

• Feature creep — Sem querer querendo, você acaba se empolgando


nos primeiros passos de desenvolvimento e planeja muitas outras
features, muitas das quais não complementam muito o jogo. Quando
o feature creep acontece muito cedo no projeto, o impacto pode ser
ainda 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 geralmente, 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 das vezes que o trabalho feito
por essa pessoa não pode ser continuado pelo resto da equipe. Vamos
supor que você perde sua 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 uma


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 na forma que que que as coisas funcionem, 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 nada ao jogo ou está atrapalhando o ritmo,
não pense nem duas vezes. Fora.

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. Observar desconhecidos jogando o
último build. E realmente se perguntar: Como podemos melhorar?
Como podemos simplificar? Como podemos ter o melhor jogo possível
e retirar tudo que não adiciona à experiência?
Um jardim bem podado passa uma mensagem estética mais forte do que um
sem podar.

O corte como escolha estilística

Isso pode ser um processo traumático pois 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. Ou ter as duas deixa a gameplay um pouco
confusa. 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 jogador. Por isso, esteja sempre atento às ramificações
de sua gameplay e, de preferência, conduza alguns A/B testings.

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.

10.
Fechando esse jogo

E partindo para próxima!

Grandes chances que seu primeiro jogo não vai vender bem. Talvez a
imprensa nem cubra. Existe a chance que seu público mal fique sabendo
sobre o ele. Ou não, talvez tudo isso dê certo, mas o jogo em si é mal
recebido. As pessoas te odeiam. Você se odeia. É o fim de tudo.

Ou não.

Veja bem, tudo depende de como você define uma palavrinha:

Sucesso

O que é sucesso para você, nesse momento? Viver de fazer jogos? Fazer
jogos como hobbies? É terminar esse projeto? Veja, seu primeiro jogo
não é o fim, você não tem que ter atingindo todas as suas metas ao
termina-lo e lança-lo. Seu primeiro jogo é só um passo, o primeiro de
muitos, de chegar onde você quer e talvez até superar essa meta. Não
tenha pressa, não seja ganancioso, um passo de cada vez te leva mais
longe de forma mais consistente.

Seu primeiro jogo vai não só te ajudar a entender os processo


necessários para se fazer e terminar um jogo, ele também vai te ensinar
a falhar. Muito. E aprender a cair, levantar e continuar é o aprendizado
mais importante que qualquer pessoa nessa indústria pode ter.

Boa sorte com o seu projeto, com esse e com todos os outros! Não
esquece de me avisar do lançamento dos seus jogos no
gamestartlivro.net !

Você também pode gostar