↓ Arquivos ↓

Arquivo → July, 2009

Behind Closed Doors – como o gerente dos sonhos trabalharia

Behind Closed Doors

Behind Closed Doors

De uns tempos pra cá tenho tido a necessidade de aprimorar o meu lado “gerencial” (algo incrívelmente rock orgasmico está para acontecer nos próximos meses (mistério por enquanto)). Sendo assim, abandonei por algumas semanas a minha leitura convencional (nada de Wittgenstein e Hegel, muito menos algoritmos de qualquer espécie…) para tentar entender como de fato funciona o trabalho de um gerente.

Na minha busca por leitura apropriada, topei com inúmeros livros intragáveis. Eu não quero ser um expert em administração/gerenciamento/burocracia. Quero apenas saber se estou fazendo as coisas da maneira correta e, melhor ainda: aonde estou vacilando feio na minha percepção de gerenciamento. E o “Behind Closed Doors” caiu como uma luvra pra mim.

Isto porque não é um livro de administração convencional: não há teorias expostas, muito menos regras rígidas sobre como o trabalho de gerenciamento deve ser feito. Ao invés, as autoras optaram por narrar o cotídiano de um gerente fictício (Sam) que é basicamente o gerente que qualquer um sonha ter. Num primeiro momento, o que veio à minha mente foi: “putz! isto deve ser brega pra cacete!”: ainda bem que estava errado, pois a abordagem funciona muito bem. São expostos pequenos detalhes do dia a dia que separam um gerente idiota de outro funcional. A todo momento me vinha aquela sensação de “ahn… então é por isto que fulano fez aquilo…”.

(aliás, a escolha feita pelas autoras faz sentido, visto que o livro faz parte da excelente coleção “The Pragmatic Programmers”)

Acredito que para pessoas como eu, que possuem paixão pela parte técnica do trabalho e uma certa preguiça relacionada à area gerencial o livro expõe um lado prático da gerência que destrói diversos preconceitos relacionados a esta área. O leitor tem uma noção de como um gerente deve lidar com situações como por exemplo funcionários insatisfeitos ou falta de foco dentro das empresas, sem utilizar aquele vocabulário pedante com o qual topei em outras leituras intragáveis sobre o assunto.

Realmente recomendo a leitura do livro. Porém se você estiver sob o domínio de um gerente idiota, um aviso: você sentirá IMENSA inveja dos subordinados de Sam!

Metal Gear Nanna no Google Code

Metal Gear Nanna

Aos interessados,coloquei o código fonte de Metal Gear Nanna no Google Code.

O endereço é http://code.google.com/p/metalgearnanna/

Metal Gear Nanna – Criando jogos usando C++ e OpenGL: o modelo – Parte II

Diagrama de classes inicial

Diagrama de classes inicial

O mais importante no projeto deste jogo, sem sombra de dúvidas é o modelo, pois os gráficos, assim como toda a interação do usuário com o jogo é resultado do estado definido neste.

Vamos começar pela classe Elemento. Esta representa, como o próprio nome já diz, um objeto que será representado na janela principal do nosso jogo. Trata-se de uma classe abstrata, que irá prover os atributos e métodos básicos que serão utilizados pelos elementos concretos do nosso jogo: Nanna, Inimigo, Parede e Destino (os explicarei novamente a seguir).

Na classe Elemento os seguintes atributos encontram-se definidos:

x e y: a posição do elemento na tela. No caso, por padrão estes elementos irão corresponder ao canto superior esquerdo de cada elemento de tela.

altura e largura: adivinha! :)

visivel: indica se o elemento em questão será renderizado ou não pela aplicação. Este atributo só será de fato útil quando formos trabalhar com a inteligência do jogo.

Esboço de Nanna vista de frente

direcao: a direção do elemento naquele momento. É importante para que saibamos qual imagem renderizar. Por exemplo: se Nanna estiver na direção NORTE, iremos renderizá-la de costas, se for SUL, de frente

