deV( )id Games | because we're tired of no return;

TAG | Prototipagem

Feb/11

26

Gamerama 2011

Mortos? Não. Desaparecidos? Um pouco. Parados? Nunca!

A verdade é que estamos sempre preparando algo por debaixo dos panos. Bom, pelo menos desde o fim do período! A boa notícia é que o nosso “sumiço de fim de período” vai terminar porque, bem, a graduação terminou, mas a má notícia é que isso envolve ocupar as férias terminando sua monografia de Projeto Final em vez de fazer joguinhos. Por outro lado, o tal Projeto Final é um framework para jogos e um protótipo de um jogo 3D velho conhecido de todos nós, o que torna a coisa toda bem mais agradável!

Ops, eu falei que ficamos apenas escrevendo uma monografia em vez de fazer joguinhos? OK, é mentira. O Yanko estava fazendo joguinhos durante boa parte do tempo em que deveria estar escrevendo, e tal projeto secreto será divulgado ainda durante este final de semana se a meteorologia contribuir a nosso favor. Fiquem ligados!

Mas em especial, além disso, durante a semana passada aconteceu no prédio da Fundação Getúlio Vargas (FGV), em Botafogo, Rio de Janeiro, mais uma edição do Gamerama! Como não podemos perder uma oportunidade de acordar cedo e pegar duas horas de engarrafamento para fazer joguinhos e novos contatos, obviamente nós da deV()id estávamos lá presentes, firmes e fortes. Como nosso amigo Guilherme Xavier fez o grande favor de descrever extensivamente a estrutura do evento ao longo dos quatro dias (terça a sexta) no blog oficial, vou dedicar este post a contar com maiores detalhes a nossa experiência pessoal e as regras dos jogos (loucos) que desenvolvemos.

O que, você ainda não clicou no link para o blog oficial para conhecer o evento? Tudo bem, vai lá, eu espero. Enquanto isso, veja esta foto que tiramos no fim do último dia (e eu kibei do blog oficial, então você poderá encontrá-la lá também):

Equipe final do Gamerama Workshock: Tabuleiro Botafogo

Pros realmente preguiçosos: foi um evento de 4 dias, de terça a sexta-feira. Os três primeiros dias foram divididos em duas partes: uma de teoria, com uma palestra sobre Game Design proferida pelo Guilherme, e outra de prática, onde a turma era dividida em grupos e cada grupo deveria desenvolver o design de um jogo: analógico nos dois primeiros dias, e eletrônico no terceiro. O último dia foi inteiramente dedicado à finalização da implementação do protótipo do jogo eletrônico (que na prática foi iniciada ao longo do resto do terceiro dia, em casa mesmo).

Nosso grupo inicial era formado por mim (Tinnus), Yanko e o Dudu, um designer e ilustrador muito gente boa que contribuiu enormemente nas discussões de design e principalmente na confecção da arte final do jogo eletrônico. Recomendo fortemente que todos conheçam seu trabalho visitando o Arte Cinco Produções Artísticas.

Ah, e você não pode entrar na FGV com qualquer peça de roupa que mostre as pernas. A não ser que seja uma mulher. Não que eu reclame de mulheres poderem mostrar as pernas, mas acho que um calor de 40 graus no Rio de Janeiro deveria ser suficiente para deixarem homens mostrarem as canelas também =P

Pois bem, no primeiro dia deveríamos desenvolver um jogo que utilizasse apenas dados comuns, com um número de cada entre 1 e 6 (ou um D6, se você for do tipo maníaco por RPG). Além disso, todos os jogos tinham um tema e algumas restrições conceituais que deveriam ser seguidas, e não poderiam depender exclusivamente de sorte. Obviamente eu não lembro quais eram as restrições do primeiro dia, mas o que conseguimos depois de uma hora gastando massa cinzenta foi um jogo chamado “Termo-Pôker (com dados)”. Sim, soa estranho, e era mesmo, mas não reclame, o jogo só poderia usar dados! Resumindo bastante, a mecânica consistia em ter um dado que funciona como “termostato”, mostrando a temperatura atual da “sala”. Sendo um jogo para dois jogadores, um jogador quer esfriá-la e o outro, esquentá-la. Para isso, eles revezavam dois papéis, onde um jogava um segundo dado enquanto o outro posicionava um terceiro dado de certa maneira, oculto do primeiro jogador, que poderia então optar por jogar seu dado novamente ou não. O resultado da rodada dependia da soma dos dois valores, o que introduzia um fator de “blefe” ao jogo. Acabou não sendo lá muito divertido, mas é incrível o que descobrimos ser possível conseguir com um conjunto tão restrito de interfaces a serem trabalhadas.

