CubaGames

Criando Um Jogo em Windows Forms - Parte 6 - Colisão De Borda

Fernando Lorenzon — Wed, 03 Feb 2010 13:22:17 +0000

Neste post, vou mostrar algo bem simples. É a colisão de borda.

A borda nada mais é que um delimitador da área do jogo, que pode ser os extremos da tela, por exemplo.

Esta detecção é importante caso seja necessário manter um sprite dentro da tela. Por exemplo, nos jogos de tiro em scroll vertical como a série Sonic Wings, você não consegue movimentar o avião além da própria tela. Quando o aviãozinho atinge o limite da tela, ele simplesmente não se locomove mais naquela direção.

Utilizando a classe Sprite criada no post anterior, podemos chamar uma função que retorne um booleano para detecção de colisão para uma determinada borda. Quando o retorno for true, o que podemos fazer é zerar a velocidade naquela direção, e talvez voltar um pixel para que o sprite saia do estado de colisão e não fique "preso".

Uma coisa que eu esqueci de mencionar no post anterior é que para que possa ser detectado com facilidade as colisões, o ideal é usarmos sprites retangulares. O problema é que um Super Mario quadradinho não venderia tão bem...

Para contornar este problema, devemos sempre usar, associado à imagem do sprite, um retângulo invisível que servirá de zona de detecção. Quando mais ajustado ao tamanho da imagem, melhor.

A classe Sprite possui um objeto pictureBox dentro dela, e esse pictureBox possui a imagem do sprite, e além disso, ela é um retângulo cujas dimensões podem ser facilmente obtidas. Ou seja, o próprio pictureBox serve tanto como imagem quanto zona de detecção. Se fosse no XNA puro, teríamos que renderizar a imagem em cima de uma retângulo invisível e usar a imagem para exibição, e o retângulo para detecção.

Fugindo um pouco, mas nem tanto... Vocês já perceberam que nos primeiros Resident Evil as imagens que formam os cenários são navegáveis pelos personagens como se fossem 3D? Como o jogo sabe numa imagem onde começa o corredor ou onde está a porta? É simples. O jogo não sabe. Os programadores posicionam em cada imagem do cenário um cubo de detecção exatamente com as dimensões das áreas "caminháveis" de cada imagem. E é por este cubo invisível que a engine do jogo se enxerga para deslocar os personagens. A foto não influencia em nada.

Possíveis bordas feitas por mim

No caso do nosso sprite, até seria possível ficar testando a sobreposição de imagens, pixel a pixel, para proporcionar uma colisão perfeita. Mas se fizessem isso com Mario, ele nunca rodaria nos consoles antigos. Lembram que eu mencionei sobre uma detecção de colisão que eu fiz comparando pixel a pixel os retângulos? Nem usei os pixels da imagem, que certamente pesaria mais ainda, e ainda assim o jogo ficou com uns 5 quadros.

Em imagens mais complexas, são utilizados mais retângulos por sprite, e as colisões são testadas individualmente. Um exemplo disso são os jogos de luta 2D. Quem já fuçou no MUGEN já deve ter visto isso.

Voltando à colisão de borda, temos que testar a colisão de cada borda individualmente. Para isso, basta chamar a função para cada borda que deve ser testada, passando o limite dela, o sprite, e a direção.

Para criar a função, eu criei também um enumerador com as quatro direções, e assim fica mais fácil passar a direção como parâmetro.

Para cada direção, eu uso um dos vértices do retângulo do sprite para testar a colisão. Eu criei para a classe Sprite quatro propriedades para retornar cada vértice do retângulo, começando a partir do superior esquerdo (0,0) e girando no sentido horário:

Para testar uma colisão do lado esquerdo, preciso usar o vértice 1 ou o 4.

Para testar uma colisão em cima, preciso usar o vértice 1 ou o 2.

Para testar uma colisão do lado direito, preciso usar o vértice 2 ou 3.

Para testar uma colisão embaixo, preciso usar o vértice 4 ou 3.

Todos os sprites ocupam uma posição absoluta na tela. A tela nada mais é que uma grade de pixels, que começa no canto superior esquerdo como 0,0, e termina no canto inferior direito como 640,480 (caso esteja usando esta resolução).

Então, se o vértice 1 estiver na posição do eixo X=0 ou menos, houve uma colisão do lado esquerdo. Se não pararmos o sprite neste momento, nada impede que ele saia da área visível da tela. É perfeitamente possível um sprite ocupar coordenadas de valores negativos (-52,300).

Vamos à função:

PLAIN TEXT

public static bool DetectBorderCollision(Sprite sprite, Enum.Direction direction, int collisionPoint)
{
bool collided = false;
if (direction == Enum.Direction.Down)
{
if (sprite.Vertex3.Y>= collisionPoint)
{
collided = true;
}
}
else if (direction == Enum.Direction.Up)
{
if (sprite.Vertex1.Y <= collisionPoint)
{
collided = true;
}
}
else if (direction == Enum.Direction.Left)
{
if (sprite.Vertex1.X <= collisionPoint)
{
collided = true;
}
}
else if (direction == Enum.Direction.Right)
{
if (sprite.Vertex2.X>= collisionPoint)
{
collided = true;
}
}
return collided;
}

Uma função extremamente simples e leve. Se quisermos testar a colisão nos quatros lados da tela, teremos que chamar a função 4 vezes. Para cada vez, passamos uma das direções e o limite da borda, em pixels. Na colisão à esquerda, o collisionPoint deve ser 0. Para a colisão à direita, o collisionPoint deve ser 640.

O que será feito com o retorno da função depende de cada game ou situação. No WinForms Lander, só testo a colisão na parte de baixo. Caso haja colisão, a nave quebra, o jogador perde uma vida, e o estágio é reiniciado. Só passa de fase se o jogador pousar na plataforma.

Você Não Escapará da Sega

Fernando Lorenzon — Wed, 27 Jan 2010 20:40:56 +0000

Em uma coisa a Sega é bem melhor que a Nintendo & CIA: ela conhece seu passado glorioso.

Mas viver só do passado, aí não.

Durante esses anos todos, a Sega se meteu em muitas áreas para lucrar um pouco mais com seus games antigos. O problema é que a coisa está saindo do controle. Daqui a pouco terá Sonic 2 até no relógio.

Eu acho muito divertido ver o quanto a Sega tenta lucrar com seus games antigos. Ela simplesmente tenta enfiar seus games em todos os tipo de coletâneas, aparelhos, emuladores, relançamentos...

A cada nova geração de consoles, a Sega cria uma nova coletânea de games do Sonic e outros clássicos. Tudo o que for comercialmente viável (ou nem isso), a Sega encara. O pior é que às vezes o mesmo produto / serviço é relançado com pequenas modificações. Ou coletâneas parciais são lançadas, sempre desvalorizando a anterior.

