OctopusTeam blog

Scratch de natal!

2011-12-31T12:01:00.000-08:00

Neste natal, minha família resolveu dar um netbook pro meu sobrinho de oito anos, que já lida com o computador melhor que muita gente por aí.
Como não podia deixar de ser, o gurí ficou todo satisfeito, e sobrou pro “tio Márcio” a tarefa de rechear o netbook com programas e jogos. E foi fazendo isso que encontrei na internet o Scratch . Trata-se de um ambiente de programação integrado destinado principalmente a crianças (mas não somente).
Ao invés de digitar o código, você arrasta e conecta blocos de instruções como REPITA X VEZES ou SE-SENÃO.

Scratch from Karen Brennan on Vimeo.

Obviamente não é algo para desenvolvimento profissional, nem amador a ponto de qualquer criança conseguir fazer o que bem entender, mesmo assim é uma ferramenta incrível pra prototipar idéias e fazer jogos simples para estudo ou apenas por diversão.
A curva de aprendizado é bem pequena e a facilidade de controlar sprites na cena e obter entrada do usuário faz do scratch o melhor ponto de partida pros leigos iniciarem na programação de jogos.
Outra coisa bem interessante sobre o scratch é que é bem fácil publicar os projetos feitos nele. A própria IDE faz o upload pro portal do scratch, onde a comunidade pode jogar, comentar e baixar os "fontes" dos projetos. No portal, o projeto roda como uma applet java, mas há uma nova opção de rodar como flash.

E claro, enquanto digeria a ceia de natal, comecei a fazer um pequeno game no scratch. Comecei brincando com a lógica e vendo até onde poderia ir, e acabei me surpreendendo com as possibilidades desse programa. A mecânica já é conhecida e bastante simples. O jogador deve acertar as 3 bandeiras com um tiro de canhão para passar de fase. Para atirar, o jogador deve configurar o ângulo da parábola e a velocidade do tiro. São 4 fases ao todo, em especial a fase 3 é bastante desafiadora. Quantos tiros você precisa para completar as 4 fases ? Espero que aqueles que jogarem se divirtam tanto quanto eu me diverti escrevendo. Bom Jogo! E boa programação pros que quiserem se aventurar (Se não conseguir visualizar o jogo nesta página, acesse diretamente por este link ).

Clique na bandeira verde no topo direito para começar o jogo.
Saiba mais sobre este projeto

Feliz ano novo!

Game Design por quem entende do assunto

2011-02-23T08:14:00.000-08:00

Game Design é um conceito mal compreendido pela maioria das pessoas que não estão envolvidas com o mundo do desenvolvimento de jogos.

É comum as pessoas confundirem com desing gráfico ou até mesmo design da arquitetura do software do jogo.Game design se trata de transformar uma idéia em um jogo de maneira que mantenha o jogador jogando.

E para manter o jogador na frente do seu jogo, há uma quantidade enorme de pontos para se pensar como usabilidade, imersão, narrativa, dificuldade, rejogabilidade e inúmeras outras. Por isso o designer de um jogo precisa entender consideravelmente dos vários aspectos que envolvem a produção do jogo que pretende criar. Um game designer (na minha opinião) deve ser capaz de esboçar no papel a aparência dos personagens e ainda que de maneira simples, modelar um preview (ainda que simplista) de elementos de uma cena do jogo, conhecer tecnicamente a plataforma,linguagens, engines e ferramentas utilizadas no projeto do seu jogo.

Possivelmente alguns vão discordar dessa minha visão, dizendo que o designer do jogo deve se abster dos aspéctos mais técnicos do processo. Bom, como todo apaixonado por desenvolvimento de jogos, procuro ler bastante me informar de como pensam os grandes nomes da indústria, e eis que encontro uma entrevista (antiga) com o Senhor Fumito Ueda, sobre o processo de desenvolvimento de ICO (jogo obrigatório para todo aspirante a game designer!). E nessa entrevista o Senhor Ueda, demonstra em diversos pontos sua multidisciplinaridade e como isso resultou num projeto sublime, que conhecemos como ICO.
A entrevista pode ser lida na íntegra aqui

Vou comentar aqui algumas partes da entrevista que suportam a visão que tenho do game designer:

"In 1997, he got the idea to create a game with the universal theme of "boy meets girl," with the two main characters hand-in-hand during an adventure. To express the imagery behind this vague concept, he took an assistant and made a 3-minute movie using Lightwave."

