Nuss… E Agora?!?

27ago/071

Um por todos e todos por um: as diversas profissões necessárias para fazer um jogo (parte 2)

Continuando o artigo, hoje falarei da parte técnica, o pessoal que ta em contato direto com o código ou programa. Esse grupo é composto por:

  • Gerentes de Projeto

São o cérebro por trás do bom andamento de um jogo. São eles os responsáveis por fazer todo esse monte de profissionais pensarem e trabalharem em conjunto. Eles organizam cronogramas, delegam funções e cobram prazos. Por inúmeras vezes são eles o contato do grupo de trabalho com o cliente, o que faz com que não seja difícil encontrar o Game Designer como o Gerente do Projeto.

  • Analistas de Sistema

Os analistas são responsáveis por traduzir para diagramas tudo aquilo que o Game Designer quer. Esses diagramas funcionam como a planta de uma casa, indicando para os programadores a forma exata que eles devem programar. Dessa forma, podemos pensar nos Analistas como os arquitetos do projeto

  • Programadores

Se os analistas são os arquitetos, os programadores são os pedreiros. São os responsáveis por pegar aquela papelada toda que os analistas fizeram e implementar, para que o programa venha a existir. Existem programadores de diversos tipos: existem aqueles que só trabalham com algumas linguagens ou paradigmas de programação, existem aqueles que só trabalham com um tipo de tarefa, como Inteligência Artificial, Interface, Redes ou Banco de Dados.

  • Bug Testers

São os caras responsáveis por identificar bugs no programa, descobrir como eles funcionam e reportá-los para que os programadores possam corrigir.

  • Administrador de Banco de Dados (DBA)

Esses caras são os responsáveis por gerenciar aquele banco de dados gigantesco onde estão guardados todos os personagens do seu servidor. Eles fazem cópias de segurança, procuram por novas tecnologias e melhoram o banco de dados para que ele funcione da forma mais rápida possível.

  • Administradores de Rede

Esses caras são os responsáveis pela segurança e bom funcionamento dos servidores de jogo. Fazem desde o bloqueio de ataques hacker à busca de melhorias na velocidade de transferência de arquivos.

Listei hoje somente algumas das profissões técnicas que um jogo pode ter. Por exemplo, imagine que, se o jogo exige um novo joystick ou outro tipo de periférico, também teremos que ter uma equipe toda responsável pela criação dele e também um grupo responsável pela interação entre os dois.

No próximo artigo eu vou falar da parte humana, um grupo horrendamente nomeado por mim que designa aquele grupo de profissionais que trabalham com os aspectos humanos do jogo, como marketing, publicidade. Portanto, até lá.

[EDIT]: Aqui estão os links para as Partes 1 e 3 do artigo

25ago/071

- Pára tudo! -

Agora pouco, quando eu visitava o servidor que controla as estatísticas de acessos do Nuss... E Agora?!? vi que tinha um link pelo qual 2 pessoas visitaram o blog.

Imaginem minha surpresa que, ao visitar o link, encontrei uma matéria sobre o Nuss! O blog é o do Rodrigo Flausino que, de uma forma muito amistosa, dedicou um pouco do seu tempo para falar bem desse trabalho que tenho realizado.

Flausino, estou aqui agradecendo muito à essa força que me deu, mesmo sem nunca termos conversado. Quero também parabenizá-lo pelos artigos sobre o mundo dos jogos, principalmente por esse sobre o efeito do clima em jogos, a divulgação do gamedevmap (genial essa idéia!), e, principalmente, essa resenha sobre a matéria da Veja sobre o crescente realismo dos jogos eletrônicos.

Teu blog já está permanentemente linkado e devidamente assinado. Recomendo que façam o mesmo, pessoal: tem muita coisa sobre entretenimento digital lá que não dá prá perder..

- Agora sim voltemos à programação normal

25ago/072

Um por todos e todos por um: as diversas profissões necessárias para fazer um jogo (parte 1)

Um GRANDE erro recorrente quando falamos em desenvolvimento de jogos é achar que basta aprender a programar para tirar aquela idéia da cabeça e trazê-la para a realidade.

