Howdy!

Há um tempo atrás estava pensando sobre DRM (Digital Rights Management, aquela coisa que só não te irrita se você não paga por jogos há anos), Quality Assurance e desenvolvimento de jogos na pindaíba – e cheguei a uma idéia que talvez seja mais ou menos como usar armas de destruição em massa para acabar com a fome mundial.

Parte 1: Eu nunca joguei Assassin’s Creed II.

Nunca. Eu me COÇO pra jogar, fui louco pelo primeiro, mas não encostei no segundo nem com uma vara de 20 metros de comprimento. Não, nem o pirata. Por que? Porque me recuso a pagar por algo que não posso usar quando quiser. O DRM novo da Ubisoft é simplesmente ERRADO! Você, pra jogar um jogo puramente single-player, precisa estar conectado o tempo inteiro – e se a sua conexão cair ou coisa do tipo, o jogo simplesmente trava. Puf. Onde quer que você esteja. E se o servidor deles cair? É, pois é, você não está com sorte.  Eu ia linkar essa última frase com uma fonte de notícia, mas uma pesquisa inteira do google demonstra melhor.

Quando você vende um produto, a pessoa tem o direito de fazer o que quiser com ele. Vetar a cópia, tudo bem, dá pra entender. Mas se ela não tem nem o direito de utilizar esse produto quando e onde quiser, tem algo de errado. Se fosse um serviço onde estar online fosse realmente necessário (como num MMORPG, por exemplo), as pessoas não se incomodariam porque você não estaria tirando algo dos jogadores: é simplesmente um efeito colateral do valor agregado (jogar com centenas/milhares de pessoas ao mesmo tempo). A Valve, quando lançou o Half-Life², exigia conexão com o Steam para ativar o jogo – o que foi muito mal visto, mas ainda assim, possibilitava ao consumidor jogar offline após essa ativação – e hoje em dia transformou o sistema numa plataforma que de fato INCENTIVA a compra e utilização, porque agrega valor de diversas maneiras.

Quando eu vou jogar? Quando ele estiver bem barato em alguma promoção do Steam.

Parte 2: Assegurando a Qualidade

Tivemos dois casos bem icônicos nos últimos meses: All Points Bulletin da Realtime Worlds e Elemental: War of Magic da Stardock. Os dois casos são tão ruins que eu não sei nem por qual começar…

Ok, RIP RTW. APB era pra ser um MMORPG a la GTA

Ahem… a la GTA. Tinha tudo pra dar certo. O sistema de customização deles era genial, tinha perseguição de carros, batalha entre facções (se soltar pipa foi o primeiro jogo multiplayer, eles eram o polícia e ladrão), um plano inovador de mercado e WHOA! Eles falharam. Tão miseravelmente que a empresa faliu em dois meses depois de lançar o jogo.

O que aconteceu? Bom, tem uma série de posts de um dos desenvolvedores (pt. 1, pt. 2, pt. 3) em que ele explica o que houve. E os dois grandes fatores foram: confiar demais no feedback de um número limitado de jogadores e falta de direção forte na empresa e no design do jogo. O jogo foi lançado com vários bugs, erros e gameplay mal desenvolvido – e a comunidade nos testes fechados estava tão animada em ter entrado no “clubinho do beta” que simplesmente falava “NOSSA O JOGO É MUITO MANEIRO AMIGOS!!!111one” e, quando alguém criticava alguma coisa, sofriam um caso de internet rage e diziam que “É SÓ UM BETA, TÁ LEGAL? É SÓ UM BETA! NÃO GOSTOU, VAI JOGAR OUTRA COISA!!!!11one“.

Infelizmente eles não sabiam (ou não queriam ver) que um beta é pra tratar dos bugs pontuais, não do gameplay não-funcional de um jogo. E aparentemente, os responsáveis pela empresa também não souberam medir bem esse feedback, o que terminou com o fim do jogo e da empresa – cinco anos de desenvolvimento e dezenas de empregos jogados fora.

O outro caso foi o do Elemental: War of Magic. Quando o beta do jogo foi lançado, bom… não era o beta. O jogo foi vendido num estágio em que parecia mais um protótipo do que gostaria de ser do que the real deal. A coisa foi tão terrível que o CEO da Stardock teve que emitir várias cartas abertas de justificativa e desculpas e dizer “ok, o jogo simplesmente não estava completo” – e não porque eles fizeram de propósito, mas sim porque não souberam ver que ele estava quebrado e incompleto. Mais uma vez, falta de liderança e dar ouvidos a uma comunidade pequena de entusiastas, que não sabia ver o que tinha de errado – que é justamente o que precisa ser feito em playtests de qualquer fase, especialmente em closed/open betas. Neste caso, pelo menos, eles tiveram a chance de tentar se recobrar: todas as atividades do estúdio foram paralisadas e  focadas no desenvolvimento e melhora do Elemental, com aqueles que compraram o jogo até o primeiro grande update ganharem o primeiro DLC pago gratuitamente. Justo.

Parte 3: MineCrack – how much money can one Persson make?

Se você nunca ouviu falar de MineCraft, não vá a www.minecraft.net e baixe o alpha, tente logar com um usuário qualquer e dê “play offline”. Se você passar mais de 15 minutos jogando, pelos meus cálculos, você não vai parar mais.

MineCraft é um joguinho com visual retrô (leia-se: feio), em que o mundo é um cenário aleatório todo feito de cubos, cada um de um material. Você quebra esses cubos pra coletar o material de que eles são feitos e depois pode montá-los como quiser, ou combiná-los para fazer ferramentas. O objetivo é sobreviver durante a noite dos ataques de monstros. Ele foi criado por um cara só, um programador chamado Markus Persson. É feito em java. Esse cara hoje ganha quase 100  MIL EUROS por DIA vendendo A VERSÃO ALPHA do jogo.

Eu também não dava nada por ele mas, um dia, baixei pra dar uma olhada. Calhou de ser exatamente quando os servidores do cara simplesmente caíram por excesso de conexões e ele teve que desativar o login de jogadores. Como milhares de pessoas já tinham comprado o jogo pra ter acesso, ele simplesmente deixou todos poderem jogar, para não bloquear os seus clientes. Justo!

Eu jogo offline sempre. O alpha do jogo está em pré-venda por €9.95 e a versão completa custará €20.00, uma pechincha! Ainda não comprei só por um motivo:

As we at Mojang continue to release more complete builds of the game, we will also be reducing the discount gradually until we reach the final version and full price of the product. So the earlier you buy, the better value you get! Although we are very passionate about this project, we cannot guarantee that it will be completed – that’s why we offer the discounted price

Opa, espera. É uma pré-venda ou uma venda? Eu compraria o jogo pra poder jogar o multiplayer, com certeza. Mas o multiplayer é exatamente a parte bugada atualmente, e eu não tenho previsão de quando e até mesmo SE isso vai ser consertado? O negócio me parece menos agradável, especialmente com o euro a R$2,30.

Aliás, em qualquer post de blog do Notch (como é conhecido o desenvolvedor), há duas “facções” nos comentários: os que incentivam e os que estão de fato MUITO irritados porque o jogo não vê atualizações há um bom tempo. Como o cara ganhou uma bolada (estima-se que tenha ganho algo em torno de 4 milhões até agora), resolveu montar uma empresa, que será dedicada ao MineCraft…. e a um novo projeto. Adicione isso ao servidor caindo constantemente e a nenhuma novidade no jogo há mais de um mês e você tem INTERNET RAGE! Mas, tenho que dizer aqui… justo!

O que a Wolfire está fazendo com o Overgrowth é exatamente a mesma coisa: vendendo o alpha do jogo pra financiar o resto do desenvolvimento. A diferença é que eles já são um time há algum tempo e garantem que o jogo será lançado (e tudo aponta que será, de fato). Assim, você pode comprar com “menos medo” do que você compra o MineCraft.

Parte 4: Apenas rapazes latino-americanos, sem dinheiro no bolso

O que nos traz a nós, desenvolvedores independentes, sem parentes importantes, sem o bigode maneiro do Belchior. Qual a maior vantagem de fazer a pré-venda de um jogo, sendo um indie? Você pode, além de ganhar uns trocados, testar o seu jogo. De graça. Explico: as empresas parrudas gastam milhares de dólares contratando testers, pessoas especializadas em jogar de novo e de novo e de novo cada pequena parte do jogo, procurando por bugs e melhorias a serem feitas. Por que? Porque quando você lança o jogo, as milhares de variações possíveis de sistemas, de coisas malucas que as pessoas podem tentar fazer, de erros que você não previa vão ser todas enfrentadas por ele – o mesmo problema que qualquer outro produto de software enfrenta. A diferença é que a frustração é a pior inimiga de um jogo, logo, você quer evitar isso ao máximo.

Uma solução para nós seria fazer o que eles fazem: vender o jogo e usar o feedback dos compradores para melhorar e testar. Genial! Só tem alguns problemas (e agora você vai entender por que diabos tem um wall of text dividido em 3 partes aqui em cima):

1. Como você garante que o seu jogo, mesmo incompleto, não seja pirateado? Até que ponto você quer dar acesso às pessoas?
2. Se o seu jogo é um alpha, as pessoas que pagaram por ele REALMENTE gostaram da idéia, e estão muito interessadas. Como fazer para ter uma amostra mais imparcial dos problemas do seu jogo, tanto bugs quanto gameplay, e um grupo que, na média, saiba enxergar tanto as coisas boas quanto as ruins?
3. Como você pode GARANTIR que o seu jogo vai ser terminado, e que as pessoas vão receber o produto pelo qual elas pagaram, e ficarem satisfeitas?

E finalmente chegamos ao ponto. A coisa toda de “always-online” e DRMs draconianos é ridícula – mas se você está agregando valor ao invés de retirá-lo, a coisa muda. Quem jogou o Open Beta do World of Warcraft, há muitos e muitos anos atrás, por exemplo, ficou muito feliz de jogar e não se importou quando perdeu seus personagens e deu com a cara na porta de um dia pro outro. Por que? Porque o jogo é inerentemente online, e porque eles tiveram a chance de participar da experiência – e é aqui que o DRM é o exato oposto: não foi algo que bloqueava o acesso de quem estava pagando, e sim um “try before you buy”, que é o motto de grande parte dos times de piratas. As pessoas, pra ter a experiência do jogo antes, não se importam em perder o seu progresso e seu acesso quando acaba o período de testes.

E não é isso que o Notch faz com o MineCraft, por exemplo? Mais ou menos! Não é “try before you buy”. É buy cheaper and try. E sem garantias de quando os problemas serão sanados – o que irrita os clientes e, de fato, dá pra entender.

Então como nós, desenvolvedores independentes, podemos usar essas idéias para testar nosso produto e divulgá-lo sem ter as condições de garantir que vamos/quando vamos entregar o produto completo? Simples. Não cobramos. E deixamos as pessoas jogarem até o produto ser lançado.

Como funciona o DRM do Bem (TM)?

1. Todo jogo chega a um ponto do desenvolvimento em que está pronto o suficiente para passar por playtests e precisa ser testado em grande porte. Para isso, você vai fazer um open-alpha ou open-beta;
2. O desenvolvedor cria um banco de usuários: para participar, o cara tem que se cadastrar. Você pode selecionar todos que se cadastrarem, ou apenas uma parte, mais específica, dependendo do foco do seu teste e do estágio do seu desenvolvimento;
3. Para jogar, o cliente precisa ser identificado, assim como no DRM do Mal (TM) e estar online. Isso não tira completamente o propósito porque hey, é de graça! Além disso, a opinião dele vai influenciar diretamente em como o seu jogo será no futuro – todo mundo ganha;
4. O cara que for tester do jogo pode/deve ganhar vantagens futuramente (mais sobre isso daqui a pouco);
5. Quando o seu período de testes acabar, você fecha para novos registros e fecha (se achar melhor) o acesso ao jogo até o próximo período de testes;
6. Quando o jogo estiver pronto para ser lançado, você fecha de vez o acesso à versão de testes;
7. Você lança o seu jogo sem DRM (porque ele é coisa do capeta), bem testado, e com vários tweaks relacionados ao feedback dado pelos jogadores – o que evitará que você tenha que lançar um 0-day patch da vida.

Ta-da!

A coisa toda aqui é: você precisa testar o seu jogo, e precisa fazer playtests que não envolvam só pessoas do seu círculo social próximo. Mas cada fase de testes é diferente: quanto mais cru está o jogo, mais a pessoa tem que entender de jogos e desenvolvimento para dar opiniões que vão te ajudar. No entanto, quanto mais próximo você chega ao jogo completo, mais pessoas diferentes têm de testar. E como você alcança isso? Free candy on the Internets!

