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

CAT | Fundamentos

 

Paramos de fazer trocadilhos com "devoid", mas jamais pararemos com trocadilhos!

Paramos de fazer trocadilhos com "devoid", mas jamais pararemos com trocadilhos!

Assim como os trabalhos que eu já pus por aqui, nós decidimos colocar nosso Projeto Final de curso (ou TCC, para quem é de TCC) disponível para vocês baixarem/lerem/citarem/verem screenshots antigos do SumoCheckers. E assim como várias outras coisas, esquecemos de postar!

Como acabamos de lembrar, você agora pode baixá-lo aqui, com um nome de arquivo gigantesco para compensar o nome pequeno do trabalho em si:

Download: Dystopia e Sumocheckers

O foco é na implementação e na relação entre game design e limitações técnicas – então talvez sirva pra quem não é de computação também. No mais, é sempre bom ter artigos em português pra citar (nós sofremos com isso na época!)

Quaisquer dúvidas e comentários, falem comigo ou com o Tinnus no twitter, ou comentem aqui mesmo no post!

, , , , , , , , ,

Howdy!

Primeiramente, bem vindos ao novo site da deVoid deV( )id – contando com um domínio próprio e um jeito muito mais estaile de se escrever o nome!

Essa mudança toda é um dos motivos pelo nosso sumiço. Esperamos que vocês gostem! O site novo ainda está em alpha, se notarem qualquer coisa de errado e/ou tiverem sugestões pro tema, podem mandar pra gente! Ainda estamos configurando o servidor, então mandem por comment, mas assim que tudo estiver certo vamos divulgar os novos e-mails de contato.

Fechando o arco dos Fundamentos deVoid, venho falar (finalmente) sobre “o que diabos vocês estão fazendo aí?”. Vou propor uma adivinhação. Eu dou uma dica e você tenta descobrir.

"Adivinhações? Eu adoro adivinhações!"

"Adivinhações? Eu adoro adivinhações!"

Envolve damas e cavalheiros enormes de gordos usando nada além de fraldas.

"...o quê?"

"..."

Calma, já vamos chegar lá.

1- A idéia Inicial

Há muito tempo atrás, eu e o Tinnus estávamos num período de ócio criativo pra projetos no laboratório que fazíamos iniciação científica na faculdade. Na época, muita gente por lá jogava Tactics Arena, um joguinho por turnos em que você tinha diversos personagens num tabuleiro, cada um de uma classe, com atributos e habilidades diferentes. Era meio que um “xadrez” em cima disso.

Só que tinha um problema: era muito parado. O pessoal que fugia das aulas jogava pra matar o tempo, mas pouca gente ia pra casa pensando “vou jogar isso quando chegar!”. E aí me bateu uma idéia: e se em vez de as batalhas funcionarem por turnos, elas fossem em tempo real? Assim, quando um personagem fosse atacar o outro, passaria pra uma batalha com controle direto do jogador.

Só precisou desse estalo pra uma semana depois eu ter um documento de 20 páginas descrevendo a história de um mundo que misturava George Orwell com Steampunk. Cada personagem do jogo teria classes, skills, os mapas seriam personalizáveis, você teria que recolher recursos durante as batalhas pra poder criar unidades fora delas e aumentar seu exército… isso tudo e dezenas de outras idéias de gameplay.

Pra quem já leu o about, viu que eu juro que não existem idéias megalomaníacas demais. E eu juro mesmo. Existe é dinheiro e experiência de menos :D

2- Dois caras

Era isso que nós éramos. Dois caras precisando bolar uma coisa pra fazer na iniciação científica. E com experiência (quase) nula em qualquer projeto de grande porte. Precisávamos de algo simples pra começar, mas não vinha nada à cabeça. Até que um dia o Tinnus teve um estalo também: por que não ao invés de cenários mirabolantes e grids personalizáveis, um campo de 8×8? E ao invés de diversas classes, só duas, pra começar?

Te lembra alguma coisa?

Checkers

"Damas!"

