Pense pequeno: Foca no jogo
e corta tudo essas bosta
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 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 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.
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
Foca no jogo e corta tudo essas bosta