Vou compilar uma lista de coisas antigas da Sega que foram lançadas. Vejam que o volume de produtos chega a ser absurdo:

Sonic Compilation

Uma compilação dos jogos do Sonic para Mega Drive. Inclui:

- Sonic the Hedgehog;
- Sonic the Hedgehog 2;
- Dr. Robotnik's Mean Bean Machine;

Sonic Jam

Uma compilação dos jogos do Sonic para o Saturn. Inclui:

- Sonic the Hedgehog;
- Sonic the Hedgehog 2;
- Sonic the Hedgehog 3;
- Sonic & Knuckles;

Sega Ages

Foram lançados para Saturn alguns clássicos 16-bits da Sega sob esta série. Eles são:

- Out Run;
- Space Harrier;
- Galaxy Force II;
- After Burner II;
- Fantasy Zone;
- Power Drift.

Além disso, teve algumas outras versões não muito populares com mais games antigos.

Sega Ages 2500

Uma série para PS2 com 33 volumes, sendo cada volume um port de games da Sega para arcade. Aqui entraram alguns jogos 3D:

- Vol. 01 Phantasy Star Generation 1
- Vol. 02 Monaco GP
- Vol. 03 Fantasy Zone
- Vol. 04 Space Harrier
- Vol. 05 Golden Axe
- Vol. 06 Bonanza Bros.
- Vol. 07 Columns
- Vol. 08 Virtua Racing
- Vol. 09 Gain Ground
- Vol. 10 Afterburner II
- Vol. 11 Hokuto no Ken (?????) (Fist of the North Star)
- Vol. 12 Puyo Puyo Tsuu Perfect Set
- Vol. 13 Outrun
- Vol. 14 Alien Syndrome
- Vol. 15 Decathlete Collection
- Vol. 16 Virtua Fighter 2
- Vol. 17 Phantasy Star Generation 2
- Vol. 18 Dragon Force
- Vol. 19 Fighting Vipers
- Vol. 20 Space Harrier Complete Collection
- Vol. 21 SEGA System 16 Collection: SDI & Quartet
- Vol. 22 Advanced Daisenryaku: Doitsu Dengeki Sakusen
- Vol. 23 Sega Memorial Selection
- Vol. 24 Last Bronx
- Vol. 25 Gunstar Heroes, Treasure Box
- Vol. 26 Dynamite Deka
- Vol. 27 Panzer Dragoon
- Vol. 28 Tetris Collection
- Vol. 29 Monster World Complete Collection
- Vol. 30 Galaxy Force II Special Extended Edition
- Vol. 31 Cyber Troopers Virtual-On
- Vol. 32 Phantasy Star Complete Collection
- Vol. 33 Fantasy Zone Complete Collection

Sega Smash Pack

Coletânea de jogos da Sega para PC:

- Altered Beast
- Columns
- Golden Axe
- Out Run
- Phantasy Star II
- Sonic Spinball
- The Revenge of Shinobi
- Vectorman

Sega Smash Pack 2

Continuação de uma coletânea só poderia ser cortesia da Sega:

- Comix Zone
- Flicky
- Kid Chameleon
- Sega Swirl
- Shining Force
- Sonic the Hedgehog 2
- Super Hang-On
- Vectorman 2

Sega Smash Pack para Dreamcast

- Altered Beast
- Columns
- Golden Axe
- Phantasy Star II
- The Revenge of Shinobi
- Sega Swirl
- Shining Force
- Vectorman
- Sonic the Hedgehog
- Streets of Rage 2
- Virtua Cop 2
- Wrestle War

Sonic Mega collection

Uma coletânea lançada para PS2, XBox, Gamecube e PC com os jogos clássicos do mascote lançados no Mega Drive. Eles são:

- Sonic the Hedgehog;
- Sonic the Hedgehog 2;
- Sonic the Hedgehog 3;
- Sonic & Knuckles;
- Sonic 3D Blast;
- Sonic Spinball;
- Dr. Robotnik's Mean Bean Machine.

Sonic Mega Collection Plus

Além dos jogos da coletânea anterior, foram incluídos alguns jogos lançados para Game Gear:

- Sonic the Hedgehog;
- Sonic Chaos;
- Sonic Drift;
- Sonic Labyrinth;
- Dr. Robotnik's Mean Bean Machine;
- Sonic Blast.

Sonic Gems Collection

Mais uma coletânea para PS2 (apenas no Japão) e Gamecube que além incluir os jogos das coletâneas anteriores, ainda inclui alguns jogos extras do Sonic:

- Sonic CD;
- Sonic the Fighters;
- Sonic R;
- Sonic the Hedgehog 2 (Game Gear);
- Sonic Spinball (Game Gear);
- Sonic Triple Trouble (Game Gear);
- Sonic Drift 2 (Game Gear);
- Tails' Skypatrol (Game Gear);
- Tails Adventure (Game Gear);

E alguns jogos secretos:

- Vectorman;
- Vectorman 2;
- Bonanza Bros.;
- Streets of Rage;
- Streets of Rage 2;
- Streets of Rage 3;

Será que precisou lançar TRÊS VEZES a mesma coletânea para ela ter uma quantidade aceitável de jogos do Sonic? Porque não lançou o Sonic Gems Collection logo na primeira vez?

Mega Drive portátil

Inúmeros portáteis baseados no Mega Drive foram lançados, com jogos na memória e alguns com possibilidade de expansão via SD Card.

Emulador do Saturn

A Sega chegou até a comprar e distribuir um emulador de Saturn Para Windows, e assim vender jogos de Saturn pela rede CYBER DISC. O emulador é o GiriGiri. Claro que não prosperou.

PlaySEGA

Portal de jogos pagos e gratuitos jogados direto pelo browser. A grande maioria é do Mega Drive. Muitos só assinaram o serviço só para ganhar um controller usb no estilo daquele do Mega Drive.

Jogos na Live Arcade

Muitos jogos da Sega foram publicados na XBox Live Arcade. Muitos deles podem ser encontrados em outras coletâneas.

Jogos no Virtual Console

O Virtual Console possui uma extensa lista de games da Sega disponíveis para compra.

Jogos no IPhone

Vários clássicos estão sendo portados para o IPhone e vendidos pela AppStore.

Emulador no IPhone

Não bastasse os games vendidos separadamente, agora o IPhone terá um emulador, que agregará os games da Sega e centralizará as compras.

Sonic's Ultimate Genesis Collection

Coletânea para XBox 360 e PS3 dos maiores clássicos da Sega lançados para Mega Drive.

Sonic Classic Collection

Coletânea básica para DS:

- Sonic the Hedgehog
- Sonic the Hedgehog 2
- Sonic the Hedgehog 3
- Sonic & Knuckles

(Fonte das listas: Wikipedia)

