Postmortem: Necromante de Abechét, Parte 1

Semana que vem, dia 13, é o lançamento oficial de Necromante de Abechét, o primeiro jogo que eu fiz totalmente sozinho. Para mim já está na hora de partir para outro projeto. (Mentira. Eu já estou trabalhando em outro projeto faz tempo. Dois, se você excluir o livro que acabei de escrever).

Há muito o que se falar sobre o processo de criação de Necromante de Abechét, e minha ideia é apresentar aqui o processo da ideia inicial até esse lançamento. Bora?

Idealização

Em meados de 2010 eu escrevi um livro de fantasia. Era o 6o livro que eu escrevia do início ao fim e viria a ser o 3o a ser publicado, agora em Janeiro de 2015. Acho que quem já acompanha meu blog sabe que eu gosto de criar mundos, e esse livro, Império de Diamante, veio de uma vontade de criar um mundo de fantasia que fugisse do padrão elfos, anões e dragões.

Pois que quando eu terminei o livro, havia uma dúzia de personagens menores e situações que poderiam render uma história a parte. Uma delas é a do necromante, um escravo herege mantido em segredo pelo Zaim de Abechét, um dos protagonistas do livro. O necromante jamais aparece no livro, mas fala-se muito dele. Mais de uma vez ele tem papel importante na trama. Mas, o que realmente me fisgou a escrever uma nova história foi esse trecho aqui:

“Não importava como ele sabia. Também não havia razão para negar e causar-lhe problemas futuros. Estudou com falso interesse o copo de aguardente. Tinha sido um presente o atual Zaim de Maar, junto com as garrafas de aguardente. Um agradecimento por ter emprestado o balawoo para localizar o assassino de seu filho dois anos antes.”

Cara, como seria um jogo em que o jogador é um necromante investigando um crime? Existem alguns livros que usam premissas similares, mas não lembro de nenhum jogo com esse tema.

Comecei a anotar ideias sobre essa história. Não tinha muitos detalhes definidos sobre a província de Maar e absolutamente nada sobre seu governador ou seu filho além dessa linha ai e uma ou outra no livro. O primeiro passo foi pensar em como o jogador poderia usar a necromancia num jogo, e quais as consequências disso.

O mais óbvio veio primeiro: ele vai lá, fala com a alma do morto, e descobre o assassino.

Ah, mas não é tão simples, porque no livro mesmo você descobre um detalhe sobre como funciona essa magia.

“Apesar da eficiência do seu assistente, passara-se quase uma hora antes que o corpo pudesse ser levado ao balawoo. Quando o espírito do assassino foi interrogado, muito de sua essência já havia se deteriorado. Apesar de que isso significava que aquela alma resistiria menos, sua personalidade praticamente obliterada pelo tempo desde sua morte, também significava que a comunicação com o espírito tornava-se mais difícil.”

Já definia aí o primeiro passo do jogador: interrogar o morto e descobrir algumas pistas sobre o mistério. Pensei, então, em outras formas de obter pistas. O jogador poderia investigar de forma tradicional, conversando ou procurando objetos pelo jogo. Ah, e se ele possuísse uma ‘visão além do alcance’? O poder de ver uma o que o mundo invisível sobreposto ao mundo real?

Nesse ponto não existia jogo ainda, só ideias por alto. Não sabia nem que tipo de jogo era. Pensava em um RPG top-down. Como meu objetivo era primeiro contar uma história, isso não era um problema (ainda).

Por fim, não queria que o necromante fosse um combatente. Ele é um sacerdote de verdade e seus poderes são rituais. Pensei em incluir um segundo personagem, um soldado enviado para ficar de olho no necromante (afinal de contas, ele é um herege). Em caso de combate, seria o soldado a fazê-lo para manter o necromante vivo.

Já tinha 3 conceitos de mecânica básicas. Precisava, então, de um jogo.

Necromante, o RPG

Meu instinto de jogador de RPG me dizia que esse jogo precisava ser um RPG. O formato mais simples me parecia ser o estilo clássico do JRPG, da visão de cima. Poderia ter a cidade (ou partes dela) por onde o jogador explorava, falava com personagens, etc.

É nesse ponto que entra o passo mais importante de qualquer desenvolvimento de jogos: analisar os requisitos, entender os recursos disponíveis, e avaliar a viabilidade do projeto.

Não faltam engines para se desenvolver jogos por aí. A lógica me levou a olhar o RPG Maker, mas nunca fui com a cara de JRPG. Claro que já vi jogos bem diferentes e eu poderia eliminar o combate típico do JRPG. Fui examinar as lojas de assets de arte.