“E por que um cara testaria o seu jogo pra você? Ele deve ganhar algo em troca, já que trabalhar de graça é só pra desenvolvedor indie.”

Sim, deve! O importante no fim é não só o cara prestar um favor ao desenvolvimento (e, se ele gostar do jogo e pensar em comprar, a ele mesmo no futuro), mas também se divertir enquanto isso! Então o primeiro passo é, diabos, o seu jogo parecer interessante. Outra coisa importante é não colocar muitos empecilhos no registro (ninguém gosta de ficar horas respondendo questionários pra criar um usuário). Outra coisa legal, que o Google é rei em fazer, é um sistema de convites. O cara que for escolhido pra se registrar pode convidar outros mesmo que os registros pra tester já estejam fechados – afinal de contas, especialmente se o seu jogo é multiplayer, o cara tem que jogar com os amigos! Finalmente, pode culminar em um desconto na hora de comprar a versão final.

“Então vai ser oba oba? Qualquer um que se registrar vai ganhar todas essas vantagens?”

Não! Afinal de contas, o cara que se dedicou aos testes não pode receber a mesma recompensa que um cara que simplesmente se registrou. Incentive o feedback, faça um sistema a la “pay per bug”: a cada bug encontrado por um usuário, ele ganha pontos; a cada sugestão dada que entre no jogo, também. Assim, ele pode trocar esses pontos por convites, descontos, ou quaisquer outras vantagens que você imaginar.

“Então eu não deveria fazer uma pré venda do jogo?”

Oras, você pode. Basta garantir que você consegue lançar o seu jogo se cópias forem vendidas – ou pelo menos, devolver o dinheiro.

“E se algo acontecer e eu NÃO conseguir lançar meu jogo, mesmo que não tenha vendido nenhuma cópia?”

Cada caso é um caso. Mas o motto deveria ser lançar o jogo, gratuitamente, aberto a todos. Afinal de contas, o cara que se esforçou pra testar o jogo pra você merece uma recompensa – e você não vai ganhar nada deixando o jogo engavetado pra nunca mais ser desenvolvido.

WHOA!

Bem vindos ao final do post mais longo da deV( )id até hoje!

tl;dr:

• DRM do Mal(TM) é mau. Você não deve ser vetado de jogar um jogo pelo qual você pagou;
• Abrir o seu jogo para testes do público é bom pra você e pro público: quando ele for lançado, você vai ter iterado o desenvolvimento o suficiente para não precisar de um 0-day patch da vida;
• DRM do Bem(TM) consiste em usar técnicas do DRM do Mal(TM) para restringir acesso ao seu jogo em diferentes fases do seu desenvolvimento, para que o público possa testá-lo e, no final, quando for lançado, o mesmo não deve conter nenhum tipo de DRM.

Estamos considerando seriamente um esquema desse tipo para o SumoCheckers. Assim, precisamos da sua opinião! Comentem e vamos agitar a discussão a respeito =)

E como não poderia faltar… EM OUTRAS NOTÍCIAS!

O evento está com data 90% definida. Será em abril de 2011. Já temos alguns palestrantes confirmados e estamos correndo atrás de outros. Em breve um hotsite!

A não ser que algo melhor apareça, o nome será GameCraft 2011 – Rio. Se não acharam legal, mandem sugestões. Vox populi, vox dei!

APB, Demos, DRM, DRM do Bem(TM), DRM do Mal(TM), MineCraft, RTW, Ubisoft

Pré-leitura pra quem não sabe o que são normal maps e como eles são usados em jogos: http://en.wikipedia.org/wiki/Normal_mapping

Resumo pra quem tem preguiça de ler: é uma técnica onde se tenta aplicar iluminação em um objeto de poucos polígonos como se ele fosse mais detalhado do que realmente é. Na prática, isso significa que tudo fica mais bonito

Pois bem. Sempre quisemos colocar isso em ação nos nossos Sumokas, mas sempre havia coisas mais importantes a se fazer (tipo menus e condições de vitória, essas coisas inúteis). Porém, com a recente (res)subimissão do jogo ao SBGames, chegamos a uma situação um pouco mais folgada que nos dá liberdade de trabalhar um pouco no que der vontade

Então, ontem à noite me deu vontade de colocar essa joça de normal mapping pra funcionar. Na verdade o material artístico necessário (a textura com o normal map do modelo baseado numa versão hi-poly) já existia e havia sido testado fora do jogo, então era “só” questão de ajeitar materiais e shaders para utilizar isso. O que, como sempre, não se mostrou uma tarefa muito trivial. Segue abaixo a sequência de resultados conseguidos até a meia-noite:

O maior problema, na verdade, foi que pra começar, foi difícil achar um shader que fizesse o que a gente queria. Ou tinha coisa demais (e ia afetar a performance desnecessariamente) ou tinha de menos. Bom, como eu sou cabeça-dura, peguei um que tinha coisa de menos e fui adicionando funcionalidade aos poucos, enquanto aprendia a usar shaders com OGRE. O último screenshot mostra como a coisa estava até ontem.

O trabalho de hoje consistiu em adicionar ao shader um detalhe que havia sido esquecido: levar em consideração a cor definida pro objeto no material (por isso os Sumokas parecem mais claros do que deveriam). Mas, ainda assim, havia problemas: o shader só funcionava com Direct3D e 16 bits

Enfim resolvi tomar vergonha na cara, usei um shader prontinho pra OGRE (que o Yanko havia achado) e agora tá tudo funcionando muito bem Segue o resultado final (observação: as sombras projetadas foram desligadas para evidenciar as diferenças no material):

E assim termina mais uma odisséia deV( )id e mais um detalhe incrementando o SumoCheckers. Pode parecer que a diferença foi pequena, mas são estes detalhes que fazem o jogo se tornar cada vez melhor

Antes e Depois, Normal Mapping, Odisséias, Sumo Checkers, SumoCheckers

Nós não somos desenvolvedores Linux por padrão. No entanto, sempre tivemos bem forte a idéia de que é importante se desenvolver pensando o máximo possível em ser independente de plataforma – ou seja, sempre que vamos escolher um pacote para plugar na Dystopia, nosso framework in-house, nos esforçamos o máximo pra não ficarmos tentados por features mágicas se elas estiverem atreladas a um SO específico. Grande parte disso também vem da inspiração no post dos caras da Wolfire Games que faz a pergunta “por que rodar em MacOS e Linux?” – e é um must read pra qualquer desenvolvedor.