A classe abstrata Elemento possui dois métodos abstratos que são fundamentais para nosso jogo:

Elemento::draw(): Desenha o elemento na tela. Cada elemento irá se desenhar de maneira distinta. Por esta razão, este método foi definido como abstrato nesta classe, obrigando as demais a implementá-los.

Elemento::mover(direcao: tipoDirecao, incremento: float): Este método recebe dois parâmetros: direcao e incremento. O parâmetro direcao indica para onde estou movendo o elemento (veja o enum tipoDirecao no diagrama de classes para ver seus valores óbvios), e incremento a distância percorrida pelo elemento a cada chamada deste método. No caso, serão alterados os atributos x e y da classe, que correspondem à sua posição na tela.

Descrita a classe Elemento, vamos passar agora para a descrição das suas classes derivadas:

Metal Gear Nanna

Nanna: Trata-se de nossa heroina. No estágio inicial do código fonte, trata-se do único elemento que podemos movimentar (e que possui qualquer tipo de movimento, diga-se de passagem). Só para lembrar, o objetivo de Nanna consiste em evitar ao máximo os “Traficantes de Delícias” (classe Inimigo), que uma vez a avistando, irão obrigá-la a comer alguma coisa, reduzindo assim o número de pontos que obteve nos vigilantes do peso.

Estou prevendo para Nanna duas capacidades: a de se movimentar e também a de distrair os seus inimigos. Para tal, Nanna irá gritar, fazendo com que os mesmos mudem de direção, possibilitando assim que ela os despiste.

Esboço dos Inimigos de Frente

Esboço dos Inimigos de Frente

Inimigo: Ah, estas cozinheiras da Bahia… Vivem nos engordando!  Seu comportamento será definido pelo próprio mecanismo do jogo ao invés de Nanna, que será comandada pelo jogador.

No caso do Inimigo, há alguns atributos a mais: ele possui um raio de visão (definido pelo atributo direcao) e também se movimentará sozinho pelas 4 direções em busca de Nanna. Uma vez que esta esteja no seu campo de visão (que também será rendericado), automáticamente Nanna perderá pontos.

Esboço de uma parede

Esboço de uma parede

Parede: Uma paredde é uma parede, que é uma parede e, bem: uma parede. A única função de uma parede consiste em limitar os movimentos de Nanna. Uma parede não se move (ao menos não inicialmente), sendo assim, o método mover em nada modificará os atributos de uma parede neste momento.

O único método sobrescrito no caso será draw, que deverá expor o esboço exposto ao lado.

Destino: Para chegar ao final de uma fase, Nanna precisa saber aonde chegar. Por esta razão, existe a classe destino. No momento em que Nanna interceptar o destino, o mapa atual será descarregado da memória e o seguinte carregado, até que todos os mapas sejam finalizados e o usuário chegue ao final do jogo.

O Mapa!

O mapa pode ser visto como o container de todos os elementos do nosso jogo. Nele estarão armazenados os apontadores para cada classe derivada de Elemento de nossa aplicação.

Neste estágio atual do jogo, o código mais interessante sem sombra de dúvidas é o mapa, que inclusive já é renderizado (toscamente, é verdade, mas renderizado!), como pode ser visto na imagem abaixo:

Mapa atual de Metal Gear Nanna

Mapa atual de Metal Gear Nanna

Todos os elementos são inicialmente renderizados como quadrados, variando apenas suas cores: Nanna é vermelha, o Inimigo laranja, as paredes azuis e o destino verde (soa quase como um poema, não é mesmo?).

No caso, as posições dos elementos são definidas em arquivos externos, carregados pelo programa quando o mesmo é iniciado. Estes arquivos externos encontram-se no formato texto para que sejam de fácil edição, e são similares ao exposto na imagem abaixo:

Cada linha do arquivo possui um significado:

Primeira linha: nome do mapa

Segunda linha: código interno do mapa (será muito útil em um futuro próximo)

Terceira e quarta linnhas: número de linhas e colunas do mapa (mais sobre isto abaixo)