Sim, damas! O jogo é um tabuleiro simples, as regras são poucas e, se você parar pra pensar, tem dois “tiers” de personagem: a peça normal e a dama, com a incrível capacidade de… andar pra trás.

“Damas? Foi isso que vocês fizeram? Mas e as batalhas emocionantes em tempo real?”

A-ha! Aí veio a segunda idéia do Tinnus: quando ele era mais novo, jogava um joguinho (que pela segurança da imagem pública dele eu não revelarei aqui) que, basicamente, consistia em bolinhas se empurrando pra fora de um ringue. E, segundo ele, era realmente muito divertido, apesar de simples.

A questão é: nós tínhamos uma idéia muito legal, gigantesca, mas não implementável. O que nós fizemos? Olhamos a coisa de fora e fizemos um sub-set do que a gente queria fazer. E voilá, tínhamos um protótipo daquilo tudo que, se feito da maneira correta, poderia ir sendo expandido até chegar na idéia final.

3- SumoCheckers

Entenderam agora? É um joguinho de damas em que, quando uma peça vai comer a outra, as duas entram num ringue e uma tem que empurrar a outra pra fora dele. Lembram do que eu disse no primeiro fundamento? Tínhamos o core do gameplay. Não tem mais o que tirar. Se isso for divertido, dá pra se fazer um jogo em cima.

E qual não foi a nossa surpresa ao ver que quando nós executávamos um jogo que tinha essa cara:

profanidades eram jogadas pra todos os lados, contando até com gente se mexendo na cadeira pra tentar executar uma manobra. E você sabe que quando tem xingamentos e movimentos corporais involuntários envolvidos, a coisa deve estar dando certo!

E o que aconteceu? Apresentamos o projeto de inciação científica (focando na pesquisa de implementação do framework e da inteligência artificial, obviamente, já que falar pra Academia© que você está fazendo um joguinho é a mesma coisa que falar pra sua vó no jantar de família que você está namorando o Jorjão) e… o pobre SumoCheckers ficou enterrado por outras obrigações com o laboratório.

Até que um belo dia, nossa bolsa acabou. E aí bateu a idéia de terminar o jogo e ver no que dá. Afinal de contas ninguém arruma emprego de gamedev sem portfolio ;)

4- Where do we go now?

Bom, mesmo sendo um projeto simples, o trabalho é enorme. Esse blog é parte dos passos pra se criar sinergia e sair da inércia do “por onde começar?”. Já tínhamos a idéia na cabeça e o protótipo na mão. E daí?

A primeira coisa que tínhamos que fazer era pôr o jogo à prova: será que ele seria divertido pra alguém além de nós dois? E bom, por mais que a pessoa tenha boa vontade e entenda que num protótipo o gráfico é o de menos, seria difícil manter alguém atraído o suficiente pra jogar uma partida inteira. Então o primeiro passo foi dar uma nova roupagem à coisa toda. Fomos disso:

scOld2pra isso:
ssNewProtoSS1ssNewProtoSS2ssNewProtoSS3
Sim, os gráficos não são nada demais e foram feitos em um dia, mas as pessoas já dizem “ahhh que legal que tá agora, tem bonequinhos!”. Acredite em mim, em matéria de playtest com gente de fora do projeto, é um mundo de diferença.

Quais os próximos passos? Estamos marcando playtests com algumas pessoas e vamos assistir (em silêncio total e absoluto) e fazer anotações. isso vai ser feito pra comparar as coisas que nós SABEMOS que têm de ser melhoradas com as coisas que vão nos sugerir. E principalmente: vamos ter feedback sobre coisas que temos dúvidas de como proceder. Sabemos que muitas coisas vão bater, e isso é bom, pois é sinal de que estamos na direção certa. Mas o importante mesmo é saber ouvir os detalhes: às vezes a pessoa quer uma coisa e não sabe expressar direito, e você tem que se manter imparcial pra pegar as sutilezas. Vamos começar com um grupo pequeno e de pessoas próximas e, ao longo do tempo, vamos expandindo, sempe colhendo dados pra nos guiar melhor.