Existem várias profissões ou competências relacionadas diretamente ao desenvolvimento de um software comum e, no caso de um jogo, esse número aumenta ainda mais. Todos eles trabalham em conjunto para que um jogo venha à luz do mercado. Para facilitar o entendimento, vou quebrar esse conjuntão de competências nos seguintes grupos: parte técnica, parte artistística, parte humana. Hoje veremos a parte artística:• Game Designer
O Game Designer é o cara das idéias. É ele quem idealiza o jogo, pensa nas regras e perde tempo imaginando como o mundo e os personagens serão. Um Game designer também é responsável por supervisionar o grupo de produção, garantindo que suas idéias sejam seguidas à risca. É também responsável por realizar todas as pesquisas para garantir a viabilidade de suas idéias, como as pesquisas de mercado. Ah, o Game Designer também tem que ser muito bom escritor e sacar bastante de psicologia, já que tem que criar personagens reais e descrever muito bem o mundo em que o jogo vai se passar.

• Roteiristas
Como os roteiristas de um filme, mas aqui escrevendo o roteiro do jogo. Quando um Game Designer entrega uma história simples, são eles os responsáveis por deixá-la viciante e incrível.

• Artistas Gráficos
Artistas gráficos ou Art Designers são aqueles responsáveis por transformar em desenhos aquelas idéias que o Game Designer tem, quando ele não é capaz de desenhar tão bem assim. Muitas vezes são os caras responsáveis também pelas ilustrações dentro do jogo (como sprites ou texturas), quando essas funções não estão subdivididas. Tem artistas que definem o estilo visual do projeto, tem artistas que só copiam esse estilo para as diversas outras coisas a serem desenhadas e tem aqueles que simplesmente colorem desenhos já prontos.

• Modeladores
Os Modeladores são como os caras dos desenhos, mas fazem a parte 3D. Sabe aquela árvore show de bola, aquela arena foderosa ou aquele monstro perfeitão? Então, isso tudo é coisa dos Modeladores. Modeladores 3D podem trabalhar só em locais (como Mappers), só com animações (como Animadores), ou até mesmo só com os modelos 3D de objetos específicos, como armas ou prédios.

• Compositores
Aha! Aí está todo o pessoal da música, a parte mais ligada ao roteiro que qualquer outra em um jogo. Não adianta ter uma cena linda sem uma trilha sonora que defina exatamente aquilo que se vê. Tem compositores que compõem os efeitos sonoros, enquanto outros compõem as músicas, o que chamamos de trilha sonora.

Vale lembrar a todos que, apesar desse monte de competências listadas, elas são só algumas de todas. Vários projetos têm mais competências, enquanto outros não possuem a metade de todas as listadas aqui. Tudo depende da disponibilidade de dinheiro, de profissionais e se aquilo se aplica ao projeto (prá quê roteiro se meu jogo é um xadrez?).

No próximo artigo, falarei da parte técnica: programadores, analistas, projetistas e todos esses caras que trabalham com o código do jogo. Até lá!

[EDIT]: Aqui estão os links para as Partes 2 e 3 do artigo

23ago/073

Orientação a Objetos: Q raios é isso!? (parte 3)

Voltemos ao exemplo anterior dos contêineres. Como vocês se lembram, quando eu joguei o método fechar() na classe Mãe, eu fiz com que ele fosse acessado por todas as classes filhas, por herança. “Claro, senão você não vai poder fechar nada” você diz. Concordo plenamente com essa observação, mas vamos parar pra pensar no seguinte: será que uma caixa, uma bolsa, uma garrafa e uma mala são fechadas da mesma forma?

Ouvi alguém dizer “É claro que não!” aí! É claro que não são fechadas do mesmo jeito. “Mas Tiago, se eu tenho um fechar() que é igual para todo mundo, como que vou fazer para fechar uma mala se é diferente de fechar uma garrafa?”. Aí que ta o negócio, eles não são necessariamente iguais para todo mundo.Quando você diz que a classe mãe tem o método fechar(), você diz que todas as classes filhas TAMBÉM possuirão o método fechar(), mas não necessariamente que todos os fechar() serão iguais. Isso é o que chamamos de Polimorfismo.

Logo assim que herdamos fechar(), podemos reescrever esse método em cada uma das classes filhas, mudando essa forma de fechar cada uma delas. Polimorfismo, ao pé da letra, significa “Capacidade de alguma coisa possuir várias formas”.

Poderíamos também sobrecarregar o método ligar() da classe Eletrodoméstico para que pudéssemos ligar uma televisão, um computador, uma geladeira e um vídeo-cassete.

