domingo, 20 de setembro de 2015

Prototyping For The Win!

Uns dias atrás uma pessoa perguntou se eu sou maluco. Tá, isso acontece com frequência, não só depois que, umas semanas atrás, eu resolvi largar tudo pra fazer o meu jogo. Essa pessoa em questão se referia ao tempo que eu disse que levaria para fazer o Strike Squadron Caracará e lançá-lo. Meu plano (que continua o mesmo) é tê-lo a venda a tempo da apocalíptica venda de fim de ano do Steam.

Fora o fato de que isso significa conseguir que um jogo que não existe seja aceito no Greenlight (dedos cruzados aqui), a maior parte é montar o jogo, criar o conteúdo e testá-lo o suficiente pra que não queime meu filme pra sempre.
Existem mil razões que eu posso te dizer que isso é totalmente viável. Dá pra começar falando que eu fui lead designer de um jogo de caça objetos pra Facebook que foi de conceito ao lançamento em uns 3 meses, já com umas 60 fases. É, a equipe era bem maior, mas só era eu e outro cara fazendo game design, level e texto do jogo todo.

Dá pra falar, também, sobre as game jams. Convenhamos. Todo ano milhares de jogos são feitos em períodos de 48 horas e eu vejo muitos deles com total capacidade de se transformar num jogo comercial com a adição de conteúdo.

Mas dessa vez meu foco vai ser protótipo.

Acho que já mencionei antes por aqui no blog que eu comprei o Scirra Construct 2 pra prototipar. Já usei tanto para trabalhos pagos quanto de bobeira. Foi a uns 2+ anos atrás que eu fiz o primeiro protótipo do meu “space sim 2D”. Dá pra jogar esse protótipo aqui (setas pra mover, espaço pra atirar). A arte é toda “emprestada” da internet, e eu sinceramente não lembro de onde eu tirei. Mas a nave do jogador fui eu que fim!
Era só isso, uma missãozinha curta num level minúsculo, mas já me mostrava o básico, incluindo um sistema de “ramificação” rudimentar (as mensagens variam dependendo do estado do cargueiro e da estação). Levei uma tarde pra fazer isso.

Então meu HD foi pro saco e eu perdi todo o código desse protótipo.

Lá pra meados de 2014 eu decidi fazer um novo protótipo usando a arte do Star Citizen pra fazer um “fan game”. Dessa vez queria ir mais longe: 2 missões, escudos que se regeneram, mísseis, minas, naves grandes com torretas, etc. Levei uma semana trabalhando de noite nisso. Algumas pessoas do forum do Star Citizen jogaram e adoraram. me fez querer ir mais longe. Você pode jogá-lo aqui (mesmos controls, mais Enter pra disparar mísseis). O problema era a arte.
Fica aí uma lição importante: aprenda até onde você pode alcançar. Eu adoraria fazer um space sim 3D com uma campanha ramificada com co-op, mas eu sei que isso seria grande demais pra fazer sozinho em 4 meses. Eu também sabia que, apesar de já ter sido ilustrador antes de entrar na indústria de jogos, não conseguiria fazer uma arte boa o suficiente para esse projeto.

Meu primeiro instinto foi entrar em contato com um estúdio pra quem trabalhei anos atrás. Eu tinha criar muito de uma das propriedades intelectuais deles e sabia que eles tinham toneladas de arte na gaveta. E se rolasse uma parceria nesse projeto? Fiz mais um protótipo durante o fim de semana usando a arte deles que eu encontrei na internet e a minha experiência no conteúdo deles. Aproveitei pra incluir também um diálogo com algum elemento de ramificação que eu tinha feito no meu primeiro jogo solo, Necromante de Abechét (falei dele aqui).

Enquanto a proposta nunca passou das primeiras reuniões, os comentários de quem jogou esse e o outro protótipo me fizeram perceber que eu tinha um produto forte nas mãos. Um em que valia a pena investir. Você pode jogar o protótipo aqui.
Então veio aquele dia pouco mais de um mês atrás quando eu escrevi sobre a Crise do Game Designer de Meia-idade.