Com isso, Sonic The Hedgehog, o jogo original para Mega Drive, já apareceu nos seguintes consoles (avulso ou numa coletânea):

Mega Drive/Genesis

- Sonic The Hedgehog;
- Sonic Compilation;

Saturn

- Sonic Jam;

Dreamcast

- Sega Smash Pack;

iPod Nano

- Sonic The Hedgehog;

iPhone

- Sonic The Hedgehog;

Celulares

- Sonic The Hedgehog;

Virtual Console

- Sonic The Hedgehog;

- Sonic Mega Collection;
- Sonic Mega Collection Plus;

PS2

- Sega Genesis Collection;
- Sonic Mega Collection;
- Sonic Mega Collection Plus;
- Sonic Gems Collection;

Gamecube

- Sonic Mega Collection;
- Sonic Mega Collection Plus;
- Sonic Gems Collection;

XBox

- Sonic Mega Collection;
- Sonic Mega Collection Plus;

PSP

- Sonic The Hedgehog (PS Store);
- Sega Genesis Collection;

PS3

- Sonic The Hedgehog (PS Store);
- Sonic's Ultimate Genesis Collection;

Xbox 360

- Sonic The Hedgehog (XBLA);
- Sonic's Ultimate Genesis Collection;

Game Boy Advance

- Sonic The Hedgehog;

Wii

- Sonic The Hedgehog (Virtual Console);

Internet

- Sonic The Hedgehog (PlaySEGA);

PS.: Esta listagem pode estar incompleta. O objetivo do texto é especialmente mostrar o jeito Sega de ser.

Criando Um Jogo em Windows Forms - Parte 5 - Colisão Simples

Fernando Lorenzon — Mon, 25 Jan 2010 16:26:37 +0000

Uma das coisas mais importantes em um jogo é a colisão. Isso não significa que deva haver uma explosão ao colidir sprites, mas simplesmente fazer com que o Super Mario possa caminhar sobre o chão sem atravessá-lo.

Existem muitas implementações para colisão. Desde implementações simples até das mais complexas. Por exemplo, a colisão usada nos jogos do Mario para coletar as moedas só precisa informar se Mario tocou a moeda. Mas para testar a colisão em um koopa, é necessário verificar se Mario está acima ou no lado ao tocar o inimigo. Caso esteja em cima, Mario sai ileso e elimina o inimigo. Caso esteja no lado, Mario perde uma vida.

Para testar uma colisão dessas, é bem mais complicado. Principalmente se os sprites se movem com mais velocidade.

O que vou mostrar agora é a colisão simples (aquela da moeda). Até porque a minha colisão que detecta a direção do toque não é 100% confiável em altas velocidades (parece até coisa de mecânica quântica). Eu digo "minha" colisão porque fiz questão de tentar criar uma solução por conta própria, sem pesquisar nada na internet. É claro que futuramente terei que ir atrás disso, pois não sou um bom programador de jogos e nem um bom matemático.

Para detectar uma colisão simples, o ideal é usar cálculos e algoritmos que usem poucos ciclos de CPU. É bem difícil saber o quanto um cálculo usa de CPU. Mas podemos deduzir a complexidade dele pela quantidade de linhas de códigos e quantidade de loops usados.

Uma das minhas idéias iniciais para detectar colisão deixou o jogo com uns 5 quadros de animação por segundo. Enquanto as outras duas mantinham a velocidade de 50. Aí podemos ver que não daria certo usá-la

Mas porque ficou tão pesado? Porque o que eu fazia era comparar pixel por pixel a área utilizada por cada um dos sprites que eu estava testando a colisão. Quando eu vi a degradação da performance, logo busquei outra alternativa, bem mais leve.

Vamos a elas:

Mas para fins didáticos, vou mostrar minha idéia dos 5 FPS:

Comparando colisão entre sprite1 com sprite2:

1 - gerar lista com todos os pixels do sprite1

2 - gerar lista com todos os pixels do sprite2

3 - comparar cada pixel com sprite1 com cada pixel do sprite2

Este método é bastante lento, mas 100% confiável. O problema é que se um sprite com 50x50 pixels for comparado com outro sprite 50x50, estaremos comparando 2500 pixels contra outros 2500. Isso tudo 50 vezes por segundo.

O método mais simples e igualmente preciso que eu usei no jogo foi este:

1 - Verificação Horizontal (Eixo X):

1.1 - Subtrair a distância (sempre em pixels) da extremidade da direita do sprite mais à direita com a extremidade esquerda do sprite mais à esquerda;

1.2 - Somar a largura do sprite1 com a largura do sprite2;

1.3 - se a distância for menor ou igual à soma das larguras, realizar a verificação Vertical.

2 - Verificação Vertical (Eixo Y):

2.1 - Subtrair a distância (sempre em pixels) do topo do sprite mais acima com o fundo do sprite mais abaixo;

2.2 - Somar a altura do sprite1 com a altura do sprite2;

2.3 - se a distância for menor ou igual à soma das alturas, a colisão foi confirmada.

No passo 1.3, vejam que há condição para continuar. Se uma colisão em uma das dimensões não tiver sido detectada, não há necessidade de testar na outra dimensão.

Colidir em uma dimensão parece coisa de doido, mas o que quero dizer é o seguinte:

Na figura acima, houve uma colisão no eixo Y, mas não no eixo X. Portanto, para um jogo 2D, não houve colisão. Veja que os dois quadrados ocupam as mesmas posições referentes a altura.

Já nesta figura acima, houve uma colisão no eixo X, mas não no eixo Y.

E aqui, finalmente ocorreu uma colisão nos dois eixos.

Segue o código abaixo.

PLAIN TEXT

public static bool DetectCollision(Sprite sprite1, Sprite sprite2)
{
bool partial1 = false;
bool partial2 = false;
int xDistance = sprite2.Vertex2.X - sprite1.Vertex1.X;
int yDistance = sprite2.Vertex4.Y - sprite1.Vertex1.Y;
//Verifica se sprite2 está mais à esquerda que sprite1
if (sprite2.Vertex1.X <sprite1.Vertex1.X)
{
xDistance = sprite1.Vertex2.X - sprite2.Vertex1.X;
}
//Verifica se sprite2 está mais ao topo que sprite1
if (sprite2.Vertex1.Y <sprite1.Vertex1.Y)
{
yDistance = sprite1.Vertex4.Y - sprite2.Vertex1.Y;
}
int xSize = sprite1.PictureBoxMain.Size.Width + sprite2.PictureBoxMain.Size.Width;
int ySize = sprite1.PictureBoxMain.Size.Height + sprite2.PictureBoxMain.Size.Height;
if (xDistance <= xSize)
{
partial1 = true;
}
if (partial1)
{
if (yDistance <= ySize)
{
partial2 = true;
}
}
return partial2;
}