Veja bem, eu já trabalhei como ilustrador e designer gráfico anos atrás, mas fazer o conteúdo de arte para um RPG é complicado. É bastante trabalho, e eu tinha definido uma meta: lançar o jogo junto ou logo depois do livro. Seria inviável fazer toda essa arte sozinho.

O primeiro problema veio com a dificuldade de encontrar os tipos de assets que eu procurava. Busquei referências artísticas, esbarrando com quadros impressionantes pintados no século 19. Eram cenas passadas no norte da África e no Oriente Médio que davam a imagem do que que eu queria. Mas não encontrei nada substancial de arte para jogos top-down que incluísse personagens negros. Sério. Os únicos que encontrei eram raros ‘guerreiros tribais’ bem arquétipos, que não era o que eu precisava. Também não encontrei nada substancial para construir os cenários.

Quase desisti.

Necromante, o livro-jogo

Se o peso da arte era tão grande, e se eu fizesse um livro-jogo? Já tinha trabalhado em um projeto com dois amigos criando algo do gênero para mobiles e sempre fui fã desses jogos. E se fizesse algo assim, usando apenas algumas ilustrações que eu fizesse? Seria viável.

Pesquisei engines que pudessem me ajudar nesse esquema. Encontrei o Twine. Baixei o dito-cujo e comecei a brincar com ele. Não demorou muito para pegar o jeito e perceber que era esse o formato para o jogo.

Comecei a criar a primeira parte do jogo no Twine. Compilei. Rodei.

Erro.

Teste, pesquisa, mudança, compilação, teste, erro. Fui descobrir que existia um bug bizarro no Twine. Ele dava pane se o calendário do seu Windows tivesse dias de mês ou semana com acentos. Típico bug de programa feito por quem só fala inglês...

Fui no site. O bug era conhecido, mas não tinha previsão de ser consertado.

Quase desisti de novo.

Necromante, o adventure

A coisa ficou parada por um tempo. Fui trabalhar em outras coisas, inclusive um livro de RPG tradicional onde do necromante aventura poderia ser incluída. Comecei a juntar imagens de referência, encontrando ainda mais quadros daquela leva que mencionei. Alguns eram espetaculares. Só de olhar dava pra imaginar histórias acontecend, personagens e... veio o estalo.

E se eu fizesse um adventure usando esses quadros como cenários e personagens? Os artistas que os pintaram já morreram há mais de 100 anos, então não existiria problemas de propriedade da imagem, certo?

Pesquisei o assunto. Descobri que não era bem assim. Enquanto os quadros caíram no domínio público, as fotos daqueles que as tiraram não. Mas existiam alguns sites disponibilizando gratuitamente fotos desses quadros. Bingo!

Resolvi montar um protótipo. O engine escolhido foi o Scirra Construct 2. Eu já tinha uma licença paga, comprada havia 1 ano, que só tinha usado para fazer protótipos de jogos. Estava na hora de fazer um jogo com ele.

O primeiro passo foi revisitar as ideias das mecânicas nesse novo formato. O jogador poderia clicar em partes dos quadros para encontrar informações ou disparar diálogos. Escolhi um formato de diálogo “Hub” onde cada escolha do jogador sempre volta à origem. Incluí um elemento de progressão de diálogo: se o jogador tivesse com ele um item ou informação nova, novas opções se abriam.

A questão da nova visão era a mais fácil. Criei a Máscara, um item que, ao ser colocado pelo jogador, o permite ver a mesma cena com outros olhos (literalmente). O quadro ganha uma sobreposição meio bizarra, e novos objetos tornam-se clicáveis.

O problema era que nada impedia o jogador de colocar essa máscara e sair clicando. Além disso, o jogo perdia o potencial de combate. Não queria gastar tempo em um sistema que seria secundário ao jogo. (Esse foi o produtor em mim falando mais alto).

Veio o segundo estalo.

Lembrando lá do início do post: ser um necromante era uma heresia. O Império de Diamante é uma teocracia governada por um deus-vivo. Ou seja, ser um necromante é garantia de morte. E se ao invés de um sistema de vida ou hit points, invertesse para um sistema de notoriedade? O personagem não sofre dano e morre ao chegar a 0 de vida; ele atrai atenção ao usar seus poderes, e é denunciado (e executado) ao chegar ao nível máximo de notoriedade.