Parecido com o Polimorfismo, temos o conceito de Sobrecarga. A Sobregarga é um tipo de Polimorfismo, mas possui algumas sutis diferenças. Imagine aquela Arena Multiuso do Pan, onde tivemos as competições de Basquete e Ginástica Olímpica. Dependendo do tipo de competição, a estrutura do ginásio é mudada. Se temos o método prepararParaCompeticao(), podemos dizer que, se prepararParaCompeticao receber Ginástica Olímpica, ele vai funcionar de forma diferente de quando receber Basquete. Ginástica Olímpica e Basquete são o que chamamos de parâmetros do método.

Sempre que temos O MESMO MÉTODO funcionando de formas diferentes dependendo dos parâmetros que foram passados, nós temos sobrecarga.

Como o intuito do blog NÃO é ensinar programação, não vou fazer que vocês se percam em linhas de código. O mais importante é que vocês entendam esses conceitos básicos e possam aplicá-los a quaisquer linguagens que queiram aprender.

É claro que, às vezes, teremos umas linhas de código em Action Script 3.0. Tenho que falar do Jogo, afinal de contas. A diferença é que elas serão meramente ilustrativas,ajudando a explicar algum problema de design ou projeto.

Falando nisso, acho q já é hora de voltarmos a ver coisas mais abrangentes, não? Então esperem para saber um pouco sobre os diversos profissionais que, juntos, são responsáveis pela concepção de um jogo. Até lá!

[EDIT] Links para as outras partes da matéria? Taê! Parte 1 e Parte 2

20ago/071

Orientação a Objetos: Q raios é isso!? (parte 2)

Continuando o artigo anterior, o básico da Orientação a Objetos pode ser entendido como um conjunto de classes e objetos que se relacionam. Hoje vou definir essas relações, começando pelo mais importante de tudo:

  • Encapsulamento

Vamos pensar num cofre. Ele tem uma área externa, com uma maçaneta para abrir/fechar a porta e um display onde você entra com a senha para destravar a porta. Essas partes às quais todos nós temos acesso, na orientação a objetos, são chamados de parte pública, sejam eles atributos ou métodos.

Nessa altura, nosso cofre está assim:

E pra que serve um cofre??? Ponto para quem disse que é para guardar as coisas. Na parte de dentro, protegido do acesso de pessoas indesejáveis, estão as coisas guardadas. Esse conteúdo protegiddo do acesso das pessoas é o que chamamos, em orientação a objetos, de parte privada. Como a parte pública, a parte privada pode ter métodos ou atributos. Nossa classe então ficaria assim:

E se você permitisse a somente algumas pessoas especiais o acesso ao conteúdo desse mesmo cofre, essa parte privada se tornaria uma parte protegida. Novamente, uma parte protegida pode ser composta por métodos, atributos ou ambos.

Encapsulamento é justamente isso: dar proteção diferente às diferentes partes de uma classe. Quando um atributo ou método é privado, somente a própria classe pode acessá-lo e usá-lo (somente o cofre pode tocar seu conteúdo). Se fosse público, qualquer classe poderia utilizar-se daqueles métodos ou atributos (qualquer um que passar poderá ir lá e entrar com uma senha no cofre). Agora, para explicar exatamente como funciona uma área protegida, temos que falar de herança.

  • Herança

Voltemos ao Cofre. O cofre é um tipo de contêiner, um objeto que contém outros objetos. Guardadas as devidas diferenças, um cofre é como uma bolsa, uma caixa, uma garrafa ou uma mala. Todos são feitos de algum material, guardam uma quantidade de coisas dentro e podem ter ou não uma senha. Você pode colocar ou retirar coisas do contêiner, bem como abrir e fechá-lo. Esses são, respectivamente, atributos e métodos intrínsecos do objeto: aquilo que todos os objetos daquela família possuem.

Quando falamos em herança, nós pegamos esses atributos intrínsecos e jogamos numa classe especial, a classe mãe. Todas as classes daquele tipo, os CONTÊINERS, herdam da classe mãe os atributos e métodos que ela tem a oferecer. A relação de nossas classes fica então assim:

Nesse tipo de relacionamento, existem as classes mães e as classes filhas. Quando uma classe (agora chamada de filha) herda algo de uma outra classe (agora chamada de mãe), ela passa a possuir não só aquilo que é dela, mas também aquilo que a classe mãe tem. Esses atributos que só a classe filha tem são os chamados atributos extrínsecos, coisas não comuns a todos os indivíduos daquele tipo. Adicionando alguns extrínsecos nas classes filhas, tudo ficaria assim:

Nesse exemplo, CAIXA, além de possuir o atributo “tampa”, possui os atributos “material”, “conteúdo” e “senha” por herança. Também por herança ela possui os métodos “colocarCoisaDentro()”, “retirarCoisaDeDentro()”, “abrir()” e “fechar()”. É assim que a herança funciona na orientação a objetos: passando tudo da classe mãe para a classe filha.

“Ta, ta. Mas e o raio do Protected???” Pois então, quando você define que um atributo ou método é Protected, você está permitindo acesso SOMENTE às classes filhas.

Vale lembrar que, quando fazemos uma herança, a gente pega cópias do que está escrito e joga naquela classe. Herança não significa que estamos gastando o dinheiro dos nossos pais milionários e sim que agora o dinheiro é todo nosso.

No próximo artigo, pretendo falar sobre sobrecarga e polimorfismo. Até!

[EDIT] Pegaê links para as Partes 1 e 3 do artigo!

15ago/075

Orientação a Objetos: Q raios é isso!? (parte 1)

Hoje eu vou falar do paradigma de programação que escolhemos para fazer o Jogo, a Orientação a Objetos. Ela começou lá pela década de 60 acompanhando uma tal Engenharia de Software, que falava, na época, sobre os problemas que os programadores teriam com a crescente complexidade dos programas.

Não vou entrar em detalhes avançados sobre isso ainda, mas basta saber que a Orientação a Objetos foi criada para simplificar o desenvolvimento de grandes programas, tornando o código muito mais fácil de entender e alterar o código-fonte.

Ela parte do princípio de que TUDO num programa pode funcionar como objetos no mundo real, possuindo suas características, operações e relacionamentos com outros objetos.

  • Classe

Tudo que temos num programa Orientado a Objetos vem de uma ou várias classes, sendo uma espécie de fôrma na qual as coisas são moldadas. Uma classe deve ser sempre genérica, possuindo todas as características daquilo que ela representa.

Pensemos em um BLOG. Ele tem um template, um nome, assunto e dono, certo? Essas características são os atributos da classe BLOG: substantivos que separam um BLOG de um PROCESSADOR DE ALIMENTOS. As ações do BLOGGER, como “exibir artigo”, “atualizar artigo”, “mudar de template” ou “editar html” são o que chamamos de métodos. Essa classe então, ficaria assim:

  • Objeto

Um objeto nada mais é que um indivíduo feito numa classe. “Mas hein?”, você me diz. Bom, voltemos ao exemplo anterior do BLOG. Todos vocês sabem que existem trocentos blogs perdidos pela internet. Todos eles são blogs, mas possuem características diferentes entre si: cada um possui um nome diferente, com templates e donos variados. O Nuss... E Agora?!? é diferente do Vovó viu a Rede em diversos aspectos, porém ambos são iguais em uma coisa: são BLOGS.

“Ser um BLOG” é o mesmo que ser um Objeto, Instância ou Ocorrência da classe BLOG.

Utilizando o gancho desse exemplo, objetos são diversas instâncias ou ocorrências (diversos blogs na internet) de uma mesma classe (BLOG), dividindo atributos iguais (Nome, Dono), mas sendo diferentes no valor desses atributos (Vovó viu a Rede, Mário Marinato; Nuss... E agora?!?, Tiago Frossard).

  • Mensagem

“Joaozinho, vai lá na sala e pega o aspirador de pó, meu filho” ... “Toma, mãe, tá aqui”. Pronto, você acaba de entender o conceito de mensagem.

Mensagem nada mais é que um Objeto pedindo para que o outro faça alguma coisa pra ele. Se a mãe está ocupada fazendo muitas coisas, por quê não delegar à outra pessoa a responsabilidade de ir buscar o aspirador de pó?

Bom gente, esse é o básico do básico. Nos próximos artigos eu vou falar sobre herança, encapsulamento e outras coisas um pouco mais avançadas. Então pessoal, até lá!

[EDIT] Seguem os links para a Parte 2 e a Parte 3 do artigo!

13ago/075

Paradigmas de Programação: Estilos diferentes de escrever o mesmo texto