Vocês devem ter visto que existe uma classe chamada Sprite. Esta classe é uma implementação minha para facilitar as coisas. Uma das facilidades é poder retornar o X/Y de cada um dos vértices do pictureBox, obtido através do Location e do Size. A implementação da classe Sprite segue abaixo:

PLAIN TEXT

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using System.Drawing;
namespace WinFormsLander.Classes
{
public class Sprite
{
/*
*
* 1------2
* | |
* | |
* | |
* 4------3
*
* */
public Point Vertex1
{
get
{
return new Point(this.PictureBoxMain.Location.X, this.PictureBoxMain.Location.Y);
}
}
public Point Vertex2
{
get
{
return new Point(this.PictureBoxMain.Location.X + this.PictureBoxMain.Size.Width, this.PictureBoxMain.Location.Y);
}
}
public Point Vertex3
{
get
{
return new Point(this.PictureBoxMain.Location.X + this.PictureBoxMain.Size.Width, this.PictureBoxMain.Location.Y + this.PictureBoxMain.Size.Height);
}
}
public Point Vertex4
{
get
{
return new Point(this.PictureBoxMain.Location.X, this.PictureBoxMain.Location.Y + this.PictureBoxMain.Size.Height);
}
}
public PictureBox PictureBoxMain;
public string ID;
public Image ImageDefault;
public int FlipVCounter;
public int FlipHCounter;
public bool FlipV;
public bool FlipH;
public float VerticalVelocity;
public float HorizontalVelocity;
public float TotalVelocity;
public float Y;
public float X;
public float StretchedY;
public float StretchedX;
public int DefaultHeight;
public int DefaultWidth;
public float VerticalVelocityLimit;
public float HorizontalVelocityLimit;
public float Drag;
public float GForce;
public bool vBouncingZone;
public bool hBouncingZone;
public int FlickCount;
public float Accel;
public float AccelMpS;
public Sprite(PictureBox pictureBoxMain)
{
this.PictureBoxMain = pictureBoxMain;
this.PictureBoxMain.BackColor = Color.Transparent;
this.ID = "";
this.ImageDefault = null;
this.FlipVCounter = 0;
this.FlipHCounter = 0;
this.FlipV = false;
this.FlipH = false;
this.VerticalVelocity = 0;
this.HorizontalVelocity = 0;
this.TotalVelocity = 0;
this.Y = PictureBoxMain.Location.Y;
this.X = PictureBoxMain.Location.X;
this.StretchedY = 0;
this.StretchedX = 0;
this.DefaultHeight = this.PictureBoxMain.Size.Height;
this.DefaultWidth = this.PictureBoxMain.Size.Width;
this.VerticalVelocityLimit = 50;
this.HorizontalVelocityLimit = 50;
this.Drag = 0;
this.GForce = 0;
this.vBouncingZone = false;
this.hBouncingZone = false;
this.FlickCount = 0;
this.Accel = 0;
this.AccelMpS = 0;
this.PictureBoxMain.BackgroundImage = this.ImageDefault;
}
}
}

Saber Algo vs. Saber o Nome de Algo

Fernando Lorenzon — Tue, 19 Jan 2010 15:53:24 +0000

Este é um texto que não se aplica totalmente com games, mas darei o devido enfoque gamístico ao tema.

Hoje, na era da informação, sabemos de muita coisa. Mas muitas delas apenas sabemos seu nome. E enganamos a nós mesmos achando que saber nomear algo é ter conhecimento sobre este algo.

Querem um exemplo? Pergunte para qualquer um porque os objetos caem ao soltá-los, e muito pomposamente, quase com uma ar de doutor, o sujeito responderá: "As coisas caem por causa da gravidade."

Isso não explica absolutamente nada. Na verdade, até hoje não se sabe o que é realmente a gravidade. Só medimos seus efeitos, mas não sabemos o que a manifesta. Isto está sendo inclusive o maior esforço da física quântica atual, o de tentar unificar a relatividade geral (nova teoria da gravitação) com a mecânica quântica.

Isso não impede o pensamento quase tautológico das pessoas, afirmando que as coisas caem por causa da gravidade, e a gravidade existe porque as coisas caem.

Qualquer moleque sabe de cor os nomes de cada carro esportivo de luxo por aí. Mostre uma foto de uma Ferrari 355 e prontamente qualquer adolescente dirá o nome, exibindo uma grande pseudo-sabedoria.

Quem assistiu o filme Idiocracy, provavelmente deve lembrar da cena onde o protagonista pergunta porque consideram aquela bebida verde tão boa. E todos sempre respondiam algo como: "porque contém electrolytes", fazendo sempre um gesto com as mãos. Aí quando se perguntava se eles sabiam o que era "electrolytes", eles desconversavam e explicavam que era o que tornava a bebida boa.

No universo dos jogos, isso ocorre com bastante frequência. Qualquer universo ligado com alta tecnologia traz consigo uma infinidade de siglas para definir cada um de seus elementos. Às vezes, um nome anterior já existente e perfeitamente compreensível dá lugar a um novo acrônimo, trazendo também um novo frescor na definição antiga.

Querem exemplos?

1 - ACM

ACM é a sigla para "Advanced Computer Modelling", que significa nada mais que "Modelagem Avançada por Computador". Isso soa bonito, mas é somente um eufemismo para imagem pré-renderizada.

Esta tecnologia foi empregada em inúmeros jogos, mas foi em Donkey Kong Country que o acrônimo foi utilizado pela primeira (e talvez única) vez. Talvez antes de DKC nenhum outro jogo utilizou imagens pré-renderizadas com tamanho nível de qualidade para criar sprites e cenários. Mas de novidade mesmo, não há nada. Parece até que a maneira como a imprensa cita o tal ACM denota algo acima do normal; uma tecnologia que só foi possível usando um chip especialmente projetado para compor o cartucho. Donkey Kong Country possui uma engine muito parecida com a de Super Mario World. O console exibe o sprite independente dele ter sido gerado em pixel art ou digitalizado. Na memória, é tudo a mesma coisa.

Alone in the Dark usava gráficos pré-renderizados para os cenários, assim como os primeiros Resident Evil. Vectorman para Mega Drive tinha seus sprites criados a partir de modelos em 3D pré-renderizados assim como DKC. Acho que até o Sonic teve algo assim também. Já perceberam o quanto os gráficos de Sonic parecem plastificados? Pena que os fãs da Sega só ficam chorando, ao invés de investigarem essas coisas também.

Pit-Fighter e Mortal Kombat usavam algo muito próximo do tal ACM, mas com imagens obtidas de filmagens. Apesar de alguns poderes e personagens terem sido criados digitalmente e depois utilizados para gerar os sprites.

O termo é tão genérico que posso criar um similar agora. ACM poderia significar "Advanced Clay Modelling", que é uma tecnologia usada para criar os games da série Clay Fighters, com personagens feitos de massinha e digitalizados (Goro de Mortal Kombat também foi criado assim).