Ueda iniciou o projeto criando uma animação. Ok, tinha um assistente, mas não parou simplesmente na fase do "Tive uma idéia"!

"Full production on the game began in October 1998; the team had made the decision to go with hand-done key frame animation rather than motion capture. Ueda claims that actors weren't able to understand the situation and move appropriated..."

Aqui, da pra ver o quanto o designer estava comprometido com a sua visão do jogo, dispensou o uso da tecnologia de captura de movimentos e optou por animação manual por que os atores não compreendiam como se mover adequadamente.

"Ueda wasn't satisfied with the results they were achieving, and became frustrated that the hardware wasn't capable of realizing his initial vision. He considered three options: either canceling the project outright, altering the design to try and finish the game on PSone, or changing platforms. After some deliberation, the team began converting the project for the PS2 hardware."

Aqui, o designer percebe que o hardware não estava sendo suficiente para alcaçar a visão inicial do jogo e ficam limitados a 3 opções: cancelar o projeto, alterar o design do jogo, ou mudar par outra plataforma. Como o jogo saiu para Playstation2 e não playstation, sabemos qual foi a decisão tomada. O importante aqui é o quanto o designer apostava na sua visão do gameplay e quanto compreendia da tecnologia em que estava trabalhando. Fico pensando na responsabilidade de entrar numa sala de reunião, e dizer para aqueles que pagam pelo projeto 2 anos depois de começado, que o hardware não é suficiente para implementar a visão inicial. Percebo que muita gente apostava na proposta inicial, afinal, não compete ao designer decidir se um jogo será cancelado ou não. Acredito que o que os executivos das empresas interessadas tinham era apenas o vídeo de 3 minutos, feito no início do projeto mostrando o gameplay que pretendiam alcançar, e ainda sim, mantiveram o design inicial e decidiram mudar a plataforma

Ao longo da entrevista, as visão do Sr Ueda em relação a narrativa, roteiro e imersão são demonstradas como neste trecho onde ele explica uma decisão simples - e fundamental na atmosfera do jogo - de não legendar as falas da personagem Yorda.

"Explaining why he opted not to include subtitles for Yorda's dialogue, he said that it was critical to the physical contact and "holding hands" concept that the two not be able to communicate and talk to each other all the time during gameplay."

Outros exemplos da multidisciplinaridade inerente ao papel do designer, podem ser lidos aqui, onde Ueda comenta tencicamente os efeitos de iluminação aplicados sobre as partículas implementadas para o jogo Shadow of the Colossus (como a poeira que levanta quando os colossos andam por exemplo).

"This is a method which performs lighting calculations using the relationship between the viewing direction and the lights affecting the particle, which creates an effect where the particle textures appear properly highlighted. The particles lighting calculation itself becomes expensive for the vector unit, but "the particle effect becomes 3D, because it is real-time and interactive, which is a big effect in itself."

Como eu disse no início do post, cabe ao designer conhcer tecnicamente os aspectos que envolvem a construção da sua visão. E pudemos ver pelas entrevistas que nos 2 grandes títulos concebidos por Fumito Ueda, ele esteve envolvido desde os aspectos mais técnicos do hardware até as facetas mais sutís da narrativa.

Obviamente o processo de desenvolvimento de um jogo como ICO ou Shadow of the colossus não pode ser comparado a nenhum título produzido atualmente no Brasil, mas a essência do papel do designer, é a mesma desde o mais simples PONG até a sala mais escura do castelo de ICO.

Quando eu crescer, quero ser que nem ele. Ha ha!

Alguns links interessantes:
ICO na fase de desenvolvimento para o PSOne
Making of Shadow of the Colossus
Site brasileiro sobre Fumito Ueda e seus Games

Terminal de comandos embutido no jogo

2010-10-21T16:34:00.000-07:00

No jogo que estamos fazendo, precisei continuamente reinicar o jogo para forçar o reload do cenário, ou inserir DrawString()’s no método Draw() para acompanhar o estado de algmas variáveis. Percebi que já havia tido necessidades semelhantes neste e em outros projetos. Decidi então que era hora de incluir um terminal que me permitisse automatizar ações comuns durante o desenvolvimento.

Muitos jogos utilizam um terminal para permitir que os jogadores ativem cheats ou façam configurações rápidas no contexto do jogo. Não sei dizer qual foi o primeiro game a incorporar um terminal de comandos mas acredito que apareceram na época dos vovô Quake2(alguém sabe ?).

