Ponto V!

Home Mercado Post Mortem Postmortem: Jump-O
ByteBrushers Independent Game Development Team
Postmortem: Jump-OImprimir
Escrito por ByteBrushers

Olá, leitores! Só alegria? Fomos gentilmente convidados pelo Vinícius – bom amigo e também nosso professor da pós em jogos digitais da PUCPR – para escrever o post mortem do jump-O, um jogo que fizemos para iOS e lançamos na App Store, aqui para o PontoV. Neste post mortem vamos contar algumas histórias relacionadas ao jump-O, como foram as fases de design e desenvolvimento e também dificuldades que encontramos ao longo da jornada de dois meses.

image

O time

O time é composto por Gabriel Mathias Rocha e por mim, Victor Lappas Giménez. Um pouquinho de história, eu e Gabriel nos conhecemos há alguns anos já. Fizemos faculdade juntos, apesar de cursos diferentes (nos encontrávamos em trocas de laboratórios e corredores de blocos), e depois acabamos nos encontrando novamente na empresa em que trabalhamos hoje. Meu time na empresa trabalhava junto com o time dele, então acabamos podendo conversar sobre vários outros assuntos que não conversávamos durante a faculdade, incluindo a paixão por programação e jogos. Em 2012 eu entrei na pós-graduação em jogos digitais na PUCPR. O primeiro ano foi acabando e eu estava bastante contente com o resultado e o networking que estava fazendo no curso. Atormentei a vida do Gabriel até ele fazer a inscrição para a turma de 2013 e me enviar o comprovante de pagamento, assim eu pararia de azucrinar. Ele começou o curso em 2013, e depois de várias e longas conversas sobre como aproveitaríamos o que estávamos aprendendo e encontrando na pós, acabamos por nos unir e criar a ByteBrushers, atualmente composta por nós dois.

Como a idéia surgiu

A ideia surgiu de duas fontes, que acabamos por misturar.

Uma das fontes veio de conversas aleatórias que tínhamos sobre como era difícil ser nerd na nossa época de escola – e éramos. Os dois. Hoje, ser geek (uma variação para um nerd tecnológico) é divertido e tem até seriados específicos pra isso. Hoje também existe algo chamado bullying – na nossa época isso era justificado pela ciência por meio da seleção natural, onde o mais adaptado é que sobrevive. Conversado sobre isso, chegamos à mesma conclusão – de que, por mais que nos esforçássemos, não nos sentíamos parte do mundo em que vivíamos. Éramos diferentes dos que nos cercavam, e na maioria das vezes acabávamos sendo alvo de chacota e brincadeiras de mau gosto. Esse é o motivo principal pelo qual Roundy, que é o personagem principal do jump-O, é o único geometricamente diferente de todos os outros elementos do jogo.

A segunda fonte veio de outras conversas sobre minimalismo em jogos, sobre como um jogo podia ser muito divertido, mesmo que com arte, conceitos e controles simples. Bom, somos 2 programadores – nossa única saída para arte própria é ela ser simples. Queríamos fazer um jogo que nós mesmos gostaríamos de jogar, cujo foco fosse a simplicidade e modo geral.

Jump-O para iOS

Já tínhamos começado a desenvolver o jump-O para PC, usando C++ e SFML. Porém, o curso da pós começou a demandar um pouco mais. Fora isso, eu e Gabriel começamos um curso de desenvolvimento para iOS que também começou a demandar mais. Acabamos não tendo escolha a não ser engavetar o jump-O para PC por algum tempo. Quando no fim de 2013, fim da primeira etapa do curso de iOS, foi proposto para toda a turma um mini challenge, o Gabriel falou na hora: “é a chance de desenvolvermos o jump-O para iOS”. Eu discordei de início pois, pensava em lançar o jump-O para PC antes de qualquer outra plataforma mobile. Depois de uma boa discussão, acabei concordando com ele.

Ainda não tínhamos visto SpriteKit (nova framework da Apple para jogos 2D no iOS7), mas ok – já tínhamos tido uma boa quantidade de Objective-C (linguagem de programação para aplicações para Mac e iPhone/iPad/iPod Touch) e assim foi. Caímos de cabeça na SpriteKit. Para nossa surpresa (ou não), foi bastante fácil entender como as coisas dentro dela funcionavam, e saímos metralhando código. A arte do jump-O já estava pronta de sua versão para PC, o que nos poupou um bom tempo. A música foi feita no GarageBand (software da Apple para criação e edição de música), com alguns Apple Loops e melodias gravadas por mim mesmo usando o teclado do MacBook. Confesso que ter que “tocar” usando um teclado de computador é bizarro – e ruim. Muito ruim. Como meu cabo MIDI, para ligar meu piano digital no MacBook, ainda não havia chegado “das terras asiáticas”, foi o que deu pra fazer.

Em 3 dias, o core do jogo estava pronto com seus elementos básicos: o Roundy, os blocos de plataforma, blocos com espinhos e blocos atiradores. Tudo (até então) funcionava bem. Todos os testes que fizemos eram promissores. Isto feito, hora de começar a trabalhar no gameplay. Levamos 10 dias pra terminar a primeira versão do jump-O e apresentar. A boa surpresa foi ver como a turma e os professores aceitaram o jogo. A pergunta durante a apresentação foi: “quando sai na App Store?”. Com isso em mente, passamos por aproximadamente um mês e meio polindo e equilibrando o jogo. Nesta etapa, conversamos também com alguns professores da pós (aos quais somos bastante gratos) para tentar aprender algo a mais do que vimos em sala – ouvir os mais experientes é sempre essencial. O que você faz com o que ouve é uma decisão sua, mas é bom ouvir histórias e porquês.