Aliás, desconfie da utilidade de qualquer sigla que possua "a" de "advanced".

2 - Blast Processing

Esse é o termo por trás do grande poder de processamento do Mega Drive. Ok, é óbvio que o nome foi inventado pela Sega para demonstrar o quanto o Mega Drive era mais poderoso que o console da geração anterior (comparar processamento entre consoles de diferentes gerações é apelação). Mas também foi utilizado para mostrar que o Mega Drive tinha algo mais que o recém lançado Super Nintendo. Veja que o Super Nintendo realmente tinha tecnologias reais, como o Mode 7, que era um conjunto de instruções capazes de aplicar escala, inclinação e rotação em imagens de background, gerando coisas reais mesmo, como as pistas em 3D de F-Zero.

Em um quesito o console da Sega realmente superava o Snes: Clock da CPU. O Snes possui uma CPU que atinge até 3,58MHz, enquanto o Mega Drive atinge 7,6MHz. Isso com certeza foi um diferencial em jogos que não possuem muita complexidade, mas apresentam muitos sprites e grande velocidade, como é o caso de Gunstar Heroes, Sonic, Contra Hard Corps, entre outros.

Talvez a Sega não tenha usado o Clock para fazer comparações diretas com o Snes porque o único número que as pessoas estavam familiarizadas para comparações era o poder de processamento, medido em bits. Isso nos leva ao próximo termo.

3 - 16/32/64/128 bits

Quem nunca falou do console utilizando os bits de processamento para comparações? O problema é que ninguém sequer tem noção de como os bits influenciam a performance ou a qualidade gráfica.

Quantas vezes já ouvi gente dizer que preferia o Nintendo 64 ao Playstation porque o Nintendo 64 era "64", e o Playstation era "32".

Os jogadores estavam tão acostumados a comparar e comprar consoles baseando-se no poder de processamento expresso em bits que vários fabricantes se aproveitaram disso para mentir um pouco. O Jaguar foi exaustivamente anunciado como um console de 64 bits, mas tinha um poder de processamento próximo do 3DO. Se não me engano, os marketeiros obtinham o número 64 somando os bits de cada processador interno, o que é um absurdo. A própria SNK chegou a declarar que o Neo Geo possuía 24 bits, porque somavam os 16 bits do processador gráfico com os 8 bits da cpu. Dois processadores de 32 bits não formam um de 64 bits. A arquitetura de hardware não é assim tão simples.

Para fazer uma analogia bem barata, é como que você tivesse um objeto de 2 metros de largura e alegasse que ele poderia ser levado para dentro de uma casa que possui uma porta na frente de 1 metro de largura e uma porta dos fundos com 1 metro também. (Mas não pode quebrar o objeto no meio)

O primeiro console genuinamente 64 bits foi o Nintendo 64. E desta vez, parece que a própria Nintendo cedeu aos números e estampou o 64 em quase toda a linha de produtos da época. Eu possuo o N64 e às vezes me sinto constrangido com tanto 64 estampado nos títulos. Depois de um tempo fica bobo. Igual ao "Super" na maioria das séries que saíram do Nes e continuaram no Super Nes.

O poder de processamento é tão mal compreendido que muitos profissionais da indústria simplesmente chutavam os valores de acordo com o que parecia mais óbvio. Por exemplo, o Dreamcast, mesmo sendo 64 bits, tem muito mais poder que o Nintendo 64, "então só pode ser 128 bits", pensavam alguns.

Mas afinal, o que esses bits significam? Como falei, ninguém sabe. Nem mesmo eu. O que imagino é que esses bits se referem ao tamanho dos registradores do processador (pequenas memórias) que armazenam os valores que estão sendo processados no momento. Também se referem às instruções da CPU. O que é uma instrução? No caso, é um comando que a CPU entende, escrita somente com 0 e 1. Uma soma é uma instrução, assim como ler um endereço de memória, pular endereços, multiplicar valores, etc. Ou seja, o Playstation consegue ler instruções de até 32 zeros e uns. O que isso acrescenta na qualidade gráfica é difícil de compreender. Talvez isso permita que algumas instruções possam ser implementadas adequadamente. Tipo, para aplicar sombreamento, é necessário algumas informações do polígono, endereços de memória, cores e etc. Se o processador não possui "espaço" para ler tudo isso, essa instrução não pode ser utilizada. Mas mesmo que possua poder, ainda é necessário que o processador implemente aquela instrução (aceleração por hardware, no caso).

Mas tudo isso é especulação.

4 - Jogabilidade

Este é um termo difícil de explicar. Mas sempre foi utilizado como simplesmente os comandos do joystick. Ou seja, se o Mega Man possui um pulo mais preciso que o de Simon Belmont, a jogabilidade de Mega Man é melhor. Claro que jogabilidade não pode ser somente isso. Se fosse, como definir a jogabilidade de jogos point and click? Se em Myst ou Monkey Island você não possui botão de pulo, a jogabilidade é pior? Claro que não. É justamente o ato de resolver enigmas apontando e clicando que define a jogabilidade desses games.

Quem me acompanha desde 2008 já sabe que escrevi muito sobre o tema. Aqui está o índice.

Criando Um Jogo em Windows Forms - Parte 4 - Física

Fernando Lorenzon — Wed, 13 Jan 2010 22:53:09 +0000

Aqui serei mais teórico.

Como aplicar física em jogos?
1 - Usando uma boa engine que já faça isso;
2 - Usando boas bibliotecas que façam isso;
3 - Manifestando um pouco do Newton que há dentro de nós;

Como a idéia toda desta série é entender como tudo funciona, e não simplesmente criar um jogo o mais rápido possível, ficaremos com a terceira opção. Apesar de eu gostar de física, nunca estudei muito tal disciplina, e hoje sinto bastante dificuldade com vários cálculos básicos. Graças ao jogo em si, eu consegui redescobrir muitas coisas, pois na prática é mais fácil de entender um conceito.

Vamos:

A Física, entendida por muitos estudantes como a abreviação da disciplina "Educação Física", não é chutar uma bola e marcar um gol, e sim calcular sua tragetória, peso, velocidade, aceleração e etc.

Para quem quer criar jogos de RPG, ignorem tudo isso. Para os demais, vamos analisar algumas coisas:

Num fluxo de jogo, não basta aplicar uma fórmula para deslocar um objeto para outro lugar. É preciso MOVER o objeto um pouco a cada update.

Como o fluxo é contínuo, você não deve prever onde os objetos estarão, e sim mover os objetos na direção que a fórmula deve prever. Complicado?

Quando aplicamos uma fórmula para descobrir a aceleração ou velocidade de um corpo, o que obtemos é o valor em distância/tempo (km/h, m/s, mph, etc...). Se temos a velocidade e multiplicarmos pelo tempo, obteremos a posição onde o corpo estará.