Linhas subsequentes:

As linhas subsequentes dizem respeito ao posicionamento dos elementos na tela. No caso, es trata de uma matriz de n linhas por m colunas, tal como definido nas linhas de número 3 e 4 do arquivo de configuração do mapa.

Cada caractere dentro desta matriz representa um dos elementos descritos acima: V = vazio, N = Nanna, I = Inimigo e E = Saída. Na realidade, para elementos vazios poderia ser definido qualquer caractere diferente de N, I ou E. No entanto, para que a visualização fique mais fácil, optei pelo caractere V mesmo (se quiser, modifique o arquivo de mapa trocando os caracteres V por qualquer coisa. Você verá que o programa funciona da mesma forma).

Conforme este arquivo é carregado, novas instâncias da classe Elemento vão sendo criadas e seu posicionamento configurado de acordo com a linha e coluna na qual se encontram (fica nítido no código fonte como isto é feito).

Renderização do mapa

A renderização do mapa é simples: neste há um atributo chamado conteudo, do tipo ItemLista. Este na realidade é o elemento inicial de uma linha encadeada. Sendo assim, o que o software realmente faz consiste em interar em cima destes elementos executando o método draw de cada instância. Em seguida, é chamado o método draw do atributo Nanna, que não se encontra dentro desta listagem.

Nanna não se encontra dentro desta listagem por duas razões:

1) É um elemento que é acessado constantemente

2) É um elemento único. Em um mapa, ao menos por enquanto, só pode haver uma Nanna.

O código fonte

Ei! Após ter falado tanto do programa, com certeza vocês devem estar querendo dar uma olhada no mesmo, certo? O disponibilizei para download neste link. Eu sei que é uma maneira bem tosca de disponibilizar código fonte, mas é que ainda estou procurando algum lugar para hospedar o meu repositório Mercurial. Assim que o encontrar liberarei para vocês maiores detalhes sobre como obter versões atualizadas deste bichinho.

(eu pensei no github, mas o estado do git para Windows (sim, estou usando Windows ao invés de Mac OS no desenvolvimento deste projetinho…) atualmente ainda é muito precário, além disto, devo confessar que tenho uma certa preferência pelo Mercurial)

Fontes adicionais de informação

Neste estudo, alguns livros estão sendo de EXTREMA valia para mim:

C++ Como Programar

