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

Feb/11

26

Gamerama 2011

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

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

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

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

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

Equipe final do Gamerama Workshock: Tabuleiro Botafogo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· · · ·

Sit in the Mountain!

Sit in the Mountain!

Post-muito-mortem do Brasil Game Jam. O post infelizmente vai ser mais corrido do que eu gostaria pelo fogo cruzado de fim de período (e porque eu gastei todo o tempo que eu tinha editando os vídeos). Isso, obviamente, não quer dizer que vai ser curto, porque eu vou intercalar o texto com os nossos vlogs ;D

Introdução:

Pra quem não sabe, o Brasil Game Show sediou uma Game Jam, onde 10 times de universitários de todo o Brasil tinham que criar um jogo em 40 horas, com um tema sorteado na hora, usando a Unity3d. Na mesma hora fui inscrever um time da deV( )id, mas, infelizmente, o Tinnus não pode ir. Assim, agreguei duas pessoas oficialmente para o evento: Felipe “Mascote” Pedrosa e Renato “Lond” Cerqueira, dois caras que estudam com a gente e também têm essa idéia maluca de *cof*tentar tirar leite de pedra*cof**ahem* trabalhar com games.

À esquerda, o Lond, e à direita, Mascote

À esquerda, Lond, e à direita, Mascote

Chegamos ao Sulamérica (onde aconteceria a feira e a jam) bem adiantados, pra evitar problemas, e carregando mais bagagem do que muita gente que veio de fora do estado. Bagagem as in “tralha” e não as in “experiência com Unity” já que, na real, somando as horas do time com a ferramenta antes da Jam, chegamos a um total de… 9 horas, ou coisa do tipo.  Isso indica a primeira coisa óbvia: fomos lá para participar, e não para ganhar – o que deixa a coisa toda bem mais fácil, mas não menos estressante.

Largamos nossas tralhas e fomos assistir o keynote do evento. Antes de qualquer coisa, quero parabenizar o pessoal do BGS por ter organizado uma Jam. Esse tipo de evento é MUITO importante, especialmente pra esquentar o cenário nacional, já que os caras que participam desse tipo de coisa hoje são aqueles que vão trabalhar/montar empresas no futuro. Networking é a chave!

Without further ado, nosso primeiro vlog:

DISCLAIMER:

Eu ia colocar bleeps e bloops de GameBoy por cima de todos os palavrões e termos xulos que nós acabamos deixando escapar. Infelizmente, eu não tive tempo pra isso. Infelizmente também, nós tivemos uma postura Jorge Amado/WikiLeaks ao gravar os vídeos. Em duas línguas. Resumindo: esses vídeos são visualmente SFW, mas é melhor você assistir de fones.  =$

No vídeo: um overview do canto que a gente (teoricamente) iria dormir e nossos primeiros comentários sobre o tema.

O tema:

Dez frases de dez pensadores, para 10 times, no ano de 2010. Tão profético que deu 10, coelho. No caso, Paulo Coelho.

“Quem almeja montes não se detém por pedras no caminho.”

Fun trivia: procurando pelo google, não achei essa frase e, a que eu achei que diz a mesma coisa, é de Josué Martí, que  foi mártir da independência cubana. A frase dele é a seguinte:

“Quem vai em busca dos montes não se detém a recolher as pedras do caminho.”

Existem várias opções: ou a gente anotou a frase errado (bem possível), ou alguém recebeu um ppt da avó com o autor errado (depois de uma piada sacana do tio de autoria do Veríssimo). Ou talvez o Paulo Coelho tenha reescrito a frase… enfim, vamos supor que é dele pra manter o ten, ten, ten.

Brainstorming e a estrutura do time:

Primeiro ponto certo: definimos, no dia anterior, como seria a estrutura do time. Isso é bom porque todas as partes têm que ter um responsável, e nem sempre votações dão certo, especialmente em timeframes tão pequenos. Não é uma posição de VANTAGEM, e sim de RESPONSABILIDADE: se alguma decisão que você toma dá errado e prejudica o projeto, é responsabilidade sua. Assim, como o Lond tinha maior experiência em Unity (todas aquelas 7 ou 8 horas que ele usou durante a semana) e em C# (todos aqueles 2 ou 3 anos que trabalhou com isso), obviamente ficou de Lead Coder. Eu acabei ficando de Lead Game Designer – e já digo desde já que, naquele espaço de 40 horas, poderia ter desempenhado melhor o meu papel. Mais sobre isso mais pra frente.

Ok crianças, sabe que horas são? Hora de… MONTAGE!