Mas para um sprite se mover, temos que reposicioná-lo a cada Update. Como num jogo 2D comum temos pixels, e aqui temos nosso Update() disparado por Timer.Tick() a cada 20 milisegundos, nossa velocidade é medida em pixels por tick.

Ou seja, se um sprite se desloca com uma velocidade de 1 p/t (pixel por tick), e um tick é disparado a cada 20 milisegundos (resultando em 50 ticks por segundos), temos a velocidade de 50 pixels por segundo.

Numa tela de jogo de 640 pixels de largura, o sprite demoraria 13 segundos para atravessá-la completamente.

Definindo um pouco as coisas:

Velocidade: é a taxa mudança de posição de um corpo ao longo do tempo. Se a cada tick temos a mudança de posição em 1 pixel, nossa velocidade é 1 p/t (não existe essa medida, e nem adianta sugerir à SI).

Aceleração: é a taxa de aumento de velocidade num determinado período de tempo. Se no primeiro tick temos 1 p/t, e no próximo temos 2 p/t, no terceiro estaremos com a velocidade acumulada do primeiro somado do segundo (1 + 2).

A cada tick o sprite pulará mais pixels de uma vez:

Ticks: |
Pixels: +

|+|++|+++|++++|+++++|++++++|

Como representar isso?

Simples. É só criarmos uma variável para acumular a velocidade e somá-la aos pixels que representam a localização dos sprites.

No exemplo da bola na parte 3, nós movíamos a bola em um pixel a cada tick quando o jogador mantinha uma seta pressionda. Agora vamos acrescentando unidades em uma variável e transferiremos o valor total dela no Location do sprite:

PLAIN TEXT

//Declarar como global
int vel = 0;
if (this.ks.IsKeyDown(Microsoft.Xna.Framework.Input.Keys.Left))
{
vel = vel - 1;
}
if (this.ks.IsKeyDown(Microsoft.Xna.Framework.Input.Keys.Right))
{
vel = vel + 1;
}
this.pictureBox1.Location =
new Point(this.pictureBox1.Location.X + vel, this.pictureBox1.Location.Y);

o que estamos fazendo acima é:

1 - Criar uma variável para armazenar velocidade;
2 - Adicionar ou subtrair unidades a ela dependendo da direção esquerda/direita (velocidade na direção oposta é negativa)
3 - reposicionar o pictureBox acrescentando a velocidade à sua posição no eixo X atual;

Execute e veja como para os lados a bola possui aceleração, velocidade e inércia. Enquanto para cima e para baixo ainda se move do jeito antigo.

Aqui vai o código completo da tela: link

Quanto um Cartucho de NES Aguenta?

Fernando Lorenzon — Sun, 10 Jan 2010 16:41:00 +0000

Vi este vídeo no kotaku e achei impressionante.

Veja você também, tema pelos seus DVDs frágeis e cheios de não-me-toques e ajoelhe-se diante do poder do bom e velho cartucho / Printed Circuit Board !!!!

Para quem quer montar uma coleção de games antigos, isso pode ser um alívio. Desde que pare a coleção nos 16-Bits, claro.

Criando Um Jogo em Windows Forms - Parte 3 - Lendo Teclas

Fernando Lorenzon — Wed, 06 Jan 2010 17:53:22 +0000

Nesta terceira parte, já vamos avançar para a parte prática. O foco desta série não é ensinar programação C#, nem Windows Forms. Portanto, vou partir do princípio que quem me acompanha aqui já possui conhecimento básico sobre estas tecnologias. Para quem quer aprender um pouco, aqui tem um tutorial básico da Microsoft sobre Windows Forms. Aqui tem mais coisas.

Para começarmos, será necessário criar um novo projeto do tipo Windows Application no Visual Studio 2008. Ao criar um novo projeto, cria-se uma Solution que abriga este projeto.

Uma solução recém criada já apresenta um formulário chamado Form1. Podemos utilizar ele mesmo.

Com o XNA 3.1 devidamente instalado, vamos importar a DLL Microsoft.XNA.Framework e Microsoft.XNA.Framework.Game.

Para isso, clique com o botão direito na pasta References no menu Solution Explorer e selecione Add Reference. Aguarde a janela aparecer (demora!) e na aba .Net, selecione as DLLs Microsoft.XNA.Framework e Microsoft.XNA.Framework.Game nas versões 3.1.0.0.

Abra o ToolBox (CTRL + W + X) e, na entrada All Windows Forms, procure e arraste para o formulário o controle chamado PictureBox e outro chamado Timer.

Selecione o PictureBox e na aba Properties (F4), mude a propriedade Size para 32;32. Na propriedade BackgroundImage, clique e em Local Resource, navegue nos diretórios e selecione uma imagem qualquer. Sugiro salvar e usar esta aqui:

Agora vamos mexer no Timer. Selecione lá embaixo o timer1, que foi criado ao arrastar o Timer. Em Properties (F4), mude o Interval para 20 (50Hz). Mude também o Enabled para true;

Agora vamos implementar o evento Timer.Tick. Ainda em Properties, no topo da aba existe uma figurinha em forma de raio. Clique nela. Aqui temos os eventos disponíveis para o Timer. O único disponível é o Tick. Clique duas vezes na célula vazia e o Visual Studio vai criar o evento e a função associada ao evento (event handler), chamada timer1_Tick().

Todo o código fica neste arquivo.

Vamos escrever algumas coisas por aqui. Primeiramente, vamos criar um objeto do tipo KeyboardState. Logo acima da linha public Form1(), escreva:

PLAIN TEXT

Microsoft.Xna.Framework.Input.KeyboardState ks;

Agora, dentro do bloco timer1_Tick(), escreva:

PLAIN TEXT

this.ks = Microsoft.Xna.Framework.Input.Keyboard.GetState();
if (this.ks.IsKeyDown(Microsoft.Xna.Framework.Input.Keys.Up))
{
this.pictureBox1.Location =
new Point(this.pictureBox1.Location.X, this.pictureBox1.Location.Y - 1);
}

O que estou fazendo acima é a cada 20 milisegundos:

1 - Capturar o estado do teclado (teclas pressionadas);

2 - Verificar se a tecla pressionda é a Seta Para Cima;

2.1 - Se sim, a localização do pictureBox1 muda para um novo ponto cartesiano, onde o eixo X mantém o mesmo valor, e o Y é decrescido de um pixel.

O problema desses controles é que a posição é definida por um objeto Point que une o X e o Y. Então eu não posso simplesmente decrementar diretamente o Y, e sim recriar o Point, repassando o X e o Y do jeito que eu quero.

O interessante é que quanto mais para cima, menor é o Y. Ou seja, o ponto X=0 e Y=0 é o canto superior esquerdo do formulário. Isso vale para qualquer aplicação baseada em pixels na tela. Até o paint.