Voltou o companheiro do necromante, o soldado. Seu papel era servir de tutorial, de ponte e de executor. Ele explicaria as mecânicas e contexto do jogo, ele alertaria se o jogador chamava atenção demais.

Considerando a arte que tinha disponível, resolvi fazer o jogo como se ele fosse em primeira pessoa, com os personagens olhando para o jogador. À esquerda ficava sempre Krikor, o soldado. A direita, surgiam outros personagens ao longo das cenas. Não havia interface com cara de jogo. Tudo seria feito na base da interação com personagens e cenários.

Fiz engenharia reversa da história. Com base as imagens disponíveis em alta resolução, criei personagens, locais, pistas e o mistério sobre a morte do herdeiro da província de Maar. Construí um diagrama monstruoso ligando as cenas, definindo onde e como o jogador liberava novas informações e novos cenários na cidade, defini um caminho ideal e um caminho custoso. Tudo planejado, comecei a produção.

Nenhum plano sobrevive contato com o inimigo

Óbvio que coisas deram errado. O primeiro foi um bug que por motivo algum eu consegui resolver. Krikor, o soldado, deveria funcionar como um menu. Ao entrar em uma nova cena, ele deslizava para o campo de visão. Clicando ele, abria-se o diálogo com opções como ver o mapa, o quanto de notoriedade tinha o jogador, dicas, etc.

Mas Krikor recusava-se a funcionar direito. Algumas vezes ele simplesmente saía deslizando pela tela para nunca mais voltar. Outras vezes ele ficava escondido no canto da tela, olhando de rabo de olho. Depois de muito insistir, percebi que não valia a pena continuar com a ideia. Krikor deixou de ser menu. Criei 3 ícones que ficariam no canto direito: a bolsa com os itens recolhidos, o mapa da cidade, e um olho, que abria-se cada vez mais alerta na medida em que a notoriedade do personagem aumentava.

Óbvio que veio outro bug depois. A bolsa de itens simplesmente não funcionava. A inconstância parecia ser um problema recorrente com alguns tipos de dados do Construct. Já tinha tido problema similar em protótipos anteriores. Depois de muitos testes, resolvi cortar a bolsa de itens. Por sorte só havia 4 itens que podiam ser adquiridos no jogo, o que tornava o problema menor.

Depois de cerca de 2 meses trabalhando no jogo nos fins de semana, o jogo estava funcionando. Comecei a jogar e testar a estrutura de diálogos, de pistas, etc. Foram vários erros, com diálogos levando a lugares errados ou lugar nenhum, e a percepção de que certas pistas eram impossíveis de conquistar. Foi mais um mês intensivo corrigindo bugs de lógica e conteúdo. Nesse meio do caminho apresentei o jogo a vários amigos, a maioria com experiência de game design. Óbvio que nem todos me deram feedback, mas os que deram me ajudaram a compilar o que precisava:

• A abertura era longa depois. Havia uma “animação” dando o background, depois uma sequência de diálogo expondo a trama, antes da primeira cena, onde o jogador interroga o morto.
• Alguns objetos eram impossíveis de ver no cenário, especialmente na primeira cena, onde era obrigatório encontrar 5 itens antes de continuar.
• Para facilitar para o jogador, associar falas a números no teclado além do uso do mouse.

Fiz todas essas alterações. A primeira doeu no coração, mas foi fácil. Cortei a abertura sobre o background. O conteúdo lá presente foi dispersado pelo jogo quando necessário. Reescrevi alguns trechos aqui e ali, e pronto.

O segundo exigiu pesquisa. Olhei os jogos de Hidden Objects em busca de formas de criar pistas. Pensei em criar mecânicas similares a desses jogos, mas o produtor em mim gritou comigo. Acabei indo pra uma solução até óbvia: vez ou outra itens não encontrados são destacados com um brilho ou coisa do gênero.

O terceiro deu trabalho, mas foi simples e direto.

A avaliação mais pesada

Se você não é chato o cara de pau, não consegue nada. Fui até um grupo de desenvolvimento de jogos do Facebook e joguei lá o link pro jogo, pedindo feedback. Nomeei várias pessoas que eu acreditava poderiam me dar um feedback interessante, como o pessoal que criou o Soul Gambler, uma aventura interativa com elementos similares ao Necromante.

O feedback foi bem interessante. Anotei tudo, avaliei, coloquei pesos. Era hora de pensar como produtor primeiro e game designer depois. O que era viável no tempo que eu tinha? O que realmente faria diferença?

