Nuss… E Agora?!?

5dez/074

Personalize seu Jogo!

Esse fim de semana consegui o Need for Speed: Carbon (valeu Willian). Velhinho, sim, mas mesmo assim eu instalei pra testar. Primeira impressão foi de estar jogando um GTA só com carros. Provavelmente a impressão veio da tela de jogo: essa engine aí da cidade gigantesca com o radar+mapinha, saca? Deixa tudo com a mesma cara. Porém, se uma coisa me incentivou a criar essa matéria, foi a personalização do NFS:C.

20out/072

MVC e o Linkage: O que se deve ou não fazer? (parte 2)

Agora que todos já sabem como funciona o MVC, vou continuar com a 2a e última parte do artigo. Hoje vou mostrar os pontos positivos e negativos da implantação da arquitetura, além de finalmente mostrar o que isso tudo tem a ver com o Linkage.

Pontos positivos:

  • Abstração e desacoplamento das camadas

Quando estamos programando a interface do problema, não nos preocupamos com a programação da lógica dele, somente com o que vai e o que vem dela. Dessa forma, podemos facilmente simular todo o funcionamento da lógica do programa com uma classe de testes que simula o funcionamento da lógica. Esse é o conceito de caixa preta, importantíssimo para o bom funcionamento de um software.

  • Facilidade de manutenção

Graças a esse desacoplamento, é muito mais fácil realizar a manutenção de um programa desses. Se for um problema visual, você vai à camada responsável pelo visual do programa e pronto, corrige. Se for um problema de lógica, é na lógica que você buscará a solução. Além disso, graças ao padrão Controlador (Controller), você pode apagar toda uma janela sem perder nada de sua implementação.

Quem está acostumado a adicionar código em um botão sabe exatamente o trabalho que isso ta poupando, mas para quem não está, aí vai um exemplo. Sabe esse Mario 2 que refizeram em 3D pro Nintendo DS? Se eles não usaram o MVC para fazer o original, perderam uma gigantesca parte da lógica do programa só por trocar a interface. Em compensação, usando o MVC de forma correta eles trocariam toda a interface sem mexer em 1 linha da lógica.

  • Possibilidade de Expansão

A estrutura de camadas proposta no MVC pode (e deve) ser expandida: criar mais camadas aumenta a coesão e diminui o acoplamento, organizando melhor o seu código. No jogo, por exemplo, além da Lógica e da Interface, temos a camada de Comunicação (rede) e a camada de Armazenamento (Banco de Dados), além das camadas entre elas. Um outro jogo pode, por exemplo, ter uma camada de IA, uma camada de hardware e uma camada de comunicação com outro jogo. O nosso, inicialmente, está assim:

piramide

As camadas se comunicam através de Indireções, como os já citados padrões Controlador, Proxy e DBBroker. Isso claro, pode mudar durante a análise de Casos de Uso mais avançados, mas inicialmente, essa é a idéia. Além disso, o funcionamento desses padrões vai ficar para futuros artigos.

  • Facilidade de realização de testes

Com o programa modularizado, podemos criar classes de teste que rodam nosso programa à exaustão, podendo encontrar bugs estatisticamente impossíveis de encontrarmos. Mas sabe qual é o melhor? Você pode testar isso tudo sem ter NADA de interface pronta: a lógica fica tão independente que chega a funcionar sem a interface. Então não precisamos esperar que o pessoal do desenvolvimento resolva aquele problema dos relatórios para que o pessoal do teste disseque nosso Caso de Uso. Maneiro, não?

Pontos negativos:

  • Programação complexa

A programação torna-se mais complexa quando aplicamos o MVC. Chamadas consecutivas e abstração do código são extremamente importantes. Além disso, uma documentação de todo o projeto é imprescindível para que as camadas sejam mapeadas e seguidas da forma correta. Além disso, teremos o...

  • Uso extensivo de padrões de projeto

