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

TAG | Dystopia

 

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!

· · · · · · · · ·

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

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

Theme Design by devolux.nh2.me