Depois desses playtests, vamos ter um conjunto de coisas que as pessoas gostariam, e um conjunto de coisas que nós gostaríamos. E daí vamos definir prioridades pro que precisa ser implementado, o que não precisa, mas seria legal, as coisas que temos que evitar etc. E a partir dessas listas, vamos traçando os milestones pro projeto.

Nosso prazo final? Ainda não definido. Mas é fato que teremos alguma coisa pra mostrar no próximo SBGames – e quem sabe, mais pra frente, não façamos uma submissão pro IGF também.

5- O que VOCÊ pode tirar disso?

  1. Não tem problema ter uma idéia megalomaníaca de jogo. Mas você nunca vai ver ele pronto, a não ser que tenha um orçamento e/ou um time grande. Se você tiver uma idéia que julgue muito legal, mas grande demais, procure um sub-set básico dela – do tamanho que caiba num protótipo;
  2. Faça um protótipo. Teste até o talo. Recolha dados. Jogue ele fora – a não ser que você tenha tido o trabalho de fazer as coisas reutilizáveis;
  3. Recolha dados sobre quem está jogando o seu jogo e compare com as reações deles. Às vezes mostrar o seu FPS pra 10 jogadores de estratégia e eles gostarem significa mais do que mostrar o seu FPS pra 200 jogadores de FPS e metade deles achar legal;
  4. Sempre tenha na cabeça que, às vezes, o que pra você é genial, não funciona pra maioria das pessoas. Então teste, compare opiniões, tenha sempre o ouvido aberto aos outros. Afinal de contas, eles vão ser os jogadores. E o mais importante: não fique chateado se a sua idéia for ruim. Outras virão;
  5. Quando tudo mais estiver pronto, trace uma meta final. A partir dela, trace metas menores e vá trabalhando em cima delas, tendo certeza que elas estão convergindo pra meta final. Muita gente tem falado de usar SCRUM pra desenvolvimento de jogos e me parece interessante. Nós vamos tentar coisa do tipo – e manteremos vocês informados ao longo da viagem;
  6. GET YOUR LAZY ASS UP AND WORK!!!!

Assim chega ao fim o nosso ciclo de posts fundamentais. Em breve precisaremos de testers, então os interessados entrem em contato! Continuem nos seguindo no twitter, que lá vai ser sempre um bocado mais movimentado que aqui – mas assinem o nosso RSS, porque sempre colocaremos artigos, opiniões, tutoriais e, obviamente, updates sobre o nosso projeto!

Links adicionais:

, , , , ,

Então, estou aqui hoje para falar sobre a terceira parte dos Fundamentos deVoid(): o framework que estamos desenvolvendo para usar como base em nossos projetos, e também um pouco sobre frameworks em geral e por que eles são uma Boa Idéia.

A idéia por trás de um framework (no contexto de programação) consiste basicamente em ter uma biblioteca (ou, como eu gosto de falar, um “bando”) de código com funcionalidade reutilizável, escrito de forma modular e que possa ser plugado facilmente em “todos” os casos que você precisar de tal funcionalidade. Alguns frameworks (como o nosso) são arquitetados como várias “peças” que podem ser utilizadas, ou não, de acordo com as necessidades de seu projeto (e também são feitas para funcionar em conjunto, é claro); em outros casos, o framework é fixo e o programador deve adequar seu projeto a funcionar com ele da maneira que é esperada. Pessoal que trabalha com Java e/ou fazendo sistemas por aí deve estar acostumado com esse tipo de coisa.

A diferença, é claro, é que no nosso caso a coisa é muito mais divertida.

É fácil perceber que no caso de jogos eletrônicos, muito é reutilizável. Mesmo sem saber a fundo como os jogos são feitos, não demora a perceber, por exemplo, que Sonic e Mario (na era 16-bit) não são tão diferentes assim (exceto pelos jogos do Sonic serem melhores e mais bem feitos, evidentemente). Neste caso, estamos observando um paralelismo de gênero. Os dois jogos são do gênero de plataforma, onde o objetivo (resumindo) é sair pulando por aí atravessando obtáculos e chegar no extremo direito da fase (apesar de que o caminho em algumas fases dos Sonic’s é bem mais interessante e desafiador que isso).