Nós já tínhamos a idéia de fazer um porte do alpha do SumoCheckers pra Linux, mas por falta de tempo, outras coisas a serem feitas e espaço em HD pra eu instalar uma distro, isso estava com prioridade baixa. Até que o Diego Dukão, gente boa, me perguntou se o nosso jogo era multiplataforma. Eu respondi… bom, a verdade: ele era. Mas em teoria. Como tinha (finalmente) comprado um HD novo e já estava protelando pra escolher distro há algum tempo, decidi instalar um Ubuntu 10.04 mesmo, que seria a opção mais rápida de ficar up-and-running – e provar o conceito.

Este post é pra ajudar qualquer um que venha a ter os mesmos problemas que eu tive com as ferramentas que a gente usou. Então quem tiver interesse em fazer uma viagem pra Taerra Pinguinis, vamonos! Pra quem não tiver interesse, lá no final tem fotos do SumoCheckers atual, e aqui tem uma foto de um pinguim bonitinho:

Primeiro Problema: Code::Blocks

Ok, começamos bem. Nossa IDE de escolha é o Code::Blocks, e eu obviamente imaginei que a única coisa que eu ia precisar fazer seria abrir o projeto e remover os defines relacionados a código WIN32. Boy oh boy, was i wrong.

O Code::Blocks usa o WxWidgets e, por eu ter escolhido a versão recém-saída do forno do Ubuntu, por algum motivo místico a versão que vem nele é incompatível com a versão que o Code::Blocks usa. Primeira decisão errada: depois de bater cabeça um bocado de tempo, falei “bom, já estávamos querendo tentar o QtCreator mesmo… vamos ver no que dá”. No fim das contas, não valeu nem um pouco a pena tentar recriar o projeto numa IDE que você nunca viu na vida com um deadline de 2 dias, e eu acabei voltando atrás e procurando a solução do problema. Pra todos aqueles que tentaram usar o C::B no Lucid Lynx e se depararam com essa creca, basta seguir as instruções desse link e alternar as versões sendo usadas, que o bicho roda.

Fuck yé, ID-É!

Segundo problema: a dependência esquecida

O Dystopia tem uma interface de redes que atualmente é operada pela RakNet, que é tão boa que é basicamente “se você precisa de alguma coisa de redes pro seu jogo e já não tem no que quer que você esteja usando, use a RakNet”. A versão de testes do SumoCheckers original era completamente dependente de rede, mas nós decidimos adiar essa implementação por enquanto pra versão 3d, então atualmente os dois jogadores são controlados por teclado. O código de redes está lá, mas não está sendo usado. Mesmo assim, o framework ainda precisa da dependência (a RakNet) pra compilar.

Pra quem usa a RakNet, sabe que o Rakkar faz updates constantemente. E talvez já tenha se perguntado onde diabos ficam as versões antigas pra baixar. A resposta é mais simples do que parece: está tudo no diretório raiz do link de download da versão atual – assim, qualquer um que, como nós, não troque de versão dela a cada semana mas tenha perdido o zip original da versão que usa, pode achar as versões mais antigas aqui.

Um bump in the road pra quem não tá acostumado é o CMAKE. Ele é excelente depois que se aprende a usar, mas até pegar o jeito, é chatinho. Felizmente, existe o CMAKE-GUI, que pode ser pego com um apt-get, que facilita BASTANTE o processo. Como eu queria apenas ter algo rodando rápido, gerei o mínimo possível para resolver o problema da dependência, ou seja, se bobear, para uma versão final usando de fato a RakNet, precise rever o .SO.

INTERMISSION: .SO’s

Pra quem nunca programou em Linux, talvez não saiba: .SO’s são “shared objects”, que são basicamente as .dll’s dos sistemas *nix. Aqui tem um pouco mais de informações a respeito. Eu ainda preciso estudar um bocado pra saber como juntar tudo num pacote bonito e instalável, mas diacho, isso é só uma prova de conceito. Moving on!

Terceiro Problema: mais dependências, nomes de arquivo e diretórios

Depois de compilar a RakNet, foi a vez da Ogre3d. Para não ter que esperar o download, peguei o source que já tinha baixado no Windows pra usar. Funcionou, mas a árvore de diretórios não era a mesma, ou seja, tive que mover alguns diretórios e arquivos pra lá e pra cá até deixar tudo certo. A conexão estava lenta nesse dia, então acabou sendo mais rápido fazer isso do que esperar

Pra facilitar, aqui vai um guia completo de como instalar do source, que foi o que eu segui.

A IrrKlang, que estamos usando para o som, foi a única bondosa dependência que já vinha pré-compilada. Não tive que fazer nada, apenas avisar pro linker usá-la. Abençoados sejam!

Quando finalmente abri o projeto do SumoCheckers no Code::Blocks, acabou que ele teve alguns problemas na localização de arquivos também. Isso aparentemente aconteceu, pelo menos em parte, por problemas de nome de diretórios e arquivos – lembrando sempre: o Linux é case-sensitive, o Windows não. Sendo assim, resolvi esvaziar o projeto e re-adicionar todos os arquivos de fonte. Depois de bater cabeça um tempo com um arquivo que simplesmente não precisava estar no projeto (e por isso dava erros de compilação), pronto, tudo certo!

Aos finalmentes: HIT COMPILE!

E finalmente temos……………….. um erro. No caso, apenas *UM* erro, literalmente, e era num define: o Tinnus colocou o Sleep() pra Win32 mas não colocou pra Linux, então colocou um #error lá pra indicar que a gente deveria pegar pra consertar depois. Temporariamente usei o sleep(), mas essa função recebe segundos, ao invés de milissegundos, como o Sleep() do windows. O correto seria usar o usleep(), que recebe microsegundos (mnemônico: u é µ) e multiplicar por 1000 pra ficar equivalente.

“Finalmente! Compilou! I am Root!”  etc. Até ver que o mouse não funcionava.

Mas era um problema bobo: estávamos passando “mouse_win32″ pra função que controlava o mouse e, bom, no Linux não deveria ser isso. Por sorte, a interwebz provê a resposta facilmente: pra quem usa OIS para controlar input, provavelmente faz um

pl.insert(std::make_pair(std::string("w32_mouse"), std::string("DISCL_FOREGROUND")));
pl.insert(std::make_pair(std::string("w32_mouse"), std::string("DISCL_NONEXCLUSIVE")));

