Processo de criação e desenvolvimento de games pela empresa francesa Swing Swing Submarine. Relato de produção

1. Uma palavra sobre o estúdio Swing Swing Submarine

Swing Swing Submarine é um pequeno estúdio de desenvolvimento de games situado na cidade francesa de Montpellier. Oficialmente criado em agosto de 2010, o estúdio possui, até o atual momento, dois games comerciais, os quais fazem parte de seu ativo: Blocks That Matter e o game Tetrobot and Co. Um terceiro game, Seasons After Fall, encontra-se em processo de desenvolvimento no ano de 2014.

1.1 Equipe

Cada um dos cinco membros que fazem parte da equipe do estúdio colaboram com os projetos da Swing Swing Submarine, tendo em vista a especialidade ou a sensibilidade de cada um nas seguintes áreas: game design, programação, concepção gráfica 2D, música e efeitos sonoros.

1.2 Evolução do estúdio

O estúdio, na data de sua criação, possuía apenas dois integrantes, William e eu (Guillaume), e sempre nos reuníamos em uma sala disponibilizada por William, na cidade de Montpellier. Nos conhecemos em uma grande empresa desenvolvedora de games, a Ubisoft, e tínhamos a mesma visão: apostar em uma tentativa de trabalhar independentemente, ou seja, em nosso próprio estúdio.

Tudo começou com desenvolvimento de um protótipo para o game que denominamos por Seasons After Fall, projeto que foi suspenso pela necessidade de obtenção rápida de recursos financeiros para o estúdio. Essa necessidade nos levaria à dedicação exclusiva para a criação de jogos mais simples. Logo após esse momento inicial, juntou-se ao grupo o responsável pela criação musical, Yann, que colaborava diretamente de seu estúdio de gravação montado em seu apartamento na cidade de Angoulême, localizada à 500 quilômetros de Montpellier.

Durante a prototipagem de Seasons After Fall (2010), lançamos paralelamente dois jogos experimentais em Flash, Tuper Tario Tros. e Greek & Wicked, os quais permitiriam ao estúdio ganhar um pouco de visibilidade. Como as contas a pagar exigiam a suspensão de Seasons After Fall, criamos, além dos jogos experimentais mencionados, o game Blocks That Matter, em 2011, dentro de um prazo mais curto que o pensado para o projeto de Seasons After Fall.

Durante o período de recrutamento da equipe para o primeiro projeto (Seasons After Fall), foi, ao mesmo tempo, alcançada boa parte do desenvolvimento de outro game a somar-se ao projeto Blocks That Matter, o game Tetrobot and Co. (2013). A maior parte de seu desenvolvimento já havia sido feita pelos dois então novos integrantes, Géraud e Benoit, recém-admitidos na Swing Swing Submarine.

Em 2014 foi retomado o desenvolvimento de Seasons After Fall. Contando com 4 integrantes, a empresa deixou o seu espaço de trabalho onde havia iniciado suas atividades, deslocando-se para uma sala em um espaço coletivo de empresas de games, dividindo espaço com outros estúdios de criação como The Game Bakers, desenvolvedora de games para smartphones tais como Squids e Combo Crew.

2. Processo de criação

Entendemos por processo de criação como ao cumprimento de atividades responsáveis por conduzir a equipe no desenvolvimento do jogo. Desse processo, nasce a ideia central, fundadora, na qual é apoiado o desenvolvimento. Definimos nosso processo de criação como algo bastante orgânico e o descrevemos individualmente para cada um de nossos projetos.

2.1 Seasons After Fall

Seasons After Fall começou em torno de uma ideia que poderíamos dizer ter saído de uma dessas “viagens de programador”. Na época em que começamos a desenvolvê-lo, o estúdio se resumia a apenas dois membros, William e eu, Guillaume. Eu queria fazer um game inspirado pela “Teoria das cordas” e pela “Transformação de Fourier”. O jogador percorreria um mundo com a possibilidade de viajar em múltiplas dimensões mais ou menos escondidas, com inspiração nas quatro dimensões, X, Y, Z e o tempo de nosso mundo, além de uma outra dimensão. Em uma delas haveria uma base espectral na qual o jogador poderia colocar ou retirar frequências para retornar e ver o impacto causado em seu mundo de base, constituído pelas 4 dimensões que conhecemos. Um exemplo concreto seria a presença de espetos bem afiados que impedissem a passagem do jogador no mundo de base: um pequeno desvio no mundo espectral, com uma remoção das altas frequências (as quais em uma imagem correspondem, em geral, a seus detalhes), abrandaria os ângulos no mundo de base e os espetos tornar-se-iam menos afiados, deixando então o jogador progredir.