Meu primeiro mês de trabalho de verdade no projeto foi pra reconstruir o jogo com base nos protótipos e tudo que eu aprendi com eles. Como fazer as naves se moverem? Como construir a IA? Como fazer os inimigos se moverem direito? Tinha espaço pra aprender, claro. Mostrar essa nova versão pra algumas pessoas me fez perceber que a escala das naves estava ruim, quase invisível em alguns casos. Isso afetava o level design, que era algo com que eu não estava totalmente satisfeito (como falei aqui nesse outro artigo).

A coisa é que ter feito protótipos do jogo de formas diferentes do zero (todas as vezes levando só alguns dias) me permitiu construir o jogo em si muito mais rápido. Eu já sabia como as coisas funcionavam e o que não funcionava porque eu já tinha testado tudo isso. Depois disso era questão de adicionar algumas features menores, mas significativas, como bombas de EMP, camuflagem, belonaves modulares, etc.
Eu pretendo ter o jogo com todas as features prontas até o final do mês, já com a arte toda pronta (eu contratei um artista pra fazer o que eu não conseguia!). Planejei uma missão-demo pra mostrar o jogo em alguns eventos indie ou pela internet pra colher feedback. O foco agora é saber o conteúdo (balance e level design) e trabalhar em cima disso pra montar o conteúdo.

Agora é esperar pra isso dar certo!

sexta-feira, 18 de setembro de 2015

Fecha-se um ciclo, inicia-se outro


Dez anos atrás eu me meti a publicar um livro de ficção científica por conta própria, daquele tipo bem aventuresco, inspirado em assistir Firefly e jogar muito RPG do Star Wars, e pelo space sim que eu estava desenvolvendo com amigos nas horas livres. Só que em 2005 nenhuma editora queria publicar esse tipo de coisa, ainda mais de um autor nacional desconhecido. Eram os primórdios das Redes Sociais, bem antes dos e-Books. Contratei um ilustrador, aprendi a diagramar, fiz orçamento com gráficas e abri uma editora (que era só eu, na verdade).
Foram só 500 cópias. No primeiro ano vendi umas 350 delas. O resto saiu aos poucos, ou não saiu. Bem recentemente doei várias para bibliotecas comunitárias e escolares e programas de incentivo à leitura.

A chance é que você nunca tenha ouvido falar de Véu da Verdade, mas esse livro, e a decisão de ignorar as recusas das editoras tradicionais e correr atrás por conta própria, tiveram um significado importantíssimo na minha carreira.

Alguns meses depois de publicar esse livro, eu fui contratado como escritor freelancer para o (então) maior projeto de jogos do Brasil. Exatamente um ano depois do lançamento eu tinha meu primeiro emprego em tempo integral na indústria de jogos. Não parou aí. Mais um ano depois eu publicava meu segundo livro, dessa vez por uma editora de verdade, e escrevia um terceiro, que jamais foi lançado, mas pelo qual eu recebi para escrever mesmo assim.


Os anos passaram. Dez anos. Muita coisa aconteceu. Muita coisa eu aprendi.

Então, como contei aqui neste post, resolvi largar tudo para fazer meu próprio jogo, o mesmo que eu queria fazer lá em 2005, quando publiquei Véu da Verdade. Outros tempos, outras realidades.

Estou fazendo um space sim 2D inspirado em nada mais nada menos que meu primeiro livro, Véu da Verdade. Contratei um ilustrador, aprendi a programar, fiz orçamento com empresas de localização e abri uma empresa (que sou só eu, na verdade).

Percebi que era um ciclo de 10 anos se fechando e achei que não deveria parar aí.

Certo, não parou. O jogo, Strike Squadron Caracará, já está com toda arte pronta e deve estar feature-complete (ou seja, a programação pesada pronta) nas próximas 2 ou 3 semanas. Tenho um livro novo ligado ao jogo nas mãos de um editor que se interessou pelo projeto transmídia. Mas eu senti que faltava algo.