Nossas ferramentas: dados coloridos (com faces opcionalmente cobertas por fita amarela para ajudar a visualizá-los de um jeito diferente)

O segundo dia exigiu o desenvolvimento de um jogo de cartas. Fácil, certo? Exceto que, além de ainda existirem restrições conceituais, cada grupo só poderia utilizar um certo subconjunto do baralho (uma outra discussão é se isso foi feito porque o Guilherme só tinha dois baralhos, mas deixa pra lá). Bom, nós só tínhamos à nossa disposição as figuras de um baralho, ou seja, 4 valetes, 4 damas, 4 reis e 2 coringas. E o tema do jogo era “música”. Resultado: cada jogador (até 3) começa com 3 cartas na mão. O restante é um monte de compra. O objetivo é ter um valete, uma dama e um rei da mesma cor na mão. Para isso, em cada rodada um jogador pode comprar uma carta do monte e jogar outra de volta para ele, ou pegar (às cegas) uma carta da mão de outro jogador e permitir que ele faça o mesmo para manter a quantidade de cartas em amas as mãos. Os coringas, neste caso, só atrapalham.

“Mas onde está a música?”, eu ouço você perguntar. Pois então, a música está em que, no começo do jogo e após cada jogada, o jogador deverá cantar sua prediominância. A predominância é definida como a carta que mais aparece na mão do jogador (ou, caso ele tenha três figuras diferentes que não sejam da mesma cor, a carta de cor diferente). Como, naturalmente, reis são barítonos, valetes são tenores, e damas são sopranos, a definição de “cantar” nesse contexto é pronunciar uma nota “mí” no tom correspondente a cada tipo de carta: respectivamente, baixo, médio e agudo. Os coringas neste momento podem ser considerados como qualquer carta, possibilitando a manipulação da predominância divulgada. Além disso, quando tiver uma mão vencedora, o jogador deverá abaixar suas cartas para a mesa, cantando “Ó-PERÁ!”, se suas cartas forem pretas, ou “FÍ-GARO!”, se forem vermelhas.

Uma regra que foi desenvolvida para jogos mais emocionantes, e pouco recomendada para aqueles que possues restrições médicas contra fortes emoções, é a “morte súbita”: se entre o momento que um jogador começou a cantar a palavra da vitória e o momento em que suas cartas tocam a mesa, outro jogador o acertar (sim, fisicamente!) com uma carta de coringa, o jogador não mais é vencedor; ele é obrigado a pegar o coringa para sua mão, e o jogador que arremesou o coringa toma uma carta da mão do ex-vencedor para sua própria. Acabou que esta regra se tornou a mais divertida, gerando toda uma mecânica de blefe no final da partida.

Três jogadores experientes de "Ó-PERÁ!". O uniforme oficial para se jogar é camisa branca e calça jeans. Como foi um jogo desenvolvido na FGV, você não pode jogar de bermuda.

Por último, mas não menos importante: o jogo eletrônico! Kibando a descrição do nosso jogo do blog oficial…

Darwincraft: percorra as cavernas misteriosas em um carrinho de mineração, evoluindo e involuindo  mineradores, cujo trabalho em conjunto é a forma de avançar. Um jogo de ritmo, transporte e evolução.”