Por outro lado, o designer William imaginava um jogo no qual a natureza fosse onipresente e no qual fosse incluída uma tribo Inuit, a qual o jogador deveria ajudar a sobreviver. Havia de sua parte um ar de desconfiança sobre o meu projeto, tendo em vista sua complexidade, misturando Teoria de cordas e Transformação de Fourier ao mesmo tempo (assim como o leitor nesse momento deve estar pensando, suponho). Entretanto, de maneira natural, ele aderiu ao conceito de “mundo em várias dimensões”, mas com universo baseado na natureza. As dimensões seriam então 4 e optaríamos por algo bem conhecido por todos: as quatro estações climáticas do ano. Adicionando algo em sua poética, o jogador não controlaria um avatar humano, mas sim um animal, uma raposa, escolhida por seu aspecto selvagem e, ao mesmo tempo, familiar.

2.2 Tuper Tario Tros

Mesmo em sua fase de protótipo, a criação de Seasons
After Fall tornou-se uma tarefa extremamente complicada para apenas dois desenvolvedores, como assinalamos mais acima. Nossas atividades para sua criação tiveram que ser suspensas 1 ano após o seu início.

Para ficarmos informados do que se passava no mundo dos pequenos jogos desmaterializados Tradução do termo original do francês dematerialisé. Sua utilização para classificar um game indica que este não possui sua base material, como cartucho, chips de memória, cd-roms, blue-rays, etc. tratando-se de jogos disponibilizados diretamente na web para download (nota do tradutor), tínhamos o hábito de jogar, durante a pausa para almoço, os jogos do Xbox Live Arcade. Numa dessas sessões, fizemos o download do jogo Lucidity. Havíamos lido sua descrição que mencionava se tratar de um puzzle em plataforma 2D no qual o jogador ajudaria uma garotinha a progredir de fase, posicionando para isso as peças que caiam do alto. Ficamos entusiasmados com a descrição e, durante o download, imaginamos uma mistura de jogo de plataforma e de algo como o game Tetris. Ficamos decepcionados logo que jogamos a primeira vez: a personagem avançava sozinha e deveríamos, na verdade, posicionar as peças que não guardavam nenhuma semelhança com as existentes em Tetris, como: sapatos-mola para fazê-la saltar automaticamente, tábua para tapar buracos e uma escada para fazê-la avançar em altitude.

Depois dessa experiência, decidimos tomar um semana para criarmos o nosso próprio jogo na modalidade que poderíamos chamar por Tetris Plataformer, que seria um jogo gratuito. Não sabíamos exatamente como seria o jogo, mas a primeira coisa que foi implementada foi a justaposição horizontal de zonas de 8 blocos de largura equivalente à base de encaixe do jogo original Tetris.

Inicialmente, o personagem era o avatar Blocman, composto por vários blocos. Podia-se mover entre o modo puzzle, no qual uma peça de Tetris cairia aleatoriamente do alto, podendo-se colocá-la em qualquer espaço, e, ainda, podia-se sair desse modo puzzle e passar a controlar o avatar Blocman para caminhar sobre as peças recém-colocadas.

A ideia de William era a de utilizar um personagem de jogos de plataforma já conhecido, ao invés de Blocman. Como Tetris possui o que chamamos de “forte conotação Nintendo” Jogos lançados pela empresa Nintendo em meados dos anos 1980, os quais acabaram por se tornar clássicos do gênero (nota do tradutor)., ele havia pensado em integrar ao jogo o melhor “embaixador” de jogos de plataforma da Nintendo, o personagem Mario. Tuper Tario Tros., nome que traz o encadeamento do “T” de Tetris, com o título do jogo Super Mario Bros, acabava de nascer. O game ainda encontra-se disponível gratuitamente sobre a plataforma NewgroundsDisponível em http://www.newgrounds.com/portal/view/522276.

2.3 Greek & Wicked

Greek & Wicked nasceu do desejo do designer William em saber o que seria de um jogo atual se ele tivesse sido criado na época dos chamados Game & Watch, uma série de mini-games lançados pela Nintendo. Procurando um jogo recente que pudesse se adaptar à versão de jogo na modalidade Game & Watch (mini-game), William primeiramente havia pensado em Shadow of the ColossusJogo lançado pela Sony para o console Playstation 2, em 2005 (nota do tradutor). , no qual o combate contra um colosso seria representado em uma única tela, exatamente no modelo de Game & Watch. Por fim, a inspiração para Greek & Wicked não viria de Shadow of the Colossus, mas de um jogo bem mais conhecido: tomou-se por base o inimigo hydra, primeiro boss do jogo para Playstation 2, God of War.

2.4 Blocks That Matter

Após a divulgação de Tuper Tario Tros. pela Internet, uma boa quantidade de jogadores nos enviaram e-mails para pedir-nos que fizéssemos a continuação do jogo, ou mesmo um outro nível adicional, demonstrando verdadeiro interesse pela mistura dos universos de Super Mario e de Tetris.