Seja para Forçar Spawn de um NPC, Mostrar/Ocultar geometria de colisão ,Carregar/Recarregar um level, Exibir estatísticas (como uso de memória e Frame Rate) ou qualquer coisa você precise, um terminal é uma maneira confortável de interagir com seu jogo com o máximo de controle.

Utilizando o TerminalComponent

O terminal foi implementado segundo o padrão de projeto Singleton,
A primeira coisa a fazer é inicializar o componente:

protected override void Initialize()

{

ConsoleComponent.InitializeConsole(this, 25);

…

}

Agora basta, obter uma instância e adicionar a lista de componentes :

ConsoleComponent _terminal;

…

protected override void Initialize()

{

ConsoleComponent.InitializeConsole(this, 25);

_terminal = ConsoleComponent.GetConsole()

Components.Add(_terminal);

…

}

Por padrão a tecla F2 é utilizada para exibir/ocultar o terminal. Caso seu jogo já utilize esta tecla (pouco provável :D), você pode redefini-la através da propriedade ShowHideKey. Por exemplo, se quisermos utilizar a letra “T” bastaria o seguinte:

protected override void Initialize()

{

ConsoleComponent.InitializeConsole(this, 25);

_terminal = ConsoleComponent.GetConsole()

Components.Add(_terminal);

_terminal.ShowHideKey = Keys.T;

…

}

Pronto! Nosso game já tem um terminal! Mas pra que seja realmente útil, devemos definir alguns comandos, pois são eles – os comandos – a razão de ser do terminal.

Adicionando comandos personalizados

Vamos definir um comando chamado exit cuja função é finalizar o programa.
A primeira coisa a fazer é criar um método que será executado quando o comando for chamado. Este método deve obedecer a assinatura do TerminalCommandDelegate, ou seja, retornar void e receber um string[] como parâmetro.

private void ExitCommand(string[] args)

{

Exit();

}

Simples assim. Falta agora definir um comando no terminal que execute este método. Definir um comando é simplesmente passar para o método AddCommand o nome, uma descrição e um TerminalCommandDelegate (Delegate responsável pela execução do comando).

Para o nosso comando exit, ficaria assim:

protected override void Initialize()

{

ConsoleComponent.InitializeConsole(this, 25);

_terminal = ConsoleComponent.GetConsole()

Components.Add(_terminal);

_terminal.ShowHideKey = Keys.T;

_terminal.AddCommand("exit", "Terminates the program", ExitCommand);

…

}

Podemos definir também comandos mais complexos que recebam parâmetros, simplesmente verificando o array de strings passado para o método do comando.

Neste array, o primeiro elemento – índice zero – é sempre o nome do comando e os demais elementos, são os parâmetros passados para o comando.

Comandos pré-definidos

Além dos comandos que você definir para o terminal, existe sempre 2 comandos pré-definidos:

Comando help [comando]:

Exibe a descrição de um comando, ou se invocado sem parâmetros, exibe uma lista com todos os comandos definidos.

Comando clear:

Limpa o terminal removendo todas as linhas de texto.

Chamar o comando help passando o nosso comando exit como parâmetro, receberíamos como resposta, a descrição que criamos para o comando.

help exit

Command Description: Terminates the program

Considerações Finais

Cabem aqui algumas considerações:

1 - É conveniente impedir que o game processe input do teclado enquanto o terminal estiver ativo. Fazemos isso simplesmente impedindo que qualquer outro processamento aconteça enquanto o terminal estiver ativo

protected override void Update(GameTime gameTime)

{

// Não processa input se o terminal estiver ativo

if (_terminal.State == TerminalState.Active)

return;

// processa input

HandleInput(gameTime);

…

}

2 – O console deve sempre ser o último componente a ser desenhado , por isso, se durante a execução do jogo precisar adicionar um componente, adicione o componete com Insert() em alguma posição que não seja a última ou

remova o terminal, adicione o componente e adicione o terminal novamente.

//Remove o terminal

Components.Remove(ConsoleComponent.GetConsole());

//Adiciona o novo componente

Components.Add(outroComponente);

//Adiciona novamente o terminal

Components.Add(ConsoleComponent.GetConsole());

3 - Como o terminal é um Singleton podemos obter uma referencia em qualquer parte do programa e utilizá-lo como saída padrão de erros, mensagens e exceções.

#if DEBUG

ConsoleComponent.GetConsole().WriteLine(“Recarregando cenário”, Color.White);

