Nuss… E Agora?!?

29set/074

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?

24set/071

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

19set/072

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

Hoje o artigo é diferente. Já que tenho grande acesso de estudantes aqui no Nuss... E agora?!?, vô deixá um link muito importante, o Vovó viu a Rede. Já faz um bom tempo que estou para falar dele, tá até linkado desde o início do Nuss..., mas antes tarde do que nunca.

O Vovó viu a Rede é do Mário, um cara q eu conheci na faculdade e se mostrou um dos melhores em Análise e Projeto que eu já vi. Hoje em dia ele está comigo e com o Douglas tocando o Jogo prá frente, penando com divisões de camadas, padrões de projeto e meus designs complicados. Autodidata como ele só, resolveu criar um blog contando tudo que aprendia enquanto estudava Redes de Computadores. E num é que o troço fez sucesso?

Sabe essa porrada de texto técnico que você acha na internet? Então cara, ESQUECE isso. O Mário pega a matéria, entende, picota, joga na água e deixa secá, postando tudo lá já recicladinho, numa linguagem simples e objetiva. Quer ver? Olha só a forma com que ele explicou o Modelo OSI e as redes peer-to-peer. Mais didático? Difícil, hein....

Recomendado prá pessoas que, como ele, queiram decifrar os mistérios desse assunto tão vasto que é a conexão entre computadores. Nota 10.

16set/077

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.

13set/071

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.

11set/070

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

Pois é, resolvi fazer esse post só prá avisar que, agora, o Nuss também conta com uma comunidade no orkut, a Nuss... E agora?!? (tenho certeza que vocês não imaginariam tal nome!). A idéia dela é colocar os leitores em contato uns com os outros, permitindo a direta troca de informações. Dessa forma, estaremos expandindo o Nuss, trazendo para um ambiente mais próximo da maioria dos brasileiros.

O link está permanentemente no menu ali ao lado, "o Nuss... no Orkut", onde estará também o link para o meu perfil, caso alguém queira fazer um contato direto.

Então gente, é isso. Quem quiser entrar em contato, discutir matérias não só do Nuss... mas também de outros blogs, ou coisa do gênero, pode entrar e pedir para participar que eu confirmo a participação. Valeu gente!

9set/075

O que torna um jogo um sucesso: Gráficos, Jogabilidade ou Enredo?

Nossa. Escrever sobre isso vai ser um tanto quanto polêmico, principalmente pois as pessoas têm opiniões definidas e inflexíveis quanto a essa tríade GJE. Como já li várias e várias discussões nos mais variados lugares, hoje Tiago vai expor seu pensamento.

  • Gráficos

Mais clássico que isso, não há. Gráficos são a parte visual do jogo. Elementos 2D e 3D que compõem as telas e o mundo de jogo. Efeitos de luz, sombra, partículas, qualidade das texturas, quantidade de polígonos na tela ou qualquer outra coisa que requer mais da sua placa de vídeo. Quando você atira em um lugar e lá fica a marca, isso também está influenciando a parte gráfica.

  • Jogabilidade

Jogabilidade é a mecânica do jogo. “Simplificando”, é o que você pode ou não pode fazer e, mais importante, a forma com que você faz isso. The Legend of Zelda: Ocarina of Time tinha uma das melhores jogabilidades que eu já vi, principalmente por causa do Z-Targetting (Você segurava o Z e o Link travava a visão num inimigo, ficando livre pra espancá-lo à vontade sem perdê-lo de vista), que foi legado para diversos outros jogos.

  • Enredo

Enredo é o roteiro, a história, o pano de fundo onde as coisas se desenrolam. Enredos memoráveis rendem milhares de comentários e milhões de cifras. Lembrem-se de Chrono Trigger e Final Fantasy VII, histórias geniais de jogos antigos que rendem até hoje (Final Fantasy VII que o diga).

Minha opinião costuma mudar muito sobre esses pontos, pelo simples fato de que depende muito do que o sujeito quer fazer. “Como assim depende, Tiago?”.Cara, lembra da matéria sobre o foco em um projeto? Então, isso acontece muito também na hora de escolher os pontos fortes de um jogo. Por exemplo, pegue o Super Smash Bros. do N64. Ele estava LONGE de ter gráficos maneiros pro padrão do console (misturava bitmaps chapados com objetos 3D). Não tinha enredo (pelo menos, não que o jogo tivesse mostrado). Em compensação, o troço foi um sucesso. Aí eu pergunto: “MAS COMO PODE?!?”.