Como se tratava de marcas e personagens pertencentes à Nintendo e à The Tetris Company, respondíamos aos jogadores que a experiência com Tuper Tario Tros. deveria parar por ali. A ideia de produzir uma sequência para o jogo nos agradava muito, mas um outro fator igualmente impeditivo era a falta de tempo, tendo em vista a dedicação de nossos esforços para avançar na prototipagem de Seasons After Fall. Nossas contas a pagar acabaram por indicar-nos a decisão a ser tomada.

De fato, até o começo do ano de 2011, não havíamos ainda lançado nenhum jogo comercial e nem obtido lucro com a publicidade em nossos jogos gratuitos. O contrato social de nossa sociedade nos obrigava, de todo modo, a fazer cotização como em regime social, mesmo com nossos lucros inexistentes. Foi exatamente nesse contexto que então resolvemos parar o desenvolvimento do protótipo de Seasons After Fall, com o intuito de lançar o mais rapidamente possível um jogo de menor envergadura.

Nesse período, pessoas ainda nos cobravam um novo lançamento de Tuper Tario Tros. Então, a partir daí, começamos a imaginar uma forma de excluir os elementos pertencentes às empresas criadoras das franquias Mario e da franquia Tetris, mantendo a mesma mecânica principal do jogo que mistura satisfatoriamente essas duas plataformas de jogo.

Nessa mesma época, Minecraft Jogo online em universo aberto (open universe) lançado pela empresa Mojang em 2010 (nota do tradutor). estava em seu começo, um jogo que nos chamava muito a atenção. Decidimos que a saída que nos era possível para darmos uma espécie de “continuidade espiritual” ao projeto Tuper Tario Tros. seria a utilização de blocos de materiais como em Minecraft. Como nosso herói, havíamos decidido desde o início que o mesmo deveria ser um bloco, ou representado por algo em forma de cubo e que ele poderia, eventualmente, ser afetado pelas reações (linhas) que seriam feitas no modo puzzle do jogo. Blocks That Matter seria lançado 4 meses após o início do processo de desenvolvimento, para a plataforma Xbox (Microsoft), tendo chegado à plataforma PC ao fim de outros 4 meses de espera, com um editor de níveis e contendo uma plataforma de compartilhamento de níveis integrados.

2.5 Tetrobot and Co.

Depois do lançamento de Blocks That Matter, vários jogadores passaram a nos questionar sobre a possibilidade de adaptar o jogo aos acessórios portáteis, tais como smartphones e tablets, um mercado que já se mostrava em pleno crescimento. Como existe no jogo uma grande plataforma que o compõe, não era nosso intuito adaptá-la e ter que integrá-la a um gamepad virtual dentro do jogo. Dessa forma, respondíamos sempre que Blocks That Matter não parecia ser o tipo de jogo adaptável às superfícies táteis e móveis, sem querer decepcionar jogadores e empresas que se propunham a trazer contribuições ao jogo.

No início de 2012, não sabíamos ao certo qual seria nosso próximo jogo. Não queríamos retomar Seasons After Fall, pois estimávamos que seria necessário contratar mais pessoas. Em meio tempo, enquanto aguardávamos a decisão sobre o recrutamento e contratação de outros funcionários, veio a ideia de produzir um jogo mais simples, um pequeno projeto para ser lançado enquanto decidíamos sobre a continuidade do projeto Seasons After Fall.

Foi então que, em 2012 vimos passar por nós uma série de protótipos que acabavam por não agradar aos dois membros da equipe, no caso, eu e William. Alguns desses jogos haviam sido pensados para funcionar em portáteis. A simplicidade e o caráter intuitivo dos controles dos aparelhos portáteis nos agradava muito. Entretanto, a elaboração e os conceitos que isso exigiria acabaria por dar uma conotação muito ambiciosa a projetos que deveriam, na verdade, serem bem mais simples.

Voltamos então nossa atenção às nossas caixas de e-mail, buscando então o que as pessoas haviam solicitado: uma versão mobile de Blocks That Matter. Sempre que possível, tentávamos ouvir o que as pessoas nos solicitavam e isso sempre nos ajudou. Passaríamos então à etapa de concepção de uma versão mobile para o game, projeto com o codinome BTM Touch.

Rapidamente, decidimos que não poderia haver uma base em plataforma para o jogo. O foco deveria passar-se à resolução de puzzles pelo jogador. O controle do avatar robô poderia ser feito com a utilização do mouse (ou do toque de um dedo sobre a superfície tátil). Parecia-nos evidente que o modo puzzle não deveria basear-se sobre as mesmas regras e princípios do jogo original Blocks That Matter.