Lembram-se desse exemplo onde eu falei de um código como se fosse um texto? Pois então, bem como um texto, um código fonte pode ser escrito de diversas formas diferentes.

 

Se você está escrevendo em prosa, vai escrever como o Nuss... E Agora?!?, utilizando linhas contínuas. Vai escrevendo palavra por palavra até chegar ao final da linha, daí passa pra outra, e pra outra, e pra outra... Isso é diferente de uma redação em poesia, que você divide o texto em diversos versos, que não preenchem toda a linha. Você também pode escolher se quer fazer uma narrativa, escrever em linguagem culta ou qualquer outra das inúmeras formas diferentes de se escrever.

 

Agora pense comigo: se aquele mesmo texto pode ser escrito de acordo com essas inúmeras regras e diferentes estilos em prosa, verso, de forma culta ou coloquial, por que não dar também estilos ao código-fonte?

 

Cada linguagem de programação aceita um estilo ou grupo de normas para que você escreva o programa e não se perca naquele texto todo. Esse estilo é o que chamamos de Paradigma de Programação. Talvez os 2 mais comuns hoje em dia sejam:

 

  • Programação Procedural

 

Nesse tipo de programação, o programa é dividido em partes menores, que são então divididas em partes menores ainda, e menores, e menores, até que aquele problema gigantesco seja transformado em trocentos problemas menores. É o famoso “Dividir para conquistar”.

 

Por exemplo, eu quero um programa que me gerencie as notas dos alunos de uma escola. Para isso, o programa tem que ser capaz de ler esse monte de notas e alunos, realizar as médias, me dar os valores das notas finais, calcular quem passa e quem fica de recuperação. Tem que ser capaz também de recalcular baseado nas recuperações e mais uma pá de outras funções que não vêm ao caso.

 

Nesse exemplo, fica muito mais fácil quebrar o programa em partes menores e resolver cada uma dessas partes: uma parte que faz a média dos alunos, uma que lê as notas, uma que me mostre quem passou e quem ficou de recuperação... A gente vai “dividindo e conquistando” cada pedacinho até que o programa todo esteja conquistado.

 

Na Programação Procedural, essas inúúúúúúmeras pequenas partes que, juntas, realizam todo aquele funcionamento gigantesco podem ser chamadas por vários nomes, como funções (functions), procedimentos (procedures) e rotinas (routines).

 

  • Programação Orientada a Objetos

 

Esse estilo de programação é muito parecido com a Programação Procedural, mas tem uma diferença principal. Na Programação Orientada a Objetos (Object-Oriented Pogramming, POO ou ainda OOP) a idéia principal é fazer com que o programa e seu funcionamento se pareçam ao máximo com o mundo real, visando entender melhor aquilo tudo que está escrito. Na POO, cada uma das funções ou procedimentos do programa estão dentro do que a gente chama de classe.

Cada classe representa um objeto do mundo real, possuindo suas características e ações. Então, criando aquele programa anterior, teríamos classes para Alunos e classes para Notas, por exemplo.

É um paradigma muito utilizado nos dias de hoje, principalmente quando falamos em criação de jogos ou outros programas de alta complexidade.

Existem vários tipos de problemas diferentes no mundo e nem todos os paradigmas são bons para todos os tipos de problemas. Para isso, existem paradigmas para diversos tipo de problema diferentes.Programação em Lógica vai transformar e resolver tudo utilizando a Lógica Matemática: Se rosas são flores e flores são bonitas, então rosas são bonitas. Esse exemplo simples de lógica matemática também é o usado, por exemplo, para dizer quem são seus tios e seus avós em uma árvore genealógica.

Já a Programação Funcional transforma todo o funcionamento do mundo em funções matemáticas, resolvendo os problemas com aqueles f(g(h(x))) que estudamos em matemática (e que muitos de nós fizeram(mos) questão de esquecer).

Uma Programação Híbrida reúne mais de um paradigma de programação. Normalmente atribui-se esse nome a um programa que possua partes orientadas a objetos e partes procedurais, mas tecnicamente pode ser um conjunto de quaisquer paradigmas.

Pois então, gente. É isso. Se eu falei alguma besteira aqui ou alguma coisa ficou enrolada, por favor, avisem! Só com o retorno de vocês que o Nuss... e agora?!? poderá crescer! Portanto, deixem seus comentários. Até a próxima!

9ago/073