Super Smash Bros. foi criado para ter uma jogabilidade absurda, trazendo horas e horas (e horas) de diversão para os jogadores. Você poderia escolher entre vários personagens já famosos pra sair na porrada. O objetivo era acabar com a energia ou jogar os adversários pra fora da arena, com a ajuda de ataques especiais simples de aplicar ou dos itens jogados na arena. Simples, não? Se a jogabilidade não fosse tão boa, Super Smash Bros. ia direto pro “gap in between dimensions”.

Outro exemplo é o Far Cry. Não acredito que tivesse sido o sucesso que foi se não contasse com as revoluções gráficas que conseguiu trazer, pois foram justamente elas as responsáveis diretas pelas inovações da jogabilidade. Sem os trocentos inimigos na tela procurando melhores táticas no meio das trocentas árvores, pedras, montanhas e arbustos, Far Cry seria pouco mais que um filho de Half Life.

Quando você cria um jogo, tem que saber o que seu público espera dele. Não adianta ter uma história foderooooosa num jogo de luta se, na realidade, seus jogadores tão interessados mesmo em espancar os adversários (por sinal, alguém aí sabe a história completa de Tekken ou Mortal Kombat?). Do mesmo jeito, não vale à pena você ter um gráficos primorosos pro teu jogo de estratégia se a jogabilidade dele está abaixo do que os seus jogadores querem.

O problema é que não há uma fórmula padrão para todos os jogos, e sim uma fórmula aproximada para o público que você quer alcançar. Crianças pequenas gostam de cores e bichinhos, enquanto sangue e tripas ficam para o público mais adulto.

Conhecer essa fórmula e as variáveis dela que é uma das chaves do sucesso, que depende também da capacidade de jogar e jogar o jogo várias vezes, marketing, estratégias de vendas, simplicidade de produção, preço e mais uma porrada de coisas que estão MUITO além dessa tríade GJH tão comentada.

Tá certo que, às vezes, a gente acha que vai agradar a um pessoal e acaba agradando a outro, mas não ter foco é o mesmo que tentar agradar a todos: você acaba não agradando a ninguém, o que faz seu projeto maravilhoso ir por água abaixo.

Pois então, agora são vocês: alguém aí tem algo a dizer?

7set/075

Princípio de Pareto: Como solucionar 80% dos problemas mexendo somente em 20% das causas

Título estranho, não? Como eu vou solucionar 80% dos meus problemas mexendo em somente 20% das causas?!? Isso é o que chamamos de Princípio de Pareto (ou regra 80/20). Ele foi sugerido por Joseph M. Juran, o mestre da qualidade, que deu o nome em homenagem a Vilfredo Pareto. Pareto era um economista sociopolítico que, no fim do séxulo XIX um economista italiano que viu que 80% da riqueza italiana ia para 20% da população.

A principal característica do princípio é definir visivelmente a relação ação/benefício. Dessa forma, pode-se focar nas ações que nos darão os melhores resultados.

“E pra que usar isso, Tiago?” Gente, esse princípio é EXTREMAMENTE IMPORTANTE para aqueles que querem entender a mecânica por trás das causas e soluções dos problemas em seus projetos.

Por exemplo, se a gente consegue identificar os 20% das funções mais utilizadas no nosso código, podemos trabalhar duro para melhorar essa área. Se você entendeu bem o conceito, já descobriu que melhorar esses 20% de código soluciona 80% dos problemas do programa. Show, né?

Adicionar a Análise de Pareto à sua papelada de gerência e design é muito interessante, principalmente quando você consegue expandir o conceito da regra para aplicá-la à sua realidade (como foi feito no Revolução etc ). Falando do Jogo, poderíamos realizar enquetes para descobrir quais 20% das características do projeto são mais importantes para 80% dos jogadores. Dessa forma, trabalharemos em muito menos coisas para atender a muito mais usuários

Porém, o contrário também é válido. Sem o entendimento da funcionalidade do teu programa, você pode estar trabalhando nos 80% das causas que geram somente 20% dos efeitos. Ou seja: você vai corrigir muito mais coisa e terá muito menos resultados. Chato isso, não?

