Nuss… E Agora?!?

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.

12out/070

E por quê jogar o MEU?

Taí... Continuando a idéia do artigo anterior, onde encontramos quem jogará o nosso jogo, hoje tentaremos encontrar o que fará com que o jogador jogue o seu jogo, não o da concorrência. Não achem que esse artigo será uma revolução no mercado mundial, muito menos o segredo do sucesso do seu jogo. Com ele pretendo falar um pouco sobre o diferencial competitivo, que daqui pra frente chamaremos só de diferencial.

O diferencial é uma das características principais para o sucesso de qualquer produto. É ele que identifica um produto no meio de tantos outros e atrai os consumidores, é algo que eles querem ter e, no caso dos jogos, algo que os jogadores querem jogar.Normalmente compreende um conjunto de características ao invés de somente um ponto-chave necessariamente inovador. Ao contrário, em muitos casos de sucesso de jogos, o diferencial era algo simples e óbvio, mas negligenciado nos concorrentes.

Um exemplo que me vem em mente: por simplesmente adicionar ao jogo a capacidade do personagem sentar em cadeiras, os desenvolvedores do Phobos Online conseguiram chamar a atenção de vários jogadores de Tibia, onde o seu personagem não consegue fazer isso. Tiveram até uma screenshot veiculada num dos maiores sites relacionados ao concorrente. É claro que ninguém vai passar a jogar um jogo só por quê você pode sentar em cadeiras, mas um conjunto de pequenas coisas simples podem fazer a grande diferença.

Todo mundo lembra do multiplayer de Counter Strike e Perfect Dark, da estratégia de Warcraft e Baldur’s Gate, da tecnologia gráfica de Farcry e F.E.A.R., do enredo de Final Fantasy VII e Chrono Trigger ou até mesmo da originalidade de Grand Theft Auto e Carmaggedon. Diferenciais, quando bem explorados, fazem justamente isso: lançam o jogo para a história.

“Mas como eu vou descobrir o meu diferencial?” Para essa pergunta, vou usar a mesma resposta dada no artigo anterior: Pesquisa, pesquisa e pesquisa. Praqueles que ainda não o fizeram, dêem uma lida nessa matéria sobre o mercado. Nela eu falo sobre pesquisas, dando dicas sobre como realizá-las gastando quase nada. Para organizar os resultados, leiam também essa matéria sobre o Princípio de Pareto, pois com ele vocês irão encontrar o que a maioria quer ver no jogo que vocês pretendem fazer. A idéia principal é fazer as pesquisas com o maior número possível de pessoas.

Não adianta achar o contrário: você precisa saber o que o teu público deseja jogar, a forma com que eles querem jogar e quanto eles pretendem pagar para jogar. Não é fazer um jogo e esperar que as pessoas gostem: é fazer um jogo com aquilo que os jogadores querem ver. Se seu público usa computadores antigos, isso deve ser utilizado como diferencial em relação à concorrência. Se eles desejam um jogo modificável, isso também deve ser utilizado. Se estão querendo jogar um jogo de estratégia, use-a estrategicamente para fisgá-los. Se não começar assim, duvido que termine.

5out/073

Quem vai jogar?

Antes de pensar no design do seu jogo, é importante saber responder uma pergunta simples: Quem vai jogar? Saber a quem se aplica o design que você está criando é tão importante quanto fazê-lo de forma bem feita. Devemos encontrar o máximo de características que possam nos encher de idéias para esse design. Algumas delas (que serão abordadas aqui) são:

  • Localização

“Pra quê saber isso?” Simples: para disponibilizar o jogo numa língua que eles entendam. Não adianta fazer um jogo para um público qualquer e dizer “ah, eles que aprendam inglês”. Além disso, você tem que estar inteirado dos costumes daquele povo, caso queira direcionar a eles. Americanos são fissurados em ação, sangue, explosões e tudo mais que aparece aos montes num filme do Rambo, enquanto japoneses usam muito mais seu potencial intelectual. Assim sendo, jogos de massacre e tiro em 1ª pessoa fazem muito mais sucesso nos EUA que no Japão, onde os quebra-cabeças, jogos de estratégia e RPGs dominam o mercado.

  • Classe Social