Agora vamos rodar o programa. Pressione F5 para compilar e rodar. Se tudo deu certo, o formulario e a figura aparecerão na tela. E ainda se moverá para cima enquanto a tecla Seta Para Cima estiver pressionada.

Podemos fechar a janela e continuar o programa.

Ainda dentro do timer1_Tick(), vamos aplicar todas as direções.

Basta escrever o restante:

PLAIN TEXT

if (this.ks.IsKeyDown(Microsoft.Xna.Framework.Input.Keys.Down))
{
this.pictureBox1.Location =
new Point(this.pictureBox1.Location.X, this.pictureBox1.Location.Y + 1);
}
if (this.ks.IsKeyDown(Microsoft.Xna.Framework.Input.Keys.Left))
{
this.pictureBox1.Location =
new Point(this.pictureBox1.Location.X - 1, this.pictureBox1.Location.Y);
}
if (this.ks.IsKeyDown(Microsoft.Xna.Framework.Input.Keys.Right))
{
this.pictureBox1.Location =
new Point(this.pictureBox1.Location.X + 1, this.pictureBox1.Location.Y);
}

Agora rode novamente e experimente mover a bola para todas as direções.

Por enquanto é isso. No proximo post, vamos aplicar aceleração e outras coisas a mais.

Criando Um Jogo em Windows Forms - Parte 2 - Fluxo e Update

Fernando Lorenzon — Sun, 03 Jan 2010 17:30:31 +0000

Aqui, eu tratarei um pouco sobre o fluxo de jogo.

Qualquer jogo possui uma estrutura genérica que geralmente segue o mesmo padrão. Aqui, o principal é mostrar o básico, e sem utilizar ferramentas que escondem alguns dos passos básicos do fluxo.

Como eu havia falado, o Windows Forms atualiza as figuras na tela automaticamente quando detecta uma mudança, e isso é bem difícil de controlar manualmente. Então, a parte de fazer as imagens ser renderizadas fica oculta para nós.

Abaixo está a figura com o fluxo básico do WinForms Lander. Vejam:

Como podem ver, não é nada muito complicado. Dos 3 blocos, o mais importante é o Update. Nele todas as coisas que fazem a partida funcionar são continuamente executadas num loop infinito. Bom, só não é infinito porque se o jogador vencer ou perder, o loop se quebra e o jogo segue para o terceiro bloco.

No caso do WinForms Lander, e muito povavelmente para qualquer engine, o update é disparado automaticamente. Geralmente é utilizado um temporizador (timer para os íntimos) que dispara uma função a cada X milisegundos. Em Windows Forms, eu utilizo o controle Timer. No evento Timer.Tick eu chamo a minha função Update().

O padrão para os jogos é rodar a 60 quadros por segundo, e isso conta também os updates, e não somente a atualização dos gráficos. Na verdade, como os videogames são feitos para ligar na TV, e a TV atualiza as imagens 60 vezes por segundo, o video dos consoles gera e envia imagens nesta taxa também. E como o processo de update e geração de imagens são síncronas, o update acaba rodando nesta velocidade.

Muito provavelmente, até os jogos de PC com taxa de quadros variável deve rodar seus updates 60 vezes por segundo. Ou seja, mesmo que o jogo esteja exibindo 20 frames por segundo, a captura de teclas, detecção de colisão, movimentos e toda a lógica do jogo está executando a cada 16,66 milisegundos (60Hz). Isso se deve ao fato dos jogos modernos serem assíncronos. Ou seja, a geração das imagens não bate com a atualização delas, nem com a lógica de jogo. Isso quer dizer que é possível jogar Quake 3 com a lógica rodando a 60Hz, taxa de atualização do monitor à 85Hz, e 70 FPS. Num console, principalmente os antigos, é tudo síncrono. Acredito que nos consoles antigos, disparar o update seja uma implementação de hardware, com o uso de algum temporizador baseado num chip.

Mas isso é só suposição. Imagino que seja assim porque ao usar um jogo NTSC (60Hz) num console PAL (50Hz), o jogo roda mais lento. O inverso também ocorre.

Usando o Timer do Windows Forms, é possível informar o intervalo de tempo em que o evento Timer.Tick será disparado. Com isso, podemos fazer com que a lógica do jogo seja executada no tempo que quiser. E o melhor é que o intervalo pode ser alterado a qualquer momento. O legal é que diminuindo o intervalo, todo o jogo se acelera. Não sei se é possível alterar o intervalo em qualquer ferramenta.

Por enquanto é isso.

Criando Um Jogo em Windows Forms - Parte 1

Fernando Lorenzon — Wed, 30 Dec 2009 20:07:38 +0000

De todos os colaboradores da Cubagames, eu sou o menos familiarizado com desenvolvimento de jogos. Não tenho muita familiaridade nem com Web, que geralmente possui ferramentas muito boas para implementar um jogo, como é o caso do Flash.

Mas tenho bastante familiaridade com programação de sistemas e um pouco de conceito sobre criação de jogos. A plataforma de desenvolvimento que possuo mais experiência é Windows Forms, e a linguagem que mais domino é o C#. Há alguns anos venho pensando (filosofando) como os jogos antigos de 8 e 16 bits eram criados. Hoje temos muitas ferramentas visuais, frameworks, engines, todos equipados com temporizadores automáticos, eventos, gerenciamento de memória, threads e o escambal. Com isso, criar um jogo pode ser bem rápido, mas talvez não tão didático.

Acompanhem-me:

Aventurar-se numa ferramenta dessas pode ser bastante confuso. Até eu tive dificuldades de compreender o funcionamento do XNA. E olha que ele usa C# e o Visual Studio. É claro que agora, fazendo quase tudo no braço usando Forms, já consigo entender como o XNA funciona. É por isso que quero compartilhar este conhecimento aqui. Claro que "no braço" é um termo relativo, pois com C# e o Visual Studio muita coisa já vem pronta. Só que nada vem pronto para ser utilizado em jogos. Comparando com engines como a Unity, ou ferramentas como o Flash, C# e WindowsForms é bem cru. Se eu tivesse paciência para aprender C++, com certeza usaria ele aqui.

Por um lado, ferramentas completas são úteis e muito produtivas, mas para quem está interessado em conceitos, isso pode atrapalhar mais no aprendizado do que ensinar.

Muito antes de bolar meu próprio MMO para concorrer com WoW, eu quero entender como tratar uma colisão "no muque". Ou ainda, como trabalhar os updates por segundo de jogos mais rústicos, como os antigões. Essas novas engines mascaram tudo isso. (Recomendo ler um texto muito bom do Rômulo sobre isso: Design Inchado)