Como o controle do robô era distinto, foi decidido que um outro pequeno robô apareceria no jogo, o avatar Psychobot. Esse teria como sua missão consertar o robô do jogo precedente, o personagem Tetrobot. Foi nesse período, durante o desenvolvimento do jogo, que Géraud (concepção gráfica 2D) e Benoit (programador) juntaram-se à nossa equipe.

3. Processo de desenvolvimento

Após ter mostrado o processo de concepção ou como nasce uma ideia para a criação de um game, passaremos adiante com a exposição do modo de desenvolvê-lo.

3.1. A escolha da tecnologia e das ferramentas

Antes de começarmos a tratar do tema do desenvolvimento, há sempre uma fase na qual nós decidimos sobre quais as melhores ferramentas usaremos para esse desenvolvimento. Passemos então a elas, que separamos aqui, tendo em vista cada um dos jogos desenvolvidos em nosso estúdio.

3.1.1 Desenvolvimento de Seasons After Fall

Para o primeiro protótipo do jogo, desenvolvemos nosso próprio motor (engine). Partimos de um framework básico proposto pelos 2 desenvolvedores de World of Goo Disponível em http://2dboy.com/2009/05/27/rapid-prototyping-framework/. Utilizamos outro framework com base em C++. A estratégia de partir de um framework simples e fazer a programação de todo o resto fazia parte da filosofia de trabalho da empresa Ubisoft, que desenvolveu seu próprio motor de desenvolvimento. Por esse motivo é que não optamos pelas alternativas que se ofereciam à época, como Ogre3d, Torque 2D e 3D. Para a edição de níveis, a animação e para a criação de objetos, nós nos apoiamos sobre o programa Blender Disponível em http://www.blender.org/.

Como éramos apenas dois a trabalhar no desenvolvimento nessa época, William (designer) se ocupava em fazer as animações e os gráficos com uma exigência que orientou a concepção visual e a metodologia de animação: nós decidimos utilizar uma paleta de cores e formas vetoriais como as vistas no jogo Another World Game desenvolvido pela empresa Delphine Software e lançado no mercado em 1991 (nota do tradutor). . Por exemplo, a animação de uma raposa foi realizada por um processo de rotoscopia de sequência de imagens tiradas de um vídeo do You Tube.

Utilizar formas vetoriais e cores como as escolhidas nos permitiu animar facilmente o crescimento de árvores e de toda a vegetação. O que foi mais difícil: o designer aprender a utilizar o Blender, um programa com boa performance, mas dotado de uma interface sem similar em comparação com outros programas. Foi inevitável perder-se um tempo com essa adaptação ao programa.

Ainda, o motor de jogo que construímos não era capaz de suportar todas as funcionalidades do Blender. Foi preciso, então, conhecer o que poderíamos ou não utilizar dentro de todos os parâmetros oferecidos pelo programa. Por fim, o meio de importar novos dados em nosso motor, tais como objetos, som, texturas, necessitava de um trabalho de configuração manual em arquivos de texto, o que fez com que o workflow não resultasse em algo tão otimizado.

No fim, chegamos a um protótipo jogável com cerca de 30 minutos, mas vimos também que nosso processo de produção necessitava de um pouco mais de sutileza. Verificamos que tínhamos dificuldades em iterar de maneira rápida para integrar ao projeto novas ideias ou mesmo modificar elementos que não funcionavam muito bem.

Colocando a prototipagem do jogo em suspensão pelas razões financeiras já descritas, nós chegamos à conclusão que precisaríamos de um outro workflow, se algum dia retomássemos o seu desenvolvimento. Essa experiência foi bastante enriquecedora para nós, o que nos mostrou que o pipeline e o workflow constituíam os elementos mais cruciais para o desenvolvimento de um jogo.

3.1.2 Os experimentos Tuper Tario Tros. e Greek & Wicked

Para a realização desses dois experimentos, queríamos que os jogadores em potencial pudessem acessar diretamente esses games a partir do navegador. Naquela época, não havia outra solução senão a de utilizarmos o Flash.

Considerando a forma pixelizada dos jogos que queríamos fazer, deixamos então de lado os grafismos vetoriais (entretanto, o principal elemento ativo do Flash). Começamos a fazer alguns testes mas, logo de início, descobrimos a biblioteca do Flixel, que fazia exatamente aquilo que precisávamos. Tal biblioteca foi obra de Adam Atomic, que havia já desenvolvido o runner mais conhecido, o Canabalt.

A biblioteca era realmente bem simples em sua utilização e possuía todas as funcionalidades que havíamos necessidade para a composição dos dois jogos em Flash. O desenvolvimento de cada um dos jogos levou cerca de 5 a 6 dias somente. Podemos comparar essa rotina de desenvolvimento às imersões feitas nas chamadas game jams Ocasião na qual encontram-se jogadores, programadores, designers, músicos, para a criação de games em conjunto, com a formação de grupos, que podem contar com a colaboração de outras pessoas pela web. Os jogos têm um caráter de independência e autonomia para a criação e divulgação e os projetos são realizados em apenas algumas horas ou dias, guardando sempre certo grau de simplicidade em comparação ao jogos produzidos pela indústria do entretenimento (nota do tradutor). . Nessas, o conceito do jogo deve ser simples, verificando que não são realizados muitos testes nos jogos produzidos em um contexto de uma game jam.

