E por quê jogar o MEU?

Taí… Continuando a idéia do artigo anterior, onde encontramos quem jogará o nosso jogo, hoje tentaremos encontrar o que fará com que o jogador jogue o seu jogo, não o da concorrência. Não achem que esse artigo será uma revolução no mercado mundial, muito menos o segredo do sucesso do seu jogo. Com ele pretendo falar um pouco sobre o diferencial competitivo, que daqui pra frente chamaremos só de diferencial.

O diferencial é uma das características principais para o sucesso de qualquer produto. É ele que identifica um produto no meio de tantos outros e atrai os consumidores, é algo que eles querem ter e, no caso dos jogos, algo que os jogadores querem jogar.Normalmente compreende um conjunto de características ao invés de somente um ponto-chave necessariamente inovador. Ao contrário, em muitos casos de sucesso de jogos, o diferencial era algo simples e óbvio, mas negligenciado nos concorrentes.

Um exemplo que me vem em mente: por simplesmente adicionar ao jogo a capacidade do personagem sentar em cadeiras, os desenvolvedores do Phobos Online conseguiram chamar a atenção de vários jogadores de Tibia, onde o seu personagem não consegue fazer isso. Tiveram até uma screenshot veiculada num dos maiores sites relacionados ao concorrente. É claro que ninguém vai passar a jogar um jogo só por quê você pode sentar em cadeiras, mas um conjunto de pequenas coisas simples podem fazer a grande diferença.

Todo mundo lembra do multiplayer de Counter Strike e Perfect Dark, da estratégia de Warcraft e Baldur’s Gate, da tecnologia gráfica de Farcry e F.E.A.R., do enredo de Final Fantasy VII e Chrono Trigger ou até mesmo da originalidade de Grand Theft Auto e Carmaggedon. Diferenciais, quando bem explorados, fazem justamente isso: lançam o jogo para a história.

“Mas como eu vou descobrir o meu diferencial?” Para essa pergunta, vou usar a mesma resposta dada no artigo anterior: Pesquisa, pesquisa e pesquisa. Praqueles que ainda não o fizeram, dêem uma lida nessa matéria sobre o mercado. Nela eu falo sobre pesquisas, dando dicas sobre como realizá-las gastando quase nada. Para organizar os resultados, leiam também essa matéria sobre o Princípio de Pareto, pois com ele vocês irão encontrar o que a maioria quer ver no jogo que vocês pretendem fazer. A idéia principal é fazer as pesquisas com o maior número possível de pessoas.

Não adianta achar o contrário: você precisa saber o que o teu público deseja jogar, a forma com que eles querem jogar e quanto eles pretendem pagar para jogar. Não é fazer um jogo e esperar que as pessoas gostem: é fazer um jogo com aquilo que os jogadores querem ver. Se seu público usa computadores antigos, isso deve ser utilizado como diferencial em relação à concorrência. Se eles desejam um jogo modificável, isso também deve ser utilizado. Se estão querendo jogar um jogo de estratégia, use-a estrategicamente para fisgá-los. Se não começar assim, duvido que termine.

Quem vai jogar?

Antes de pensar no design do seu jogo, é importante saber responder uma pergunta simples: Quem vai jogar? Saber a quem se aplica o design que você está criando é tão importante quanto fazê-lo de forma bem feita. Devemos encontrar o máximo de características que possam nos encher de idéias para esse design. Algumas delas (que serão abordadas aqui) são:

• Localização

“Pra quê saber isso?” Simples: para disponibilizar o jogo numa língua que eles entendam. Não adianta fazer um jogo para um público qualquer e dizer “ah, eles que aprendam inglês”. Além disso, você tem que estar inteirado dos costumes daquele povo, caso queira direcionar a eles. Americanos são fissurados em ação, sangue, explosões e tudo mais que aparece aos montes num filme do Rambo, enquanto japoneses usam muito mais seu potencial intelectual. Assim sendo, jogos de massacre e tiro em 1ª pessoa fazem muito mais sucesso nos EUA que no Japão, onde os quebra-cabeças, jogos de estratégia e RPGs dominam o mercado.

• Classe Social

Teu público é rico ou pobre? Se for rico, vai ter dinheiro para computadores de última geração. Se for assim, por quê irão jogar o teu jogo e não o World of Warcraft, por exemplo? Se teu público não tiver dinheiro pata tais máquinas, pode tirar da cabeça aquele jogaço com gráficos 3D foderosos e efeitos de luz e sombra em tempo real.