Um gráfico de Pareto fica assim, ó:

Nesse exemplo fictício, conseguimos ver que quase 80% dos jogadores querem ter mais cartas, opções de personalização de personagens, mais interação com o fórum e possibilidades de personalização de guildas.

“Então Tiago, quer dizer que eu devo me esquecer dos tais 20%?” CLARO QUE NÃO! Se esquecer dos 20% significaria perder 20% dos teus clientes, o que é um absurdo! Essa análise é voltada para resultados com o menor esforço (quando os prazos estão apertados e os clientes estão cuspindo fogo em cima da gente), mas temos sempre que trabalhar em todas as causas para que não hajam brechas para a concorrência.

Pra finalizar, vale dizer que nem sempre as quantidades vão ser exatamente essas (nem que elas necessariamente somem 100%), mas a idéia principal é que um pequeno número de causas é responsável por um grande número de efeitos. Prá quem quiser se aprofundar no assunto, taí uma ótima coisa prá se saber!

Até a próxima!

4set/073

- Pára tudo! 2 -

Novamente estou aqui para agradecer aos blogs que estão me dando uma força para fazer desse projeto um sucesso.

O primeiro me encheu o peito de orgulho. A CubaGames, fez uma matéria extremamente pé no chão sobre o Nuss... E Agora?!? aqui. Aconselho que vocês leiam a matéria como mais um estudo de caso de um Design Inchado. Até por quê sei que ainda tem gente aê que, mesmo depois de ler a matéria, continua achando que se começa a subir uma escada pelo topo.

O segundo foi o Blog do Nunes que me indicou como um dos 5 da sua lista do BlogDay 2007, nesse artigo. Fiquei muito feliz em estar na sua lista, Evandro. Muito obrigado pela vaga e espero que as matérias sejam de alguma forma úteis em seu curso de Ciências da Computação.

Por fim, uma surpresa. A professora Maria Lúcia linkou-me aqui como fonte para início dos estudos sobre Modelagem Orientada a Objetos e Diagramas UML. Fiquei MUITO FELIZ MESMO, principalmente pois é justamente essa a função do blog: ajudar aqueles que estão iniciando e não sabem por onde começar.

Professora, gostei muito da vontade de passar aos seus alunos a matéria de uma forma atrativa e, precisando, basta entrar em contato.

Voltemos agora à nossa programação normal

3set/073

Atraso em projetos de horas vagas (Ou “Olha… já tamo devendo quase 3 semanas…”)

Lembram-se que eu fiquei de falar sobre os problemas com os quais nós iríamos nos deparar? Pois então, depois do Design Inchado e da Escolha do Flash, não acredito ter esquecido desse pequeno problema...

Que pequeno problema, Tiago?” você pergunta. Sabe quando a gente passa o dia todo trabalhando numa coisa séria, que exige atenção completa e dedicação total? Aí, depois que a gente chega em casa, cansado, o quê que vamos fazer? “Tomar aquele banho”, “jogar Crysis”, “cair na cama e dormir”, todas essas são respostas válidas. Agora, me responde uma coisa: e se você ainda tivesse um jogo pra fazer? Pois então, aí que ta o problema. Todo aquele tempo de descanso, aquela hora de reflexão pra saber quem é o assassino da Taís, aquelas horinhas para escrever no Nuss... E Agora?!?, isso tudo vai pro saco.

Fazer um trabalho fora do trabalho é EXTREMAMENTE DIFÍCIL pelo simples fato de que você não pode mais jogar Warcraft III o domingo todo, não pode sair pra organizar o churrasco de aniversário, nem ir ao rodízio de pizza sem que isso afete o tempo que você tem para terminá-lo. E, apesar disso tudo ser muito lógico e extremamente idiota de ser lido, EU NUNCA FUI AVISADO DISSO!!!!!!!

Só depois de uma conversa com o Douglas que eu me toquei que o maior atraso do Jogo vem justamente dos contratempos que apertam nossas horas livres. É o meu trabalho extra que atrasa, é ele que fica preso a um PC ruim. E o Mário, coitado, ta há 2 semanas esperando que a gente quebre uma classe em 3 outras para aumentar a coesão e diminuir o acoplamento. Sim, estamos 2 semanas atrasados e, se bobear, caímos na 3ª.