As ferramentas para a concepção do jogo são as mais básicas possíveis. Por exemplo, a edição de níveis em Tuper Tario Tros. resume-se a um arquivo de texto preenchido por caracteres e as sequências de jogo. E as posições possíveis do personagem em Greek & Wicked são codificadas diretamente pela programação.

3.1.3 Blocks That Matter

Com Blocks That Matter, pensávamos que alcançaríamos um bom resultado e que este seria o nosso primeiro e único game comercial. Como tínhamos à época uma ligação bem afinada com os jogos de console, passamos a perseguir a possibilidade de desenvolver, fácil e legalmente, um game para um dos consoles existentes. E o que nos chega após essa procura foi a descoberta de um framework gratuito que permitia o desenvolvimento de jogos para a plataforma Xbox 360, o framework XNA.

Como havíamos gostado muito do framework utilizado para o desenvolvimento de Tuper Tario Tros. (o framework Flixel), decidimos por utilizá-lo novamente. Por meio de uma adaptação entre XNA e Flixel, chamada por X-Flixel, criada pela Excalibur Game Studios, começamos então a construir Block That Matter (codinome que utilizávamos para o projeto: Tuper Tario Tros. 2).

XNA recai sobre o framework. Net e a linguagem de programação C#. Essa linguagem associada ao framework utilizado acabou por se tornar uma grande ferramenta para desenvolver o jogo de forma mais rápida, com o tempo das compilações reduzido, a gestão de memória feita automaticamente por .Net e as inúmeras outras funcionalidades, tais como: gestão de joysticks, gestão de som, dentre outras.

Para a versão PC, queríamos de todo modo que o jogo pudesse ser executado em Windows (o que permitiria o framework XNA), mas também em Mac e Linux (o que XNA não permitia), para estarmos em um número máximo de plataformas e por não restringir a participação em bundles Atividade de promoção de jogos que propõe a reunião de vários deles em pacote único para a distribuição, participação de feiras e divulgação em plataformas online de games., visto que a iniciativa Humble Bundle havia nascido no ano anterior.

Existia um projeto em código aberto denominado MonoGame que permitia a execução do código XNA em Linux e potencialmente no Mac também. Entretanto, a compatibilidade se mostrava apenas parcial, resultando em perda de funcionalidades. Ainda, não se sabia se o projeto MonoGame encontrava-se ativo naquela época. Foram feitos os testes que mostraram que o jogo rodava mal no sistema Windows. Por isso, decidimos fazer uma espécie de “homenagem implícita” ao jogo Minecraft, que foi realmente fonte de inspiração para Blocks That Matter. O potencial de Minecraft resumia-se muito em sua disponibilidade para Windows, Mac, Linux e navegadores da web. Foi então que escolhemos utilizar o mesmo framework presente nesse jogo: LWJGL (Lightweight Java Game Library). A linguagem Java utilizada nesse framework, sendo próxima à linguagem C#, nos permitia realizar o jogo em poucas semanas.

No que tange às ferramentas, nos demos conta que no desenvolvimento de Seasons After Fall e de Tuper Tario Tros. havia sido muito importante poder modificar e testar rapidamente os níveis do jogo. Foi por isso que desenvolvemos um editor de níveis e o incluímos diretamente no jogo. Não se trata de ferramenta externa de onde podemos exportar dados que seriam novamente importados no jogo. Isso poderia causar uma série de idas e vindas, além do fato de que tal processo não é instantâneo.

Esse editor deveria ser de utilização extremamente simples, tendo em vista que a versão utilizada durante o desenvolvimento exigia apenas o uso de joystick como periférico. A concepção do editor foi por esse caminho, pois pensávamos que seria tecnicamente possível disponibilizá-lo aos jogadores da versão Xbox. Entretanto, na prática, havia a impossibilidade de realizar tal feito. O editor de níveis foi, então, incluído na versão PC com a base de utilização mouse – teclado.

A função principal do editor é permitir a criação de níveis (que podem ser incompletos), de testá-los em tempo real e de passar ao modo de edição em qualquer momento para adicionar ou modificar elementos. Inúmeros “superpoderes” são conferidos ao criador (jogador) que pode deslocar seu personagem por onde queira, de modo a testar facilmente as situações e as partes específicas de um nível, sem ter que implementá-lo inteiramente. Tal ferramenta tornou-se determinante para elevar a qualidade dos níveis do jogo.

3.1.4 Tetrobot and Co.

