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

TAG | SumoCheckers

 

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

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

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

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

Download: Dystopia e Sumocheckers

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

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

· · · · · · · · ·

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!

· · · · · ·

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!

· · · · · ·

Howdy!

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

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

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

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

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

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

"...o quê?"

"..."

Calma, já vamos chegar lá.

1- A idéia Inicial

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

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

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

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

2- Dois caras

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

Te lembra alguma coisa?

Checkers

"Damas!"

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

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

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

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

3- SumoCheckers

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

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

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

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

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

4- Where do we go now?

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

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

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

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

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

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

5- O que VOCÊ pode tirar disso?

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

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

Links adicionais:

· · · · ·

Theme Design by devolux.nh2.me