O MVC simples já dita o uso do padrão Controller. Expandindo camadas de Comunicação e Armazenamento, ainda usaremos Proxies como o Remote Proxy e Database Brokers. Para desacoplar essas camadas, criaremos várias classes baseadas nos padrões Indireção (usado para desacoplar 2 classes que não deveriam ter visibilidade entre si) e Invenção Pura (padrão que adiciona classes que não estão diretamente ligadas ao problema em si, mas que facilitam a solução dele). No final, a relação entre as classes é bem mais burocrática

  • Dependência do MVC na portabilidade

Para poder portar um código MVC de forma correta, o programa que irá recebê-lo precisa trabalhar nos moldes do MVC. Por exemplo, se estamos portando uma janela de cadastro de cliente já pronta para um programa parecido, ele tem que estar modularizado de forma a trabalhar com a classe Controladora para que a manutenção seja mínima. Isso causa uma certa dependência à estrutura.

  • Queda de performance

As mensagens trocadas navegam entre camadas de forma burocrática e indireta, o que faz com que os programadores “performance acima de tudo” reclamem bastante. Por exemplo, uma chamada a uma função que seria direta numa programação estruturada torna-se uma cadeia de várias subchamadas a métodos que somente levam a chamada para a próxima camada nessa estrutura, como vocÊs viram no diagrama de seqüência lá em cima.

A performance perdida está longe de ser relevante, principalmente com os processadores de hoje em dia, mas mesmo assim continua sendo um ponto negativo da arquitetura.

“Ta, ta, eu entendi o MVC. Mas o quê que o Linkage tem à ver com isso???” O linkage do Flash é uma facilidade ao trabalhar com a interface, pois permite que uma classe use os atributos do MovieClip como se fossem atributos de si mesma. A grosso modo, parece muito uma herança de atributos e métodos públicos. O maior problema é que, se não tomarmos cuidado, acabamos destruindo toda a modularidade do MVC.

O linkage só deve ser usado para que as classes de interface controlem os MovieClips relacionados à elas. No nosso jogo, temos as classes TCarta e TCartaAvatar, ambas controlando uma carta em jogo. A diferença é que, seguindo o MVC, modularizamos uma carta em 2 camadas:

  • TCarta

Controla a lógica da carta: os atributos, as contas, o dano que ela recebe, se ela está no Deck, na Mão, em Jogo ou no Cemitério e coisas do gênero.

  • TCartaAvatar

Controla todos os efeitos visuais da carta. É ela que desenha a marcação do mouse sobre a carta, quem coloca a carta em qualquer posição, que inicia/pára o arrastar, que gera os efeitos de dano e desenha na tela todos os atributos buscados de TCarta.

Dessa forma, podemos trocar completamente a interface sem mexer nas classes de lógica. Trocar para Papervision 3D, a Plasticvision 4D, a Metalvision 5D ou até mesmo OpenGL ou ClosedLG, no nosso projeto, é muuuito mais simples: basta que criemos as mesmas classes de Interface, mas agora programadas com a nova interface. MOLEZA.

Essa portabilidade ainda pode ser da interface para a lógica: nossas cartas são arrastadas independente da lógica, elas brilham independente dlógica, elas se movem independente da lógica. Basta chamar os métodos da classe de Interface na hora certa, seja em Action Script 3.0 ou qualquer outra linguagem que o Flash suporte mais pra frente.

Caso uma única classe fosse responsável por isso tudo, durante uma troca de interface ou na hora de portar um trecho do código, a manutenção seria muito mais complicada: você deveria ficar movendo/apagando métodos das classes de lógica. Isso claro, pois estou pensando numa classe bem feita, com métodos bem estruturados. Muitas vezes, o que você encontra são linhas de interface no meio da lógica. Aposto que vários de vocês já viram um “se (this.morto) rode (“AnimacaoMorto”)”. Imaginem trocar o código para o futuro suporte OpenGL nesse caso...

Se vocês já pegaram o esquema do MVC e da expansão que fizemos, criando a camada de Armazenamento, já sacou que a carta também terá uma camada de armazenamento. Ela não está implementada ainda, mas seria mais ou menos assim:

  • TCartaDados

Seria a classe responsável por materializar e desmaterializar a Carta. Pra quem não sabe, materializar é buscar os dados de um objeto no BD e criá-lo em memória e desmaterializar é jogar no BD, destruindo o objeto da memória. Essa classe também seria responsável por todos os outros métodos possíveis