#endif

Conclusão

É isso! O terminal será tão útil quanto os comandos que você definir para ele..

Deixe um comentário aqui ou mande um e-mail se este componente foi útil ao seu projeto ok ?

Baixe aqui o demo.

Componente XNA de Lockpick

2010-10-18T13:00:00.000-07:00

Depois de MUITO tempo sem postar, retomo a vida e as atividades anunciando a conclusão de um componente de lockpicking...

Lockpicking já é um recurso batante conhecido e amplamente utilizado em diversos jogos. Quem já jogou Splinter Cell, Oblivion ,Fallout (sim, usamos os gráficos de fallout neste demo) e etc. , já se deparou com essa forma de ganhar acesso a uma área, ou item protegido por uma tranca.

LockpickComponent é um componente XNA (Duh!) e pode ser integrado em qualquer jogo facilmente.
A mecânica é bem conhecida. Deve-se encontrar um ponto na circunferência que permita girar a tranca até o fim (45graus) para destrancá-la.
Ao forçar a tranca entretanto, dependendo de quão longe da posição de abrir estiver o pino, mais ou menos dano é aplicado sobre este. O pino pode quebrar se receber muito dano. Caso hajam mais pinos disponíveis, o componente automaticamente posiciona um pino novo para que o jogador possa tentar novamente.

Baseado na dificuldade escolhida, o componente gera um intervalo aleatório onde o pino deve ser posicionado que a tranca possa ser aberta. Quanto mais próximo o pino estiver deste intervalo, mais a chave de fenda conseguirá girar a tranca. Assim, é possível girar a tranca até bem próximo do fim e perceber que o pino apesar de próximo, ainda não está na posição ideal.

O construtor recebe além da referência ao game, a dificuldade e o total de pinos disponíveis para abrir a tranca.
A assinatura do construtor é a seguinte:


public LockpickComponent(Game pGame, Difficulty pDificulty, int pPinCount)

Logo, uma tranca com dificuldade normal, tendo 3 pinos disponíveis ficaria assim:

  
LockpickComponent _lpc;
…
// Uma tranca de dificuldade Normal. O jogador terá 3 pinos para tentar abri-la
_lpc = new LockpickComponent(this, _Difficulty.NORMAL, 3);

Ao criar uma instância do componente, pode-se configurar alguns handlers para os 3 eventos gerados pelo componente:


// Evento ao abrir a tranca
_lpc.OnUnlock += onLockEvent;
// Evento ao desistir de abrir a tranca
_lpc.OnCancelPickinLock += onLockEvent;
// Evento ao quebrar todos os pinos disponíveis
_lpc.onBreakAllPins += onLockEvent;

Ao iniciar, o componente faz uma pequena animação, aproximando a “câmera”. O zoom máximo pode ser customizado através da propriedade Scale, sendo 1.0 o tamanho original. No demo o valor padrão (1.5) foi utilizado.


this.Components.Remove(_lpc);

No demo, associei todos os eventos ao mesmo método, que simplesmente habilita o menu e remove o componente deixando a tela principal visível novamente. Em um jogo real, provavelmente você queira associar o eventos a rotinas que atualizem o inventário do personagem para debitar o numero de pinos usados, , abra uma porta em caso de sucesso e obviamente, remova o componente no final.

O demo pode ser baixado aqui Lembrando que é preciso o xna runtime 3.1 para que o demo execute corretamente.

:)

Videogames Live 2009

2009-10-05T17:03:00.000-07:00

Um evento incrível, emocionante e imperdível para qualquer nerd/gamer que se preze!

Aconteceu ontem no Canecão aqui no Rio de Janeiro o Videogames Live 2009, o show teve de tudo pra agradar desde a geração 8bit até a geração PS3.

Logo de início houve um concurso de cosplay e dentre as figurinhas de sempre como Mário

(Super Mario Bross) e Link (Zelda) destacaram-se um Cyrax (Mortal Kombat 3) e um Naked Snake (Metal Gear 3) que chegou ao palco em uma caixa nas proporções exatas da que se vê no game! Sabe aquilo de ver uma caixa movendo-se com um par de perninhas debaixo ? Eu não imaginava que dava pra fazer aquilo tão perfeitamente.

Me impressionou como o cidadão saía e logo depois se escondia na caixa... Haja flexibilidade!