sonic-mario

Correr, pular, esmagar inimigos, a fórmula é a mesma. Não importa se você é um ouriço azul ou um encanador bigodudo.

Tradicionalmente, para explorar este paralelismo de gênero, os desenvolvedores criam engines. De maneira geral, todo jogo é criado em cima de uma engine: o código base que faz o jogo funcionar e define o núcleo de sua mecânica; somando a engine com o conteúdo tem-se pois, um jogo. No caso do Sonic, cada novo jogo da série utilizava uma nova versão da engine desenvolvida ao longo dos anteriores, o que certamente economizou bastante no custo do desenvolvimento.

Vindo mais para perto, o conceito de engine se tornou mais conhecido para o público em geral com os jogos “modáveis”. A idéia por trás de um jogo deste tipo é que o acoplamento entre a engine e o conteúdo é bem definido e é fácil modificar o jogo apenas alterando conteúdo e sem precisar tocar no código da engine (parte do conteúdo que define o jogo pode ser composto de scripts, mas isto é outra história). Obviamente, o caso mais conhecido de mod que se tornou famoso é o Counter-Strike, que é uma modificação (e roda na exata mesma engine) do Half-Life. Novamente, é explorada a idéia de reutilizar a engine para um jogo do mesmo estilo, neste caso, de tiro em primeira pessoa (FPS).

A jogabilidade é praticamente a mesma, mas são os pequenos detalhes no conteúdo que fazem a diferença.

A jogabilidade é praticamente a mesma, mas são os pequenos detalhes no conteúdo que fazem a diferença.

Finalmente, voltando ao nosso caso, o que estamos fazendo no momento não é uma engine porque não contém lógica de jogabilidade, quer dizer, não contém nada que define como um jogo funciona. O objetivo com este framework é criar uma série de ferramentas para serem utilizadas na construção de uma engine. Ou seja, estamos explorando a reutilização de código em um nível mais baixo e explorando o que eu chamo de paralelismo de funcionalidade. Em outras palavras, reutilizamos partes do framework para criar engines, e reutilizamos engines para criar jogos. Isto funciona porque mesmo dentre engines completamente diferentes, digamos, a do Sonic e a do Half-Life, várias funcionalidades de mais baixo nível são as mesmas, citando-se:

  • Leitura de entrada (teclado, mouse, joystick)
  • Comunicação em rede / arquitetura cliente/servidor
  • Máquinas de estados
  • Controle de fluxo de execução
  • Controle do dispositivo gráfico e exibição de imagens na tela (2D ou 3D)
  • Controle do dispositivo de áudio e execução de sons/música
  • Inteligência Artificial (buscas, lógica, redes neurais etc)
  • Mecanismo de scripting

Observando estes itens, percebe-se que a idéia de reutilizá-los (ou a própria necessidade de suas existências) não é trivial ao usuário comum como no caso das engines: é mais uma separação explorada pelo desenvolvedor para facilitar seu trabalho, e como facilita! Como eu disse lá em cima, qualquer desenvolvedor sabe que tarefas de baixo nível devem ser implementadas apenas uma vez, “não reinventar a roda”, e assim por diante. E isso vale desde o sistema da padaria da esquina até o mais novo título milionário da EA ou da Ubisoft :)

Por último, vale lembrar que durante o desenvolvimento destas três camadas–framework, engine e jogo–a necessidade de uma funcionalidade em uma camada mais alta pode fazer com que esta seja implementada em outra mais baixa, assim como a criação de uma funcionalidade numa camada mais baixa pode incitar sua utilização nas camadas mais altas. Em parte pela nossa não-tão-grande experiência e pelo aprendizado em si, é mais ou menos assim que estamos levando o nosso desenvolvimento: começamos pelas idéias, pelos objetivos do projeto e propagamos para as camadas mais baixas estas necessidades.