Teu público é rico ou pobre? Se for rico, vai ter dinheiro para computadores de última geração. Se for assim, por quê irão jogar o teu jogo e não o World of Warcraft, por exemplo? Se teu público não tiver dinheiro pata tais máquinas, pode tirar da cabeça aquele jogaço com gráficos 3D foderosos e efeitos de luz e sombra em tempo real.

  • Idade e Sexo

Sexos diferentes têm preferências diferentes. Além de preferências, a faixa etária também tem limitações governamentais. Por exemplo, se você pretende fazer um jogo para mulheres adolescentes, não vai conseguir muito público adicionando serras elétricas e monstros insetóides gosmentos. Em compensação, o contrário também é válido: não adianta querer fazer um jogo da Hello Kitty para a mulecada de 15 anos.

Viu como, apesar de parecer dispensável, definir o seu público-alvo é extremamente importante? Isso não vai limitar só o design não, gente. O público alvo pode afetar diretamente a produção do seu jogo, às vezes fazendo com que você tenha que aprender coisas novas em tempo record.

Voltemos ao exemplo dos jogadores com computadores antigos. Você definiu que seu público-alvo usa computadores antigos, até 500MHz, 128MB de RAM, sem placas de vídeo e utilizando internet discada de 56Kbps. Nesse caso você vai limar o 3D de qualquer idéia, provavelmente limitando o desenvolvimento ao 2D para alcançar melhores efeitos visuais, além de ter que usar uma linguagem rápida, com interface leve e adicionar ao projeto várias técnicas de melhoria de performance, muitas das quais você nunca ouviu falar.

Essas características-chave para o programa (que o PMBOK chamaria de Requisitos Não-funcionais) não devem ser mudadas para não influenciar negativamente no andamento do projeto. Seria como se, no meio do caminho, aquele algoritmo que demorou 20 dias para ficar pronto se tornasse inútil. Além disso, elas devem ser levantadas ainda na fase de design do jogo, lá no início, para que todo o desenvolvimento vise segui-las

Agora vem o problema... isso tudo é bem complicado para quem não está acostumado a fazer. “E se eu pagar para alguém fazer pra mim?” Well, well... esteja preparado pra desenbolsar uma graninha boa pela sua pesquisas de mercado.

“Pow cara, que sacanagem! Você fala, fala e só no fim avisa que eu não vou conseguir fazer???” Pesquisas, pesquisas e pesquisas. A internet ta aí, é a maior fonte de dados do mundo. Basta sabermos como transformá-los nas informações que precisamos. Por exemplo:

  • Pesquisas já prontas.

Revistas e jornais vivem nos jogando gráficos e mais gráficos, pesquisas e mais pesquisas. Aposto que em algum lugar já tem alguma que é exatamente o que você precisa. Vale lembrar que procurar nos sites relacionados à tecnologia também é uma ótima idéia.

  • Sites de Jogos

Existe algum jogo parecido com o que você quer fazer? O teu público costuma jogar alguma coisa com freqüência? BINGO!!! Vasculhe o site e procure informações sobre o que os jogadores querem ter. Sites como o Tibia disponibilizam pesquisas freqüentes nas quais os jogadores podem votar. O melhor é que os resultados são públicos, basta escolher alguma pesquisa e usar os resultados.

  • Visite fórums

Aqui vai depender mais de você. Analisando o conteúdo e as reclamações nos fórums de jogos você consegue traçar um perfil seguro do que os jogos têm e, melhor, precisam ter. Avaliar as mensagens no fórum do Tibia, por exemplo, vai deixar bem claro que um MMORPG precisa de controle para sua comunidade não sair do controle. Isso é um ponto forte para trazer uma boa quantidade de usuários.

Isso é só o início de uma Pesquisa de Mercado, mas que é alcançável por qualquer um de nós. Mesmo simples do jeito que está, vai dar uma base boa para teu design. Para deixá-la mais interessante, teremos que fazer uma pesquisa de concorrência, de recursos, de custos e outras tantas que ficarão para próximos artigos. Até a próxima.