E o tema era gangorra. Em detalhes: você (sozinho ou com a ajuda de um amigo) controla um carrinho de mineração, daqueles que mexe uma alavanca-gangorra pra andar no trilho, populado inicialmente por dois macaquinhos simpáticos. Pontos são ganhos caminhando para frente, em uma mina aparentemente infinita. Porém, macacos se cansam rápido e gastam um pouco de energia a cada vez que movem o carrinho; para resolver este problema, eles devem pegar as bananas que caem do teto regularmente. Além disso, ocasionalmente apareceriam algumas caixas no caminho, que o jogador poderia escolher pegar, ou não, e colocar no seu carrinho-reboque. Uma caixa faz com que seus pontos aumentem mais rapidamente e que seus macaquinhos evoluam! Primeiro para homens das cavernas, e depois para homens modernos. Porém, homens evoluídos destruíram o meio ambiente (apesar de ainda gostarem de banana), fazendo com que caiam menos bananas quanto mais evoluído você está; por isso a qualquer momento o jogador pode optar por involuir seus personagens, com uma penalidade no total de pontos atual. Se sua energia termina e você fica estagnado no meio do percurso, você perde.

Para este projeto nosso grupo aumentou de 3 para 5 pessoas. Ainda assim, eu era o único programador. Como eu tenho um sistema de prioridades meio descalibrado, passei quase a quinta-feira inteira desenvolvendo o código que faria a pista infinita aleatória funcionar, e boa parte do resto do gameplay teve que ser adicionado no dia seguinte. Para piorar, eu não consegui ir no dia da definição das regras, então cheguei lá na sexta ainda sem saber de alguns detalhes. O lado da arte também não tinha andado muito na véspera, o que deixou o resto do grupo ocupado cuidando disso. Resultado: graças em parte aos gráficos-padrão do Game Maker, as bananas viraram bolhas de corações, as caixas viraram bolhas de energia (que passaram também a cair do teto), e a idéia do carrinho-reboque foi pro espaço. Mas hey, a mecânica do jogo funciona (e o efeito da evolução/involução ficou até bem legal)!

DarwinCraft: porque tudo que tem "Craft" no nome dá certo.

Para quem quiser jogar: link aqui. Desculpem o tamanho (17MB), mas é o que acontece quando você não pode usar o comando “rotate sprite” (que só tem no Game Maker Pro) e manda ele gerar 36 rotações de todas as sprites na mão =P

Controles: A e Z movem o personagem da esquerda para cima e para baixo, respectivamente, e as setas direcionais para cima e para baixo fazem o equivalente com o da direita. Para que um impulso seja dado de fato no carrinho, é preciso que ambos os personagens se movam ao mesmo tempo de acordo com a posição atual da gangorra.

Finalizando, conclusões gerais sobre o evento: é realmente muito interessante e abre sua cabeça pra um monte de coisas principalmente na área de Game Design. Além disso, treina artistas e programadores não só a trabalharem rápido, mas também a aprenderem a se comunicar e colaborar com eficiência em prol de um objetivo comum a curtíssimo prazo. Vale muito a pena para quem gosta disso, seja designer, artista, ou programador, e é sempre muito legal conheer gente nova (ou reencontrar amigos antigos).

Outras conclusões paralelas: a promoção de duas pizzas pelo preço de uma na terça-feira do Domino’s realmente vale a pena, e é REALMENTE impossível estacionar em botafogo durante a semana pela manhã.

· · · ·

O que torna um jogo viciante? São os gráficos de última geração, a inteligência artificial realista, a engine de física fazendo ragdolls voando por aí…? A resposta, se você é um jogador, é óbvia: a diversão. E por incrível que pareça, muitos desenvolvedores se esquecem desse fator – apesar de que, com o crescimento dos orçamentos e a especialização do mercado, é difícil alguém não se dar conta que um jogo não é divertido antes de ser tarde demais.

Felizmente, coisas desse tipo (quase) não acontecem mais.

Felizmente, coisas como essa (quase) não acontecem mais.

Mas e os inexperientes? Que atire a primeira pedra quem nunca pensou numa idéia de jogo e, quando foi ver, não era tão legal quanto soava na sua cabeça. Então, ó interwebs, surge a pergunta: comofas?