Trabalhei primeiro no que afetava a usabilidade, depois parti para o “eye-candy”, a coisa bonita que é imperceptível para o leigo, mas que no conjunto da obra faz diferença. Descobri finais impossíveis de alcançar e nem sequer me lembrava o que eu planejava para eles. Dos 18 finais possíveis (mais 3 variantes, dependendo do quão notado foi o necromante), 3 foram cortados e 2 foram mesclados em um só. O resultado ainda era interessante.

Depois de mais ou menos dois fins de semana de trabalho adicional, terminei o jogo.

Agora era questão de por no ar e ver o que aconteceria.

Espero voltar daqui a algumas semanas com mais informações sobre isso.

Postmortem: Space Station Ullinah - Lite

Space Station Ullinah foi uma daquelas ideias que surgem em meio a uma reunião que não vai a lugar nenhum (sim, elas também existem no desenvolvimento de jogos). Era meados de 2012. Em Dezembro desse ano peguei a versão gratuita (e, portanto, limitada) do programa Scirra Construct 2 e montei um protótipo bem simples. A ideia era testar o conceito e nada mais.

Em Abril de 2013 descobri que o site Newgrounds teria um concurso para um jogo feito com o Construct 2 que funcionasse para mobiles. Ora, por que não tentar fazer o Space Station Ullinah?

O desenvolvimento levou cerca de uma semana em horários livres. Essa foi a parte fácil! O problema foi fazer funcionar direito no tablet, porque nunca havia feito um jogo para mobile por conta própria (nem havia feito um jogo completamente sozinho, diga-se de passagem).

Um adendo: o Scirra Construct 2 é um software para desenvolver jogos em HTML5. Ele faz a parte da programação, contanto que você entenda de lógica (importante para qualquer game designer no mundo!). Portanto o meu trabalho foi puramente game design e arte. Ou mais ou menos. O infame ‘bug de lógica’ existiu e persistiu ao longo do desenvolvimento e dos testes posteriores.

O que é o jogo

O one-liner do jogo é o seguinte:

Defenda sua estação espacial e os mercadores do qual ela depende para aumentar seus lucros!

É um tower defense, mas não é. Seu objetivo é manter a estação no centro da tela viva usando lasers, interceptadores, torres de defesa, campos minados e bombas. Inúmeros cargueiros aliados circulam pelo cenário. Sempre que um deles pousa na estação ou deixa o cenário, o jogador ganha dinheiro para comprar mais defesas. De tempos em tempos surgem caças e bombardeiros inimigos atacando os cargueiros e a estação. Se a estação for destruída, game over.

O conceito é simples, mas as coisas se complicam quando você tenta implementar ideias legais que não ficam claras aos jogadores.

A grande barreira

O maior defeito percebido por quem jogou (e por mim mesmo depois de pensar criticamente sobre o assunto) foi que nunca ficou claro como usar a arma básica do jogo: o laser.

A ideia seria que, após ligar o laser, o jogador poderia passar o dedo pela tela, fazendo brotar um laser do centro da estação que cortaria tudo por onde o dedo passasse. Pense Fruit Ninja, mas com uma pausa de 5 segundos entre cada corte (que dura até 5 segundos). Cada vez que o laser passava sobre um alvo, este recebia o dano do laser. No caso dos bombardeiros, era necessário passar o dedo sobre o alvo duas ou três vezes, comos e você estivessem tentando apagar a nave com o dedo.

Mas praticamente ninguém deslizava o dedo de um lado para o outro! A maioria esperava ‘clicar’ no alvo e destruí-lo imediatamente! O efeito? A maioria dos jogadores era incapaz de destruir os primeiros bombardeiros que logo destruíam a estação. É possível que isso tenha a ver com o fato de que a maioria dos jogadores jogou no PC e não em um tablet. É provável que ninguém tenha lido as instruções iniciais ou a frase que diz “slide and cut targets to use the laser” que surgia toda a vez que o laser era ativado. O erro foi meu. Ninguém lê e eu já devia saber muito bem disso.

Pensei soluções, inclusive a de simplesmente aumentar o dano do laser ao ponto de que ele destruisse o bombardeiro de uma vez, efetivamente tornando o “cut” em “tap”. Mas um número (pequeno) de pessoas elogiou o jogo e essa feature, então por fim resolvi arriscar e manter.

Minha impressão é que poucos passaram deste momento inicial. Poucos viram o unlock de novos itens, como o campo minado e os interceptadores. Acidentalmente tinha criado uma barreira que impedia o jogador que está procurando um jogo divertido e rápido no Newgrounds. Esse jogador desistia após não entender o jogo ou achá-lo muito difícil.