A Máquina Virtual

Entender o que é e como funciona uma Máquina Virtual é extremamente importante quando queremos entender conceitos como portabilidade e multiplataforma.

Para entendermos uma Máquina Virtual, precisamos entender primeiro como funciona a programação. Quando a gente está programando, a gente está criando um texto que vai indicar o que cada coisa vai fazer. É como se a gente escrevesse uma longa lista de ordens, como “Quando clicar no botão sair, feche o programa” ou “Se for sair do programa sem ter salvo o arquivo, mostre ao usuário que o arquivo não foi salvo e pergunte se ele quer salvá-lo”, só que em uma linguagem diferente, como Inglês, Japonês ou Polonês.

Essa “linguagem diferente” é o que a gente chama de Linguagem de Programação. Existem várias dessas linguagens por aí, como C, Pascal, Java, C++, PHP e Action Script 3.0. O texto digitado (que chamamos de Código-fonte) é então compilado ou interpretado: Compilar um código-fonte significa transformá-lo em um programa, enquanto interpretar significa lê-lo para extrair dele as ordens a serem executadas.

Interpretando ou compilando, a linguagem de programação, no fundo, vai traduzir pro computador tudo aquilo que eu quero que ele faça e vai traduzir pra mim tudo aquilo que o computador me responde, como no diagrama abaixo:

“Mas e a Máquina Virtual???”, você pergunta. Já estamos chegando lá. Quando nós compilamos o código-fonte e transformamos ele em um programa complexo, acontece uma coisa indesejável: aquele programa funcionará somente no sistema operacional onde foi compilado. Ou seja: compilou no Windows, não vai funcionar no Linux. Isso faz com que a gente tenha que reescrever várias coisas no programa prá que ele funcione em outros Sistemas Operacionais. Esse é o exemplo de um programa de Baixa Portabilidade.

 

A Máquina Virtual funciona como um meio-termo entre o programa e o Sistema Operacional. Quando fazemos um programa em Java ou Action Script 3.0, por exemplo, não precisamos nos preocupar em escrevê-lo para diversos Sistemas Operacionais diferentes: a Maquina Virtual já traduz aquele código automaticamente, sem que a gente saiba como isso foi feito (o que chamamos de Forma Transparente), como no diagrama abaixo.

Não entendeu? Hmmm.... vejamos: Imagine que estejamos escrevendo um livro em português. Para ganhar mais com o livro, por quê não publicá-lo em outros países? Seguindo a idéia de uma linguagem SEM MÁQUINA VIRTUAL, teríamos que reescrever o livro em inglês, alemão e holandês.

 

Porém, se tivéssemos um tradutor, ao invés de escrevermos o texto em 3 línguas diferentes, escreveríamos em uma linguagem que nosso tradutor entendesse e ele sim traduziria para inglês, alemão e holandês.

 

Nesse exemplo, o tradutor seria a Máquina Virtual, enquanto o texto seria nosso Código-fonte. Cada país é um Sistema Operacional e a capacidade do mesmo texto chegar em diversos países é a Portabilidade dele. Se o texto foi traduzido com sucesso e alcançou diversos países, ele é considerado Multiplataforma.

Vale lembrar que esse funcionamento é bem diferente do padrão da maioria das linguagens, que devem ser compiladas pros diversos Sistemas Operacionais.

 

Pois então, agora que já sabemos como funciona uma Máquina Virtual, é hora de falarmos de uma coisa mais complexa. No próximo artigo vou explicar o que são os Paradigmas de Programação e falar um pouco sobre os mais comuns. Até breve!

5ago/072

E por quê o Action Script 3.0?

Essa é uma pergunta curta de resposta longa. Poderíamos listar aí uma porrada de razões, mas acho que as principais foram:

Integração com o Flash:
O Flash é genial para fazer interfaces 2D. Não conheço nada melhor e, sinceramente, duvido que haja algo mais prático para fazer as trocentas animações, efeitos visuais e coisas do gênero. Como brinde, o Flash CS3 tá aplicando filtros dinamicamente, como no Photoshop. Não entendeu nada? É simples: se eu quiser adicionar uma sombra a uma árvore e movê-la 360o quando um personagem soltar uma magia, não preciso fazer quase nada: já ta tudo pronto.

