Mostrando postagens com marcador Problemas. Mostrar todas as postagens
Mostrando postagens com marcador Problemas. Mostrar todas as postagens

quinta-feira, 15 de novembro de 2007

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

sábado, 20 de outubro de 2007

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/

quarta-feira, 17 de outubro de 2007

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/

segunda-feira, 24 de setembro de 2007

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/

domingo, 16 de setembro de 2007

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/

quinta-feira, 13 de setembro de 2007

Os problemas de se focar na perfumaria.

Estava olhando projetos postados por aí quando notei um erro recorrente na maioria dos projetos: as pessoas começam pela perfumaria.


Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/os-problemas-de-se-focar-na-perfumaria/

segunda-feira, 3 de setembro de 2007

Atraso em projetos de horas vagas (Ou "OIha... já tamo devendo quase 3 semanas...")

Lembram-se que eu fiquei de falar sobre os problemas com os quais nós iríamos nos deparar? Pois então, depois do Design Inchado e da Escolha do Flash, não acredito ter esquecido desse pequeno problema...


Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://www.nusseagora.blog.br/atraso-em-projetos-de-horas-vagas-ou-oiha-ja-tamo-devendo-quase-3-semanas/

sexta-feira, 3 de agosto de 2007

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.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/a-escolha-do-flash/

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.

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada aqui: http://nusseagora.blog.br/design-inchado-voce-esta-fazendo-seu-primeiro-jogo-nao-seu-ultimo/