Flash no LinuxConheço muita gente que não gosta de jogos em Flash. Mas muitos deles dizem que não gostam porque não podem programar jogos para ele. Ou porque não podem pagar pelo Adobe Flash, e outros porque usam Linux. Eu já citei algo sobre isso no post Por que eu gosto de jogos em Flash?

Como muitos sabem, a Adobe tem o Flex SDK, que são o compilador e as bibliotecas do Flex Builder, só que OpenSource. Com ele você já tem o suficiente para desenvolver qualquer jogo em Flash utilizando ActionScript 3 e as bibliotecas do Flash.

Então resolvi criar um pequeno guia para iniciar na programação de jogos em Flash no Linux. Eu aqui estou usando o Ubuntu Karmic Koala, mas acredito que não vai mudar muita coisa para outras distribuições.

Instalando o Flex SDK

Primeiro de tudo você tem que instalar o Sun JDK. Se você estiver usando qualquer distro debian-based, você pode instalar direto pelo apt-get assim:

$ sudo apt-get install sun-java6-jdk

Caso esteja usando outra distro, você pode baixar a JDK diretamente pelo site do Java. Agora baixe a SDK do Flex no site da Adobe. É um pouquinho grande, tem cerca de 120MB. Agora extraia o conteúdo do arquivo no diretório /opt/flex, que você deve criar. Supondo que você baixou o arquivo flex_sdk_3.5.zip na pasta Downloads:

$ sudo mkdir /opt/flex
$ cd ~/Downloads
$ unzip flex_sdk_3.5.zip -d tmpflex
$ sudo mv tmpflex/* /opt/flex/
$ rm -rf tmpflex

Pronto, você já extraiu a SDK do flex para a pasta /opt/flex, se quiser ter certeza disso, pode dar um:

$ cd /opt/flex
$ ls

Se você ver um monte de arquivos e pastas é porque deu tudo certo. Entretanto, você precisa adicionar a pasta bin ao PATH, para que você possa chamar o compilador pelo shell. Então faça o seguinte:

$ sudo echo "export PATH=/opt/flex/bin:$PATH" >> ~/.bashrc

Isso vai adicionar  a linha export PATH=/opt/flex/bin:$PATH ao arquivo .bashrc, o que dizer que a pasta de binários do Flex SDK vai poder ser acessada pelo shell. Agora feche todas as suas janelas de terminal, abra uma e teste se tudo está ok:

$ mxmlc --version

Se ele mostrar a versão é porque está tudo funcionando perfeitamente.

Instalando o FlashPlayer Standalone

Depois de instalar o SDK do Flex, você já pode programar normalmente e testar seus SWF’s em um navegador. Mas isso não é aconselhável porque dessa forma você não pode ver os erros de runtime que acontecerem no seu jogo. Então vamos instalar o FlashPlayer Standalone. Primeiro de tudo, baixe o pacote com o player normal e o player com debugger aqui no site da Adobe. Mais uma vez vamos extrair e instalar:

$ cd ~/Downloads
$ tar xzvf flash_player_10_linux_dev.tar.gz
$ cd flash_player_10_linux_dev/standalone/debugger
$ tar xzvf flashplayer.tar.gz
$ sudo mv flashplayer /usr/bin/
$ cd ~/Downloads
$ rm -rf flash_player_10_linux_dev

Pronto, teste agora para ver se o flashplayer foi instalado:

$ flashplayer

Onde programar?

Aqui é a parte onde a programação para Flash no Linux me decepciona um pouco. No Windows nós temos o FlashDevelop, que é uma ótima IDE OpenSource. Para Linux eu testei vários plugins para Eclipse e para NetBeans e, infelizmente, não consegui fazer nenhum deles funcionar. São, em sua maioria, muito antigos e sem suporte para as novas versões dessas maravilhosas IDE’s.

Mas há plugins de colorização de código para editores como o VIM, ou o gedit. Para instalar o plugin de colorização ActionScript 3 no gedit, baixe esse arquivo actionscript3.lang e então coloque na pasta /usr/share/gtksourceview-2.0/language-specs/.

Criando um joguinho em ActionScript 3

Depois de tudo isso, vamos criar algo bem básico só para mostrar como é a programação em ActionScript no Linux. Primeiro de tudo, crie uma pasta para o seu projeto:

$ mkdir asgame
$ cd asgame

Agora então crie uma classe bem básica em AS3:

package {

   import flash.display.Sprite;

   // Define algumas características do SWF
   [SWF(width="640", height="480", frameRate="60", backgroundColor="#00CC00")]

   public class Game extends Sprite {
      public function Game()
      {
         trace ("Jogo iniciado!");
      }
   }
}

Essa é a classe mais simples possível, ele apenas vai ter o fundo verde e vai exibir um texto no console. Salve como Game.as. Para compilar, basta chamar o mxmlc:

$ mxmlc Game.as

Depois para testar, você chama o flashplayer passando o Game.swf (que acabou de ser compilado):

$ flashplayer Game.swf

Você também pode testar isso no seu navegador.

Eu costumo criar um script, ou um alias para fazer isso pra mim. Veja como ficaria um script run.sh:

#!/bin/sh

mxmlc Game.as && flashplayer Game.swf

Então fica facinho compilar e testar a cada alteração no código:

$ ./run.sh

Ou simplesmente criar o alias run para compilar de uma vez:

$ alias run="mxmlc Game.as && flashplayer Game.swf"

E chamar usando:

$ run

Frameworks

Não poderia de citar alguns frameworks para o desenvolvimento de jogos em ActionScript 3.0 (com o Flex SDK):

Não testei a fundo nenhuma das três. Instalei e fiz alguns testes bem básicos com a flixel e com a PushButton, mas nada de interessante que eu possa postar aqui. Por isso vou deixar essa parte para um futuro post.

Conclusão

Eu comecei a criar meu primeiro joguinho em ActionScript 3 com a Flex SDK no Linux há pouco tempo. Já deveria tê-lo terminado, mas não consegui por outros fatores. Entretanto, você pode acessar o código-fonte do BallCanoide em desenvolvimento no GitHub.

No começo eu procurei usar alguns frameworks que eu citei acima, mas percebi que para esse caso eu não precisaria, pois só as bibliotecas do Flash mesmo seriam suficiente. Ainda mais que eu já tinha algum conhecimento delas.

Espero que esse pequeno guia ajude pessoas que não sabem como programar jogos em flash no Linux a começar nessa área. Ainda essa semana eu pretendo escrever um post sobre como utilizar o InkScape para criação de recursos gráficos para jogos em ActionScript com Flex SDK. Já que o Flash trabalha com imagens vetoriais nativamente, nada mais natural que usar SVG. Aguardem. =D

Google Buzz

E-Lixo é definido pela Comunidade Europeia (2003) como um equipamento elétrico ou eletrônico que foi descartado. Se o lixo convencional já um problema sério que até hoje não há soluções definitivas, o que dizer de um lixo que contém inúmeras substâncias tóxicas em sua composição e que cresce estupidamente?

Esse foi o tema de um projeto desenvolvido por mim e mais alguns integrantes na disciplina de Resolução de Problemas, que eu já comentei aqui no post Acessibilidade e Software Livre.

Fomos convidados pela orientadora da pesquisa para apresentarmos esse projeto no Congresso Internacional PBL 2010, que ocorreu no período de 8 a 12 de fevereiro na unidade EACH da USP. Por isso ainda não tinha postado sobre ele aqui no blog, esperei então passar o congresso.

Não vou comentar sobre o assunto do projeto em si neste post, mas aguardem que em breve escreverei algo interessante acerca de nossa pesquisa. Por enquanto, fique com os slides da apresentação:

Se alguém se interessar, temos também uma versão em inglês.

Publiquei o trabalho escrito no Scribd, quem quiser conferir, basta acessar o link: E-Lixo – Como enfrentar este problema com a própria tecnologia.

Gostaria muito de agradecer aos principais envolvidos no trabalho:

  • Fernando Renato Matsunaga Marchiotto
  • Guilherme Augusto Machado
  • João Paulo Domingues dos Santos

Caso alguém tenha alguma dúvida, crítica ou sugestão, pode entrar em contato pelos comentários do post. Espero receber algum feedback. =)

Google Buzz

A Campus Party 2010 começou. Maior evento nerd do mundo que ocorre aqui em São Paulo.

Só nas áreas de Desenvolvimento e Software Livre, podemos ver a grande qualidade e diversidade das palestras. Tem bastante coisa relacionado ao desenvolvimento de jogos, web e programação em geral.

Eu, infelizmente não pude ir esse ano. Entretanto, é possível acompanhar todo o evento por streaming. Eu criei uma página com o streaming de vídeo e a lista de todos os tweets que falam sobre o evento. Se você não foi, ou foi, mas quer acompanhar pelo streaming, acompanhe a campus party aqui!

Ainda estou atualizando e melhorando essa página, para que englobe batante recurso para aqueles que não foram ao evento. Entretanto, já dá pra acompanhar muito bem o evento por vídeo e twitter. Se você não foi, não deixe de acompanhar, tem muita coisa boa mesmo.

Lembre-se que o evento vai até o dia 31/01.

Google Buzz

Uma vez ouvi alguém falar algo do tipo:

Como pode um cego mexer no computador?

E infelizmente, pouca gente sabe que isso é possível. Não culpo as pessoas que não sabem disso, mas por que não as que sabem? Por não divulgarem, talvez?

acessibilidade-mil-assentos

A tecnologia avança tão rápido, e de tal forma, que se faz necessária hoje em dia. Por que discriminar pessoas com alguns tipos de necessidades diferentes? Aposto que se criassem algum aparelho para apenas negros, ou brancos, seriam acusados de racismo. Mas chega de tantas perguntas, vamos começar do início.

Na EACH, Escola de Artes, Ciências e Humanidades da USP, temos um ciclo básico. Algumas disciplinas obrigatórias que são comuns a todos os cursos. Dentre essas matérias, há uma matéria de Resolução de Problemas – baseado no método PBL (ou ABP, em português), aprendizado baseado em problemas – que, a partir de um dado tema problema, os alunos (divididos em grupos) têm de desenvolver um trabalho de pesquisa sobre algo referente ao tema dado e então tirar conclusões. Apesar de muita gente não gostar dessa disciplina, eu acho ela essencial, pois traz inúmeras vantagens. Desde o aprendizado do método científico às informações adquiridas ao assistir e consultar o trabalho dos outros grupos. Mas não é esse o tópico deste post, prometo postar mais sobre o assunto futuramente.

Então, o tema geral foi Conhecimento científico e tecnológico. Assim os grupos poderiam escolher qualquer assunto que tivesse como base o tema proposto. Logo de cara, achei interessante falarmos de algo que pouca gente se preocupa e que é de extrema importância: a acessbilidade. Como eu já tinha certo conhecimento com acessibilidade para deficientes visuais, resolvi que esse era o melhor assunto para abordarmos.

Nosso foco principal, no início do trabalho, era pesquisar e analisar formas de deficientes visuais terem acessos à informática. E pelo pouco conhecimento que eu já tinha na área, sabia que os softwares leitores de tela proprietários não eram muito barato. E como somos todos alunos do curso de Sistemas de Informação, resolvemos tratar (quase) exclusivamente de Open Source. Na verdade, tomamos como base o sistema operacional Windows.

Após algum tempo de desenvolvimento, pesquisas e visitas a instituições de apoio a deficientes visuais, selecionamos três ferramentas que julgamos interessante falar. O DosVox, o WebAnywhere e o NVDA.

nvda_100x100whiteEntão fizemos uma pesquisa sobre cada uma das três ferramentas, e criamos tutoriais básicos  sobre elas. Destacamos o NVDA, NonVisual Desktop Access, uma das melhores alternativas livres quando falamos de leitores de tela. A pedido do nosso orientador, submetemos uma versão do nosso tutorial sobre o NVDA para o Guia do Hardware, que foi aceito e publicado no site: NVDA – NonVisual Desktop Access.

Nossa apresentação foi bem descontraída. Mostramos exemplos de cada uma das ferramentas abordadas na pesquisa. Aqui estãos os slides da apresentação:

O artigo final pode ser encontrado aqui: Softwares Livres para portadores de Necessidades Especiais.

Considerações Finais

Bom, o trabalho foi muito interessante. Apesar de não ter saído exatamente como planejamos. Aliás, esse foi um dos problemas, acho. Não foi muito bem planejado. E muita gente trabalhando junto também, às vezes dá muita bagunça. Mas apesar de tudo, aprendemos muita coisa. Vários erros que não se repetirão.

Os participantes do grupo:

  • André Cavalcante dos Santos
  • Bruno Croci de Oliveira
  • Caio César Lemos Bastos
  • Dan Shinkai
  • Daniel Bissoli Moreira
  • Daniel Pinheiro Barreto

Podem esperar mais posts sobre acessibilidade no blog, eu estou sempre estudando algo em relação a isso, e assim que puder, postarei algo.

Google Buzz
08
Jan

Daqui a pouco vai começar a quarta edição da The Indie Bay Competition. Competição de games de 48 horas.

Eu vou participar. Só não escolhi qual ferramenta vou usar ainda. É muito provável que use Python e PyGame. Vale dizer que eu nunca fiz nada nem com python nem com pygame, não sei nada mesmo. Se eu resolver usá-los, vou ter que correr pra aprender enquanto faço o joguinho.

Outras opções também são Flash e C++ com SFML. Não pretendo usar C++ com Allegro, pois quero aprneder algo novo. SFML é uma ótima biblioteca gráfica, porém acho que seria muito mais complexo aprendê-la do que pygame, uma vez que também nunca mexi com ela.

Dependendo do tema, e da ideia de jogo que eu tiver, talvez usar o Flash seja a melhor opção para deixar um jogo mais polido, e que tenha mais audiência na internet.

Cafe Eu sei que alguns aqui iriam reclamar por eu postar um pouco tarde (falta pouco mais de cinco horas pro início da competição), mas esse post foi mais pra informar que eu vou participar mesmo. Claro que eu espero que mais gente aqui tente participar, porque vai ser bem interessante. E independente da linguagem ou da ferramenta, é muito provável que eu use o GitHub para hospedar o código, se você quiser acompanhar, acesse meu perfil. Além disso, também irei postar sobre a competição no twitter usando a hashtag #tibcompo.

É isso. Espero que quem puder participar, aproveite. Vai ser bacana.

Google Buzz
Web Analytics