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! ^^"

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.

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

É 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!

Cliente/Servidor, Fundamentos, Multiplayer

Vocês estão seguindo a gente no Twitter? Por lá que eu mando as coisas que não tem post por aqui. No caso, vou precisar de mais de 140 caracteres, então cá estamos enquanto a 2a parte dos Fundamentos deVoid() não sai.

Hoje eu finalmente tive tempo pra pegar e jogar o Braid melhor (depois de comprar na última promoção do Steam). Como o mundo 4 me deu nos nervos, decidi ir procurar sobre o desenvolvimento do jogo por aí. Encontrei alguns links legais no blog oficial e vim compartilhar:

1. Protótipos de jogos do Jonathan Blow – alguns dos outros jogos que ele bolou mas não chegaram a ir pra frente’;
2. Braid Graphics Briefcase – vários assets gráficos do jogo na página do artista;
3. The Art of Braid- uma série de posts no blog do artista do jogo que explica a evolução da arte do jogo. Vai até o número 9, é só mudar o número no link;
4. Understanding Games – uma série de mini-jogos explicando os fundamentos de “o que é um jogo”. É o básico que a maioria das pessoas não sabe, então recomendo fortemente;
5. The Independent Gaming Source’s (Opinionated) Guide to Indie Games – o nome já diz tudo, pra quando você não tiver mais o que fuçar na internet.

Tem outros bits ‘n’ pieces espalhados por lá que são interessantes, mas esses são os que eu achei mais importantes de compartilhar.

Braid, Clipping, Game Art, Resources

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 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.

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.

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/

Fundamentos, Prototipagem

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!

Fundamentos, Key Post, Preview

Meu irmão, que tá no mercado de TI desde que apareceu Internet comercial por aqui, me indicou isso aqui, que se aplica pra qualquer profissão, mas principalmente pra carreiras mais “fora do padrão” como desenvolvimento de jogos:

Clique na imagem para versão aumentada.

Tatuem isso na testa, pessoal. Espero que o blog retrate a jornada pela interseção dos 3 =)

De quebra, pra quem trabalha com qualquer área de TI, eu recomendo fortemente o blog do mundo.IT e a rede social do mundo.IT (especialmente a rede, já que o blog desacelerou a quantidade de postagens porque elas foram “migradas” pra rede)!

Em busca do Hoorray!, Graphs, Motivacional, Profissão

Tenho pensado ultimamente sobre o primeiro post “de verdade” do blog, e cheguei à conclusão que não poderia ter algo mais importante e primordial pro pitch do blog do que falar sobre os jogos independentes.

Pra mim é natural aceitar a idéia de que a tecnologia vem em “ondas”: um sistema se estabelece, tem seu auge, decai  e, enquanto isso, outro surge pra tomar o seu lugar. Como estamos tratando do desenvolvimento de jogos aqui, ficamos inevitavelmente ligados aos ciclos do hardware. E aí que entra uma coisa diferente no mercado dos videogames: estamos pegando outra curva enquanto uma ainda não decaiu.

Explico. Os jogos eletrônicos se tornaram uma indústria bilionária na minha geração, então, desde bem moleque, eu pude observar a “curva de subida” do ciclo até a chegarmos na situação atual. E não diria que estamos no auge, já que pra definir um “auge”, temos que estar num processo de declínio, e não é o que acontece, vide os ciclos de vida de uma década planejados pro Xbox360 e Playstation3.

Hoje em dia, existe a definição de “AAA Titles”: são os jogos de grande porte, orçamentos milionários e qualidade superior. Espera, qualidade superior? Quem define a “qualidade” de um jogo? Como forma de entretenimento, os videogames estão chegando ao nível de filmes, para o bem e para o mal. Você pode ter um pipocão com orçamento de 150 milhões de dólares…. que é uma bela porcaria. Muito bonito, muito divertido, trilha sonora épica, mas sem conteúdo, sem história, atuações pífias. E, infelizmente, muitas vezes vindo de gente com história no mercado e de franquias amadas por fans (estou falando com você, George Lucas).