, ,

Antes tarde do que nunca!

Jogos têm algo muito importante que, apesar de ser em parte meio subjetivo, ainda pode ser medido por características gerais: o Replay Value, ou seja, o quanto as pessoas vão jogar aquele jogo de novo. Existem várias características que podem influenciar isso, como IA avançada, caminhos diferentes a serem tomados, finais diferentes…

Mas no fim das contas, sempre recai no que a gente falou aqui: diversão. Você pode ter uma história genial, gráficos excelentes, mas se a experiência de jogar for igual a várias outras, as pessoas não vão voltar pra mais. Isso acontece porque temos mais prazer ao passar por experiências novas, experimentar gameplays diferentes, cenários diferentes, situações diferentes. E foi aí que apareceram dois grandes caminhos que são, teoricamente, focados no replay value:  jogos “abertos” e jogos multiplayer.

Jogos Abertos

Um jogo aberto talvez até fuja um pouco da definição normal de “jogo”, já que ele não é planejado pra haver um ganhador, e sim pra ser “vivenciado”.  Alguns são “open-ended“, ou “sandbox“: podem ter um objetivo definido, mas existe um mundo a ser explorado e você completa a história só se/quando quiser. Um grande exemplo disso é a série The Sims: você cuida dos seus bonequinhos, compra coisas pra eles e, pra muitas pessoas, mais ainda: projeta seus desejos no mundo virtual. “Nossa, eu sempre quis ter uma casa gigante e uma mesa de bilhar no meu quarto!” – e um klapaucius depois, lá está tudo isso.

"O meu nome vai ser Mindy e eu vou ter um pônei rosa! ^^"

"O meu nome vai ser Mindy e eu vou ter um pônei rosa! ^^"

A idéia é criar várias simulações de situações, ou de personagens, que façam cada “passagem” pelo jogo parecer diferente da outra – mesmo tendo um set finito de acontecimentos possíveis, quanto mais complexo o seu mundo e os seus habitantes, mais chances existem de acontecerem coisas diferentes. E nisso as séries como The Sims, Grand Theft Auto e SPORE se tornaram especialistas.

Jogos Multiplayer

Qualquer coisa que não seja Single-player é multiplayer, ok. Mas na era dos videogames de 16 bits, você só jogava com duas pessoas, e em 99,9% dos casos, ela tinha que estar na mesma sala que você (pra quem não sabe, a SEGA tinha um serviço de multiplayer via modem, onde você podia até baixar jogos).

Quando os PCs se tornaram plataformas mais populares, ficaram mais comuns os jogos que suportavam multiplayer ponto-a-ponto: você ligava com o seu modem diretamente no do seu amigo pela linha telefônica e os dois jogavam remotamente. Só mais à frente, com a popularização da Internet, o multiplayer de vários jogadores se tornou mais viável. E isso aconteceu mais ou menos na época em que os FPSs eram os grandes jogos de sucesso da indústria. E foi aí que perceberam que, mesmo que o seu single player seja algo muito legal, mas que só tenha graça de ser jogado uma vez, se você colocar um multiplayer excelente, isso aumenta o seu replay value – e o valor do seu produto.

Quake, da iD software, foi uma revolução não só nos gráficos, como também na idéia de multiplayer. Fundou a era dos “FPS’s de verdade”, que contou com sucessos como as séries do Unreal e do Half-Life. E o multiplayer dele até hoje é jogado. Lembrando que o jogo vai fazer 14 anos ano que vem, tão antigo que até as suas duas seqüências já tiveram o código fonte liberado.

Minha primeira namorada.

Minha primeira namorada.

E qual a grande sacada disso tudo, do ponto de vista da arquitetura? No Quake, mesmo o jogo Single Player era como se fosse uma conexão a um servidor local. As regras eram diferentes, mas o management de jogadores era o mesmo. E isso é muito importante, porque abre muitas portas, principalmente em relação a código. A grande essência da coisa é: mesmo que os jogadores estejam na mesma máquina, eles são clientes.