no Windows. No Linux, isso deve ser um

pl.insert(std::make_pair(std::string("x11_mouse_grab"), std::string("true")));
pl.insert(std::make_pair(std::string("x11_mouse_hide"), std::string("false")));

Resultado do experimento

Oficialmente o SumoCheckers é um projeto cross-platform =)

Precisamos apenas de 3 linhas de código adicional pra que ele rodasse em Linux: o sleep(), que já estava previsto, e as coisas de input da OIS que não previmos, realmente, mas pelo menos era bem óbvio dados os parâmetros que a gente passava. Impressionantemente, foram 2 dias fuçando direto, só nos problemas de dependência e IDE, gastando menos de 15 minutos pra resolver os do nosso código. Com isso, acho que fica bem entendido o título do post. Fazendo as coisas direitinho, o único problema que você vai ter é na sua falta de prática em outro ambiente de desenvolvimento mas, seguindo os padrões da linguagem e usando apenas bibliotecas crossplatform, você só vai precisar escrever seu código uma vez – o resto é só setup de ambiente. Próxima aventura: MacOS, depois que alguém me doar um MacBook!

Ironicamente, dias depois descobri que a versão de Windows roda perfeitamente bem no Wine. Mas hey, isso não vem ao caso, vamos a alguns screenshots do estado atual do SumoCheckers, com a nova dama e uma boniteza a mais no cenário:

É isso! Espero que acabe ajudando alguém querendo entrar na tuxlândia.

PS: Estamos precisando de um nome pro evento de gamedev que estamos montando pro ano que vem! Mandem sugestões pelos comentários ou pro @devoidgames!

PS2: o plugin de WordPress que faz os códigos identadinhos é o Syntax Highlighter Plus.

PS3: quem disse “o inferno são os outros” foi o Sartre, vale a pena ler pra entender por completo o título do post =)

PS4: está sendo projetado com ajuda dos desenvolvedores (HAH!)

10.04, CMAKE, Code::Blocks, Cross Platform, Dystopia, Framework, IrrKlang, Linux, Lucid Lynx, Port, RakNet, Sumo Checkers, SumoCheckers, Ubuntu, WxWidgets

Holas!

Pra quem notou o silêncio no @devoidgames, deve ter pensado que

a) Era fim de período

b) Tinha um deadline curtíssimo pra enviar algo pro SBGames 2010

c) Alguém ficou semi-morto

A new challenger appeared: d) todas as anteriores! Mesmo assim, eu e o Tinnus passamos pelo nosso primeiro mega-crunch. Foi tenso, e é algo que todo desenvolvedor vai passar eventualmente. Coisas feitas na correria, tudo “bom o suficiente” mas “poderia ser melhor”, trilha sonora feita em meia hora (literalmente)… mas cá estamos!

And we’re proud to present: o primeiro preview público do SumoCheckers em sua forma 3D!

Coisas a se notar: os gráficos são uma iteração dos anteriores, mas ainda são meio que placeholders. As músicas foram feitas em literalmente 20 minutos. O Tinnus programa realmente muito rápido. E coisa final a se aprender: NUNCA, repito, NUNCA você vai mandar algo que não esteja pronto antes de 23:50 num deadline às 00h. Sempre tem algo pra consertar, polir, adicionar e, principalmente, desesperar!

Sugestão pro pessoal do SBGames: mandem um e-mail de confirmação pra quem enviar o jogo! E MPEG1 não é um bom método de compressão mais, youtube/vimeo tão aí pra isso

Sugestão pro pessoal da deV( )id: quaisquer que vocês tenham, mandem!

Without further ado: o vídeo de gameplay, feat. barulhinhos do meu gTalk!

Esperamos vossos comentários, a voz do povo é a voz de Deus!

2010, Crunch, Festival de Jogos Independentes, Público, SBGames, SumoCheckers, Vídeo

Howdy!

Raras são as vezes que nós temos a oportunidade de fazer trabalhos pra faculdade relacionados a jogos – ou porque foge completamente ao escopo da disciplina, ou porque simplesmente não daria tempo de fazer algo com um monte de outras matérias pra se pensar a respeito. Então sempre que eu acabo caindo numa “eletiva de escrever” (como são carinhosamente conhecidas as matérias em que nós não necessariamente tratamos com integrais ou algoritmos), eu tento puxar a sardinha pra esse lado.

Como não estou tendo tempo pra atualizar o blog por causa do spree de fim de período, com um bando de trabalhos pra fazer, resolvi simplesmente fazer trabalhos que eu pudesse postar no blog! Um sobre a inovação da indústria, e o outro sobre… ensino.

Sim, senhoras e senhores, eu fiz um trabalho sobre games aplicados ao ensino. E sim, ele é uma expansão do meu rant sobre a quantidade enorme de coisas do tipo no SBGames do ano passado (ctrl+f “Rant 3″).

Então enquanto não atualizamos aqui com os posts mais técnicos, aqui vai:

a) “Evolução e Inovação no Mercado de Jogos Eletrônicos” – feito há alguns anos atrás para a disciplina “Conhecimento e Inovação”. É basicamente um estudo da história do videogame, que por ter sido feito há algum tempo, já está um pouco defasado. Provavelmente a maioria das pessoas que passarem por aqui vai saber da maior parte do que tem lá, mas fica o registro.

b) “Jogos Eletrônicos como Ferramenta de Ensino” – feito semana passada pra “Informática Aplicada ao Ensino”. Esse, pra quem gosta de ler o blog, acho que é mais interessante de ler inteiro. E por favor ignorem o auto-plágio de uma página do trabalho anterior, eu estava trabalhando com deadlines complicadas! O trabalho basicamente expande aqueles pontos básicos de que

• b.1) Só vai funcionar direito se o que se quer ensinar for inerente ao gameplay;
• b.2) O foco é tanto o aluno quanto o conteúdo;
• b.3) Não é nada fácil fazer um bom jogo educativo;
• b.4) Não é só na escola que existe ensino; e finalmente
• b.5) Não é porque um jogo não é educativo que ele não vai te ensinar nada!

É basicamente isso. Tem vários exemplos que acabaram não indo pro texto por falta de tempo (e porque o escopo era um pouco fechado, apesar de tudo), mas aí é só ficar de olho no @devoidgames que tão todos lá =)

—Em outras notícias!—