Mostrado: Wolfenstein, 2009, Raven Software. Não mostrado: Inovação no gameplay.

Voltando às curvas: os jogos começaram como uma indústria essencialmente independente. Muitas das grandes empresas dos anos 90, como a Sierra, ou a iD, ou a Apogee, começaram no quintal da casa de alguém que queria uma coisa: fazer jogos porque GOSTA disso. O nível de programação era baixo, os jogos relativamente simples e o retorno duvidoso. E isso foi o embrião dos behemoths atuais . Deu certo porque era bom, as pessoas gostavam e se divertiam com eles. Essa foi a primeira subida de curva: “qualquer um”, com talento e uma boa idéia, podia entrar no mercado.

Então, no fim dos anos 90 e início nos anos 2000, começou a coisa dos AAAs. E aí? Como se fazia pra entrar no jogo? A indústria já estava “adulta” e milhares de sonhadores estavam de fora. Obviamente havia contratações, mas o nível de conhecimento necessário era imensamente maior. Lá fora existem cursos universitários voltados para game design, game art e tudo mais, mas grande parte do conhecimento ainda tem que ser feito “por fora”. E uma vantagem da indústria dos jogos é que, se você é REALMENTE talentoso em alguma coisa, tem grandes chances de arrumar um emprego, independentemente de graduação formal. A VALVE, por exemplo, sempre prestou atenção na cena de MODs, vide a “oficialização” do Counter-Strike e a tomada da franquia do Team Fortress (que pra quem não sabe, foi um MOD de Quake).

Mas o que aconteceu, afinal? Duas coisas, em paralelo: uma relacionada a hardware e outra relacionada à própria indústria.

Na parte do hardware, tivemos o advento do mobile. Jogos para celular e dispositivos móveis se tornaram um novo nicho de mercado, que era similar ao início da “curva original” dos anos 80 e 90: o hardware era pouco poderoso, era necessário mais cuidado pra programar etc. E o melhor de tudo: poucas pessoas podiam fazer um jogo legal, que venderia barato, mas poderia ser o suficiente pra manter uma pequena empresa rodando, e o principal: ganhar experiência. O ponto que estamos agora já é mais avançado, onde já existe investimento de empresas grandes mas, ainda assim, é possível começar do zero.

Assassin's Creed para iPhone

A grande mudança na indústria é que, com a saturação dos arquétipos de gameplay em jogos AAA, as pessoas começaram a prestar mais atenção nos jogos pequenos, divertidos, e com alto replayability. Sucessos como o World of Goo, ou Plants Versus Zombies, ou até aqueles jogos de flash impressionantemente simples e divertidos se tornaram algo que as grandes empresas estão de olho hoje em dia. E o que esses têm em comum com os jogos de celular? Grupos pequenos de desenvolvimento, bolando coisas novas (ou só visões novas de coisas antigas, vide Braid) e deixando você mais grudado na tela do que o último jogo de orçamento gigante que você comprou por R$100,00 com desconto no Steam.

Mas afinal, pra que o post gigante? Pra dizer que “yes, you can!“. Obviamente todo mundo tem o sonho de fazer um jogo gigante, cheio de detalhes e que seria a coisa mais legal do mundo de jogar. Aí você pára, analisa o mercado e ve que hey, o desafio REAL tá em criar algo simples, que as pessoas queiram de fato jogar over and over again e que você desenvolveu com o seu vizinho e seu primo. E se você fizer ISSO dar certo (em matéria comercial e/ou de notoriedade na “cena”), e conseguir repetir o feito mais de uma vez, talvez seja realmente pra isso que você nasceu.

Go indie. We’re going, you should too

PS: grande parte da idéia do blog é interagir com quem lê. Então por favor, compartilhem suas idéias sobre isso (e sobre os futuros posts) com a gente nos comentários!

Indie Games, Key Post

Um blog sobre a indústria, arte e ciência dos games. Rants, análises, tutoriais, o que aparecer e der tempo de fazer update. E, se tudo der certo, lar do devBlog de futuros bons projetos

Hello World