Gente, de todos os artigos que fiz até agora, esse foi de longe o que eu mais gostei de escrever. Espero, por meio desse, ajudar a derrubar essa história de que o Action Script é uma linguagem de 2a linha e que jogo em Flash é um amontoado de gambiarras. Espero também incentivar os leitores a escrever sobre qualidade de software em AS. Dá mais trabalho na hora de programar, mas esse trabalho é recompensado na hora de reutilizar o código em diversos outros projetos. Pensem nisso e até a próxima!

[EDIT] Não se esqueça de conferir o resto do artigo! Parte 1 e Parte 3, valeu?

17out/070

MVC e o Linkage: O que se deve ou não fazer? (parte 1)

Eu acredito que muita gente vai me chamar de maluco depois desse artigo, mas espero que todos entendam. Pra começar, vamos falar do MVC (ou Model-View-Controller), uma arquitetura de software baseado na idéia de interações emtre camadas de alta coesão (fazem exatamente aquilo que se propõem a fazer e nada mais que isso) e baixo acoplamento (são o mais independentes possível entre si).

“CALMAÊ!!!! QUE NEGÓCIO É ESSE DE ARQUITETURA??? O MVC NÃO É UM PADRÃO DE PROJETO???” Pois então, como eu disse, muita gente vai me chamar de maluco... Deixa eu explicar:Eu já vi vários sites, artigos e livros chamando o MVC de várias coisas. Já vi chamando de padrão de projeto, com o que eu não concordo. Ele não é um padrão de projeto pelo fato de organizar todo um sistema, não somente um bloco ou pequeno problema. Além disso, para implementar o MVC nós precisamos utilizar padrões, como o controlador (Controller).

Pensando nisso, algumas pessoas começaram a chamá-lo de meta-padrão, coisa que ele não é. Um meta-padrão definiria o comportamento dos padrões, não de toda a arquitetura.

O MVC é isso: ele define como as classes vão se comportar, ditando quem fica onde, faz o quê e, o mais importante, o por quê disso ser assim, bem como faz uma planta de uma casa. Por isso é que, em vários locais (como aqui no Nuss), vocês vão encontrar o MVC como uma arquitetura de software.

Isso é um ponto de vista, não chega a influenciar diretamente no uso do MVC. Mas é importante explicar para que ninguém saia com “cara de LG”. Beleza? Então continuemos com o artigo.

Voltando às camadas, é como se você transformasse o software no corpo humano: separasse os ossos e delegasse a eles a sustentação do corpo, o sangue ficaria com o transporte de substâncias pelo organismo e o sistema neurológico se responsabilizasse pela propagação das sensações e ordens do cérebro. É claro que as funções não são bem essas, mas é assim que as coisas funcionam.

O MVC em nosso jogo fica assim:

camadas

Com esse diagrama eu posso falar da maior característica do MVC: Toda e qualquer camada só se comunica com as camadas imediatamente abaixo de si. Lembrando-se que, para evitar dúvidas, quanto mais próxima do usuário, mais “alta” ou “alto nível” está a camada. Nota-se que nenhuma classe da Lógica realiza chamadas à classe Controladora da mesma forma que a classe controladora não realiza chamadas à Interface. Além disso, a Interface não chama diretamente método algum da Lógica: isso é feito através da classe Controladora, como mostra o Diagrama de Seqüência a seguir:

sequencia

No MVC, cada camada tem uma função específica:

  • Model (Modelo / Lógica)

Essa é a camada de negócios, onde está toda a lógica do teu sistema. No Jogo, por exemplo, é onde estão as classes TCarta, TPersonagem, TLadrilho e todas as outras relacionadas ao funcionamento do núcleo do Jogo (ou engine, se preferir).

  • View (Visão / Interface)

Na camada de visão você não encontra NADA além das classes de interface com o usuário. TCartaAvatar, TPersonagemAvatar e TLadrilhoAvatar são exemplos de classes que, no Jogo, ficam na Interface. Outras classes que estão aqui são a TIdioma (que controla todos os textos do programa) e a TJukeBox (recém implementada, que controla todos os sons do jogo)

  • Controller (Controladora)