Seria tudo mais fácil se nós 3 estivéssemos ganhando com o projeto, pegando 8h diárias para trabalhar única e exclusivamente nele. Daria tempo pr’eu pesquisar muitos jogos, pro Douglas dissecar o Action Script 3.0 e o Mário ler muito sobre padrões. Daria para fazermos nossas reuniões e gerenciarmos nosso projeto de uma forma profissional. Porém, já que não é assim (e eu sei que também não é assim prá vários de vocês), como minimizar esses problemas todos?

Pois então... No momento eu não consigo pensar em muitas coisas. Não tenho propriedade para escrever sobre como evitar atrasos nos projetos de horas-vagas (também conhecidos como “to fazendo um jogo” ou “ainda é só hobby”). Porém, o pouco de lógica e consciência que me restam (é quase 1h da manhã e tô quase dormindo no teclado...) me permite dar os seguintes toques:

1. Faça o que gosta
Quando estamos cansados, fazer o que gostamos torna o serviço leve, muuuuito mais aceitável. Se o serviço em si não lhe agrada muito e tem que ser feito...

2. Faça do jeito que você gosta
Procure resolver o problema de uma forma de que lhe agrade. Lembro do final do projeto final, quando passei uma semana trabalhando coisa de 6h diárias na documentação do dito cujo. Para tornar o serviço menos tedioso (acreditem), eu fiz todos os diagramas no Word.

“VOCÊ TÁ MALUCO, NÉ?!?” Olha, certa hora eu achei que sim. Mas eu trabalho tão bem com o Word que, acredito eu, maluco estaria se estivesse tentando fazer aquilo tudo em um outro programa, como o Rational Rose. Já que éramos obrigados a fazer a papelada toda, fiz duma forma que me era agradável. Um serviço cansativo pode acabar tornando-se um descanso. Para isso...

3. Faça com prazer
Isso significa que você deve fazer aquilo sem o peso da obrigação. Não estou dizendo para que você não leve seu projeto a sério, é só pra que você não encare a tarefa como se o seu salário dependesse daquilo. Se a mente não consegue funcionar mais, saia e descanse. Dê-se esse direito e as coisas vão ficar mais fáceis de aturar. Lembre-se: se não é seu emprego, então é um HOBBY.

4. Não se esqueça das outras atividades
Isso tem muito a ver com o tópico anterior. Não se tranque, não se feche, não se desespere. Lembre-se que, quando você não precisa cumprir horários, o chopp da 6ª feira não se torna um pecado. Realmente não dá pra ficar sem trabalhar? Então...

5. Concilie as coisas
Desenhamos muitos Diagramas de Classe e Seqüência em reuniões regadas à chopp numa praça de alimentação de um shopping em Friburgo. Isso tornou o trabalho muito mais simples de se aturar.

6. Organize-se!
Se você não se organiza, não tem tempo pra nada. Termine as coisas pendentes ao invés de arrumar mais coisas pra terminar. Tente montar uma rotina flexível, separando um tempo para teu projeto. Fazer um cronograma é sempre essencial, mensurando o que se consegue fazer e o tempo que se demora a fazê-lo. Se não há um limite para resolução daquele problema, não há noção de atraso. Se não há noção de atraso, também não tem como saber se o projeto vai sair e quando se espera que ele saia. Daí pra frente, tudo fica tão nebuloso que se acaba duvidando da viabilidade da tarefa.

7. Foque-se!
Sem foco, não há trabalho que renda. Se você vai tirar 1h do seu tempo livre, TIRE 1H DO SEU TEMPO LIVRE. Não faça mais nada que divida sua atenção. Gosta de ar livre? Então vá para a varanda, leve o lap top e aproveite o sol. Gosta de silêncio? Então tranque-se e trabalhe à vontade. Gosta de ouvir músicas? Então ouça aquilo que quiser, o quanto quiser.

Mas lembre-se: você está buscando o foco. Você saberá que alguma coisa deu errada quando deixar de trabalhar para cantar. Não liguem, acontece muito comigo quando o Winamp escolhe uma dos Chili Peppers.

Essas são coisas que, instintivamente, eu tenho feito para despiorar essa situação, mas podem não ser aplicáveis a todos os casos. De qualquer jeito, já é um ponto de partida por onde vocês poderão desenvolver suas próprias técnicas. Aliás, falando nisso, mais alguém aí tem alguma dica para passar?