O quesito humor entretanto foi decisivo para que um sujeito descalço trajando uma bermuda, uma peruca de cabelos compridos e bigode vencesse a competição, denominando-se o “Prisioneiro de Metal Slug”. Obviamente depois de realizar os movimentos bruscos do personagem e arrancar risadas da plateia... não dava pra não dar a vitória pro cara! Realmente foi algo muito divertido.

Quanto ao show, muita coisa boa preparada especialmente para a apresentação no Brasil. O apresentador e co-criador do evento, mencionou que muitas músicas haviam sido retiradas do repertório, mas retornaram pois eram pedidos constantemente pelo público brasileiro.

O ponto alto da noite, foi o momento em que o compositor de Snake Eater - Norihiko Hibino - foi anunciado e subiu ao palco para tocar sua obra - Tema de abertura de Metal Gear 3 - junto a orquestra. Norihiko, deixou o palco visivelmente emocionado com o público aplaudindo-o de pé.

A presença de Norihiko realmente foi um presente para os Brasileiros.

Das músicas que não se podem deixar de mencionar, tema de Mario Bross onde a plateia acompanhava a orquestra com onomatopéias estilo “tananãn”, tema de Shadow of the colossus que misturava a música de abertura com uma das batalhas de colossus, tema de Halo, Warcraft e finalmente os temas de Chrono Trigger e Crhono Cross. Um show que vale cada centavo pelo seu conteúdo. Infelizmente, alguns pecados na organização e infra-estrutura deixaram a desejar. A iluminação foi terrível, as luzes não deixavam enxergar o telão central, e aleatóriamente eram apontadas para o público cegando-nos completamente. Em outros casos, deveria haver iluminação mais fraca para que se pudesse ver detalhes como luzes nos trajes de cosplays que subiam ao palco em determinados momentos, entretanto vergonhosamente só haviam spots com iluminação intensa a todo tempo. A qualidade do som também não foi das melhores, apesar da apresentação impecável da Sinfônica Vila Lobos, o som da orquestra estava baixo ao ponto da platéia em coro pedir “Aumentem a orquestra!”.

Mesmo com as falhas de infra-estrutura ou organização, não sei bem, o show foi, como já havia dito, sensacional, e vale cada centavo dos 140 reais que custou o ingresso. Saímos do show com gostinho de quero mais, e já ansiosos pelo que virá no ano que vem.

Simplesmente divertido

2009-07-14T17:15:00.000-07:00

Hoje encontrei perdido no meu HD de backup, o primeiro game 3D que fiz, há un 1 ano quando comecei a estudar GameDev. Este jogo é para celulares feito em JAVA e simula a velha brincadeira de fincar uma faca entre os dedos com a mão apoiada sobre a mesa.
O jogo move a faca em arco variando o raio, ora mais perto das extremidades dos dedos, ora mais perto do centro da mão. O jogador tem então 30 segundos para fincar a faca na mesa o maior numero de vezes possível. A cada acerto, soma-se 1 segundo ao tempo de jogo, a cada erro, subtraem-se 2 segundos do tempo de jogo. Obviamente o jogo emite gritos de dor quando um dedo é atingido e o vibrador do celular é ativado por uma fração de segundo.

Eu pensava ter perdido este game durante um particionamento mal sucedido no meu notebook.
Depois de enxugar as lágrimas dos olhos (eu me emocionei ao reencontrar meu primeiro game!).
Perdi uns minutos jogando no emulador e pesando na simplicidade desta idéia. Quase me surpreendendo de quão divertido este game é. Uma brincadeira tremendamente simples tornou-se um game divertido de jogar. E isso é basicamente o que importa para o jogador. Diversão!

Não adianta um game com gráficos arrasadores se não tiver um gameplay divertido! Em muitos casos menos é mais. Antigamente, não era possível ter os gráficos que temos hoje e não haviam recursos computacionais para simulações físicas complexas tais como vemos nos jogos atuais.
Nessa época, os jogos valiam a diversão que ofereciam. Vai dizer q nunca passou uma tarde inteira jogando Enduro, pitfall ou Pac-man ? Lembre-se como eram toscos (visualmente) mas como eram divertidos estes games!

Vamos fazer uma comparação tosca, Assassins Creed Versus Tetris. Claro que se compararmos gráficos tetris nem entra na disputa, mas e quanto ao desafio ? E diversão ? Assassins Creed é um jogaço, mas depois da segunda ou terceira "missão" você começa a ver que todas vão ser iguais...
O jogo não te desafia (apesar de ainda ser um bom jogo! Não me crucifique!), enquanto cada partida de tetris é nova e imprevisível!