Está cada vez mais perto a confirmação do evento de jogos que o pessoal da deV( )id (eu e o Tinnus) tá montando com o pessoal do LabIC-UFRJ (eu, o Tinnus e o @rafalopes ). Serão dois dias em outubro dedicados a palestras e mesas redondas, abertas a todos os interessados – incluindo, obviamente, uma mostra de jogos independentes. Fiquem de olho! Se tudo der certo, em breve teremos um hotsite

Ensino, Eventos, Faculdade, Indústria, Inovação, Trabalhos

Como nós acabamos de ter uma entrevista publicada com o pessoal do EArena Games (hoorray! Valeu, pessoal!), imagino que bastante gente vá cair de pára-quedas por aqui. E por isso, resolvi fazer essa pequena retrospectiva sobre o que aconteceu no blog até agora, dividindo por assunto, para que os interessados em conhecer o blog não tenham que digerir textos gigantes completamente fora dos seus interesses.

Então lá vamos:

Rants (o que eu vejo por aí e sinto vontade de chiar a respeito)

• Devoid Politics – Polêmica! Efeitos de luz! Gamers contra o projeto de lei do Sen. Valdir Raupp;
• Ressaca SBGames 2009 – Mais do que sobre o evento, sobre as entrelinhas que eu pude observar do cenário nacional;

Fundamentos (alguns pontos importantes pra quem está começando no mundo de gameDev)

• Intro - Por que começamos por aqui?
• Parte 1:  Prototipagem – qual a importância de um bom protótipo antes de começar o desenvolvimento?
• Parte 2: Cliente/Servidor - por que é legal partir desse raciocínio pra sua estrutura;
• Parte 3: O Framework – um pouco sobre o framework que estamos desenvolvendo;
• Parte 4: O Projeto – a resposta para a proverbial pergunta “mas o que diabos vocês estão querendo?”

SBGames 2009 (cobertura do maior evento nacional da área)

• Dia 1 – Novidades, keynotes e uma chuva dos diabos;
• Dia 2 – Negócios, Ubi Brasil e Playstations;
• Dia 3 – Gente esquisita e jogos independentes;
• Prólogo: vide Rants, “Ressaca SBGames 2009″;

Geral (posts sem pai nem mãe)

• devoid updates? – um pequeno keep alive pra dizer no que estamos trabalhando e um pedido de desculpas pela ausência de posts com um screenshot do estado atual do SumoCheckers;
• Arte nos games: do Impressionismo ao Uncanny Valley – café com leite, mas didático;
• Clipping do DevBlog do Braid – como eu gastei uma tarde com Jonathan Blow & Cia;
• Tatuem isso na testa! – Um pequeno infográfico da jornada de qualquer wannabe;
• Going indie – por que vale a pena arriscar;

Pra quem já lia o blog, recomendo o EArena Games, um site nacional bem legal de notícias com gente que sabe o que faz! (como vocês já devem ter percebido, se seguem o @devoidgames)

E pra quem chegou hoje… espero que venham mais vezes! Sigam a gente no twitter, assinem o RSS do blog e metam bronca nos comentários!

EArena Games, Entrevista, Retrospectiva, Tudo Até Agora

Olá todo mundo! Por favor, finjam que as teias de aranha são decoração adiantada para o Halloween (ou um jogo de terror que secretamente estamos preparando). Elas serão faxinadas em definitivo em breve!

Mas vamos à vaca fria: o que diabos nós andamos fazendo? Um FAQ/keep alive da nossa parte:

1) A deVoid morreu?

Nem de perto! Na verdade, não estávamos nem hibernando – o tempo só ficou um pouco curto pra manter o blog. Temos várias coisas caminhando em paralelo. Infelizmente uma dessas coisas se chama “graduação de Ciência da Computação na UFRJ”, por isso o silêncio de nossa parte!

2) E o que diabos vocês andam fazendo?

Basicamente, desde o nosso último post, o que rolou foi o seguinte

• O Tinnus quebrou a cabeça por semanas tentando fazer um sistema decente de lag compensation pro protótipo do SumoCheckers. Como tem alguns problemas inerentes ao nosso gameplay, isso virou um post que ainda está sendo rascunhado, já que alguns ajustes são necessários, mas assim que ele tiver chegado num ponto de “eureka”, vocês vão ter um artigo bem legal (e técnico) por aqui;
• O Yanko bolou mais uns 5 game designs diferentes que eventualmente podem aparecer daqui um tempo;
• Nós decidimos começar o desenvolvimento “final” do framework Dystopia (a base do nosso projeto, e provavelmente nosso projeto final). Então estamos plugando tudo pra poder, em breve, ter um protótipo 3d exatamente igual ao 2d, e daí pra frente, é só adicionar todos os sistemas necessários pro jogo.
• Fomos entrevistados pelo pessoal do EArenaGames, entrevista que deve ir ao ar essa semana ou na outra! Avisaremos pelo twitter!
• Estamos tentando descobrir por que diabos o Rio não tem um Chapter da IGDA. E se não acharmos nenhum motivo impeditivo, queremos agitar a unificação da cena daqui. Qualquer um interessado em estudar a viabilização disso (mesmo que não seja formalmente IGDA, mas pelo menos um “epicentro” pros desenvolvedores cariocas), por favor, deixe um comentário pra gente entrar em contato via e-mail!
• Estamos também correndo atrás de financiamento na UFRJ para fazermos um evento carioca de games, juntando palestras acadêmicas e de gente do mercado. Infelizmente, precisamos da resposta da pró-reitoria responsável para viabilizar financeiramente o projeto – mas queremos que seja algo que englobe estudantes, profissionais e hobbystas. Mais uma vez, os interessados por favor deixem comentários pra que a gente possa entrar em contato por e-mail caso isso se confirme! E claro… vai ter uma mostra de jogos independentes

3) Até quando vocês vão fazer posts com o título contendo um trocadilho com “devoid”?

Ei!

4) Sobre o que vocês devem postar num futuro próximo?

Muita coisa rolou na briga Activision x Infinity Ward, muita coisa se falou do DRM da Ubisoft, muitas promoções “pague quanto quiser” no mundo indie… então tem bastante coisa pra fazer rants a respeito. E claro, sempre que tivermos updates significativos/artigos sobre o projeto, vamos postar aqui. E claro, continuamos sempre clippando notícias no @devoidgames!

5) Falando nisso… e o jogo?

