Casos de Uso? Mas hein?

Tá, tá, foi vacilo meu, mas é que eu nem me toquei que o termo Casos de Uso pudesse significar interrogações pra vários de vocês. Pra resolver isso, ta aí: uma explicação sobre os Casos de Uso!

Esses tais Casos de Uso (CdUs daqui pra frente) não são nada mais que cada uma das diversas interações que o usuário vai ter com o seu programa. Na maioria das vezes, cada tela ou janela diferente significa um CdU diferente, mas como jogos são muito mais complexos, várias vezes tempos diversos CdUs na mesma janela. “Andar com o personagem”, “utilizar magia”, “selecionar alvo”, “pegar item” e “conversar” são diversos CdU que você realiza na mesma tela: a tela de jogo.

Devido à troca de endereço, a continuação desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/casos-de-uso-mas-hein/

Mais problemas... E agora?!?

Nesse exato momento, estamos tentando resolver um problema meio chatinho. Até então, estávamos desenvolvendo o Jogo SEM a camada de Armazenamento, já que isso simplifica (e muito) o nosso trabalho. Para acessar as cartas do BD, usávamos métodos com lógica falsa que simulava um acesso ao Armazenamento, mas que, na realidade, construíam tudo o que era pra ser construído diretamente em código.

Eu vi um leitor ali com cara de “oO?”. Xô passar um exemplo: A gente tem um método BuscarCartas() que deveria ir à camada de Armazenamento e materializar todas as cartas para que a interface pudesse desenhá-las. DEVERIA, mas não está fazendo isso. Pelo contrário: BuscarCartas() está cheia de linhas de código que criam diretamente aquele monte de cartas que deveriam ter sido buscadas no Armazenamento.

“Ta Tiago, mas qualé o problema disso?”. O problema é que o exemplo cresceu demais. Antes isso funcionava perfeitamente, pois ainda estávamos acertando o funcionamento básico da interface e as interações dela com a lógica do caso de uso Batalhar. Agora que precisamos trabalhar corretamente com a diversidade de cartas entre os jogadores, o troço não dá vazão: temos que ficar criando métodos falsos um em cima do outro, o que tem me deixado com medo. No final, se esse monte de métodos continuar crescendo, pode dificultar muuuuito a inserção da camada de Armazenamento.

Ainda não está nada certo, mas o Douglas deu a idéia de utilizar um padrão chamado Database Broker (ou só DB Broker), uma Indireção entre a camada de Armazenamento e o resto do programa. Assim, uma vez criado o DBBroker, todos os acessos ao armazenamento vão ser realizados por ele, bem como funciona com a Controladora. Independente de como seja implementado o Armazenamento, basta trocar a lógica dos métodos do DBBroker que tudo está 100% funcional.

“E por que fazer isso?” Pois nosso BD vai ser inicialmente uma tabelona XML mesmo. Estamos tendo trabalho suficiente com a interface e a interação dela com a lógica para implementarmos um BD distribuído. Somos só 3, nada de inchar o design ;)

P.S.: Caso algum de vocês leitores já passaram por algum problema do gênero, agradeceria muito se rolasse uma ajuda com esse problema!

P.S.2: Desculpem pela falta de matérias, mas realmente não tô tendo muito sobre o que postar: graças à esse rolo, não muito tem acontecido no Jogo. Pelo menos, a solução vai virar um outro artigo.

P.S.3: Não não, realmente prefiro o Wii. - Já vi isso em algum outro lugar ;)

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

É gente, depois de um bom tempo enrolado com problemas e mais problemas (aparentemente, até o meu MAC foi clonado), eu consigo finalmente disponibilizá esse código (com a ajuda do Douglas, claro). É o que dizem: "antes tarde do que nunca". Falando sobre o código em si, tanto eu quanto o Mário achamos que ele ficou um cado complexo por causa da Controladora usando o Singleton. Pensei seriamente em tirar esse Singleton, mas resolvi deixá ela assim mesmo para que vocês tenham mais um exemplo do uso do padrão num programa. Basta deixar claro que o Singleton NÃO É NECESSÁRIO para o exemplo.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/mvc-e-o-linkage-o-que-se-deve-ou-nao-fazer-parte-3/

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.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/mvc-e-o-linkage-o-que-se-deve-ou-nao-fazer-parte-2/

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

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/mvc-e-o-linkage-o-que-se-deve-ou-nao-fazer-parte-1/

Singleton: Limitando e Distribuindo

O nosso Jogo tem uma característica muito especial: ele é traduzido dinamicamente, sem a necessidade de recompilação. Para isso, estamos colocando todo o texto em uma classe especial, a TIdioma. O problema é que, se nós estivéssemos utilizando um objeto simples, a cada “new” que déssemos, teríamos uma cópia inútil do objeto ocupando espaço inutilmente. Dessa forma, se tivéssemos 500k de texto, poderíamos estar ocupando vários megas da memória.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/singleton-limitando-e-distribuindo/

Padrões de Projeto: O que são e pra que servem?

Quando começamos o projeto em Action Script 2.0, começamos a ter problemas com o Flash, já que não tínhamos prática para montar um projeto mais robusto. Foi quando o Douglas (naquela época o Mário não estava ainda com a gente) começou a recorrer aos grandes fórums sobre o assunto, para resolver problemas de boa programação. Depois das 4 primeiras respostas, o meu mundo mudou completamente.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/padroes-de-projeto-o-que-sao-e-pra-que-servem/

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?

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/orientacao-a-objetos-q-raios-e-isso-parte-3/

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:

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/orientacao-a-objetos-q-raios-e-isso-parte-2/

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.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/orientacao-a-objetos-q-raios-e-isso-parte-1/

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.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/paradigmas-de-programacao-estilos-diferentes-de-escrever-o-mesmo-texto/