O jogo é o resultado de quase um ano de pesquisa, o que se deu após o lançamento de Blocks That Matter. O ano de 2012 foi dedicado à prototipagem de vários embriões de jogos que não conseguimos terminar. Para prototipar de maneira rápida, nós nos demos conta de que era necessário uma ferramenta mais poderosa que apenas um editor de níveis baseado em blocos.

Foi então que passamos a prestar atenção no Unity, motor combinado com um editor de jogo genérico, quer dizer, ferramenta que nos permite fazer jogos seja em 2D, em 3D, ou jogos de tiro em primeira pessoa (first person shotting ou FPS), e jogos de plataforma (2D). Sendo o Unity baseado na linguagem C# como linguagem de script, nós nos sentimos bem mais à vontade, pois tratava-se da mesma linguagem utilizada para a versão para Xbox de Blocks That Matter.

Nós, então, desenvolvemos toda uma gama de protótipos com Unity para, ao fim, decidir criar uma “sequência espiritual” para o jogo Blocks That Matter. Tetrabot and Co. seria desenvolvido com Unity e outras ferramentas seriam criadas no interior do motor, pois ele nos dava essa possibilidade. Um editor de níveis incluídos no jogo foi uma dessas ferramentas criadas, mas outras também foram necessárias, criadas sob a forma de “sobre-camadas” adicionadas às funcionalidades de Unity (para as animações, a criação e a gestão de sons, dentre outras).

3.1.5 Seasons After Fall (a retomada)

Nosso próximo projeto para 2014 será exatamente dar continuidade ao primeiro projeto de nosso estúdio Swing Swing Submarine: Seasons After Fall. Agora com a pretensão de continuar utilizando para a construção do game.

O que foi feito até então: concluímos a fase que poderíamos chamar por fase de R&D (pesquisa e desenvolvimento) R&D, do francês Recherche et Développement, termos que correspondem à “pesquisa” e “desenvolvimento” na língua portuguesa (nota do tradutor). e a fase de pré-produção. Trata-se então do momento em que eu e Benoit, os dois programadores da equipe, experimentamos novos métodos que podem responder às necessidades de jogo. Por sua vez, William e Géraud começam a conceber o que chamamos por target gameplay footage, um pequeno vídeo para uso interno nessa etapa de produção, destinado a reproduzir o que veremos em algumas sequências do jogo.

3.2 O game design coletivo

Em nossa equipe, William é o único game designer de formação, embora o design de games seja uma função compartilhada por todos os membros da Swing Swing Submarine. William se ocupa mais detidamente do level design (desing de níveis, ou fases dos jogos) e da coesão final do design do game. Ele exerce também muitas outras atividades paralelas, como a gestão de nossa sociedade, por exemplo.

Todos propõem suas visões e opiniões sobre o andamento das atividades e, então, tentamos atingir o melhor resultado. Trata-se de procedimento muito orgânico e muito iterativo. A nosso ver, trata-se da solução mais justa por deixar todos participarem e ajudarem na escolha da direção por onde seguirá o projeto, o que favorece a sensação de sentir-se implicado de fato nas decisões.

Não existe um Game Design Document (GDD) em nossa empresa. Um GDD sempre é usado em grandes empresas e trata-se de documento que descreve de maneira bem precisa os elementos com os quais teremos que lidar na produção e como esses elementos funcionam. No caso, um GDD é oferecido a uma equipe de programadores e o jogo pode ser implementado a partir desse documento. Bem, na prática é um pouco mais complicado que esta simples descrição de como funciona, e esse é o motivo de não adotarmos tal prática na Swing Swing Submarine. Podemos dizer que muitas vezes não produzimos nem um GDD e mesmo nenhum outro documento com uma função a ele similar.

Na maioria dos casos, desde que há algo que precisamos escrever ou documentar, trata-se muito mais de uma lista de ideias sob um quadro, ou mesmo algumas linhas capazes de resumir as grandes linhas, ou seja, uma documentação das escolhas que são feitas oralmente por nós.

3.3 Um processo iterativo

Quando começamos a desenvolver um jogo fazemos uma ideia ou temos uma visão do que ele poderá vir a ser, e essa ideia pode se mostrar depois bem distinta do produto final. Uma ideia que parece ser genial no início pode ser simplesmente ignorada quando integrada ao jogo, por resultar em algo mal-acabado ou por fazer emergir algo que não corresponde em nada aos outros elementos já a ele integrados. É por isso que nossa equipe tenta ao máximo iterar em todos os domínios, em todas as áreas do desenvolvimento.

Por exemplo, o grafismo não pode ser trabalhado e aperfeiçoado ao exagero desde o começo. Nós nos contentamos apenas com os chamados placeholders, seguidos por versões rough e versões que vão sendo afinadas, melhoradas até que se possa chegar ao gráfico final.