Level design

Como jump-O é um jogo feito de tiles, usamos a resolução do iPod Touch 5 (que tínhamos disponível pelo curso de desenvolvimento para iOS) para calcular o tamanho. Seriam 20 tiles de altura por 30 de largura – orientação do dispositivo em landscape. Assim, na largura, ainda sobrava espaço para a barra de pontos, estrelas, tempo, indicador de level e etc.

clip_image002

Figura 1 - Fase 2-2 do jump-O, anterior à etapa de polimento e balanceamento de gameplay.

Visto que cada tile ali é um objeto, precisávamos de uma maneira fácil de ler uma fase e jogá-la na tela. Acabamos optando por usar arrays – cada fase é uma matriz. Porém, como criar fases? Abrir um editor de texto e ficar montando matriz na unha? Não – fizemos também um editor de fases, esse em C++ e SFML, pra que pudéssemos agilizar o processo de level design. E aliás, que processinho – criamos algo por volta de 120 fases. Destas ~120, algumas ficaram boas, outras ficaram mais ou menos, e algumas ficaram horríveis. De qualquer forma, é pra isso que o processo serve – fases que eram boas ficaram quase que inalteradas, e as que eram mais ou menos foram usadas pra fazer fases novas, mas com o que aquelas tivessem de melhor. Este é o editor que fizemos rapidinho:

clip_image004

Figura 2 - Level Editor para o jump-O.

Dificuldades

De longe, tanto a linguagem quanto a framework não foram dificuldades. Da linguagem já tínhamos visto bastante, e como jump-O é minimalista, simples, foi relativamente tranquilo aprender o que precisávamos da SpriteKit para fazer o jogo. Entretanto, o que, de certa forma, complicou um pouco foi o resultado das fases rodando no dispositivo. O simulador de iPhone roda com o que a máquina oferece – muito diferente das características do dispositivo. Então, resolver colisões em grande número tende a fazer o dispositivo literalmente sentar. De onde tantas colisões? Veja a fase 4-1, por exemplo:

clip_image002[6]

Figura 3 - Fase 4-1 no editor de fases.

Vê todos aqueles tiles de plataforma (quadrados pretos sem preenchimento)? Da forma como eles são criados (por nós), para a SpriteKit todos eles estão colidindo entre si. Inicialmente, isso fez a quantidade de quadros desenhados por segundo despencar de 60 para 4. Como todo objeto tem um physicsBody associado, o que fizemos foi diminuir 1 pixel de cada lado. Ou seja, se o tile tem 32x32, seu physicsBody tem 30x30. Tudo parecia ok, até que quando Roundy deslizava lentamente sobre plataformas, ele começou a cair nesses vãos de 2 pixels entre os physicsBody dos blocos. De volta à prancheta...

A solução acabou sendo a seguinte: criar aqueles blocos de plataforma sem seus physicsBody. Criamos uma função que varre a matriz da fase, buscando por códigos de blocos de plataforma, identificando agrupamentos. Estes agrupamentos geram novos physicsBody (barras verticais ou horizontais), para que este problema de cair em pequenos vãos não aconteça, incluindo a solução anterior correspondente a não colocar os blocos em colisão. Foi o que resolveu para garantir o fps (quadros por segundo) e deixar a movimentação do Roundy suave.

clip_image004[6]

Figura 4 - jump-O em modo debug, mostrando os physicsBody de plataformas e paredes.

Conclusão

Para os guerreiros que aguentaram ler até aqui, obrigado. Já aprendemos muito durante este processo, e ainda estamos aprendendo pois, ele ainda não acabou. Já temos elementos novos e atualizações prontas pra saírem. Além do aprendizado técnico, vimos que ainda temos muito a aprender em relação ao processo de lançamento de um jogo em si, manter o interesse dos jogadores ativo e prestar atenção em todo feedback recebido.

Caso esteja interessado, caro leitor, dê uma olhadinha no jump-O na App Store. Estamos interessados em todo feedback que pudermos receber dos jogadores para constantemente melhorarmos o jogo e, consequentemente, a maneira como trabalhamos e o entretenimento que proporcionamos aos jogadores que gostam dos nossos jogos.

Um abraço,

ByteBrushers Independent Game Development Team


Comentários (2)
  • Ytrio Salmito  - Gostei!
    avatar

    Interessante ideia x)

  • Felipe Castelhano  - Muito massa
    avatar

    Legal ver os desafios que vcs tiveram e como criaram um editor de fases - serve de motivação para as aulas de ios que vem por aí na turma de 2014 da pós da puc

Escrever um comentário
Your Contact Details:
Gravatar enabled
Comentário:
[b] [i] [u] [url] [quote] [code] [img]   
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch::(:shock:
:X:side::):P:unsure::woohoo::huh::whistle:;):S:!::?::idea::arrow:
Security
Por favor coloque o código anti-spam que você lê na imagem.
LAST_UPDATED2  

Busca

Linguagens

Twitter