Então, por causa dessa minha curiosidade e também falta de compromisso para criar um jogo propriamente dito, comecei a fuçar um pouco no Windows Forms com C#, usando a ferramenta Visual Studio 2008. Aqui eu me sinto em casa. Porém, O WindowsForms já é todo otimizado e "fechado" para uso em programas com telas estáticas, com botões, campos de texto, barras, grids etc. Traduzindo, Windows Forms não foi feito para criar jogos. Então pensei: "Perfeito!".

O problema do Windows Forms é que o programa fica esperando o usuário interagir com as telas, pronto para capturar teclas pressionadas e cliques de mouse. Num jogo, o que ocorre é o contrário. Ele funciona continuamente, mesmo sem a intervenção do jogador. Ou seja, se você largar o controle por um tempo, morre.

Para poder quebrar essa primeira e talvez a única barreira que o WindowsForms oferece ao criar jogos, eu tive que usar uma biblioteca em que eu determinasse quando pegar as teclas pressionadas pelo jogador e aplicar a lógica de jogo. Ou seja, o programa não ficaria esperando as teclas serem pressionadas para disparar os eventos.

Comecei a procurar por uma biblioteca que fizesse leitura de teclas com intervenção do programador, e logo descobri que o próprio XNA possui a dita cuja.

A biblioteca usada foi justamente uma que acompanha o XNA. O resto foi WindowsForms puro.

No início, fiquei apenas fazendo uma esfera deslizar pela tela conforme o uso das setas. Logo depois eu comecei a criar mais e mais funções para fazer diversas coisas, como gravidade, arrasto, colisão, leitura do teclado, aplicação dos comando para a esfera, esticamentos, etc. No processo, acabei até adquirindo alguns conhecimentos sobre física. Afinal, criar jogos é uma boa oportunidade de aplicar teorias da física.

Tudo utilizando imagens carregadas num "botão". No WindowsForms, essa é a melhor (ou única) maneira de representar sprites.

Quando percebi, já tinha um bom começo para criar um jogo. E foi o que fiz. Com o que eu já tinha, daria para criar sem grandes problemas uma versão simples do jogo clássico Lunar Lander. E assim nasceu o projeto WinForms Lander. Com este game, acabei juntando coisas que me interesso, como física, astronomia, games e desenvolvimento. Só assim para sentirmos motivados a criar algo.

Logo no início, ficou óbvio o quanto o WindowsForms é limitado para trabalhar com imagens. Quanto mais sprites e backgrounds existir, menos fluentes ficam os sprites. Isso se deve ao fato do WindowsForms atualizar as imagens na tela por conta própria. Você desloca uma figura, e a imagem se move sem você dizer quando isso deve ocorrer. O resultado não é tão ruim quanto parece, desde que se use pouquíssimos sprites numa tela.

Conforme fui desenvolvendo, fui aprimorando os códigos e arrumando a estrutura das funções. Posso dizer que o resultado ficou muito bom.Para contornar as limitações tecnológicas, fui adicionando conteúdo para tornar o jogo mais divertido, e atualmente o jogo já conta com várias "navinhas" e estágios, com variáveis diversas para aumentar o limitado desafio.

Inclusive, todas as naves foram desenhadas por mim num criador de ícones, e foi bastante divertido bolar as naves e os poderes especiais de cada uma (sim, eu fiz isso). Como se trata de um jogo de pousar corretamente, os poderes se limitam a auxiliar o pouso, como anti-gravidade, estabilização, etc.

Estou incluindo alguns efeitos sonoros também. E não tenho nenhuma biblioteca avançada em mãos para tocar os sons paralelamente e de qualquer jeito. Estou usando a biblioteca padrão para tocar sons em WindowsForms. É bem fácil de carregar um som e tocar, mas não é possível tocar áudios paralelamente. Portanto, tudo tem que ser feito controlando manualmente se o áudio está tocando, se deve trocar de áudio, etc. Difícil, mas recompensadoramente didático.

Posso dizer que o jogo está uns 70% pronto, faltando apenas aprimoramentos na jogabilidade e algum polimento no código. O jogo já salva e carrega, possui naves e fases secretas, e terá alguns desafios extras.

Quando terminar, ainda vou migrar o jogo para o XNA, que atualmente nem parece mais o bicho de sete cabeças de antes. E com certeza melhorarei o que o WindowsForms não permitiu.

Bom, este texto foi somente uma introdução. No próximo post, eu explico um pouco o que aprendi e aos poucos vou esclarecendo sobre lógica de jogo em geral e algumas decisões tomadas por mim durante o desenvolvimento.

Esta série não tem o intuito de ensinar a programar C#, nem mesmo de ensinar a criar jogos a torto e direito. Tenho a intenção de explicar mais coisas teóricas, que serão úteis mais para frente, conforme eu for mostrando os códigos.

Você talvez deva estar se perguntando: "Se Windows Forms é ruim pra jogos, por que perder tempo com ele?"

Volto a salientar: isso tem somente fins didáticos. Eu ainda vou converter o jogo para XNA daqui alguns meses, e aí sim teremos um jogo decente (ou não).

Mas na verdade, se for analisar a simplicidade de alguns games antigos, o WinForms Lander até que não está indo mal.

Para quem já conhece C# e tem interesse em acompanhar a série, será necessário o Visual Studio 2008 ou o Visual C# Express Edition para programar. Ah, e instale o XNA 3.1 para utilizar a biblioteca. O C# Express e o XNA são gratuitos.

Após a conclusão do game, me aventurarei com o XNA. E com certeza criarei uma série de tutoriais sobre XNA.

Zoeira News - Pitfall Motion

Fernando Lorenzon — Sun, 27 Dec 2009 03:05:16 +0000

Dando continuidade à série de notícias inventadas por mim, a Actvision é a bola da vez, soltando mais uma delas:

Actvision relançará Pitfall com controle próprio

É isso mesmo!

A Actvision não descansa nem no Natal. No embalo do tremendo sucesso de Tony Hawk's Ride e sua prancha-controle, a Actvision anuncia um novo game da série Pitfall com seu próprio controle.

Segundo as especificações, o controle, batizado de Vine e-Motion, se trata de um cipó com sensor de movimentos. O controle poderá - ou deverá - ser pendurado para que o jogador se balance nele e assim passe a controlar Pitfall Harry!

O jogo será basicamente um conjunto de seções de salto, onde o jogador deverá se agarrar (literalmente) ao controle e balançar. Assim que o jogador se solta, o controle calcula a velocidade e faz com que Harry também salte no jogo. Apesar dos riscos, eles garantem que é extremamente seguro e não há perigo de se machucar. Muito menos acertar a TV (o controle acompanha 3 acolchoados para colocar no chão).

Com o sucesso iminente, a empresa cojita lançar alguns jogos do Tarzan para aproveitar o controle.

A empresa garante que será um sucesso e provavelmente enterre o projeto Natal devido à grande tecnologia e inovação por trás do cipó,... digo, Vine e-Motion.