Planejamento e cortes

Outra questão, que consumiu um bom tempo de desenvolvimento e correções, foi o tamanho do jogo. A edição gratuita do Construct tem algumas limitações, como o número de ações/condições que podem ser criadas por projeto. Isso me obrigou a substituir features por outras mais simples e mesmo simplificar algumas que eu considerava ‘core’. Por exigência do concurso o jogo precisava funcionar em tablets, mas por ser web, era bom que também funcionasse com um mouse. Isso significava mais linhas de ação/condição e, portanto, mais cortes.

Voltei para a prancheta (no caso o draft do Game Design Doc do jogo) onde tinha uma lista de features (em especial itens de jogo) que pretendia colocar:

• 
  Tirei o item que fechava os portais porque parecia menos útil (e havia um bug em que naves já seguindo para esse portal acabaram parando no espaço e ficando lá até serem destruídas) e o substituí por uma “bomba antimatéria” que destruía todas as naves (inimigas e aliadas) na tela;
• Tirei as naves especiais que apareciam de vez em quando e limpei a lógica do jogo, removendo elementos como o número máximo de naves inimigas e aliadas no cenário. Havia um bug em que o contador ignorava uma ou outra nave destruída, de forma que o contador não zerava e ferrava com a lógica toda;
• Usando uma variante da mecânica do laser, fiz com que, sempre que um cargueiro aliado fosse destruído, deixasse cair um contêiner (um loot) que podia ser arrastado para a estação para reduzir suas perdas. O efeito visual era o de um raio trator, mas nada mais era do que um drag simples;
• Para reduzir o perigo dos bombardeiros, fiz com que o laser destruísse (imediatamente) os torpedos disparados pelos bombardeiros e, também, que o contêiner que caía dos cargueiros destruído servisse como uma barreira, de forma que era possível criar uma barreira temporária em torno da estação para protegê-la. Duvido que algum jogador tenha tido tempo de perceber esse truque.

O jogo acabou indo capenga para o concurso, o que foi um grande erro guiado apenas pela minha vontade (estúpida) de não gastar dinheiro com o Construct.

Feedback Positivo

Recebi algumas mensagens de apoio. Dois jogadores em particular me enviaram várias mensagens antes e depois do concurso elogiando a ideia e propondo soluções. Falou sobre incluir mais elementos no jogo e novos itens, além de um tutorial. Sugeriu que o jogador pudesse fazer upgrade da estação.

No fundo eram ideias que eu já tinha em mente, mas tinha dúvidas se funcionaria (como o caso do upgrade de partes da estação). Nenhuma delas cabia no tamanho do Construct grátis.

Quanto ao tutorial, era lógico que precisava assim que vi os reviews criticando a “dificuldade” do jogo porque “a arma inicial é inútil contra o bombardeiro”. Coloquei uma tela inicial que “explicava” a interface e os objetos do jogo, de forma que, quando o jogo começasse, houvesse apenas um caça inimigo e um cargueiro aliado em cena. A ideia era explicar o uso do laser. Não sei se funcionou. Quem testou (e me deu feedback) me falou o óbvio: “nem li.”

Conclusão

Poucos dias antes do fim da data do concurso, o Scirra Construct 2 ficou em promoção no Steam. Parecia que era de propósito. Acabei comprando um dia antes do final do prazo do concurso, mas não mexi no jogo. Deixei como estava.

Olhando o jogo que ganhou o concurso, o Magnetize, percebi que deveria ter me mantido na simplicidade. Magnetize é um jogo ridículo de simples tanto em design quanto em implementação e mereceu muito o prêmio. Não acho que o Space Station Ullinah seja má ideia, tanto que já estou trabalhando em uma versão “de verdade”, mas foi uma aposta errada para o concurso da Newgrounds.

Recentemente tirei o jogo do ar no site. Havia alguns (poucos) jogadores me enviando mensagens, pedindo que eu atualizasse o jogo pois eles tinham gostado. Por fim achei melhor não gastar munição agora, para não correr o risco de queimar o filme com um jogo que pode ser bem melhor.

Espero nos próximos meses voltar a trabalhar no jogo e, quem sabe, finalmente lançá-la na versão que ele merece. Quando isso acontecer, volto aqui para mais um post mortem!

Links:

Scirra Construct 2 - https://www.scirra.com

Magnetize - http://www.newgrounds.com/portal/view/615109