Temos alguns out-takes dessa parte, onde tentamos esquentar água com um rabo-quente no banheiro do lugar para café e Cup Noodles. Fun trivia: cup noodles tem 60% do sódio que você vai consumir em um dia. Fun trivia 2: se você ligar uma resistência de 110v em uma tomada de 220v, preste atenção pro cabo não fritar.

O jogo:

Vou confessar: nós fomos com uma idéia “backup” pra lá: se tudo der errado, ou se o tema for propício, faríamos um platformer que já tínhamos pensado anteriormente, e tinha sido a coisa com a qual tínhamos praticado. Acabou que fomos um dos poucos times que NÃO fizeram um platformer. Não vou contar qual a idéia baked que tínhamos porque guess what: planejamos executá-la futuramente também.

Tínhamos definido um horário para acabar o brainstorming: 22h, no máximo. Segundo ponto certo: contamos com atrasos no cronograma, o que obviamente aconteceu. O brainstorm foi GRANDE, muitas idéias jogadas, e é engraçado, vendo agora os vídeos, como é o processo de criação. O que eu achei mais legal: o jogo foi meio catártico, dado a situação. Acabamos fazendo um jogo de exploração, mais “introspectivo”, só injetando um pouco de ação no final – o que talvez eu classifique como “primeira coisa errada”.

Estávamos lá pela experiência e não pelos prêmios, o que eu acho que foi uma vantagem e uma desvantagem: por um lado, nos deixamos levar por idéias mais subjetivas que, sem muito trabalho, seriam difíceis de transparecer pra qualquer jogador. Por outro lado, as idéias eram muito legais e, por isso, temos um projeto pendente hoje em dia, que é terminar o jogo direito 😉

A nossa grande sacada foi como abordar a frase-tema com uma dicotomia: como fazer um jogo que mostrasse que a frase está correta E errada ao mesmo tempo? Tudo na vida tem seus dois lados. O gameplay que nós planejamos consegue isso, na minha opinião: as pedras no caminho estão lá pra serem aproveitadas e, ao mesmo tempo, são coisas a serem deixadas de lado. Então, pelo menos no que planejamos, conseguimos de-void o jogo de um significado mais profundo =)

Let the Game-Making begin!