• Idade e Sexo

Sexos diferentes têm preferências diferentes. Além de preferências, a faixa etária também tem limitações governamentais. Por exemplo, se você pretende fazer um jogo para mulheres adolescentes, não vai conseguir muito público adicionando serras elétricas e monstros insetóides gosmentos. Em compensação, o contrário também é válido: não adianta querer fazer um jogo da Hello Kitty para a mulecada de 15 anos.

Viu como, apesar de parecer dispensável, definir o seu público-alvo é extremamente importante? Isso não vai limitar só o design não, gente. O público alvo pode afetar diretamente a produção do seu jogo, às vezes fazendo com que você tenha que aprender coisas novas em tempo record.

Voltemos ao exemplo dos jogadores com computadores antigos. Você definiu que seu público-alvo usa computadores antigos, até 500MHz, 128MB de RAM, sem placas de vídeo e utilizando internet discada de 56Kbps. Nesse caso você vai limar o 3D de qualquer idéia, provavelmente limitando o desenvolvimento ao 2D para alcançar melhores efeitos visuais, além de ter que usar uma linguagem rápida, com interface leve e adicionar ao projeto várias técnicas de melhoria de performance, muitas das quais você nunca ouviu falar.

Essas características-chave para o programa (que o PMBOK chamaria de Requisitos Não-funcionais) não devem ser mudadas para não influenciar negativamente no andamento do projeto. Seria como se, no meio do caminho, aquele algoritmo que demorou 20 dias para ficar pronto se tornasse inútil. Além disso, elas devem ser levantadas ainda na fase de design do jogo, lá no início, para que todo o desenvolvimento vise segui-las

Agora vem o problema… isso tudo é bem complicado para quem não está acostumado a fazer. “E se eu pagar para alguém fazer pra mim?” Well, well… esteja preparado pra desenbolsar uma graninha boa pela sua pesquisas de mercado.

“Pow cara, que sacanagem! Você fala, fala e só no fim avisa que eu não vou conseguir fazer???” Pesquisas, pesquisas e pesquisas. A internet ta aí, é a maior fonte de dados do mundo. Basta sabermos como transformá-los nas informações que precisamos. Por exemplo:

• Pesquisas já prontas.

Revistas e jornais vivem nos jogando gráficos e mais gráficos, pesquisas e mais pesquisas. Aposto que em algum lugar já tem alguma que é exatamente o que você precisa. Vale lembrar que procurar nos sites relacionados à tecnologia também é uma ótima idéia.

• Sites de Jogos

Existe algum jogo parecido com o que você quer fazer? O teu público costuma jogar alguma coisa com freqüência? BINGO!!! Vasculhe o site e procure informações sobre o que os jogadores querem ter. Sites como o Tibia disponibilizam pesquisas freqüentes nas quais os jogadores podem votar. O melhor é que os resultados são públicos, basta escolher alguma pesquisa e usar os resultados.

• Visite fórums

Aqui vai depender mais de você. Analisando o conteúdo e as reclamações nos fórums de jogos você consegue traçar um perfil seguro do que os jogos têm e, melhor, precisam ter. Avaliar as mensagens no fórum do Tibia, por exemplo, vai deixar bem claro que um MMORPG precisa de controle para sua comunidade não sair do controle. Isso é um ponto forte para trazer uma boa quantidade de usuários.

Isso é só o início de uma Pesquisa de Mercado, mas que é alcançável por qualquer um de nós. Mesmo simples do jeito que está, vai dar uma base boa para teu design. Para deixá-la mais interessante, teremos que fazer uma pesquisa de concorrência, de recursos, de custos e outras tantas que ficarão para próximos artigos. Até a próxima.

E o que TE influenciou?

Hoje eu acordei com uma coisa na cabeça e vou fazer um artigo diferente. Artigo não, uma pergunta. Eu tava parado, pensando no design do Jogo e uma coisa veio em mente: esse jogo é um pedaço do Magic, um pedaço do Yu-Gi-Oh, um pedaço do Triple Triad, um pedaço de sei lá mais que jogo e, mesmo assim, não é nenhum deles: é algo novo, único… é o Jogo. Mas como uma cópia pode deixar de ser uma cópia?