Bom, ele está apenas entrando na fase de protótipo 3d… então não há nada final pra ser mostrado ainda, por isso a ausência total de novidades, ou screenshots ou coisas do tipo. Não queremos mostrar nada enquanto não estiver com assets na versão final.

 

 

 

 

 

 

 

 

 

Stay tuned!

Eventos, IGDA Rio, Preview, Screenshot, SumoCheckers, UFRJ, Updates

O post numa casca de nós

Todo mundo já deve ter ouvido falar do projeto de lei do senador Valdir Raupp que determina pena de até 3 anos para quem comercializar, distribuir ou estocar jogos considerados “ofensivos”. Isso rodou as comunidades de jogadores, até mesmo em meios internacionais e motivou uma carta aberta à população por parte da Abragames.

O que nem todo mundo percebeu é que o projeto está, há um bom tempo, em vias de aprovação. A notícia já tem quase dois meses, mas a bigorna só me caiu na cabeça agora: o que exatamente nós, como cidadãos, desenvolvedores e jogadores estamos fazendo a respeito?

Na atual situação, após ser aprovada na Comissão de Educação, o projeto é enviado para a Comissão de Constituição e Justiça. Se lá também for aprovado (corrijam-me se eu estiver errado aqui) ele vai pra mão do presidente, este podendo vetar (enviando de volta para que seja replanejada) ou aprovar, virando, assim, lei de fato.

Pra quem não tiver tempo, nem paciência de ler, já adianto a pergunta chave do post: o que NÓS podemos fazer? Eu pergunto isso com toda sinceridade do mundo, porque realmente não sei. Espero que vocês tenham sugestões, o espaço de comentários está aí pra isso.

Agora, pra quem quiser ler um dos posts gigantes, lá vamos nós.

---

“Ofensivo”

Resumidamente, o projeto de lei

Altera o art. 20 da Lei nº 7.716, de 5 de janeiro de 1989, para incluir, entre os crimes nele previstos, o ato de fabricar, importar, distribuir, manter em depósito ou comercializar jogos de videogames ofensivos aos costumes, às tradições dos povos, aos seus cultos, credos, religiões e símbolos.

Ignorando completamente a justificativa ignóbil de que

[...] os videogames mudam as funções cerebrais e insensibilizam os jovens diante da vida. Os jogadores frequentes sofrem danos a longo prazo em suas funções cerebrais e em seu comportamento.

dada pelo sen. Valter Pereira, podemos partir para o grande problema do texto: o que classifica algo como ofensivo?

Na real, qualquer coisa pode ser ofensiva a qualquer pessoa. Um cristão pode se sentir ofendido por um jogo como Diablo. Ou então uma pessoa negra ou um latino pode se ofender com o fato das gangues do GTA San Andreas serem compostas por membros de suas etnias. Diabos, a Associação dos Pingüins e Galinhas do Sergipe pode ficar ofendida com o fato do Taikodom ser baseado na ação de voar. Os monstros do planeta Blwarh podem ficar ofendidos com a idéia de que um deles poderia matar uma criança inocente. O próprio Valdir Raupp pode ficar ofendido com o fato desse post mencionar os dois inquéritos do Supremo Tribunal Federal em que ele é investigado, as duas ações penais que ele é réu, a assessora que ele não sabe quem é e o seu ex-assessor que ganhou uma rádio. Aliás, o povo brasileiro inteiro pode se sentir ofendido de ter políticos  por aí apertando a mão do José Sarney também!

Não é que eu ache legal um jogo em que você abate freiras e grávidas golpeando-as com cópias de Mein Kampf. Tudo tem seu limite. Mas quanto mais nos aproximamos da fronteira dos jogos com a arte, esse limite fica mais complicado de se definir. E aí entra Voltaire: “Posso não concordar com a sua opinião, mas vou defender até a morte o seu direito de expressá-la”. E se na verdade esse jogo só mostra pra você o quão ERRADO é fazer isso? Qual a validade dessa provocação? É diferente de um filme como “A Queda” que, mal ou bem, coloca Adolf Hitler numa posição em que pode receber empatia da platéia? Ou o “Tropa de Elite” que faz as pessoas se dessensibilizarem com o uso de tortura como modo de conter a violência urbana?

Com muito estardalhaço foi lançado, há uns bons anos, o “Super Columbine Massacre RPG!“, um jogo que colocava o jogador como um dos assassinos do massacre na escola. Em 2007, ele foi um dos selecionados para o Slamdance Festival (festival de cinema independente que acontece ao mesmo tempo que o Sundance, só pra dizer que é independente MESMO). E no fim das contas, foi removido (com certeza por pressões de patrocinadores, apesar disso ter sido negado pelo diretor do evento). O resultado? Grande parte dos jogos que hoje em dia são verdadeiras pérolas do cenário indie dos jogos também foram tirados da competição pelos seus criadores, em sinal de protesto. Entre elas fl0w, Everyday Shooter, Castle Crashers e Braid.

O que o Jonathan Blow falou a respeito? Basicamente, deu uma de Voltaire. Não é que seja um jogo legal, bem feito ou divertido de se jogar. A discussão transcende o certo e o errado JUSTAMENTE porque o jogo é ambíguo nesse sentido: ele te faz PENSAR. Coisa que a mídia em massa evita a todo custo.

E por que se preocupar?

Justamente por causa da mídia. Existem incontáveis leis que existem, ninguém sabe nada a respeito e não são policiadas. Por exemplo, alguém lembra que atendimento técnico por telefone, desde 2008, deve funcionar 24/7 e o prazo máximo para resolução de problemas é de 5 dias? Aparentemente a Americanas.com e o Submarino.com não, vide minhas compras de Natal. Mas hey, é lei!

Então por que achar que a lei dos jogos ofensivos não vai cair no esquecimento? A-ha! Mídia. É um assunto polêmico. Centenas de milhares de pessoas acham que jogos eletrônicos são prejudiciais, que são portas para a violência, que são coisa do Diabo. E isso é explorado todo santo dia na mídia. Lembram dos “assassinatos do RPG” há alguns anos atrás? Ou o Duke Nukem ser tutorial pra um bom rapaz, se formando em medicina, resolver descer bala por aí? É culpa dos jogos? Claro que é. Os pais negligentes ou as doenças mentais ignoradas por anos a fio e, principalmente, o fomento da ignorância nas massas obviamente que não são. E isso é explorado o máximo possível. E exposição na mídia é importante pra várias carreiras, principalmente a de… Político!