Essa semana eu ouvi a um episódio do CabulosoCast sobre e-books que me fez pensar.

Então peguei o antigo arquivo de Véu da Verdade e o reli. Reescrevi trechos que não estavam bons tecnicamente falando, incluí novos capítulos na jornada dos protagonistas, corrigi os erros que passaram na revisão original.

Voltei às origens.

Hoje a edição comemorativa de 10 anos de Véu da Verdade está sendo lançada na Amazon pelo preço de custo, R$5,99. Se você tiver sorte ainda pega na promoção de lançamento (ou seja, de graça).

Meu objetivo não é lucrar com a obra. Já lucrei com ela 10 anos atrás. Minha intenção é comemorar minha carreira como escritor e game designer, é incentivar você a ler uma história que eu adorei escrever e que muitos adoraram ler. É te apresentar esse novo mundo para que num futuro bem próximo você queria jogar Strike Squadron Caracará, ler o livro no prelo ou mesmo meu outro, de fantasia, Império de Diamante (que, se você tiver sorte, também está em promoção na Amazon agora).

Porque eu acredito que histórias devem ser contadas, e elas devem ser contadas em mídias diferentes, de formas diferentes, interligadas em uma rede muito, mas muito mais complexa do que qualquer livro, jogo ou filme é capaz de construir.

E, quem sabe? Talvez seja esse o início de um novo ciclo para você também.

segunda-feira, 31 de agosto de 2015

Level design modular (e como a pré-produção pode te salvar a vida)

Na prática, fazer jogos significa fazer e refazer.

Primeiro me deixa explicar sobre o que é o jogo em que eu estou trabalhando, já que isso tem tudo a ver com level design.

Strike Squadron Caracará é um jogo de combate espacial 2D baseado em missões. Não é um shoot ‘em up onde você desvia de uma enxurrada de balas e mata milhares de inimigos que por acaso voam seguindo sempre o mesmo padrão. Você voa missões de escolta, ataque, etc, ao lado de alas, como em Wing Commander, Starlancer e Freespace.

Mas a história não é sobre uma Terra unificada ou um governo super tecnológico que lembra muito os EUA no espaço. É sobre uma aliança de países latinos e africanos fazendo o que pode com o que tem. Eles operam de estações espaciais emprestadas, o que significa que não têm a base de operações móvel típica da maioria dos simuladores espaciais. Por enquanto guarde essa informação.

Muito antes de decidir largar meu emprego e freelas para fazer meu próprio jogo eu fiz um protótipo usando o Scirra Construct 2, incluindo missões cheias de arte “emprestada” da internet. Avançando meses no tempo, eu já tinha conseguido algumas definições que afetariam a produção, a principal delas sendo que eu usaria peças modulares para montar as fases.

Você provavelmente já ouviu ou leu por aí algo sobre o assunto: para reduzir o custo de produção e o tempo de carregar o jogo reusa-se os mesmos objetos para se montar as fases de um jogo. Já tive uma experiência semelhante antes em outros jogos em que trabalhei, então não tinha porque não seguir essa premissa. Uma vez eu decidi contratar um artista 2D para meu projeto, eu já sabia que a primeira coisa que ele ou ela faria seriam peças modulares para estações espaciais.

Meu primeiro passo aí foi listar esses objetos. Como eu já tinha experiência com esse tipo de coisa, chegar a uma primeira lista foi fácil. Procurei referências pela internet, em outros jogos e arte conceitual. Cheguei a uma lista de 10 peças.

Quando contratei o artista tivemos uma conversa rápida sobre o que eu esperava dessas peças. Ele fez um rascunho rápido do que seriam essas peças, e eu usei o poder do Photoshop para construir alguns exemplos do que eu gostaria de construir com elas.

A primeira coisa que essa brincadeira me disse foi que eu precisaria de mais peças, especialmente um domo/disco menor, e que minha ideia original de usar fatias do disco principal não daria certo do jeito que eu imaginei.