Mas eu não preciso fazer isso pro meu jogo, ele é só single player!” – Concordo com você. Se ele não vai ter nenhuma faceta multi-jogador, realmente é completamente fora do escopo. Mas no nosso caso, como não tivemos nenhuma idéia de puzzle genial, não temos um artista genial, e nem uma IA genial (ainda) e muito menos dinheiro pra contratar uma equipe maior (e genial), decidimos fazer crowdsourcing do trabalho duro e colocar a diversão na mão dos jogadores :D

É sério. De preferência bolo.

No nosso framework, tanto os jogadores (locais ou remotos) como a IA são tratados como “clientes”. O código do servidor instancia o núcleo do jogo e espera por conexões. Isso possibilita que todo o código de controle seja o mesmo para todos os tipos de personagem. Assim, o que acontece não é definido pelo tratamento no código do jogo pra cada tipo de entidade, e sim pela reação das entidades ao ambiente (isso envolve filosofia e cartas-na-manga pro futuro, então não é o foco do artigo, mas um dia eu explico).

E quais as outras grandes vantagens dessa abordagem?

  • Os clientes funcionam como “terminais”, ou seja, podem haver mudanças no servidor sem que isso afete o código do cliente, não sendo necessário fazer deploys de versões novas a cada mudança ou ajuste. Isso é essencialmente importante pra fazer fine-tuning da jogabilidade e do balanceamento;
  • O código de jogo é completamente reutilizado no que tange a lógica do mundo. Não existem checagens se o jogo é multiplayer ou não, só é preciso bloquear a entrada de jogadores caso não seja esse o intuito;
  • O servidor é o juiz: somente as checagens básicas do jogo são executadas no cliente, mas as decisões reais de regras acontecem no servidor. Isso permite maior segurança contra cheats. Claro que quando o sevidor está em um cliente, ele pode sofrer algum tipo de modificação, mas a idéia é sempre fazer coisas reutilizáveis – quem sabe até a época em que você arrume grana pra pagar um servidor dedicado.

Nosso primeiro projeto será essencialmente multiplayer. Talvez vá ser adicionado single player no futuro, mas a IA tem que ser melhor estudada antes de ser plugada – como cliente do servidor local ;)

Curiosidade de sobremesa: reza a lenda (contada por ele mesmo) que quem inventou o conceito de jogos pela internet foi o Al Lowe, criador da série Leisure Suit Larry, em 1990. Confira o causo aqui!

, ,

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/

,

Olas!

Estou ainda tentando achar o sweet spot de quantidade de tempo entre postagens aqui, então pros poucos que já acompanham, comentem o que acham a respeito disso =)

O blog, como dito antes, vai servir não só como portal relacionado a notícias e artigos de desenvolvimento de jogos, mas também como devblog do projeto que iremos desenvolver. Por isso, decidi colocar uma pequena série de posts que vão embasar o que vem por aí. Nas próximas semanas, pretendo ter no ar os seguintes posts:

  1. Prototipagem – vai tratar da importância de prototipar uma idéia de jogo antes de começar o desenvolvimento real;
  2. Paradigma Cliente-Servidor – por que é uma boa idéia pensar no seu jogo assim;
  3. O Framework – nós da deVoid() já estamos trabalhando há algum tempo em um framework para facilitar o desenvolvimento de aplicações, vou falar um pouco sobre ele aqui;
  4. O Projeto – finalmente, vou falar de vez qual é o projeto que nós temos em mente e dar mais detalhes a respeito.

A série não deve demorar muito a se completar, com os posts 1 e 4 sendo de fato os mais longos (talvez haja até um merge do 2 e 3). Depois dessa série, nós vamos atualizar sempre com o progresso das nossas reuniões e colocaremos em pauta as nossas decisões de design, passo a passo, para que possa servir tanto pra quem lê aprender um pouco mais, como também pra comentarem e ensinarem pra gente onde estivermos errando. Isso tudo, claro, sem deixar de fazer posts relacionados à indústria.

Stay tuned!

, ,

Busca

Tema baseado no jQ por devolux.org