Criar um jogo é como criar um texto: estamos vivenciando experiências, culturas e pontos de vista que nos são alheios. Depois, filtramos tudo aquilo que nos interessa e reciclamos as sobras, alimentando-nos de um verdadeiro banquete intelectual. Essas moléculas de conhecimento são absorvidas, vivendo no subconsciente, nos moldando e nos fazendo crescer. É exatamente quando passamos a aplicar nossas experiências sobre aquelas recém absorvidas.É assim que, de surpresa, chegamos àquelas conclusões de “se fosse meu, eu não faria assim” ou “ih, ta faltando um botão aqui fazendo isso”. É assim que pegamos as diversas idéias que temos na cabeça e montamos nossos Frankensteins. É assim que as coisas acontecem no Jogo e, com certeza, acontecem aí por fora.

Em mim, essas experiências se definem bem pela minha infância, pela influência do SNES e o mundo de 16 bits. Influência tão grande que, ainda hoje, meus olhos brilham com uma animação em sprites.

Para mim tornou-se impossível esquecer jogos como Super Metroid, Zelda: A Link to the Past, Super Mario Kart, Street Fighter, Chrono Trigger e Demon’s Crest, continuando pela estratégia de SimCity e War Craft, chegando até o 3D Okami, Wind Waker e Paper Mario, trazendo o ambiente 3D para o clássico 2D.

Por mais que o tempo passe, ainda continuo apaixonado por um belo 2D feio à mão, o que, “coincidentalmente” ou não, casa perfeitamente com o Flash que tanto nos tem ajudado. Não adianta, essa é minha influência, já faz parte de mim, é por essas pedras que caminho.

Isso ficou martelando na minha cabeça, principalmente depois de ter lido uma matéria na Cubagames. O pessoal postou um artigo sobre jogos que estão sendo desenvolvidos e mostrados em blogs, mostrando uma lista de desenvolvedores que estão socando cabeça para tocar seus projetos dos sonhos.

Fiquei imaginando a gigantesca lista de leitores do Nuss, da Cubagames e de todos os outros blogs que têm coisas em mente e não podem desenvolver. Uma gigantesca lista de experiências, culturas e pontos de vista diferentes, vivendo em seu subconsciente, influenciando suas decisões há todo momento.

Agora, depois de ter lido sobre as MINHAS influências, eu pergunto: e o que TE influenciou?

Singleton: Limitando e Distribuindo

O nosso Jogo tem uma característica muito especial: ele é traduzido dinamicamente, sem a necessidade de recompilação. Para isso, estamos colocando todo o texto em uma classe especial, a TIdioma. O problema é que, se nós estivéssemos utilizando um objeto simples, a cada “new” que déssemos, teríamos uma cópia inútil do objeto ocupando espaço inutilmente. Dessa forma, se tivéssemos 500k de texto, poderíamos estar ocupando vários megas da memória.

Isso, quando temos um projeto pequeno, não faz tanta diferença: acaba-se sabendo tudo que está ou não na memória, principalmente quando somente um programador fez aquilo tudo. Porém, há uma grande falha de programação: quando agregássemos um novo programador, ele teria que saber TUDO que já foi feito, da forma que foi feita, entendendo a lógica de tudo que já tá pronto para, aí sim, programar sem erros.Para resolver esse problema, o primeiro padrão de projeto que usamos para resolver um problema no Jogo foi o Singleton. Esse padrão GoF garante que a classe possui somente uma instância, criando um ponto de acesso global à ela. Isso é feito da seguinte forma: o programador NÃO cria um objeto daquela classe. Ao invés disso, a própria classe testa se ela possui uma instância dela mesma. Em caso negativo, a classe cria e retorna essa instância para o programador; em caso positivo, ela simplesmente retorna essa instância já criada.

Utilizamos esse tal de Singleton para garantir que, durante toda a execução do nosso programa, tivéssemos somente uma ÚNICA classe de tradução jogada na memória. Ela é criada no início do programa e, então, todo acesso à TIdioma é realizado via um ponteiro para ela.

O singleton pode ser aplicado à qualquer classe que você queira limitar. Abaixo vai o código genérico que deve ser aplicado:

package
{
	public class TSingleton
	{
		// Atributo de instância
		private static var _instancia:TSingleton = new TSingleton();

Esse atributo _instancia é a chave toda do Singleton e será explicado mais abaixo. O interessante é ver que, com o = new TSingleton(); a instância é inicializada na hora da criação do objeto.

		 // Atributo de teste
		private var _valor:int;

_valor é um atributo qualquer. Vamos usar aqui só para testar o funcionamento do padrão Singleton.

O construtor de uma classe Singleton deveria, por definição, ser protegido, para que, ao tentar usá-lo, o compilador desse um erro. Porém, o Action Script 3.0 NÃO PERMITE construtores privados. Como resolver isso?

		 //-----------------------------------------------------------
		public function TSingleton()
		{
			if (_instancia)
				throw new Error("Uso: TSingleton.Instancia.Metodo()");
		}

Quando _instancia é iniciada lá em cima, na criação da classe, o construtor é chamado a 1ª e única vez. Todas as outras vezes que alguém tentar construir na mão a classe, o teste é vai garantir que não seja possível criar uma segunda instância.

“Mas Tiago, se eu num posso chamar o construtor, como que eu vou criar um objeto da TSingleton???”. Isso é fácil. Você NÃO CRIA! “Mas hein?!?”

		//-----------------------------------------------------------
		// Esse método é o que iremos chamar daqui pra frente
		 // ao invés do construtor da classe
		public static function get Instancia():TSingleton
		{
			return TSingleton._instancia;
		}

Toda vez que você precisar acessar um método de uma classe com o Singleton (no nosso caso, a própria TSingleton), você vai usar pela linha TSingleton.Instancia.Metodo() (onde Metodo() é qualquer método da classe), garantindo que em TODAS AS VEZES você está acessando a mesma instância. Abaixo, mais 2 outros métodos de teste.

		//-----------------------------------------------------------
		// Método simples para retornar um atributo qualquer,
		// nesse caso, ‘valor’
		public function Valor():int
		{
			return this._valor;
		}

		//-----------------------------------------------------------
		// Como o método anterior, mas agora setando o valor do
		// atributo
		public function SetarValor( valor:int )
		{
			 this._valor = valor;
		 }
		//-----------------------------------------------------------
	}
}

Agora vai uma classe extra mostrando como usar uma classe com o padrão Singleton. A lógica de uso, nesse caso específico, está imbutida no construtor da classe, mas poderia estar em qualquer local.

Explicando passo a passo:

import TSingleton;

TODA classe que terá visibilidade de Singleton DEVE incluí-la. Dessa forma, mesmo sendo uma classe Global, áreas do programa que NÃO deveriam vê-la, NÃO verão. Isso evita muitos problemas de acoplamento, efeitos colaterais e melhora muito a reutilização.

public function TPrincipal()

{

	// Provocando o erro:

	//var teste:TSingleton = new TSingleton();

	TSingleton.Instancia.SetarValor(345);

	this.Exibe();

}

Como o construtor da TSingleton está protegido do acesso do programador, usar var teste:TSingleton = new TSingleton() vai resultar no erro:

Error: Uso: TSingleton.Instancia.Metodo()

at TSingleton$iinit()

at TPrincipal$iinit()

Lembrando que Uso: TSingleton.Instancia.Metodo() é a string que passamos para throw new Error lá no construtor de TSingleton, permitindo que vocês troquem a mensagem para algo mais descritivo, caso queiram.

Só para terminar, eu ressalto que esse é somente um dos vários algoritmos diferentes para o Singleton que vocês podem encontrar aí pela internet. Ele foi criado pelo Douglas prá nossa TIdioma há algumas poucas semanas, pois nenhum dos que encontramos era satisfatório o suficiente. Alguém aí tem mais algum exemplo do Singleton?

PS.: Aqueles que querem mesmo testar o Singleton, os arquivos estão aqui ó. Download Action Script 3.0 Singleton class (portuguese) here. Saiba mais: Wikipedia

Se até a vovó viu, por quê não ver você também?

Padrões de Projeto: O que são e pra que servem?

Quando começamos o projeto em Action Script 2.0, começamos a ter problemas com o Flash, já que não tínhamos prática para montar um projeto mais robusto. Foi quando o Douglas (naquela época o Mário não estava ainda com a gente) começou a recorrer aos grandes fórums sobre o assunto, para resolver problemas de boa programação. Depois das 4 primeiras respostas, o meu mundo mudou completamente.

