Antes de continuarmos pelos padrões de projeto, acho importante ter aqui uma explicação sobre o Princípio da Substituição de Liskov. Ele é comum nas boas práticas de programação orientada a objetos e seus conceitos aparecem muito ao utilizar diversos padrões de projeto, principalmente no uso de Interfaces em padrões como o State (estado), o Strategy (Estratégia) ou os diversos tipos de Factories (Fábricas). Apesar de sua popularidade, ainda sim costuma dar um nó na cabeça de quem está começando.

Historicamente falando, O princípio foi introduzido em 1993 (muito recente, como podem ver) por Barbara Liskov e Jeannette Wing no artigo Family Values: A Behavioral Notion of Subtyping. Segundo ele:

Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.

“Mas hein?!?” Apesar de parecer complicado, não é. Traduzindo isso para uma linguagem mais simples:

Se você pode chamar um método q de uma classe TMae, pode também chamar o método q de uma classe TFilha com herança de TMae.

“Bom, melhorou bastante. Mas você não pode explicar melhor não, Tiago?” Se uma classe herda de outra classe, cria-se a relação de “é um”. Explicar isso à fundo é material para um outro artigo, mas basta dizer que quando a classe TFilha herdou os métodos de TMae, ela passou a ser uma TMae estendida, melhorada (daí algumas linguagens utilizarem a palavra extends para definir herança): ela tem TUDO que uma TMae tem, além das coisas que só TFilha tem.

Se TFilha tem tudo que a TMae tem, as chamadas por TMae podem receber uma TFilha sem o menor problema. Entendamos o código abaixo:

Primeiro criamos uma classe TMae:

package Classes
{
	public class TMae
	{
		public function TMae()
		{
		}

		public function Voce(): void
		{
			trace ("Eu sou uma TMae");
		}
	}
}

Como TMae precisa de uma filha, vamos criá-la herdando de sua mãe:

package Classes
{
	import Classes.TMae;

	public class TFilha extends TMae
	{
		public function TFilha(): void
		{
			super(); // Chama o construtor da classe TMae
  		}

		public override function Voce():void
		{
			trace ("Eu sou uma TFilha");
		}

		public function Mae():void
		{
			// chama o método Voce() da classe mãe
			super.Voce();
		}
	}
}

Vale lembrar que TFilha pode ter seus extras, como fiz com o método Mae(), que exibe a mãe de filha, o método Voce() de super. Para colocar isso tudo para funcionar, precisamos da classe TMain:

package
{
	import flash.display.MovieClip;
	import Classes.TMae;
	import Classes.TFilha;

	public class TMain extends MovieClip
	{
		public function TMain(): void
		{
			var mae: TMae = new TMae();
			var filha: TFilha = new TFilha();

			trace ("======= MAE =======");
			this.testarLiskov(mae);

			trace ("======= FILHA =======");
			this.testarLiskov(filha);

			trace ("======= MAE DA FILHA =======");
			filha.Mae();

			//trace ("======= MAE DA MAE? =======");
			//mae.Mae();
		}

		public function testarLiskov(obj:TMae)
		{
			obj.Voce();
		}
	}
}

A saída disso é a seguinte:

	======= MAE =======
	Eu sou uma TMae
	======= FILHA =======
	Eu sou uma TFilha
	======= MAE DA FILHA =======
	Eu sou uma TMae

Para terminar, lembrem-se que o Princípio da Substituição de Liskov não é comutativo. Ou seja: podemos trocar a TMae por uma TFilha, mas não uma TFilha por uma TMae. Se TFilha pode possuir mais métodos e atributos  que TMae, não temos como chamá-los diretamente por TMae. Para confirmar, basta descomentar a linha mae.Mae() e ver que o compilador não consegue encontrar o método Mae() em TMae (claro, ele é de TFilha!).

Saiba mais sobre o Princípio na Wikipédia.

• Liste quantos jogos em Flash quiser. Preferencialmente aqueles que, por algum motivo de design chamaram sua atenção.
• Diga o que desses jogos te chamou a atenção, seja em quantas linhas quiser.
• Repasse para outros blogs.

Começando a brincadeira, chamo o próprio Dauto, o Diego, o Ricardo, o Flausino e o Bruno. A minha lista você encontra aqui.