A controladora é uma camada intermediaria entre a Lógica e a Interface, que faz somente a propagação das mensagens da interface para a lógica, visto que a lógica não pode se comunicar com a interface.

A continuação do artigo, com os prós e contras da arquitetura, além do que o Linkage do flash tem a ver com isso vai ficar para o próximo. Então gente, até lá!

[EDIT] Seguem os links para as Partes 2 e 3 do artigo.

29set/074

E o que TE influenciou?

Hoje eu acordei com uma coisa na cabeça e vou fazer um artigo diferente. Artigo não, uma pergunta. Eu tava parado, pensando no design do Jogo e uma coisa veio em mente: esse jogo é um pedaço do Magic, um pedaço do Yu-Gi-Oh, um pedaço do Triple Triad, um pedaço de sei lá mais que jogo e, mesmo assim, não é nenhum deles: é algo novo, único... é o Jogo. Mas como uma cópia pode deixar de ser uma cópia?

Criar um jogo é como criar um texto: estamos vivenciando experiências, culturas e pontos de vista que nos são alheios. Depois, filtramos tudo aquilo que nos interessa e reciclamos as sobras, alimentando-nos de um verdadeiro banquete intelectual. Essas moléculas de conhecimento são absorvidas, vivendo no subconsciente, nos moldando e nos fazendo crescer. É exatamente quando passamos a aplicar nossas experiências sobre aquelas recém absorvidas.É assim que, de surpresa, chegamos àquelas conclusões de “se fosse meu, eu não faria assim” ou “ih, ta faltando um botão aqui fazendo isso”. É assim que pegamos as diversas idéias que temos na cabeça e montamos nossos Frankensteins. É assim que as coisas acontecem no Jogo e, com certeza, acontecem aí por fora.

Em mim, essas experiências se definem bem pela minha infância, pela influência do SNES e o mundo de 16 bits. Influência tão grande que, ainda hoje, meus olhos brilham com uma animação em sprites.

Para mim tornou-se impossível esquecer jogos como Super Metroid, Zelda: A Link to the Past, Super Mario Kart, Street Fighter, Chrono Trigger e Demon’s Crest, continuando pela estratégia de SimCity e War Craft, chegando até o 3D Okami, Wind Waker e Paper Mario, trazendo o ambiente 3D para o clássico 2D.

Por mais que o tempo passe, ainda continuo apaixonado por um belo 2D feio à mão, o que, “coincidentalmente” ou não, casa perfeitamente com o Flash que tanto nos tem ajudado. Não adianta, essa é minha influência, já faz parte de mim, é por essas pedras que caminho.

Isso ficou martelando na minha cabeça, principalmente depois de ter lido uma matéria na Cubagames. O pessoal postou um artigo sobre jogos que estão sendo desenvolvidos e mostrados em blogs, mostrando uma lista de desenvolvedores que estão socando cabeça para tocar seus projetos dos sonhos.

Fiquei imaginando a gigantesca lista de leitores do Nuss, da Cubagames e de todos os outros blogs que têm coisas em mente e não podem desenvolver. Uma gigantesca lista de experiências, culturas e pontos de vista diferentes, vivendo em seu subconsciente, influenciando suas decisões há todo momento.

Agora, depois de ter lido sobre as MINHAS influências, eu pergunto: e o que TE influenciou?

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

3ago/071

Design Inchado: “Você está fazendo seu primeiro jogo, não seu último”

Lembram-se bem do início do jogo? Aquela coisa gigantesca, miraculosa, digna de bilhões de Euros e de uma revolução no mercado. Sim, pelo menos é isso que a gente acha quando está encabeçando um projeto e é justamente isso que causa o grande problema do Design Inchado.