Foi também quando o artista entendeu minha visão (nunca se esqueça de mostrar exemplos do que você quer fazer para aqueles com quem você trabalha, tanto artistas quanto programadores!). Após algumas idas e vindas, ele me mandou o passo seguinte do processo, um desenho já com várias peças, inclusive algumas que ele criou por conta própria. Por que não, né? Na verdade eu acho isso um dos melhores aspectos de trabalhar com outras pessoas: eles sempre têm algo a adicionar (ou melhorar) no projeto.

Depois de mais algumas idas e vindas, chegamos a uma versão final das peças! Com elas construí as primeiras estações espaciais e substituí as artes “emprestadas”. Mas, claro, tinha um problema enorme: a forma com que eu montei o jogo (em termos de código) tornava impossível usar peças isoladas da forma em que eu imaginei.

Bom, assim, eu ainda podia usar as peças para construir dezenas de estações espaciais diferentes, mas eu precisaria fazê-lo no Photoshop, fora da engine. Ou seja, as vantagens de reduzir o tamanho do arquivo e o tempo de carregar o jogo seriam jogas fora.

A razão para isso tudo tem muito a ver com como funciona o Scirra Construct 2, o engine que eu escolhi para o projeto.

Em resumo, o Construct usa Layouts (o mapa da fase em si, onde você coloca objetos e comportamentos básicos) associados à Event Sheets (onde você coloca o código em si).

Em Strike Squadron Caracará eu queria que cada missão tivesse o jogador passando por várias áreas. Era como no jogo Starlancer: a missão começa do lado de fora da sua nave-mãe, então você salta para outra área onde enfrenta alguns inimigos, depois salta para outra área onde há uma estação espacial, depois de volta à nave-mãe.

O problema é que o Construct não deixa transferir objetos entre Layouts. O que isso significa é que eu não poderia transferir o jogador, NPCs e naves sendo escoltadas entre áreas sem perder os dados como vida, mísseis sobrando, etc. Tá, tinha um jeito, usando variáveis globais, mas seria mais ou menos como fazer isso aqui em código.

No protótipo a fase era montada por código. Cada vez que o jogador saltava para a próxima área, os objetos na fase eram deletados, e novos objetos eram criados.

Isso funcionava perfeitamente com objetos inteiros, mas era impossível (ou melhor, extremamente caro) replicar o processo com estações modulares, cada uma com 10+ peças que precisavam estar na posição e rotação exatas para ficar direito.

Depois de alguns testes e rabiscos, cheguei a duas opções.

Primeiro era uma variação da versão anterior. Ao invés de detelar e criar objetos, eu colocaria todos eles já na fase, mas cada área escondida em uma camada diferente do Layout. Na medida em que a missão progredia, a camada anterior seria escondida e a nova seria revelada. Funcionava... mas não era muito mais do que uma gambiarra. Eu ainda precisaria criar inimigos, torretas e minas na mão, pelo código, e havia um risco enorme de bugs caso eu não incluísse uma dezenas de ‘ifs’ ao longo do código, tipo subitamente todas as camadas se revelarem, deixando o espaço meio cheio demais.

A segunda opção era mudar o conceito do jogo. Ao invés de montar missões como em Starlancer, fazê-lo como em Wing Commander ou Freespace: cada missão era uma área (ou layout) inteira. Só que no meu jogo a base de operações é uma estação espacial, e não uma nave-mãe móvel (lembra?), então o espaço precisaria ser enorme de verdade. Isso levava ao risco do jogador se perder enquanto a missão no código seguia em frente em outro canto do mapa. Eu provavelmente também precisaria de um mapa, uma feature que eu não tinha incluído do orçamento original do projeto.

Minha experiência com simuladores espaciais 3D me diziam que mapas grandes era perigosos. Eu lembro bem quando a física começava a se desmontar na medida em que o jogador se afastava da coordenada 0,0,0. Mas minha pesquisa me dizia que isso não era um problema com o Construct. Na verdade, era uma de suas vantagens: por ser 2D e construído em HTML5, o tamanho do mapa era (quase) irrelevante. O que importava de verdade era o número de objetos únicos na fase. Agora, como eu estava construíndo estações espaciais com peças modulares...
Então resolvi fazer isso. Enquanto o mapa original tinha 3.600 pixels por 2.600, testei um mapa de 100.000 x 100.000.