O melhor livro de C++ que conheço, é o dos Deitel (assim como o livro de Java, Perl e C# também são os melhores).

Se você quer saber o básico de programação em C++, o livro é este.

OpenGL: Uma Abordagem Prática e Objetiva
De Marcelo Cohen

Um excelente texto introdutório ao OpenGL. Basicamente, do pouco que sei de OpenGL até agora, 90% vêm desta fonte.

A abordagem é muito simples, tornando o contato inicial com OpenGL pouquíssimo traumático. Na realidade, é até surpreendente: eu realmente achava que OpenGL fosse algo que só engenheiros da NASA pudessem dominar. Com este livro, vi que a história não é bem assim.

Computer Graphics: Theory Into Practice
De Jeffrey J. McConnell

Enquanto o OpenGL: Uma Abordagem Prática e Objetiva é mais mão na massa, o foco deste livro é mais a teoria por trás da computação gráfica. Aliás, primeiro tomei contato com este livro, e só depois com o primeiro.

Os exemplos do livro são todos em OpenGL, sendo assim, o que o primeiro não tratar, com certeza você encontrará com maiores detalhes neste.

Daqui para frente…

Se você executar o código fonte atual, irá perceber que Nanna pode fazer algo incrível: ela passa pelas paredes. Sendo assim, antes de renderizar Nanna com gráficos melhores, a primeira coisa a ser feita consiste em implementar os algoritmos de detecção de colisão.

Sendo assim, nos próximos posts começarei a trabalhar com maiores detalhes questões referentes à implementação de Metal Gear Nanna. Neste processo, iremos ver como funciona o OpenGL e também quais os erros que venho cometendo neste desenvolvimento (o que normalmente é o mais interessante em todo aprendizado).

Logo… até o final de semana que vêm (ou antes)!

The IDE Syndrome

A common complaint I get a lot at Grails Brasil is about the lack of support for Grails on the major IDE’s. Well, I really don’t see it as a problem, but actually as a solution for another much more serious one, which I usually call “The IDE Syndrome”.

If you feel more than one of the symptoms above watch out: you probably are “infected” and maybe doesn’t even know it!

Symptoms

  • Difficulty to adapt to other IDEs (classical example: those who are used to Netbans usually hate Eclipse and vice-versa)
  • You’re able to build your applications using the wizards/tools of your IDE, but don’t know actually how the frameworks/libraries in which your application is based actually work.
    (good example: you always use the visual editor of your IDE to build your JSF pages but don’t know how the JSF tags work)
  • Most of your tasks are done using the wizards/tools of your IDE or a lot of “drag and drop”.

    WARNING: In this case there’s a 99% of chance that you’re infected

An IDE can make your job easier, but it won’t actually do it for you

This is the greatest mistake in my opinion, and I know lot’s of people who actually believe in it. An IDE is created to make easier the use of other programming tools and frameworks, but they aren’t actually made to do your job! Have you ever heard the question “do you code in (your favorite IDE here)?”?

The implementation process goes beyond drags, drops and wizards. You know that, I know that, but I can see many “developers” which don’t. An IDE can create the illusion that software development is easy, but actually what is being created is the illusion of power.

In this case, there are two question that you should make to yourself: if the answer is “no” to any of these, well: again: you’re infected.

Do you really know how the frameworks/language/environment you’re using on your application work?

Can you work without code completition?
(I know many people that don’t (!!!))

Can you do your job without your IDE?

The IDE offers a work methodology which not necessary is the best of all or the only one

This is one of my major concerns about getting addicted to an IDE. When an IDE is being developed, it  is based on a set of principles accepted by those responsible for it’s development, which not necessarily are the only ones available.

Yes, usually is a highly efficient way of getting things done, but it’s not the only one. I think that it’s really important for a developer to know as many ways of doing it’s job as possible: even if some of these are worse than those offered by your IDE.

Someone used to work only with Netbeans for example may know only one building tool: Ant, and ignore completely other options like GANT, Maven, etc. (I know that there are plugins for these other tools too. But the fact is that usually the average IDE addicted doesn’t use them). Actually, Netbeans does such a great job on this part that is highly possible that an IDE addicted doesn’t even know that there’s something called “ant” at all!

An IDE is actually an abstraction of a set of knowledges/tools

As a consequence, those addicted to an IDE only know the abstraction, not the subjacent technologies behind it.

And here comes the leaking abstraction phenomenon, best described by Joel Spolsky in his article The Law of Leaky Abstractions. Every abstraction have limitations. As a consequence, there’ll be a moment in which it won’t work for unpredictable behaviors. So, it’s inevitable that some day things won’t work as expected for the IDE addicted. Oh oh!

So, should I avoid an IDE?

Of course not!!! It’s plain stupid to avoid what can make your life easier! What you should avoid is getting the illusion that all you need to know to get your job done is how to work with your IDE. Remember: it’s only an abstraction.

Believe-me there’s life (a lot of actually!)  without an IDE :)

Síndrome da IDE

Frequentemente no Grails Brasil me deparo com a seguinte reclamação: “não há grande suporte das IDEs ao Grails ainda”. Sabe: na realidade não vejo isto como um problema, mas sim como uma solução a um problema muito comum, que costumo chamar de “Síndrome da IDE“.

Se você sente um ou mais dos síntomas abaixo, abra o olho: provávelmente você está com este problema e talvez não saiba:

Sintomas

  • Dificuldade em se adaptar a IDEs diferentes da que você está acostumado a trabalhar
    (exemplo clássico: aqueles que amam Netbeans e não conseguem trabalhar com Eclipse ou vice-versa)
    Este síntoma fica evidente pelo ódio que usuários de uma IDE costumam apresentar em relação a outras.
  • Consegue criar aplicações usando os assistentes/ferramentas da IDE, porém não sabe como os recursos do framework utilizado de fato funcionam
    (Exemplos: você cria aplicações JSF usando os editores visuais do Netbeans, porém não conhece as tags do JSF usadas na geração de suas páginas.
    Outro exemplo clássico: desconhecimento do arquivo web.xml da sua aplicação, que é automáticamente gerado pela IDE)
  • A maior parte do seu trabalho no desenvolvimento de uma aplicação é executada usando o mouse e/ou assistentes fornecidos pela IDE (uma generalização do sintoma acima citado)

    (Aviso: este sintoma normalmente é a CONFIRMAÇÃO da síndrome)

IDEs facilitam o trabalho, mas não O executam

Acredito que a maior parte das pessoas acaba por cair nesta armadilha por uma razão muito simples: confundem o fato de uma IDE surgir para facilitar o trabalho do desenvolvedor, mas não executá-lo. É inegável que uma IDE facilita o nosso trabalho, porém é importante lembrar que elas FACILITAM, e não EXECUTAM.

Quem aqui nunca pegou para dar manutenção em um sistema 100% feito com assistentes de IDE e o famigerado “arrastar e soltar” que atire a primeira pedra. No caso, o único trabalho do “desenvolvedor” consistiu em executar em uma ordem pré determinada alguns dos recursos oferecidos pela sua IDE. Há trabalho do profisisonal neste caso? Sim, claro: porém incompleto, pois ele provávelmente responderá “não” (se for honesto) às duas perguntas abaixo:

Você possui conhecimento sobre como DE FATO funcionam os frameworks/linguagem/ambiente de desenvolvimento usados pela sua IDE?

Sem a sua IDE, você consegue dar manutenção no código gerado?

A IDE apresenta uma metodologia de trabalho que não é a única (e nem necessáriamente a melhor)

Este ponto normalmente é ignorado pelos viciados em IDEs. Uma IDE ao ser desenvolvida, o é baseado em um conjunto de princípios tidos como verdadeiros POR AQUELES QUE A DESENVOLVERAM. Porém, estes mesmos princípios não são universais ou mesmo os melhores possíveis.

Sim, há grande possibilidade de que seja um modo de trabalho extremamente eficiente, porém nada impede a possibilidade de existência de outros modos de trabalhos mais eficientes. Ao se fixar no modo de trabalho de uma única IDE, o usuário acaba por ignorar TODAS AS OUTRAS possibilidades de trabalho existentes e, pior ainda, acaba por ignorar a possibilidade de criar a sua própria.

Um bom exemplo seria o Netbeans. Como ferramenta de build, é usado o Ant. Se você só trabalhar com o Netbeans, irá ignorar completamente outras ferramentas como Maven, GANT, etc. Neste caso, há inclusive plugins para outras ferramentas, porém é interessante lembrar que o viciado em IDE normalmente a utiliza exatamente da maneira como foi instalada.

A IDE é uma abstração em cima de um conjunto de conhecimentos

A IDE na realidade é uma abstração de um conjunto gigantesco de conhecimentos (processo de build, conhecimento dos frameworks subjacentes, ferramentas, etc). Como consequência, aquele que utiliza apenas a IDE corre o risco de conhecer APENAS esta abstração, e não o que realmente ocorre por trás dos panos.

E aqui entra como consequência um fenômeno muito bem descrito por Joel Spolsky: a lei do vazamento da abstração (sim, fiz uma tradução tosca) (vale a pena ler o artigo: The Law of Leaky Abstractions). Toda abstração possui limitações. Como consequência, invariávelmente ocorrerão situações nas quais a abstração não prevê determinado comportamento das tecnologias abstraidas. Como consequência, as coisas não funcionarão como o esperado (pelo usuário).