Quando a gente vai pensar em um jogo, é raro que pensemos no básico, principalmente pois tudo que temos no mercado aí é grandioso ao extremo. Perdeu-se a graça dos jogos simples, como o Tetris e o Pong. Hoje tudo tem que ser 3D, piscante e movente. Tudo deve começar do alto, enquanto os grandes clássicos como Mario Kart, Final Fantasy, Donkey Kong e Sonic eram uma coisa extremamente simples. A diferença é que eles foram ORIGINAIS: criaram um gênero próprio “estilo Final Fantasy” ou “estilo Mario”.

Pois então. A frase do título foi dada por nosso professor de Projeto Final ao ver o nosso primeiro design. Só quando ele deu o toque que eu me dei conta da burrice que estávamos fazendo: estávamos começando a subir a escada pelo último degrau. Tínhamos que fazer um jogo pra passar na matéria, não para ser uma revolução no mundo dos jogos. Foi assim que, por volta de Março desse ano, como estávamos trocando de linguagem de programação (e já iríamos perder o que fizemos em Action Script 2.0 mesmo), eu resolvi refazer todo o design do jogo.

Nada mais daqueles personagens com trocentas magias, com troca de equipamentos, com arenas montáveis como um quebra-cabeça. Agora o Jogo tornou-se um simples card game de estratégia em turnos, pra Internet, muito mais implementável que as infinitas animações que tínhamos antes. Não temos mais a alta complexidade inicial que tínhamos, que só servia para aumentar a distância entre a gente e a concretização do projeto.

Hoje o Jogo ganha em originalidade e simplicidade: estamos com os pés no chão e sabemos que um design inchado só faz com que fique cada vez mais difícil concluir o projeto.

O problema maior é que não há uma fórmula para definir um design inchado. Isso depende muito de conhecimento da área e das tecnologias que você pretende usar, aliado ao trabalho que o grupo de projeto conseguirá realizar. No meu caso, temos agora 3 bons alunos, cujas competências complementam a dos outros. Podemos fazer muito menos que um grupo de desenvolvimento profissional, com algumas dezenas de programadores, modeladores, artistas e o que for. Um design inchado para nós seria muito mais simples que um design inchado para esse grupo profissional.

O importante é estarmos sempre cientes do tamanho do passo que podemos dar, para que aquele tombo feio não seja iminente. Comece implementando problemas pequenos e vá acrescentando novas funcionalidades aos poucos, para não se perder no meio de muito trabalho. Lembre-se: não vale ter um jogo muito bom em mãos se não conseguir implementá-lo do jeito que deve ser.

2ago/070

O Jogo

Bom, anteriormente eu falei do Jogo mas não disse nada sobre ele. É por isso que esse post vai ser dedicado a esse projeto que tem teimado em acabar com os miolos.

O Jogo era, inicialmente, de estratégia estilo Worms ou GunBound: simples, mas podendo ser expandido quase que infinitamente. Mais do que isso, o Jogo estava fácil de implementar, de ser programado e ver o mercado. Isso era o q pretendíamos fazer, mas eu não estava satisfeito com sua simplicidade.

Foi aí que tive a idéia de transformá-lo em um tipo de estratégia diferente. Sabe aquela estratégia isométrica que o Final Fantasy Tactics popularizou? Pois então, resolvi que era aquilo que iríamos fazer. Criei vários sistemas de magias, ação/reação, árvore de profissões e toda a porrada de coisas que vocês possam imaginar. O jogo passou a ser para redes locais, na arquitetura chamada peer-to-peer, onde um computador se conecta diretamente com outro computados, como nos programas de transferência de arquivos Emule e KaZaA.

Aquele design inicial que estava simples e fácil de fazer virou um design complexo, muito profissional e complicado de ser implementado. Naquela época, o importante era que eu estava feliz com o que tínhamos em mãos, mesmo sabendo que seria difícil de ver o projeto alcançar a luz do dia.

Isso tudo aconteceu antes de cursarmos a matéria Projeto Final I. Estávamos adiantando o máximo que podíamos, já que a empreitada era mais complicada que o padrão na faculdade e sabíamos que teríamos que correr muito atrás por nós mesmos. No final desse mesmo semestre já tínhamos o design e toda a interação jogador-Jogo definidos. Faltava uma coisa: um membro no grupo.