Orientação a Objetos:
O Action Script 3.0 é completamente Orientado a Objetos, um paradigma ou estilo de programação que se aproxima muito do que temos no mundo real. Com isso, podemos aplicar os padrões de qualidade dos programas da atualidade, facilitando e MUITO a programação do código e a reutilização dele.

Portabilidade com rapidez e leveza:
Com o Flash eu posso fazer o Jogo da mesma forma para diversos Sistemas Operacionais, como Linux, Mac e Windows. Posso até fazer para celulares sem muitas modificações. Isso é o que chamamos de portabilidade e é alcançada graças ao conceito de Máquina Virtual.

O pessoal que já saca um cado de programação pode dizer: “Mas o Java já não faz isso???”. Sim, o Java já faz isso há muito tempo.

O Java é uma outra linguagem de programação. Muito famosa e usada, até mesmo o Action Script 3.0 se baseou nela. A diferença é que o Java é muito pesado e lento, além de não possuir uma interface nativa (uma parte gráfica padrão) tão poderosa quanto à do Flash. Em contraste, o Flash sempre foi rápido e leve: um computador antigo consegue controlar várias animações na tela sem ficar lento. A grande diferença é que agora ele está 10x mais rápido! Refizeram essa tal Máquina Virtual do Flash por causa dessas novas mudanças.

Agora, prá quem não sabe o que é exatamente essa tal Máquina Virtual, nosso próximo artigo será explicando bem o que isso significa. Então gente, até lá!

3ago/070

A Escolha do Flash

Lá atrás, há mais de 1 ano, quando abrimos mão de todas as alterações para retomar o design original, tínhamos que encontrar alguma tecnologia que nos permitisse refazer rapidamente tudo aquilo que já estava feito antes, tanto em código quanto em visual.

Foi assim que, conversando com meu parceiro de projeto, o Douglas, fiquei sabendo das possibilidades do Flash. Tá, eu já ouvia falar do Flash pra o desenvolvimento de sites, mas tudo que eu sabia dele ainda era muito abaixo do que necessitávamos. Queriamos um programa para fazer um jogo, não um site. Isso não sabíamos se ele faria.

Douglas deu uma pesquisada nos fórums e viu que era uma ferramenta muito mais poderosa do que achávamos. Era a época do Flash MX, programa que resolvemos adotar para fazer nosso Jogo. Ele conseguiu ser a coisa mais bipolar que eu já vi na vida.

Ao mesmo tempo que era muito fácil fazer diversas coisas no Flash, como animações e interface no geral, era muito complicado seguir nosso paradigma de programação, a Orientação a Objetos. Tudo era muito engambiarrado, cheio dos conhecidos “jeitinhos brasileiros” para que funcionasse. Ele era muito poderoso, mas não supria nossas necessidades. Foi um verdadeiro inferno.

Enquanto pesquisávamos a solução de alguns problemas, descobrimos a existência de um tal Ellipsis, um pacote de atualização pro Flash MX q resolvia problemas gravíssimos para nosso projeto. Verdade seja dita: o tal do Ellipsis resolveu muitíssimos dos nossos problemas, mas não todos.

Os problemas eram causados pelo tal Action Script 2.0, a linguagem de programação do Flash naquela época. Era em AS2.0 que a gente dizia o que acontecia quando clicávamos em um botão, ou que controlava quem causava dano em quem, o quanto causava, quem estava vivo e quem estava morto.... O problema é que ele pirava em coisas simples por não ser uma linguagem de programação que estava 100% integrada ao paradigma em que fazíamos o projeto.

Terminado nosso Projeto Final, continuamos a trabalhar no Action Script 2.0 para acertar aquilo que não estava do jeito que queríamos. Isso durou poucas semanas, graças a Deus, pois ficava cada vez mais penoso trabalhar com aquele catiço. Foi quando, mais uma vez, Douglas avisou-me sobre o Flash.

Dessa vez, ele me disse sobre o tal do Action Script 3.0, uma tal revolução aí na programação em Flash. O Action Script 3.0 era completamente Orientado a Objetos, o paradigma que nós escolhemos para fazer nosso jogo. Isso facilitaria muito na hora de passarmos pro Jogo tudo aquilo que queríamos que ele tivesse: agora o Jogo ia ser exatamente aquilo que estávamos querendo que ele fosse.

Na próxima eu vou falar um pouco sobre o Action Script 3.0 e as razões de tê-lo mantido como linguagem principal do Jogo. Até lá!