No game que estou desenvolvendo atualmente, me deparo em momentos onde ainda não decidí como certas ações serão feitas pelo jogador. Com certeza, o ponto de partida para decidir será respondendo a pergunta: "Como fica mais divertido ?"

O primeiro game – 5 dicas para começar

2009-07-09T14:50:00.000-07:00

Todo geek ama video-games! Como todo bom geek, eu sempre quis criar meus próprios games. A estrada para a criar games é árdua, longa e a curva de aprendizado é grande. Por isso, para aqueles que querem começar , aqui vão dicas para evitar que seu primeiro game vire um vaporware:

1 – Não morda mais do que consegue mastigar

Não comece tentando fazer um clone do seu jogo preferido! Ele certamente foi feito por uma equipe enorme de profissionais experientes trabalhando full time e com recursos adequados. Seja realista, se você não tem experiência com 3D, comece com 2D ou modo texto. Saiba até onde você pode chegar com o conhecimento que tem. Obviamente todo projeto tem um desafio e algo que precisamos aprender durante o percurso. Questione-se se o volume de conhecimento que você precisa obter para concluir seu projeto, é razoável. Não adianta planejar algo que você precise estudar 1 ano para conseguir começar. Uma boa idéia é começar com jogos clássicos como pedra-papel-tesoura , jogo da velha ou tetris.

2 – Comece com Demos

Um game é composto de muitos elementos. Quando possível , faça pequenos projetos para aprender cada elemento separadamente. Por exemplo, lembra de Resident Evil 1 ? Esse game não permitia que o jogador movesse a câmera, ao invés disso, mudava o ângulo da câmera automaticamente de acordo com a posição do personagem no mapa. Se seu game utilizará esse recurso, faça um demo antes para entender melhor como funciona esse mecanismo. Isso evita que você polua o código do projeto completo com código de algo que você ainda está estudando.

3 – Planeje!

Por mais simples que seja o game, faça um documento de como ele deve funcionar. Descreva o gameplay, sistema de contagem de pontos, teclas utilizadas para controlar o jogador, condições de vitória, derrota e etc. Quando você documenta o seu game, vai perceber que ao contrário do que imagina, você não sabe exatamente como vai funcionar cada parte.Durante o projeto este documento servirá de guia, e você saberá exatamente em que parte do game estará trabalhando, quais estão prontas quais ainda serão feitas. Além disso, documentar o game permite que outras pessoas possam te ajudar no projeto, já que o conceito não está só na sua cabeça.

4 – Participe da comunidade

Ao contrário de Chuck Norris, nós meros mortais, não sabemos tudo e sempre precisaremos de ajuda em algum momento. Participe de forums sobre GameDev, Um bom começo é o www.gamedev.com.br.

5 – Não parta do Zero

Não gaste tempo fazendo o que você pode obter pronto com a comunidade ou com o oráculo (leia-se Google). Se seu game precisa de um emissor de partículas e você não sabe como fazer um, consiga um pronto na internet e utilize! Não estou dizendo que você não deve aprender como funciona um emissor de partículas, mas para que seu primeiro game saia do papel, você precisará manter o foco no que interessa: o game. Isso se aplica a tudo, física, networking, AI, GUI e etc. Para seus primeiros games, faça o mínimo de código que não se aplique diretamente ao gameplay. Assim seu projeto ganha vida com menos esforço e você não desanima!

Como dizia o tio Ben: “Grandes poderes trazem grandes responsabilidades”. Tome cuidado para deixar nos fontes as referências do autor (nome, email, site onde conseguiu) do código que você está utilizando. Obviamente, não é por utilizar algo que já está pronto, que você deve se acomodar. Reserve um tempo para estudar o código que pegou e aprender a fazer um demo (dica 2) com sua própria implementação.

Bom começo!

Post que pariu!

2009-07-08T18:14:00.001-07:00

Primeiro post é sempre o mais difícil. Mas tem que começar em algum lugar!
O mínimo aceitável é que descreva aqui os assuntos que pretendo abordar no blog. Então vamos lá:
Tecnologia, gadgets, desenvolvimento e mercado de games no Brasil, algum humor (nunca é d+) e sei lá mais o que der na telha, afinal o blog é meu :D

Como eu disse, primeiro post é complicado, por isso fico por aqui e preparo um segundo post decente :)

Carpe Diem!