Só pra explicar o drama: levei 9 minutos segurando a tecla de velocidade máxima pra cruzar o mapa de um lado ao outro.

Então, né, o que não faltava era espaço. Me deu até uma vontade de repensar o jogo todo, fazer algo com mundo aberto... Ah, não. Para! Agora não. Faço isso no próximo jogo. Pronto, resolvido. Próximo jogo vai ter mundo aberto e um monte de outras coisas legais que eu quero fazer. Mas não agora.

Agora eu estou trabalhando num jogo militar baseado em missões, e nós não queremos nossos pilotos desaparecendo em serviço enquanto o comboio que deveriam estar protegendo acaba sendo destruído.

E se eu tentasse algo misto? E é isso aqui que estou usando agora:

A estação espacial do jogador fica em um layout separado onde o jogador interage com os NPCs (de forma parecia com as cidades de Banner Saga). Quando o jogador sai em missão, ele vê suas naves decolarem e saltarem, então um novo layout é carregado. Esse novo layout vai variar de tamanho dependendo da missão em si, e já virá com o mapa todo montado. Novos elementos podem aparecer ou velhos mudar, mas o jogo será montado de forma que até possa existir alguma exploração, mas de forma controlada. De repente o jogador esbarra com contrabandistas negociando armas com piratas; talvez ele encontrei inimigos preparando uma emboscada. Quem sabe?

Por agora vou construir as missões dessa forma e ver no que dá. De repente eu acabo construíndo uma fase com uma estação modular gigantesca, de uns 50.000 x 50.000 pixels, só porque eu posso.

De qualquer forma, o esquema agora é fazer e testar. E, então, refazer se for preciso.

quinta-feira, 6 de agosto de 2015

Crise do Game Designer de Meia Idade

Meu nome é João Beraldo, e eu faço parte de uma espécie em extinção no Brasil.
Tá, meio dramático, mas, continue lendo. Você vai entender onde eu quero chegar.
Tenho 36 anos, já a meio caminho dos 37. Fiz meu primeiro jogo aos 12 anos, quando era estagiário de uma empresa de software. Quando me mandaram testar um sistema de documentos vinculados (imagine a Wikipedia offline em 1991), fiz um jogo no estilo livro-jogo em que, dependendo do personagem que você escolhia, tinha escolhas e cenas diferentes.
Inventei de ser game designer e escritor de verdade por volta do ano 2001 quanto quis fazer meu próprio space sim. Comecei por baixo: tive uma ideia para um RPG via mIRC usando um software de mapeamento e combate como suporte. Wing Commander: Frontier teve por volta de 35 jogadores de 10 países diferentes. Pra mim era o maior sucesso.
As brincadeiras tomaram um caminho mais sério quando, meses depois, juntei-me a 5 amigos para fazer um space sim 3D chamado Border Wars (cujo vídeo de techdemo está abaixo). Era o jogo dos meus sonhos tomando forma.
Não éramos os únicos caras no Brasil fazendo jogos nessa época, claro. Mas a falta de redes sociais e de conteúdo online fazia com que cada experiência fosse isolada e única. Era tão raro que entre 2002 e 2004 chegamos a ser chamados para dar palestras em eventos na UFRJ e UERJ, e também em uma das primeiras SBGames (acho que em Salvador? Não pude ir).
Eram tempos bizarros, de achômetro, que, imagino eu, tinham muito a ver com os anos 70 nos EUA, em que se fazia muito na garagem, no tempo livre.
Só anos depois fui conhecer pessoas como Daniel Garcia, Fernando Chamis, Winston Petty, Marcelo Carvalho e Christopher Kastensmidt. Se você não conhece esses nomes, sugiro pesquisar. Talvez você se surpreenda.
O tempo passou. O programador e, depois, eu, fomos contratados por uma empresa grande que surgira “do nada” com seu próprio space sim, um MMO. Border Wars nunca ficou pronto e daquele grupo seguiu cada um seu caminho, metade ainda na indústria, a outra em outras áreas. Vieram outros empregos, outros jogos. Vieram os MMOs. Vieram os jogos sociais. Vieram os jogos de smartphones e tablets. Vieram os serious games e jogos educacionais.
A cada ciclo surgiram novas coisas a aprender, novas oportunidades de trabalho.