Teste: se você é viciado em Netbeans, configure-o para fazer o deploy da sua aplicação usando Java Webstart. Será que as ferramentas oferecidas pela IDE REALMENTE resolverão o seu problema (me conte depois sua experiência).

Então devo fugir da IDE completamente?

Claro que não criatura! É estupidez evitar o que facilita a sua vida. É como alguém que compra um carro. Óbviamente você não precisa saber o funcionamento interno com detalhes. Porém, se um dia se encontrar no meio do deserto com seu carro estragado, é bom saber pelo menos o suficiente para que não morra abandonado no deserto (fui exagerado no exemplo? Bom, vocês entenderam aonde eu quero chegar pelo menos).

Metal Gear Nanna – Criando jogos usando C++ e Open GL – Parte I

Metal Gear NannaIniciei um novo hobby neste final de semana: criação de jogos. De todas as atividades, a que mais me diverte sem sombra de dúvidas consiste em programar (há momentos nos quais tenho de me beliscar para acreditar que me pagam para isto!).

Após ter desenvolvido zilhões de aplicações empresariais/corporativas, acabo por ter a impressão/certeza de que sempre estou executando as mesmas tarefas: CRUD, validação de dados, formulários, bancos de dados, etc. Que tédio!

A solução para acabar com o problema consiste em buscar algo completamente diferente do feijão com arroz. O que poderia ser mais distinto que o desenvolvimento de um jogo?

  • A interface com o usuário não é a partir de formulários
  • Não preciso lidar com banco de dados algum (ainda irei escrever um dia sobre a minha teoria de que bancos de dados emburrecem programadores)!
  • É significativamente mais complexo, pois preciso gerenciar detalhes de gerenciamento de recursos com muito maior detalhamento.
  • Não estou preso a nenhuma restrição comercial!

Objetivos pessoais

Meus objetivos pessoais neste projeto consistem em me aprofundar no aprendizado do C++ e OpenGL a partir de uma aplicação real. Já faz no mínimo uns 6 anos que sei C++, porém nunca tive uma oportunidade de usá-la em um projeto real. Visto que a oportunidade não veio, porque não criá-la?

Além disto, ano passado fiz a matéria “Computação Gráfica” na faculdade, aonde aprendi OpenGL, que abriu meus olhos para o fato de que desenvolver aplicações gráficas não é algo tão complexo como até então imaginava. Na realidade, como exporei nesta série de posts, é quase fácil.

Enredo e Objetivo

O personagem principal da história é Nanna (minha esposa (aliás, uma bela maneira de homenagear quem amamos, não é mesmo?)), que após entrar para o grupo dos Vigilantes do Peso precisa vencer as tentações da vida dietética. A jogabilidade será basicamente a mesma presente no jogo Metal Gear original para MSX.

(a propósito, enquanto escrevia este post, descobri que existe uma versão do jogo para PC que pode ser baixada aqui)

Metal Gear original para o MSX

Nanna deverá chegar à sede dos vigilantes do peso saindo de sua casa. Mas o caminho não é tão tranquilo quanto aparenta, pois Nanna precisa evitar os malditos “Traficantes de Delícias” que, caso a vejam, acabarão por convencê-la a comer alguma coisa.

Cada um destes traficantes possui um raio de visão que Nanna deverá evitar. Caso a vejam, automáticamente nossa heroina perderá pontos. O jogo termina se uma das condições abaixo for satisfeita:

  • Nanna está com pontos menores ou iguais a zero.
  • Nanna chegou à sede dos vigilantes do peso em todas as fases.

Ainda não pensei se será possível restaurar pontos perdidos, porém nada impede que, além dos malditos traficantes, também existam “academias” espalhadas pelos diversos níveis do jogo aonde Nanna poderá voltar à boa forma.

Plataforma adotada