O problema não são os políticos serem regressistas. É a população. É ela que põe eles lá. Aliás, isso é o grande defeito da democracia: a ignorância da maioria afeta a vida de todos. Então, caso essa lei passe, qualquer jogo que caia na boca de um juiz sem noção vai poder entrar nos trâmites dela como “ofensivo”. E é daí pra baixo.

E a indústria? Aquela que foi até citada no Gamasutra há alguns dias atrás, por alguém que acha que a gente pode, de fato, deslanchar? Bom, pensem assim: quem é que vai ter interesse em fazer lobby em um país onde os seus consoles não vendem porque os seus jogos não podem ser comprados? E se não tiver lobby, como as taxas de importação pra hardware e software de gaming vão abaixar, diminuindo a “necessidade” de pirataria do grande público? E de que vai adiantar publishers investindo aqui em jogos que não vão vender lá fora, já que os com algum potencial de exportação foram considerados “ofensivos” em território nacional? E finalmente: onde vamos ficar como artistas?

O que fazer, então?

O que eu disse ali em cima vale pra quem (ufa, obrigado) leu tudo até aqui. Não sei, não sei mesmo. Mas coisas me cruzam a cabeça: por que não teve um abaixo assinado FÍSICO no último SBGames a respeito, por exemplo? Eu honestamente não sei se essas coisas contam pra alguma coisa ou não, mas imagino que um bolo de 20kg de papel deva contar mais do que 20 abaixo-assinados virtuais diferentes e desconexos. Não diminuindo a iniciativa, mas quem poderia unificar tudo em um só?

O que a Abragames, como órgão representante da indústria, por exemplo, pode fazer? O que nós, como cidadãos que pagamos impostos, podemos fazer? E como consumidores, o que podemos fazer para que empresas como a  Microsoft e a Sony, que querem entrar no mercado nacional nessa área, ajudem nisso?

A qualquer um pára-quedista que tenha alguma idéia, por favor, comente. Como todas as outras facetas da nossa terra-devoid-games, precisamos ser pró-ativos, antes que seja tarde demais.

Política, Projeto de Lei, Rant, Valdir Raupp

Pra não deixar o pobre blog abandonado até o turbilhão de fim de período terminar, deixo pra vocês um post café-com-leite que eu fiz pra mandar pro Ideafixa. Eles estavam precisando de um colaborador pra parte de games e pediram pros candidatos escreverem algo.  Eu não entrei, mas o Bruno, que foi um dos escolhidos, escreveu um post bem legal e na mesma linha que vocês podem conferir aqui!

I quote:

“[...]

Como todos já devem ter percebido, a indústria dos games já está tomando as proporções da indústria dos filmes: o recém lançado Modern Warfare 2 foi o maior lançamento de entretenimento em matéria de vendas até hoje nos EUA, e teve um orçamento estimado entre 40 e 50 milhões de dólares. Ah, e ele também parece um filme – e o diretor foi recentemente chamado pra dirigir um longa metragem.

Hoje em dia, as técnicas de texturização e de iluminação de um jogo são bem similares àquelas dos filmes de animação, mas com uma diferença: enquanto cada quadro gasta horas para ser rodado em um filme de efeitos especiais, os jogos têm de ser renderizados em tempo real. Isso é conseguido usando, além de várias outras técnicas, os shaders. Shaders são, basicamente, programinhas que rodam dentro da placa de vídeo e calculam como a luz reagiria numa determinada superfície, definindo forma e textura de um objeto virtual – e fazendo todos esses efeitos legais que você vê na tela.

E com a potência dos computadores e dos consoles atuais, cada vez mais se investe no fotorrealismo. A desvantagem disso? Orçamentos cada vez maiores e o famigerado “Uncanny Valley“, uma situação bolada por um japonês chamado Masahiro Mori, que diz mais ou menos o seguinte: se uma coisa for muito, mas muito parecida com um ser humano de verdade, mas não for IGUAL a um, nosso sistema cognitivo vai estranhar mais do que se fosse MENOS humano, de fato. Soa meio esquisito, mas com certeza você já se deparou com algo que te desse essa sensação.

Obviamente, com os avanços na tecnologia, estamos conseguindo nos afastar disso, vide os personagens do (também recém-lançado) Left 4 Dead 2.

Enquanto isso, no extremo oposto, temos os jogos com gráficos abstratos, cartunescos e nada realistas. E, assim como no cinema, eles normalmente caem em cima da “cena independente”. Sim! Nós temos uma cena independente, e ela é cada vez maior. Com orçamentos apertados (ou nulos), uma boa idéia na cabeça e times pequenos, grandes sucessos foram criados. E algum deles são simplesmente lindos, vide o Braid.   [Nota do editor: era um post café com leite, eu disse]

Que não dá pra realmente perceber o quão bonito é sem ver em movimento:

A sacada é a seguinte: é muito caro fazer um jogo que rode em qualquer máquina e pareça um filme, mas é barato usar poucos recursos e um bom senso artístico. O Begotten, do Elias Mehrige, por exemplo, com certeza não deveria ser tão assustador sem os efeitos de edição – custosos em relação a tempo, mas baratos no orçamento, em comparação aos grandes efeitos digitais. Assim como o Braid usa alguns velhos truques na manga do mundo dos jogos pra parecer uma tela viva.

E qual a moral nisso tudo? Nada é o que parece – mas parece que é mais ainda. E é essa a grande máxima da magia visual dos jogos.

” And I unquote. Provavelmente vocês vão me ver falando de maneira mais extensa a respeito de direção de arte, especialmente porque nós vamos ter que arrumar uma pro SumoCheckers.

Voltamos no meio de dezembro à programação normal!

PS: ainda sobre o Ideafixa, a Maru, a outra colaboradora (e uma excelente artista!) falou sobre o Team ICO. Pra quem quiser conferir, clicai aqui.

AAA, Arte, Braid, Ideafixa, Indie Games, Modern Warfare 2

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.

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

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

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?

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:

pra isso:

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:

• Entenda SCRUM em menos de 10 minutos
• A nossa apresentação da Jornada de Iniciação Científica. Tem um pouco sobre o Framework, um pouco sobre IA e um pouco sobre o SumoCheckers em sua versão embrionária.

Boas Vindas, Fundamentos, Nova Casa, Projeto, SumoCheckers, Xzibit