Ao que concerne ao game design, vemos aí também muitas iterações acontecerem. Por exemplo, em Block That Matter, o sistema final de colocação de blocos foi criado somente em etapa mais avançada da produção, durante o seu desenvolvimento. No início, o jogo permitiria apenas a colocação de Tetrominos (formas geométricas compostas por 4 blocos) e a seleção da matéria compondo cada bloco, no interior de cada Tetromino, era feita aleatoriamente. Houve a necessidade de algumas iterações para que então decidíssemos em dar a possibilidade ao jogador para colocar os blocos 1 a 1, obedecendo uma regra de proximidade entre os blocos já depositados (um bloco deve sempre estar colado a um bloco colocado anteriormente, e o primeiro bloco estar colado a um bloco do cenário).

Foi o mesmo que ocorreu com o design do deslocamento do robô em Tetrobot and Co. No começo, o deslocamento do robô não era gerado por um simples clicar, no qual o robô calculava sozinho o caminho mais curto e seguro. O deslocamento era antes definido por um traçado completo desde o usuário até o robô e seu destino. Nós nos demos conta que o aspecto mais divertido não estava ligado ao ato de definir o traçado do deslocamento, mas sim no posicionamento do robô em uma ou outra casa disponível. Por isso, o controle do robô foi então simplificado.

O level design das fases ou níveis do jogo não derroga a regra da iteração. No começo, trata-se mais de uma acumulação de situações. Em seguida, os níveis ganham forma gradativamente. É preciso diluir as coisas. É gradativamente que o jogador aprenderá como ele poderá fazer algo no jogo e como fazê-lo de modo mais natural, compreendendo quase intuitivamente o que deverá fazer em cada situação, evitando uma grande quantidade de informação a ser assimilada de uma só vez.

Enfim, a iteração é igualmente válida para a parte de código. Tenta-se implementar as novas funcionalidades por etapas. Por exemplo, o controle de personagens passa por uma primeira implementação, em seguida, analisando o que é sentido durante o ato de jogar, efetua-se retoques até ser possível obter o controle ideal. O mesmo acontece para a gestão da câmera do jogo e outras fases de produção.

Nós não aplicamos às cegas tais métodos considerados ágeis para o desenvolvimento em nossos jogos. O que fazemos é utilizar desses métodos como base e, mesmo com isso, em boa parte dos projetos, observamos que estamos em atraso em relação ao plano que havíamos definido como ideal.

3.4 Playtests

Ao longo da concepção, tentamos fazer os testes dos elementos dos jogos com outras pessoas que não os membros do estúdio de criação. Isso nos serve para validar o mais rapidamente possível se um elemento é compreensível, divertido, jogável, por exemplo. Inicialmente, são amigos desenvolvedores que se colocam à nossa disposição, pelo fato de que o jogo encontra-se em fase inicial de elaboração e não possui, por isso, boa apresentação. Em seguida, aumenta-se o círculo de participantes aos testes. Entram em cena amigos de amigos próximos. Os elementos testados nessa fase são ainda bem pontuais: testa-se os primeiros níveis para saber quais serão os problemas que os jogadores encontrarão. Falamos bastante com as pessoas que testam o jogo por faltar-nos elementos para que compreendamos sozinhos os problemas ora existentes.

Na última parte do desenvolvimento, lançamos uma chamada para playtest às pessoas que não conhecemos, fora de nosso círculo de amizades, de modo a obter uma opinião verdadeiramente externa. Colocamos o jogador em teste diante da tela e não oferecemos a ele nenhuma explicação, a não ser que sejamos questionados sobre algum ponto do jogo por ele não compreendido. Tais testes com pessoas desconhecidas são um pouco estressantes, pois, na maioria dos casos, o desenvolvimento do jogo está em fase avançada e ainda aparece uma multiplicidade de problemas que devem ser corrigidos rapidamente antes de seu lançamento.

3.5 Ao lado do desenvolvimento

Para completar o ciclo do processo de desenvolvimento de nossos games, nesse tópico listaremos outras atividades a ele relacionadas.

3.5.1 Marketing

Com relação ao marketing de nossos produtos, reconhecemos nossa fraqueza, devido ao fato de que nenhum de nossos integrantes possui tal formação e ninguém pode dedicar todo o seu tempo para essa atividade. Desse modo, deixamos as ações de divulgação baseadas no “faça você mesmo” e, por enquanto, ainda não lançamos chamadas a interessados em nos ajudar nesse campo da comunicação e marketing, o que deverá ser feito somente na ocasião de lançamento de nosso próximo jogo.

Nossos primeiros passos dados na divulgação pela imprensa foram algo bem específico, pois se tratava, na maioria, de sites que falavam de nossos games de maneira espontânea, sobretudo do nosso primeiro jogo em Flash, Tuper Tario Tros., podendo mesmo dizer que houve, nesse caso, o elemento viral presente. Com essa mídia espontânea, ganhamos um pouco de visibilidade e aproveitamos para fazer nosso estúdio ser conhecido, mesmo que minimamente.