Essa é uma dica rápida para quem quer desenvolver para um videogame de última geração. No ByteArray você o WiiFlash, uma biblioteca em Action Script 3.0 que liga faz a comunicação entre seu Wiimote e o Adobe Flash, Flex ou Air.

Graças à comunicação do Wiimote (e seus metaperiféricos Nunchuk, Wii Balance Board...),  basta reconhecê-lo como um dispositivo Bluetooth no seu PC, rodar o WiiFlash Server e pronto, começar a desenvolver. O problema maior aqui é a documentação toda em inglês, o que pode afastar aqueles que têm dificuldades na língua... Vejam como uma ótima oportunidade para começar a estudá-la!

Aqui você baixa o Wiiflash com o código fonte, caso queira modificá-lo ou até mesmo adicionar novas funcionalidades à biblioteca.  Na página do Google Project Hosting do WiiFlash você encontra exemplos de como é simples trabalhar com o joystick. Falando nele, esse link explica como fazer seu PC reconhecê-lo, podendo trabalhar com mais de 1 ao mesmo tempo.

Esse vídeo em inglês ensina o necessário para que você inicie seu desenvolvimento. Só fique de olho pois ele foi feito em um Mac... Ou seja: nada de Windows Explorer ou Menu Iniciar.

O site wiiplayable possui uma grande lista de jogos em Flash que podem ser jogados diretamente pelo Wii através do Opera.

Abaixo, uma lista de exemplos de uso do wiiflash:

• Simulação de Vôo
• Wiispray
• Wiirimbau

Lá atrás, há mais de 1 ano, quando abrimos mão de todas as alterações para retomar o design original, tínhamos que encontrar alguma tecnologia que nos permitisse refazer rapidamente tudo aquilo que já estava feito antes, tanto em código quanto em visual.

Foi assim que, conversando com meu parceiro de projeto, o Douglas, fiquei sabendo das possibilidades do Flash. Tá, eu já ouvia falar do Flash pra o desenvolvimento de sites, mas tudo que eu sabia dele ainda era muito abaixo do que necessitávamos. Queriamos um programa para fazer um jogo, não um site. Isso não sabíamos se ele faria.

Douglas deu uma pesquisada nos fórums e viu que era uma ferramenta muito mais poderosa do que achávamos. Era a época do Flash MX, programa que resolvemos adotar para fazer nosso Jogo. Ele conseguiu ser a coisa mais bipolar que eu já vi na vida.

Ao mesmo tempo que era muito fácil fazer diversas coisas no Flash, como animações e interface no geral, era muito complicado seguir nosso paradigma de programação, a Orientação a Objetos. Tudo era muito engambiarrado, cheio dos conhecidos “jeitinhos brasileiros” para que funcionasse. Ele era muito poderoso, mas não supria nossas necessidades. Foi um verdadeiro inferno.

Enquanto pesquisávamos a solução de alguns problemas, descobrimos a existência de um tal Ellipsis, um pacote de atualização pro Flash MX q resolvia problemas gravíssimos para nosso projeto. Verdade seja dita: o tal do Ellipsis resolveu muitíssimos dos nossos problemas, mas não todos.

Os problemas eram causados pelo tal Action Script 2.0, a linguagem de programação do Flash naquela época. Era em AS2.0 que a gente dizia o que acontecia quando clicávamos em um botão, ou que controlava quem causava dano em quem, o quanto causava, quem estava vivo e quem estava morto.... O problema é que ele pirava em coisas simples por não ser uma linguagem de programação que estava 100% integrada ao paradigma em que fazíamos o projeto.

Terminado nosso Projeto Final, continuamos a trabalhar no Action Script 2.0 para acertar aquilo que não estava do jeito que queríamos. Isso durou poucas semanas, graças a Deus, pois ficava cada vez mais penoso trabalhar com aquele catiço. Foi quando, mais uma vez, Douglas avisou-me sobre o Flash.

Dessa vez, ele me disse sobre o tal do Action Script 3.0, uma tal revolução aí na programação em Flash. O Action Script 3.0 era completamente Orientado a Objetos, o paradigma que nós escolhemos para fazer nosso jogo. Isso facilitaria muito na hora de passarmos pro Jogo tudo aquilo que queríamos que ele tivesse: agora o Jogo ia ser exatamente aquilo que estávamos querendo que ele fosse.

Na próxima eu vou falar um pouco sobre o Action Script 3.0 e as razões de tê-lo mantido como linguagem principal do Jogo. Até lá!