Organizando os pensamentos com um Mapa Mental

Sabe quando a gente ta cheio de coisas na cabeça e precisa documentar, mas não sabe por onde começar? Sabe quando a gente tem um brainstorming em mãos e tem que organizar aquilo tudo? Sabe quando queremos mostrar o passo-a-passo de um jogo? Para esse tipo de coisas, vou mostrar-lhes o Diagrama de Mapeamento Mental, Mapa Mental, ou Mental Mapping Diagram. O nome é pomposo, mas o diagrama em si é a coisa mais simples de ser feita, pois não pode atrapalhar seu fluxo de raciocínio: é pensar numa coisa e inserir um nó relativo à ela.

Devido à troca de endereço, a continuação desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/organizando-os-pensamentos-com-um-mapa-mental/

Atualização inteligente é o que há!

Eu estava completamente sem assunto. Esse problema do BD e a possível implementação do Database Broker ainda estão por ai (falando nisso, o Douglas acaba de pipocá no MSN), enchendo nossas cabeças atrás de uma solução viável. Quando eu cansei, fui jogar esse Marvel: Ultimate Alliance. Procurando na net sobre o tal jogo, descobri que a versão do PC, com o uso de um Patch, permite que joguemos com 2 personagens novos: Colossus e Moon Knight [EDIT] Como o blog já recebeu uma porrada de gente atrás desse patch, fiz questão de disponibilizar o link. Basta clicar aqui ;).

Devido à troca de endereço, a versão completa desse artigo pode ser encontrada no endereço http://nusseagora.blog.br/atualizacao-inteligente-e-o-que-ha/

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/