O problema é que o tempo passa, as coisas mudam, mas não o suficiente.
Quase 15 anos depois que comecei, praticamente não existem vagas para game designers no Brasil.

OK, existem, se você for estagiário e tiver sorte, ou se tiver experiência e contatos no ramo. Mas o Game Designer novato pode (e deve) aceitar riscos que o Game Designer de meia idade não pode (e não deve).
Em 2007 me mudei com mala e cuia para Florianópolis para trabalhar em jogo. Em 2011, vim para São Paulo para trabalhar em jogo. Hoje recusei me mudar para o Rio (onde eu nasci e cresci).
O Game Designer de meia idade é marido e pai, e mudar fica complicado.
O Game Designer de meia idade também tem custos maiores e precisa de um salário maior, que a maioria das empresas não pode paga. Isso quando sequer cogitam contratar um game designer, por mais júnior que seja.
Este ano, quando fui ao BIG Festival, tive um choque de realidade: não conhecia praticamente ninguém lá. Certo, existem os caras que conheço de Facebook, cujos nomes começaram a ficar conhecidos na indústria. Mas... cadê todo mundo? Cadê as literalmente centenas de pessoas com quem trabalhei ao longo desses anos todos?
Foi aí que a ficha caiu.

Para o Game Designer de meia idade existem apenas 4 escolhas:
  • Abandonar a indústria;
  • Mudar para outro país;
  • Tornar-se professor;
  • Abrir sua própria empresa.
Não, eu não vou abandonar a indústria. Se depender de mim, nunca.
Não vou mudar de país. Já recebi propostas, mas hoje são tão indesejáveis quanto uma mudança de São Paulo para o Rio.
Não tenho jeito para dar aulas. Já trabalhei muito como tutor de game designers juniores, e acho que até fiz um bom trabalho, mas sala de aula não é pra mim.
Ouço quase que diariamente que abrir uma empresa é furada, em especial de metade dos caras que listei ali em cima. E, vamos ser realistas: abrir uma empresa significa trabalho que vai te impedir de fazer game design. Não é o que eu quero.
Que alternativa tenho eu, então, se me recuso a aceitar essas 4 escolhas?
Criar minha própria.
Segunda-feira recusei o emprego no Rio, depois fui a empresa para quem prestava consultoria de GD e me desliguei da mesma. Encerrei meu contrato de freela com um estúdio indie nos EUA.
Contratei um ilustrador freelancer.
Comecei a fazer meu próprio jogo.

Talvez eu seja maluco. Fazer meu próprio jogo não dá dinheiro (custa, na verdade), nem dá estabilidade. Mas me mantém em casa com minha família e, talvez mais importante para o Game Designer de meia idade, permite que eu faça o jogo que EU QUERO.
Quase 9 anos exclusivamente na indústria, e sempre fiz o jogo dos outros.
Agora é a minha vez.
Até porque, se não fizer agora, não faço nunca.
Não sou totalmente louco. Aprendi muito e sei definir escopos viáveis. E os anos de suor e lágrimas me deram a possibilidade de viver um bom tempo sem precisar de um emprego ou freelas. A Game Designer de meia idade tem reservas, e tem uma esposa compreensível que, depois de anos seguindo o marido, hoje está numa posição financeira melhor e mais estável. Se é que estabilidade é algo viável na indústria de jogos brasileira.
Eu vou fazer esse jogo.
Eu vou colocá-lo na rua até o final de 2015.
E vai valer a pena.
Só para provar que as coisas estão andando, fica aí uma concept art.
Vejo vocês em breve.

quinta-feira, 7 de maio de 2015

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.