Alguns casos de sucesso

Imagino que todos já tenham ouvido falar do World of Goo, jogo indie que fez o maior sucesso. Mas vocês sabem daonde ele saiu? Apresento-lhes o Tower of Goo.

Um dia um grupo de estudantes da Carnegie Mellon’s Entertainment Tech Center resolveu propor o seguinte: e se nós passássemos o semestre inteiro desenvolvendo jogos com tempo de desenvolvimento de uma semana? E foi o que eles fizeram. Seria escolhido um tema a cada semana, e os jogos teriam de ser desenvolvidos em cima disso, em 7 dias, por uma pessoa. Ao final dessa semana, eles iriam comparar os jogos e trocar conhecimentos. E um desses jogos foi o Tower of Goo, que ganhou sucesso, e acabou dando origem ao World of Goo.

Outro que vocês também devem conhecer é o SPORE. Bolado pelo Will Wright (que se vocês não sabem quem é, deveriam se envergonhar e clicar no nome dele pra ler o artigo da Wikipedia antes de terminar esse aqui), ele engloba vários estágios diferentes na evolução de uma espécie: você começa como célula, vira uma criatura, monta uma civilização e acaba conquistando o espaço. E tudo isso com um mundo vivo onde há interações entre espécies nesses diferentes estágios.

Finalmente, temos o Portal. Baseado na engine do Half Life 2, você usa uma arma que atira portais que “grudam” nas paredes, teto e chão dos níveis; usando isso pra resolver puzzles com os objetos ou com o próprio ambiente.

E o que todos esses jogos têm em comum?
Todos eles foram sucesso de crítica, de venda, e de público? Não só isso. Eles também fizeram uso grande da prototipagem. E uma coisa está intimamente ligada à outra.


Prototipagem, a – insira tagline heróica aqui –

A prototype is an original type, form, or instance of something serving as a typical example, basis, or standard for other things of the same category. The word derives from the Greek πρωτότυπον (prototypon), “archetype, original”, neutral of πρωτότυπος (prototypos), “original, primitive”, from πρώτος (protos), “first” + τύπος (typos), “impression[1][2].”

A idéia toda da prototipagem é fazer uma prova de conceito do seu gameplay. Verificar se, tirando toda a roupagem, ele ainda tem o principal: diversão. Não são os shaders 7.0 em DirectX 15, é a sensação boa que você tem quando repete a mesma coisa durante horas e, mesmo assim, não se cansa disso em anos.

Diablo II, da Blizzard. Criou calos no indicador de uma geração inteira e é reconhecido cientificamente como uma das primeiras formas de crack digital.

Diablo II, da Blizzard. Criou calos no indicador de uma geração inteira e é reconhecido cientificamente como uma das primeiras formas de crack digital.

Então, se você tem uma idéia que gostaria de desenvolver, em qualquer nível que ela esteja, pense no seguinte: o que é o núcleo de diversão do meu jogo? Depois de delinear isso (e lembre-se: é só o básico do básico, o que o jogador de fato ficará fazendo ao longo do gameplay), faça uma análise pensando se só isso é o suficiente para manter seu público entretido. Às vezes, ao cortar bastante da idéia, vemos que não temos uma boa premissa de design, e sim um conjunto de features.

Vamos olhar o caso do Portal, por exemplo. A sua história é menos conhecida que a do World of Goo, inclusive: um grupo de estudantes do Digipen Institute of Technology fizeram um projeto chamado “Narbacular Drop”, que envolvia uma princesa presa por um demônio e precisava escapar de uma caverna. Mas essa caverna era “viva”, e tinha o poder de criar portais a pedido da princesa. Assim, o jogador tinha que resolver puzzles abrindo e fechando portais e usando a física como ferramenta. E como eles tiveram certeza de que o jogo pegaria? Eles fizeram um protótipo.

“Nossa, então eles gastaram meses desenvolvendo a engine 3d e o sistema de portais antes mesmo de começar a programar o jogo de fato?”