Tentamos utilizar nosso blog com uma certa frequência para atividades de divulgação, cadência que foi reduzida e a qual queremos aumentar em curto prazo. No que tange à imprensa, enviamos aos veículos especializados os nossos releases e outros informativos de divulgação, além de versões dos games, estando incluída também nessa lista a imprensa online. Os sites profissionais e amadores no âmbito dos games, assim como importantes canais do You Tube, recebem igualmente a nossa atenção.

Apesar de todos os esforços, não é simples obter a atenção dos sites aos quais nos dirigimos. Provavelmente, a dificuldade é devida ao tipo de jogo que propomos e em vista do modelo de jogo que é mais difundido no grande mercado. A visibilidade torna-se algo não facilmente assegurado aos nossos projetos.

Para incrementar a divulgação, nós temos também participado de difusão de nossos produtos em grupos ou pacotes de jogos, os bundles, o que nos garante também algum retorno financeiro. A visibilidade advinda do lançamento desses pacotes de games é relativamente satisfatória e é frequente termos nossos jogos mencionados em sites especializados graças a isso.

3.5.2 Financiamento

No que tange ao financiamento, começamos com o nosso estúdio sem prever remuneração aos sócios. Felizmente, a França é um país que possui um sistema de incentivos bastante interessante, o que facilitou bastante nossa instalação e nossa manutenção assim que começamos.

Nossa filosofia dispõe que “o jogo precedente deve financiar o jogo subsequente”. Atualmente, Blocks That Matter garante o financiamento de Tetrobot and Co., mas esse último ainda não encontra-se a ponto de financiar Seasons After Fall. Para este último, obtivemos uma subvenção de uma organização francesa que tem por objetivo favorecer a criação de novas propriedades intelectuais em nosso território. O CNC, Centre National de la Cinématographie, nos ajuda com um incentivo de cerca de 75 000 euros para o financiamento do projeto.

De todo modo, a mais importante soma de nossos lucros provém da participação em pacotes de jogos (bundles) e das liquidações que fazemos sobre o valor de nossos próprios jogos. Dentre os pacotes de jogos mais lucrativos que já participamos, podemos dizer, sem nenhuma dúvida, que o mais importante foi Humble Voxatron Début, organizado por Humble Inc. e por Cube Bunble, projeto que integramos pela plataforma de games Steam.

3.5.3 Difusão

Os jogos que nós desenvolvemos até o momento são autopublicáveis, ou seja, são propostos a partir de plataformas online, para download. Nosso primeiro jogo foi distribuído pelo canal Xbox Live Indie Games, do console Xbox 360. Em seguida, conseguimos atingir a plataforma Steam em PC (Windows, Linux) e em Macintosh, essa que constitui atualmente a mais importante plataforma para download de games para computador no mundo.

Experimentamos diferentes plataformas, tais como Desura, Indievania, Impulse, Gameolith. Entretanto, Steam foi a única a nos fornecer um rendimento suficiente para permitir-nos autopublicar nossos jogos e a desenvolvê-los satisfatoriamente. Nos últimos tempos, entretanto, tem sido cada vez mais difícil para nós nos mantermos visíveis em plataformas como a Steam, tendo em vista uma recente explosão de jogos, em quantidade e qualidade, sobre esta plataforma.

3.5.4 Comunidade

Para concluir esse breve relato sobre a produção, desenvolvimento e processo de criação no estúdio de desenvolvimento de games da Swing Swing Submarine, em Montpellier, França, gostaríamos de expor que sempre dedicamos uma atenção especial aos jogadores que se interessam por nossos jogos. No momento, o incremento de nossa comunidade é algo ao qual nos empenhamos muito, lugar onde sempre disponibilizamos aos jogadores algumas ferramentas para cocriação de jogos, incluindo a elaboração de conteúdo narrativo. Ao mesmo tempo, tentamos nos mostrar bastante acessíveis pelas redes sociais da web. Em nossos jogos, tentamos sempre esconder pequenas surpresas, como senhas, url e e-mails secretos, que poderão ser desbloqueados. Tais segredos irão permitir ao jogador descobrir elementos suplementares em nossos jogos.

Por fim, organizamos eventos e concursos com certa frequência, como, por exemplo, o calendário específico que permite aos visitantes de nosso site, ou de nossas páginas em sites sociais, de ganhar dois jogos por dia, um deles criados por nós e um outro jogo criado por algum desenvolvedor de nossa preferência. Um outro atrativo são os levels featuring, nos quais antecipamos, por meio de pequenas montagens de vídeo, as criações mais surpreendentes dos jogadores.