Quase 5 da matina, já estávamos BEM cansados, mas estávamos otimistas. A parte técnica, envolvendo a perspectiva que a gente queria – o mundo é uma grande esfera, mas a câmera fica perto o suficiente para que pareça um horizonte quase… horizontal. Achamos que seria a mais difícil, mas coding wizardry fez funcionar. O grande problema: não tínhamos internet. E toda a coisa de “bom, tudo bem, a gente não sabe mexer direito na Unity, mas é só catar coisas na internetz pra aprender” foi por água abaixo. Ou suor abaixo, já que o ar-condicionado também tinha dado problema 8(

Apesar de adiantados na implementação técnica, o gameplay ainda não existia, o que pelo nosso cronograma era um atraso BEM grande.

Depois da soneca: day 2

Originalmente pensamos em dormir todos ao mesmo tempo, mas acabamos optando por dormir cada um um pouco, separadamente, não deixando o desenvolvimento parado em nenhum momento (só nos de brain-freeze e falta de internet).  Pelo inglês enrolado e pela troca de palavras, o sleep deprivation começou a atacar – coisa que só piorou ao longo dos dias.

Nessa hora, eu já tinha conhecido algumas pessoas e batido papo, aprendido coisas, e notado uma das coisas mais engraçadas: a postura dos times era dividida em 3 categorias. Tinha os que estavam lá pra participar, os que estavam lá pra participar e ganhar, e os que estavam lá pra ganhar. Teve gente que fez social, bateu papo etc. em vários graus, mas teve gente também que não saiu um segundo da frente do computador, não falou com ninguém e, segundo relatos, tava inclusive preocupado com roubo de idéias. Imagino que esses tenham sido os que menos aproveitaram – ou pelo menos os que aproveitaram menos do que podiam.

Por outro lado, muita gente se ajudou, muita gente me ensinou coisas, e a solidariedade se instaurou principalmente na hora da comida, já que o povo estava todo preso lá. Isso foi a parte mais legal pra mim! (não comer, mas a interação positiva que o pessoal teve. Comer eu ainda tava comendo cup noodles.

HMMM Cup Noodles

HMMM Cup Noodles

As pequenas coisas da vida

Nunca pensou como um banho poderia ser a melhor coisa da sua vida? Tente ficar numa sala com 28 outros machos, trabalhando, sem dormir, com a mesma roupa, por quase 20 horas.

So many notes, and so little time

Falta de internet pra consultar, falta de sono, falta de experiência com a ferramenta. Tudo isso pesa, especialmente se você não fez uma coisa MUITO importante: deixou o mundo lá fora. Quando você se propõe a fazer algo do tipo, você tem que se focar literalmente só naquilo. A sua vida vai rodar durante 40 horas naquela game jam, naquele projeto, então nada mais pode puxar seu processamento. Eu, infelizmente, dei o mole de deixar estresses de fora me pegarem e tomarem minha atenção e tranquilidade – isso só atrapalhou.

Them sleepy goggles

Felizmente, dormir pouco aparentemente deixa a gente meio bebum, então em algumas horas, o humor geral melhorou – especialmente porque tínhamos feito um bom progresso!

Vou aproveitar pra pedir desculpas pra todo mundo em volta, que teve que aturar nossa insanidade, cantando em conjunto, completando as frases um dos outros e fazendo coisas esquisitas. Pelo menos o time estava bem entrosado!

Sobre o GameGambi, isso é algo importante: é uma game jam, você está lá pra fazer o seu jogo FUNCIONAR, não importa o quão podreira esteja o código. Algumas decisões feitas no “ok, vamos fazer ASSIM, porque assim funciona imediatamente” te poupam muito tempo. E no fim das contas, isso se espalha pra gamedev em geral: obviamente, não me refiro a gambiarras programacionais, mas o conceito de que a coisa têm de “feel right“, não necessariamente “be right“.

Gamedev lá da terrinha

Sobre o sotaque: não me perguntem. Essa parte não tem muita coisa importante a se tirar, a não ser que é importante dormir no dia a dia, senão você fica daquele jeito que eu fiquei.

Reta Final

Nessa hora, eu estava colocando sons e música no jogo. Hoje me pergunto se talvez eu não tivesse dado mais atenção à implementação (já que o Mascote tinha apagado), coisa que eu fiz só no final pra dar uma “lustrada” no jogo – que funcionou bem aliás, mas ainda assim foi pouco.

Pra quem tá se perguntando pra que diabos serviu aquele barulho esquisito:

Sit in the Mountain – Puzzle Music

Nessa hora, o sleep deprivation era menos engraçado e mais desespero. Já não conseguíamos mais pensar direito, faltava muita coisa pra ajustar, e é a hora em que se faz “o que dá” na direção de “o que deveria”. Era algo que esperávamos, mas ainda não tínhamos sentido na pele, o que é bem diferente. Essa é uma parte especialmente importante de tentar se controlar o stress, senão ele vai ser descarregado em outras pessoas do time, o que nunca é bom em nenhuma situação.

Mortem

Nada mostra melhor a última uma/meia hora de evento como a música do Sonic sem ar embaixo d’água. Sério.

O jogo, no fim das contas, não ficou como a gente queria (óbvio). No entanto, ele continha os pontos-chave que gostaríamos de passar. Infelizmente, na correria, não tivemos como testar o jogo e, aparentemente, aquilo que funcionava perfeitamente (em matéria de passar de uma parte pra outra) dentro do editor da Unity, depois de compilado foi pro espaço, então o jogo ficou meio que… sem ter fim. Outra coisa besta que esquecemos e, impressionantemente, faz toda a diferença, foi o score final – afinal de contas, temos que premiar o jogador. Uma parte que era essencial ao gameplay foi a parte dos puzzles, que foi algo que não conseguimos pensar direito – e quando percebemos que o plano original não era tão bom, tivemos pouco tempo pra consertar. Mea maxima culpa, deveríamos ter atrasado a fase de brainstorm inicial e ter definido BEM como seriam os puzzles, pra não ter que repensá-los no meio da correria.

No fim das contas, temos um projeto que queremos bastante completar e fazer direito – e já começamos a planejar direitinho.

Post-Mortem

Ufa! Vamos lá.

O que deu certo:

  • Montar a equipe e definir papéis desde o início: alguém tinha que ser responsável por cada coisa importante, e essa pessoa dava a palavra final. Definimos que, caso chegássemos a um impasse com essa pessoa, teríamos 10-15min pra convencê-la do contrário. Não precisamos usar isso e, na minha opinião, o time se respeitou bem e trabalhou em conjunto o tempo todo, mesmo em situações de discordância;
  • Não fomos pra competir, e sim pra participar. Isso nos deu mais liberdade e mais tranquilidade e, especialmente, nos possibilitou interagir mais com o pessoal ao invés de ficar engolindo as máquinas 24/2;
  • Fizemos um jogo que pode ser expandido agora. O conceito foi bom e é algo que gostaríamos de fazer em qualquer âmbito.

O que deu errado:

  • Por ser um jogo subjetivo, era muito difícil polir o suficiente pra tê-lo pronto em 40 horas. Queríamos não ser explícitos em nenhum momento, mas isso não fica bom a não ser que haja MUITAS iterações em cima, coisa que a gente não teve como fazer. Pra nos adequar melhor aos tempos de avaliação (5 minutos para cada avaliador), tivemos que cortar certas partes e simplificar outras, o que fez o jogo cair num limbo esquisito;
  • Eu mexi pouco com a implementação. Alguém tinha que fazer os assets e tudo mais, mas talvez eu devesse ter diminuído o tempo que eu gastei nisso e trabalhado mais na parte técnica. Um pequeno tweak que eu fiz fez uma diferença grande no feel do jogo, ou seja, talvez se tivesse trabalhando mais nisso e menos em conteúdo, teríamos uma maior polidez;
  • “Ok, vemos isso depois” – aconteceu muitas vezes. Eventualmente, é necessário, mas às vezes pode ser um desastre. Uma peça-chave que foi tratada um pouco assim por todos nós foi a parte do puzzle, mas era minha responsabilidade colocar um pouco de “disciplina” na coisa e falar “ok, isso não pode ser deixado pra depois”;
  • “Precisamos fazer isso agora!” – por não termos internet nem experiência, às vezes gastamos muito tempo fazendo determinadas coisas que não faziam tanta diferença assim – tempo que poderia ter sobrado no final para polir.

Ufa!

Como faltam 5 minutos pra minha aula e eu já falei demais, fecho o post-mortem por aqui. O jogo, assim que der, vai ser colocado pra download no blog. Vamos usar tempo nas férias pra construí-lo como gostaríamos e, depois, vem pra cá também, obviamente.

No fim, agradeço a todos que participaram, sem citar nomes, não porque eu iria esquecer de alguém, mas porque eu não aprendi o nome de quase ninguém! De quebra, parabéns pro pessoal da Anhembi-Morumbi que levou o prêmio principal.

É noise!

É noise!

O grande aprendizado foi o seguinte: quando se tem várias pessoas trabalhando para o mesmo fim, mesmo que elas estejam competindo, elas vão entrar em menos conflitos do que pessoas não-competindo, mas com fins diferentes. Vida louca, mano! Happiness is the road! Sit in the mountain! Quem almeja mon…. bom, vocês entenderam.

Abrax!

[edit]

PS: o Lond colocou o post-mortem dele no ar também! Vale a pena conferir.

· · · · ·

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.

Está lotado de biscoitos.

Está lotado de biscoitos.

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

200 acrônimos em duas frases

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.

"Nosso jogo está genial! Veja a opinião da nossa userbase!"

Basicamente isso que não devemos fazer.

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.

Mas que a mão coça pra comprar, coça.

Mas que a mão coça pra comprar, coça.

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!

Free candy outside 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!

· · · · · · ·

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:

Primeira tentativa. Deu tudo errado, e entrou o material padrão.

Agora o material entra! Mas o shader tá errado, e fica tudo preto.

OK, estamos chegando a algum lugar! Mas seria bom que todos os membros funcionassem...

E este seria um ótimo resultado, se a idéia fosse uma luta entre bonecos de borracha.

Finalmente, o shader funcionou e os Sumokas parecem pessoas normais o/

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 😛

Era isso que acontecia se você tentasse rodar com OpenGL.

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):

Vermelhos com normal mapping, azuis sem.

Observe em especial a diferença nos ombros, e nas gorduras localizadas nas costas 😀

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 🙂

· · · ·

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:

Cuti cuti

Cuti cuti

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.

Ainda não, mas quase lá.

Ainda não, mas quase lá.

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:

Gramas

Damas

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

· · · · · · · · · · · · · ·

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!

Um menu com Z cagado que pra mim ficou muito mais estiloso que a versão final!

O tabuleiro (já um pouco bagunçado)

O tabuleiro (já um pouco bagunçado)

Eles não estão dançando.

Eles não estão dançando.

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!

· · · · · ·

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 😉

· · · · ·

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)

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)

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

· · ·

May/10

19

devoid updates?

Concorremos ao Prêmio "Technologically Impaired Duck" 2010

Concorremos ao Prêmio "Technologically Impaired Duck" 2010

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.

 

 

 

 

 

 

 

 

 

Mentira.

Stay tuned!

· · · · · ·

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!

"Malditos voadores! MALDITOS!"

"Malditos voadores! MALDITOS!"

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.

Não é o Voltaire.

Não é o Voltaire.

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.

Mais ou menos isso, mas com a internet também.

Mais ou menos isso, mas com a internet também. E não só com crianças.

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.

· · ·

<< Latest posts

Older posts >>

Theme Design by devolux.nh2.me