Foi impossível não notar uma característica chave em todos os locais onde procuramos informações: os “grandes usuários” desses locais não sabiam absolutamente NADA de POO (Programação Orientada a Objetos) e SEMPRE criticavam nosso código, dando para a gente uma solução POG (Programação Orientada à Gambiarras).

“Tiago, você está falando a maior besteria da tua vida” vocês podem dizer, mas antes de qualquer coisa, o exemplo clássico do que eu estou falando foi quando estávamos com o clássico problema de escopo do AS2.0, onde o “this” dentro de um método sobrecarregado apontava para a classe de onde ele veio, ao invés de apontar para a classe que o sobrecarregava. Antes de encontrarmos o Ellipsis (um pacotão de atualizações) e a classe Delegate, nos foi dada a seguinte resposta por um dos “grandes usuários”: “Teu código está muito burocrático. Pega todos os métodos, bota num script na 1ª frame que ele vai funcionar”. Lindo, não???

É CLARO que eu não vou falar onde nem quem mandou fazermos tamanha bizonhice, mas não posso deixar de comentar a baixa qualidade geral dos códigos que vejo por aí. Variáveis Globais pra tudo q é lado, programação monolítica (um arquivo único de 15mil linhas) e, principalmente, ignorância absoluta sobre a existência dos Padrões de Projeto, o básico do básico em qualquer aplicação com qualidade e profissionalismo.

O conceito de Padrões de Projeto (Design Patterns, em inglês, também chamados de padrões de projeto de software ou padrões de desenho de software) vem da década de 70, mas foram realmente implementados catalogados mesmo lá pro final da década de 80, por Kent Beck e Ward Cunningham. Os Padrões são conjuntos de soluções para determinados problemas no desenvolvimento do seu software. Essas soluções já foram tão testadas por aí que foram padronizadas, recebendo um nome, o problema que ele resolve, a forma com que ele resolve e as conseqüências do seu uso. A idéia era que, quando falássemos do padrão X, soubéssemos exatamente sobre o que falamos.

Um padrão de projeto possui sempre um Diagrama de Classes (como esses aqui) relacionado a ele, usado para mostrar para os programadores como o código deve ficar. Uma vez conhecido o padrão e entendido como programá-lo, fica muito fácil resolver problemas graves ou que geram muita programação inútil.

Há uma reserva quanto ao uso de Padrões de Projeto: mesmo aumentando a reutilização das soluções enquanto você ainda está projetando o software, eles diminuem consideravelmente a reutilização de blocos pequenos de software, já que você vai ter que gastar um tempinho extra na manutenção das classes. Nada que a gente já não faça, mas o uso indiscriminado pode fazer com que seu projeto fique muito pouco reaproveitável.

Apesar disso, o verdadeiro maior problema que encontramos para adicionar os padrões ao nosso projeto foi que a Orientação a Objetos do AS2.0 era falha: existia, mas o foco ainda era a estruturação. Talvez por isso as pessoas fizessem gambiarras híbridas sem a menor pena. Em compensação, quando migramos para o AS3.0 e nos deparamos com OO pura, vimos que ele está completamente preparado para a confecção de softwares de nível profissional.

Então, daqui pra frente, quando disserem pra vocês que o Action Script 3.0 é uma linguagem de programação inferior, podem bater de frente. Eu mesmo vou colocar aqui algumas matérias sobre padrões de projeto aqui. Já estou preparando algumas sobre os padrões State, Concrete Factory e Singleton (em parceiria com os verdadeiros programadores do meu projeto, claro) e, se mais algum leitor programar em AS3.0 e quiser fazer o mesmo, me mande o link que vou colocá-lo aqui.

Os problemas de se focar na perfumaria.

Estava olhando projetos postados por aí quando notei um erro recorrente na maioria dos projetos: as pessoas começam pela perfumaria.

A perfumaria era um termo usado por meu professor de Multimídia e Interfaces Homem-Máquna, Projeto Final e tantas outras que designava as coisas bonitinhas que não têm influência direta no andamento do projeto. Coisas como o ícone do programa, as janelas, os mapas… tudo isso se encaixa no termo perfumaria.O termo perfumaria também pode ser traduzido como a interface do programa. Então, começar pela perfumaria é como começar um jogo pensando nas cores e formas das magias, ao invés de se preocupar com a programação delas.

Continue reading “Os problemas de se focar na perfumaria.” »

Nuss… E agora?!? também no Orkut.