Não. O protótipo era uma simples sala 2d, com uma caixa e uma pequena plataforma, onde você atira bolinhas e essas, quando se interceptam com as paredes, criam elipses que representam os portais. E isso provou o conceito do gameplay do jogo, abrindo caminho para sua implementação completa – e posterior contratação do time inteiro pela Valve para criar o Portal como conhecemos. Você pode inclusive ainda baixá-lo AQUI.

narbac_prototype

A finalização desse artigo foi atrasada em 20 minutos por causa dessa joça.

Normalmente, com idéias inovadoras, é preciso muitos ajustes antes de se ter algo que valha a pena implementar de fato. Chegamos aí ao exemplo do SPORE, que é um dos jogos mais complexos até hoje, se não o mais complexo. Não só porque envolve diversas formas de gameplay, mas também porque utiliza grandes quantidades de conteúdo procedural, simulações de vida artificial e de física. Assim, todos os sistemas foram primeiro prototipados e foi garantido que eles funcionavam bem por si mesmos. E o mais legal é que todos eles foram disponibilizados online. Mesmo que não haja código fonte, é uma excelente fonte de inspiração.

Ok, então imagino que por agora eu já tenha convencido vocês da importância de prototipar antes de colocar o desenvolvimento a todo vapor. Então vamos às dicas:

1- Não foque em features

Eu sei, eu sei que aquela idéia que você teve de colocar a possibilidade de controlar a sua versão de Super Mario com uma tábua de WiiFit e uma torradeira USB é genial… mas isso não define o seu gameplay. Corte qualquer coisa que o seu jogador não vá fazer 80% do tempo e pense nisso depois. Veja o que é o verdadeiro núcleo do gameplay do seu jogo e teste se isso funciona. Lembre-se do princípio do KISS: Keep It Simple, Stupid!

Leitura extra que serve pra qualquer área da TI: “The Number One Reason my Startup Failed

2- Os feios também amam

Apesar dos pesares, isso é um protótipo. É pra ser simples e ser feito rápido. Você não quer gastar semanas desenvolvendo ele, e sim gastar o mínimo de tempo possível. Você não vai precisar de gráficos rebuscados ou de código super otimizado pra testar o seu conceito. Inclusive, eu diria até que, se for muito feio, cheio de bugs, e mesmo assim gostarem e voltarem pra mais, é porque você está na direção correta.

3- Ninguém vai olhar embaixo do tapete (aka: gambiarra não é pecado)

Intrinsicamente ligado com o ponto anterior. Você não precisa de animações calculadas proceduralmente, nem de engines de física para bater uma bolinha na parede. Qualquer coisa serve, desde que mostre exatamente o que você quer mostrar, mesmo que não FAÇA de verdade o que teria de ser feito. Não perca muito tempo pensando em como você vai otimizar o código e baixar a utilização da memória, só faça rodar o que o seu jogo tem que fazer. Obviamente, se alguma parte do seu código for reutilizada posteriormente, faça-o de maneira limpa e (well, duh) reutilizável.

4- You can’t polish a thurd

É isso. Às vezes você vai ter uma idéia, se apaixonar por ela, tratá-la a pão de ló, fazer de tudo que puder. Mas ela vai continuar sendo meia boca. Saiba quando desistir, ouça a opinião dos outros. Se você forçar demais, vai perder tempo que poderia estar usando em outro projeto.

O blog só foi criado e o projeto quis tomar forma porque nós já temos um protótipo e, apesar dele ter sido construído com 2 formas geométricas e 4 cores, ainda dá vontade de jogar. E se tudo der certo, no fim dessa série de posts, vamos disponibilizar pra vocês também testarem e enviarem sugestões.

Links complementares:

1- Postmortem dos projetos do Carnegie Mellon que deram origem ao World of Goo (e inspiraram grande parte desse artigo)
http://www.gamasutra.com/features/20051026/gabler_01.shtml

2-Site de downloads do Narbacular Drop, com o protótipo e vários outros documentos formais de desenvolvimento
https://www.digipen.edu/fileadmin/website_data/gallery/game_websites/NarbacularDrop/

·

Theme Design by devolux.nh2.me