Como mencionei acima, um dos objetivos deste projeto consiste em me aprofundar em C++ e OpenGL. Dentre as diversas IDEs existentes atualmente, acabei por adotar o Dev-C++ pelas razões abaixo:

  • Possui pouquíssimos recursos, o que faz com que eu me sinta o mais próximo possível do compilador.
  • Possui integração com as bibliotecas do OpenGL que precisarei.
  • Caso no futuro eu desista desta IDE, ela não impõe nenhuma estrutura de diretórios ou restrição que me impeça de no futuro utilizar o editor/IDE que eu queira.

Será utilizada a biblioteca GLUT do OpenGL para o desenvolvimento deste jogo. GLUT significa Open GL Utility Toolkit, que consiste em uma biblioteca de funcionalidades da Open GL cujo principal objetivo consiste em abstrair o sistema operacional da aplicação, tornando-a assim multiplataforma. Dentre estes detalhes, encontra-se a criação de janelas e componentes de interface. A biblioteca GLUT foi implementada para basicamente todos os principais sistemas operacionais em uso atualmente. Sendo assim, você poderá pegar o código fonte qeu disponibilizarei e compilá-lo no sistema operacional de sua preferência.

Configurando o ambiente de desenvolvimento

Instalado o Dev-C++ em seu site oficial (http://www.bloodshed.net/devcpp.html), tudo o que você precisará fazer consiste em instalar a biblioteca GLUT no mesmo.

Abrindo o Dev-C++, clique no item de menu “Check for Updates/Packages…”. Surgirá uma janela tal como na imagem abaixo:

Localize o pacote GLUT na listagem presente e em seguida clique no botão “Download selected”. Pronto: o GLUT será baixado e em seguida instalado para uso pelo Dev-C++.

O que está por vir

Não tenho experiência ALGUMA no desenvolvimento de jogos, sendo assim, estou adotando um raciocínio out of the box neste processo, ou seja, o motor responsável pelo funcionamento de Metal Gear Nanna será inteiramente baseado na minha experiência como jogador de Metal Gear 1 e 2 para MSX.

Como consequência, irei reinventar inúmeras vezes a roda neste processo, o que é exatamente a intenção aqui. Pretendo com isto saber a fundo como funcionam todos os aspectos no desenvolvimento de jogos no nível mais baixo possível.

No próximo post irei disponibilizar o código fonte já criado e expor o modelo por trás do funcionamento de Metal Gear Nanna (e, espero, irei também expor gráficos bem melhores do que os obtidos por mim até a escrita deste post).

Até lá!

Upgrade no Grails Brasil: o que precisamos melhorar?

Como mencionei no Grails Brasil, retomei com tudo o projeto “Grails Brasil em Grails”. Para tal, estou criando uma aplicação open source chamada GForum (faltou criatividade no nome, confesso) que, posteriormente, poderá inclusive ser reaproveitada por aqueles que se interessarem em criar novas comunidades virtuais (dentro de um mês ou menos pretendo liberar o código fonte para que todos possam dar suas contribuições).

Um dos pontos principais no projeto consiste em melhorar o visual do site atual, que é bastante precário.

Sendo assim, gostaria de saber as opiniões dos membros da comunidade a respeito do que poderia ser melhorado no site. Aproveito também para pedir sugestões com relação ao nosso novo logotipo, que inclusive já comecei a esboçar:

Sim sim, eu sei que ainda está tosco. E é exatamente por isto que preciso da ajuda de vocês. Aos interessados em ajudar no projeto do novo site, por favor, enviem suas sugestões de layouts/logotipos para meu e-mail: loboweissmann@gmail.com. Publicarei todas as sugestões enviadas neste blog (e também no Grails Brasil) para que juntos possamos.

Aproveitando, eis uma bela oportunidade para que todos façam o maior número de críticas ao Grails Brasil atual, pois é a partir destas críticas que a estrutura de nossa comunidade será aprimorada.

Aos que quiserem uma participação mais direta no projeto (por a mão na massa), podem me contactar por msn (kicolobo@itexto.net) ou pelo e-mail que mencionei acima.

Aguardo o feedback de vocês!

Get Adobe Flash playerPlugin by wpburn.com wordpress themes