No início do semestre seguinte, adicionamos esse membro extra, o que inchou ainda mais o design: O jogo, que era 2D, de sprites - desenhos, como nos jogos de Super Nintendo -, virou um jogo 3D, de vetores – imagens como nos videogames de última geração. Isso foi talvez a pior coisa que pudesse ter acontecido, pois descobrimos tarde demais que era IMPOSSÍVEL fazer uma coisa com metade da qualidade visual que conseguiríamos com sprites. Aquele design feito anteriormente foi pro espaço, sendo necessário refazer e repensar muito do que já tínhamos em mãos.

Passando 1 ano, terminamos por voltar ao grupo original. Aquele primeiro design foi buscado novamente, mas agora tínhamos também um servidor com acesso diferenciado para jogadores em determinados níveis. Tínhamos em mãos um jogo perfeito, mas será q ele era viável? Será que do alto de nossa nula experiência, conseguiríamos fazer um jogo assim?

Na próxima, vou falar sobre os problemas de um design perfeito, mas muito além daquilo que a gente consegue fazer. É o que eu chamo de um Design Inchado. Então gente, até lá.

1ago/077

Nuss… E Agora?!?

Quando, há uns semestres atrás, eu me vi na reta que precede o Projeto Final da faculdade, não consegui pensar em mais nada que não fosse fazer um jogo. Desde criança eu sempre fui maluco por esse tipo de coisas, sempre entendi muito bem sobre o mercado, sobre as inovações. Sempre vi o que dava certo e o que dava errado, sempre procurei os porquês dos sucessos ou fracassos. Passei por centenas de jogos, do Atari ao PS2, tinha certeza que conseguiria fazer algo de qualidade. E isso martelou na minha cabeça até que eu reunisse o grupo e caísse dentro do trabalho.

Pois foi aí que eu vi que eu não sabia NA-DA. Ou melhor, eu sabia sim. O que me faltava era a EXPERIÊNCIA. Sabe aquele “Ih, isso já aconteceu comigo. Resolvi assim, assim e assim”? Sabe aquele “AAAAAAhhh não, mas isso não se faz assim, senão vai causar os problemas tal, tal e tal”? Pois então, era isso que eu não tinha. Eu sabia muito do mercado, mas não conseguia organizar esse conhecimento. Eu sabia muito de análise, mas não conseguia implementar aqueles diagramas todos. Eu sabia muitas coisas maneiras para colocar no jogo, mas não conseguia codificá-las. Eu sabia muito, mas não conseguia nada.

Se eu tivesse tido uma ajuda, um ponto de partida, tudo seria mais fácil. Se eu tivesse alguém pra me explicar como fazer uma Game Bible, como implementar o padrão Singleton ou como fazer o controle de uma arena isométrica, tudo teria sido mais rápido e fácil. Depois de um tempo pensando, me veio aquele estalo: “Já que ninguém fez por mim, por que não fazer por alguém?”

Foi assim que nasceu a idéia de publicar o Blog, um meio fácil de alcançar o pessoal que está tendo esse monte de problemas de iniciantes. Eu vou estar focado no desenvolvimento do meu jogo (que agora não é mais só meu), mostrando pra vocês todos os problemas que encontrarmos durante seu desenvolvimento e, melhor ainda, como resolvemos cada um deles.

Vou falar de códigos, de Flash, de Programação Orientada a Objetos, UML, de Padrões de Projeto, de Game Design, de eBusiness... Ou seja: tudo aquilo que paira ao redor do desenvolvimento do Jogo (vou chamar o projeto assim daqui pra frente) Sempre de uma forma descontraída e fácil de entender, pra que todos que leiam possam extrair o máximo possível.

Lembrem-se que as soluções podem até não ser as melhores práticas, mas aqui estaremos abertos à discussão das respostas. Por que você faria diferente? Adicionaria alguma coisa? Divida com todos nós o que você pensa sobre isso.

Aqui também falarei um pouco sobre o grupo que está apostando nesse sonho, além de comentar sobre Jogo em si: O que ele era e como ficou, que tipos de alterações pretendo fazer no design e como faremos isso funcionar. Mas isso fica para os próximos artigos. Até a próxima!