“Inspirado” nisso, o @CriadorDeJogos resolveu colocar a tag #empregojogos para divulgar empregos de jogos no Brasil. Mas como isso depende de todo mundo usar essa tag… é hora de divulgar

Então, divulgue a idéia, use se for o caso… até coloquei um widget com esse termo de pesquisa aqui na barra do lado do blog.

(acho que esse é o menor post que eu já fiz :p)

(eu adoro comentários, mas o Intense Debate me odeia. Se seu comentário sumir, ele deve estar na fila de moderação ou algo assim, tenha calma que eu chego lá.)

Integrar o gameplay ao tema do jogo não é algo necessário. Na realidade, boa parte dos jogos não fazem muito esforço nesse sentido, e colocar gameplay e tema de jogo em sentidos totalmente diferentes pode gerar resultados interessantes.

Um excelente exemplo disso é Puzzle Quest:

Excelente tirinha do Penny Arcade mostra a dissonância entre gameplay e tema de jogo em Puzzle Quest

Ou seja, essa integração não é fundamental, e em muitos casos é sequer desejável – às vezes você só quer um tema de fundo para seu gameplay.

Mas essa integração, quando existe, costuma chamar a atenção. Nesse sentido, o jogo recente que se destaca nesse sentido é Braid: a mecânica é tão intimamente ligada ao tema do jogo que é difícil discernir onde começa um e termina o outro, ou mesmo qual parte veio primeiro. Mesmo sem história, a mecânica expressa o desejo de voltar no tempo, a impossibilidade de se reparar certas coisas, com maestria.

Ou, se você não tiver tempo de jogar Braid, alguns jogos pequenos e simples também fazem esforços nesse sentido. Um joguinho em Flash que me cativou nesse sentido é The Company of Myself.

Jogue The Company of Myself, um jogo "Braid-iano" com um belo tema

Esse jogo certamente bebe da fonte de Braid (o próprio autor cita que Braid foi uma de suas inspirações), mas isso não quer dizer que ele não tenha seu charme, e seu próprio jeito de integrar gameplay ao tema do jogo: no jogo você controla um homem solitário, anti-social, que acaba aprendendo a fazer as coisas sempre sozinho… mesmo que “sozinho” signifique ele e suas cópias. O design de diversas fases também reflete isso, assim como a narração do personagem no decorrer das fases. A fase que melhor representa isso é a última fase – ela não é a mais difícil do jogo (na realidade, a única que eu achei ‘difícil’ foi a 11a), mas sua solução representa muito bem o estado de espírito do personagem naquele momento.

É um dos jogos que eu terminei e pelo qual tenho um certo carinho – é um jogo curto, de meia hora, com um boneco pequeninho e um chapéu, mas que me marcou. Isso, para mim, é um triunfo (I’m making a note here: huge success).

Mas, claro, é mais fácil promover esse tipo de integração em jogos menores. A coisa começa a ficar mais complicada quando você cria um mundo 3D, coloca armas, etc…

E é justamente nesses casos que a distância entre gameplay e tema se torna mais aparente. Eu não tenho nenhum problema com a dissonância de Puzzle Quest: é fantasia, faz parte, é a proposta do jogo. Mas quando eu estou jogando um desses jogos “EU SOU UM CARA BOMBADÃO SALVANDO O MUNDO” e não consigo quebrar um pedaço de madeira na minha frente para prosseguir… bom, digamos que quebra um pouco a imersão. OK, eu entendo você não poder destruir tudo pelo caminho, mas quando a barreira na frente beira ao ridículo… “eu tenho uma metralhadora de última geração que atira cinco mil balas por segundo, armaduras de dar inveja a um tanque… oh, uma porta de MADEIRA, deixe-me ir procurar uma chave…”… sério, né?

Isso também é fruto da tendência de se fazer personagens cada vez mais poderosos, indestrutíveis, super fodões… e não colocar um gameplay coerente a isso.

O que pode nos levar a: “o que é um gameplay coerente?”. Não é uma questão simples: para termos um personagem super fodão, basta deixá-lo destruir tudo pelo cenário? Mas se o personagem fodão é bonzinho, faz sentido ele destruir o lugar onde ele está, sendo que talvez esse seja um lugar usualmente habitado por civis inocentes?

Ontem eu vi meu namorado jogando a demo do novo Castlevania. OK, não vou nem mencionar que não gostei do estilo “God of Vampires”, mas vou apenas citar uma das partes do jogo: como todo bom jogo no estilo de God of War, você vive sendo trancado em pequenas arenas até destruir todos os inimigos. OK, eu entendo, sério. Mas o obstáculo não poderia ser algo melhor do que uma grande árvore tombada que eu poderia destruir ou, sei lá, pular por cima? Nesse ponto, esses jogos beiram a uma dissonância tão grande entre gameplay e tema de jogo quanto o já citado Puzzle Quest – você não é um cara foda, você é um merdinha que não consegue pular um tronco de árvore. OK, novamente, se a idéia é ter um cara super forte num jogo desses, ao menos coloque obstáculos coerentes.

Eu nem vou mencionar RPGs… mentira, vou sim. Esse é outro gênero que pende para a dissonância cômica: “sim, ok, você vai salvar o mundo… mas primeira limpe meu jardim, ok?”. Faz parecer que os heróis são na realidade office-boys glorificados ou coisa parecida.

Na realidade, isso quase pende para o lado poético da coisa, do cinismo: “não importa se você está tentando salvar o mundo, a maioria das pessoas só quer saber do seu gato perdido”, ou algo assim. Pensando agora, é um jeito de encarar as coisas que talvez devesse ser melhor aproveitado em algum jogo. *rabisca em seu caderninho de idéias*

Pode se supor que o jogador tenha duas opções ao encontrar um detalhe absurdo: abstrair, ou enxergar o ridículo e deixar a imersão cair. E a escolha entre um e outro talvez dependa tanto da vontade do jogador, quanto do esforço dos desenvolvedores.

Ao desenvolver, porém, talvez isso devesse estar claro, para que o desenvolvedor possa escolher:

1. Tentar colocar uma integração melhor entre gameplay e tema
2. Deixar aquele aspecto mais abstrato, para que o jogador tenda a abstraí-lo
3. Mudar um detalhe do jogo que não se encaixa
4. “nah, it’s late, let’s go eat some pizza”

E talvez por ser mais fácil integrar gameplay ao tema em jogos de menor escopo, talvez devesse ser obrigatório game-designers terem experiência com jogos menores antes de tentarem fazer um super mega jogo fodão de última geração.

E aos que repararam na quantidade de “talvez” deste jogo: sim, são apenas algumas considerações pessoais que, francamente, escrevo com o intuito de colocar ordem em meus pensamentos e publico na esperança de ler novas considerações que possam me guiar a conclusões cada vez melhores.

Na realidade, ao pender para o lado da ficção interativa é fácil se sentir um excluído, já que ficção interativa não é suficientemente literatura para a maioria dos leitores, e não é suficientemente interativa para a maioria dos jogadores. Pensar em uma interface interessante para explorar jogos em texto tem sido algo constante, então. Ainda não consegui encontrar aquela interface que seria ideal, mas eu certamente tenho jogado algumas coisas interessantes.

O mais interessante, talvez, é que muitas coisas que me atraem num trabalho de ficção interativa são as mesmas coisas que me atraem em jogos mais “usuais”: mundos interessantes a serem explorados, coisas legais para serem feitas que trazem consequências que me surpreendem, diálogos e temas que fujam do “padrão”. E, de certa forma, pela ficção interativa não ter nada além de texto, cada um desses detalhes fica tremendamente acentuado.

Eu pretendo fazer uma série de posts sobre alguns aspectos que tem chamado a minha atenção. Do jeito que eu gosto de escrever textos enormes (ou melhor, do jeito que eu aparentemente não consigo escrever textos curtos), eu inicialmente pensei em escrever um único artigo sobre isso, mas mudei de idéia quando percebi que era coisa demais para um único texto. Então, vamos olhar primeiro um aspecto que para mim é muito relevante, tanto em ficção interativa quanto em outros jogos: exploração.

Exploração

Eu adoro jogos que contenham elementos de exploração: Zelda, Metroid Prime, Beyond Good & Evil, Fallout… enfim, jogos de universos ricos que contenham diversos elementos a serem descobertos. Eu gosto da sensação de estar em um mundo estranho e descobrir um pouco mais sobre ele a cada fase, a cada novo túnel. Hoje mesmo eu esbarrei com um texto do Yathzee que fala sobre esse mesmo assunto.

Por outro lado, eu gosto tanto de exploração que eu prefiro NÃO ter exploração a ter uma exploração mal feita.

Explico com um exemplo recente: eu andei jogando MUDs e comecei a jogar Achaea. Muito interessante durante o tutorial, mas eu perdi a vontade de jogar quando fui jogada no jogo em si. Explico: apesar dos vários “guias para newbies” e coisas do gênero, eu não fazia a mínima idéia do que fazer, de para onde ir.

Eu não sou uma jogadora paciente e, francamente, eu provavelmente vou me aborrecer e deixar o jogo de lado se ele me deixar perdida logo nos primeiros minutos. Ou melhor, eu sou uma jogadora que precisa de motivação, que precisa de um objetivo. Se me derem um jogo onde “você escolhe seu objetivo” eu provavelmente não escolheria nenhum, especialmente quando eu mal sei o suficiente sobre meu personagem para estar interessada em tal escolha.

Exploração sem um objetivo, sem um destino, para mim não vale a pena – não é especialmente divertido ficar digitando direções cardinais e ler descrições pouco interessantes, francamente. O que torna a exploração de jogos como Zelda interessante é justamente que o mundo é interessante, e que você tem um objetivo ao fazê-lo, por mais piegas que seja esse objetivo seja hoje em dia: “salvar o mundo”. Em um jogo, se ao virar uma esquina e perceber que não há nada interessante ali, é rápido voltar e ignorar aquela cena.

Em uma ficção interativa, isso pode ser especialmente entediante.

> N

“blablabla boring.”

> W

“blablabla more boring”

>N

“blablabla oh the boringness.”

OK, vamos voltar… mas vamos olhar todos os caminhos que eu preciso tomar para chegar de volta onde eu quero.

Entre os jogadores mais aficcionados de ficção interativa é comum se ter o hábito de escrever um mapa conforme se joga. Para alguns, isso pode ser um elemento adicional de imersão, mas eu francamente não gosto de ter que fazer mapas. E, mesmo assim, permanece o problema de ter que ficar digitando um zilhão de comandos para voltar para onde eu quero, o único problema que se resolve é ter uma folha que te diga quais são os comandos exatos para voltar para onde você quer.

Alguns jogos resolvem parte do problema com uma solução interessante: um sistema de “landmarks”, alguns pontos de referência relevantes para a história aos quais você pode voltar rapidamente apenas dizendo “VÁ PARA PONTO DE REFERÊNCIA”.

Há um paralelo a ser traçado aí, entre esses pontos de referência e lugares onde você pode se teleportar em jogos, como no caso das canções de Ocarina of Time que te levam a todos os templos, só para citar um exemplo do meu jogo favorito. Esse tipo de solução parece dizer “claro, é interessante explorar e descobrir novos locais, mas não é tão divertido ter de ficar mexendo seu controle só para chegar em algum lugar, então nós vamos te ajudar com isso”.

Então, quando se fala em exploração em um jogo, que elementos são necessários para que:

1. O jogador QUEIRA explorar aquele mundo?
2. Aquele jogador GOSTE de explorar?

Para querer explorar um mundo, ao menos para mim, é necessário uma motivação: encontrar algo ou alguém específico, tentar realizar algo, ou mesmo encontrar a saída para escapar de um lugar. Mas eu preciso de uma motivação in-game, por mais simples que seja.

Alguns jogos não começam dizendo sua grande missão logo de cara. Antes disso, dão uma pequena introdução mundo e aos personagens com algo aparentemente corriqueiro e só então acontece algo grandioso. Inúmeros jogos fazem isso, como o menino Kokiri que recebe sua fada e vai falar com a grande árvore Deku…

A questão é que sempre existe um objetivo, um “porque”. Muitos jogos se safam sem dar explicações, mas isso é especialmente difícil em jogos que exijam exploração.

E para gostar? Eu preciso de motivação para começar, mas se eu não gostar do que estou descobrindo, não há motivação que seja suficiente.

Essencialmente, eu acho que são duas coisas: o mundo ser interessante, e também que existam maneiras interessantes de interagir com esse mundo – afinal, é uma experiência agradável descobrir novos lugares usando suas novas armas e itens.

Um mundo interessante pode possuir diversos elementos:

1. Uma descrição atraente. No caso de um jogo em texto, isso significa “colorir” textos quando necessário, ao invés de apenas escrever algo como “você está numa floresta densa”, e no caso de jogos com gráficos, seriam os gráficos, que não precisam ter zilhões de polígonos, mas devem ter personalidade, algo que marque aquele mundo na mente do jogador.
2. Coisas acontecendo. Muitos jogos podem trazer uma estética baseada na esterilidade, mas a maioria dos mundos precisa de coisas acontecendo: NPCs se movimentando, monstros atacando, o sol nascendo e se pondo, engrenagens girando…
3. Segredos. Passagens secretas, tesouros escondidos, qualquer coisa que não esteja à vista mas que seja valioso. Alguns jogos usam esse elemento de maneira um tanto quanto forçada, como “encontre as 100 coisinhas brilhantes para conseguir esse Achievement”, então eu acho importante ressaltar que esse elemento é mais um adicional, que deve ser bem incorporado ao jogo – um mundo não se tornará mais interessante apenas por possuir coisinhas brilhantes escondidas (a menos que você seja realmente fanático por Achievements).
4. Desafios são, provavelmente, elementos essenciais em jogos, ao menos na maioria deles. E desafios devem se relacionar com os outros aspectos: talvez o desafio seja descobrir como continuar a explorar o mundo, como chegar em um lugar diferente, como modificá-lo, como encontrar algo escondido. E, a meu ver, é algo que sempre deve estar visível ao jogador, servindo de combustível para a exploração: explorar para chegar a um chefe, para destruir algo, encontrar outra coisa.

Esses quatro elementos são os que consigo imaginar agora e, novamente, é interessante notar que, embora o tema inicial desse artigo tenham sido os jogos de texto, todos esses detalhes se aplicam tanto a jogos de texto quanto a jogos com gráficos (sim, jogos sempre tem texto e texto também pode ser chamado de gráfico mas… vocês entenderam).

Depois da exploração, vem outro detalhe muito importante, que novamente se aplica a esses dois tipos de jogos tão diferentes entre si: interação. E é sobre isso que eu vou falar no próximo artigo dessa série.

PS: Gente, eu estou voltando a me acostumar a escrever no blog, então eu ainda estou meio enferrujada, esqueço de responder comentários… mas saibam que eu AMO todos os comentários daqui, e leio todos eles com carinho, viu?

Kissu, seeya! ˆ_^

Balanceamento de jogo é uma dessas áreas. Todo jogo deve ser balanceado, e é um fator crítico para o sucesso de um jogo, especialmente se for um multi-player. Provavelmente muitas horas são gastas alterando parâmetros até achar um bom equilíbrio. Ainda assim, eu não vi muita bibliografia falando sobre isso, com teorias sobre o assunto. Aparentemente, atualmente isso é feito com base no bom senso dos desenvolvedores do jogo, e com base em muitas horas de testes.

Apesar disso, é um problema fundamental, a começar pela própria definição de equilíbrio.

Por exemplo, um jogo multiplayer que eu aprendi a gostar é equilibrado ao ponto de que eu, com minhas três, quatro horas de jogo, consigo me divertir com meus colegas, alguns dos quais possuem mais de 200 horas de jogo. Eu sou pior do que eles, não tenho experiência com todas as classes e ainda nem consegui todos os equipamentos, mas mesmo assim, eu consigo me divertir. E muito.

E olha que eu ainda nem consegui meu sanduíche.

Minhas duas classes favoritas: Medic e Heavy

Eu só jogo com meus amigos em LAN, porque para mim não tem graça jogar TF2 sem botar gritar pro time inimigo ou tirar os fones e provocar o outro time IRL. Eu me perco nas fases com frequência (e é por isso que eu adoro mapas novos, porque aí eu não sou a única que se perde ), e só não sou um desastre completo com as duas classes que eu gosto de jogar: Heavy e Medic.

Esse tipo de equilíbrio é essencial para um jogo como esse. Imagine como seria difícil montar servidores e ter que ficar limitando por horas de jogo? Ou por equipamentos que a pessoa possui? (Não que isso impeça experiências desagradáveis online, mas isso se deve mais ao fator “a-internet-está-cheia-de-cuzões” do que ao jogo em si).

Diversos fatores contribuem para isso:

• É um jogo de equipes: então, a menos que um time seja drasticamente superior ao outro, as fraquezas de um jogador acabam se equivalendo a fraquezas de outro jogador. Claro, aquele outro time tem um sniper infernal, ou talvez um heavy, mas nós conseguimos matá-lo quando um Medic se une a um Heavy, ou quando alguém se aproveita da distração do inimigo, ou tem um tremendo momento de sorte.
• Não existe uma “estratégia” drasticamente melhor do que outras: Existem várias estratégias no jogo, algumas que são combinadas e outras que acabam emergindo por conta dos jogadores envolvidos. Às vezes o time se reúne com Heavys, Pyros e Medics, gruda no carrinho e acaba levando-o até o destino antes que  o outro time consiga reagir, às vezes o Heavy se reúne com dois Medics com UberCharge para invadir uma base. Aliás, numa mesma partida é possível ver diversas estratégias, uma após a outra, numa sequência de ação-e-reação entre os times.
• Embora existam equipes, há uma certa independência entre os jogadores: comparando com um jogo como WoW, no qual se o Healer ou o Tank morrerem numa luta difícil TODO MUNDO MORRE, é fácil perceber como essa independência ajuda no equílibrio: em Team Fortress, se você faz uma besteira e morre, geralmente isso não coloca em risco o jogo de toda equipe. Sim, é triste ser um Medic, morrer para um Spy e ver o Heavy morrer logo em seguida, mas o ritmo do jogo é tão rápido que logo existe o respawn e os jogadores se vingam daquele Spy. Aliás, o próprio ritmo do jogo é um fator muito importante no balanceamento do jogo e merece um bullet point só para ele, então…
• O ritmo do jogo é rápido: você joga, você faz uma burrada, morre, dá respawn e continua. Aquela cagada se torna irrelevante, e você normalmente tem chance de reverter o jogo. E isso colabora para que o nível de frustração com erros, seus ou de seus companheiros, não atinja níveis estratosféricos. Aquela decisão que você tomou no início do jogo não fica te assombrando durante toda a partida, como ocorre em muitos jogos de estratégia.
• Existem diversos “papéis”para os jogadores: tem dias que eu estou a fim de destruir tudo e por isso vou com meu Heavy, outros eu estou com vontade de ficar mais atrás, ajudando o resto da equipe, e por isso vou com o Medic. E isso permite que os jogadores escolham seus papéis de acordo com o seu humor, e de acordo com o que é necessário para o time.

Todos esses fatores contribuem para um jogo bem balanceado, e a Valve sabe muito bem disso: sabendo da necessidade de jogos equilibrados ela coloca ferramentas para dividir times de maneira equilibrada, dá papéis diferentes para jogadores diferentes .

Mas essa é apenas uma maneira de balancear um jogo, dentre muitas.

Um jogo pode ser balanceado de maneira diferente dependendo de diversos fatores:

• O jogo é single-player ou multi-player? Se for multi-player, existe uma série de requerimentos para que um jogador não seja brutalmente penalizado apenas por ter escolhido uma classe diferente para jogar, e é por isso que costumamos ver a conhecida trindade… “Pedra-papel-tesoura”… claro, seu mago talvez consiga arrasar com um guerreiro, mas sofre sob um ladino habilidoso, que por sua vez sofre nas mãos do guerreiro. Isto, claro, é só um exemplo, mas existem diversas considerações a serem tomadas para que os jogadores não tenham a síndrome do “claro que eu perdi, o carro dele é muito mais rápido do que o meu”.
• Cooperativo ou competitivo? Se é competitivo, deve ser uma boa idéia usar “papéis” que ressaltem a importância do trabalho em equipe.
• O ritmo é rápido ou lento? Em Team Fortress nós temos um ritmo super rápido, e é balanceado de acordo com isso: você morre facilmente, mas também volta a jogo rapidamente. Em um jogo como Starcraft o balanceamento é completamente diferente: apesar de ser um jogo no qual você faz muitas coisas ao mesmo tempo, você não pode morrer tão facilmente, ao menos não sempre e contra pessoas de nível semelhante ao seu. O que você faz no começo do jogo irá afetar todo o resto do jogo, para bem ou para mal. É um jogo rápido, mas de consequências não tão rápidas. E ainda temos jogos como Xadrez, no qual se faz uma ação de cada vez e no qual cada movimento pode ser crucial. Cada um desses jogos exige um balanceamento próprio: imagine como seria Team Fortress 2 se cada tiro que você desse fosse absolutamente essencial, ou se em Starcraft você pudesse ter uma reação absolutamente espetacular e construir um império tendo o mínimo de materiais logo depois de seus pontos muito importantes terem sido destruídos pelo exército gigante do inimigo e conseguir um virar o jogo? Não digo que seja possível, mas certamente não é comum. E se em Team Fortress uma virada de jogo é emocionante e engraçada, esse pode não ser o caso em um jogo como Starcraft, onde o emocionante são disputas acirradas no qual os dois competem praticamente com os mesmos recursos durante todo o jogo, e a partida acaba decidida por aquelas decisões culminantes no fim da partida (embora as decisões de todo o jogo sejam relevantes, claro).
• Quanto do jogo é sorte, quanto é habilidade e quanto é equipamento? A maravilha dos jogos de cartas tradicionais é que todos tem acesso aos mesmos recursos: o que determina o vencedor é tanto a sorte, de receber os recursos necessários, quanto a habilidade, de decidir o que é o melhor a ser feito naquele momento, e isso ajuda a equilibrar o jogo entre jogadores dos mais diversos níveis. Outros jogos, como xadrez, dependem quase que exclusivamente da habilidade do jogador. Já em RPGs (onlines ou não) é comum existir o fator “equipamento”: não importa quanto você entenda as mecânicas do jogo, às vezes você simplesmente tem de gastar tempo para conseguir recursos para que possa prosseguir.

E diversos outros fatores.

O ponto principal sendo: não é sequer possível pensar em balanceamento antes de se definir o que é um jogo bem balanceado, de acordo com o que está sendo desenvolvido. E é algo que pode ter diversos passos, desde a seleção da ordem na qual as habilidades dos personagens são apresentadas ao jogador, das habilidades em si, da dinâmica entre as diversas habilidades.

Um amigo está fazendo um jogo, e pediu minha opinião para balancear o jogo. Então nós jogamos uma partida e ele foi ajustando alguns parâmetros. E foi incrível como o jogo foi de “bah, boring” para super viciante mudando apenas alguns parâmetros. Ou seja, não é algo a ser subestimado. Pelo contrário, tendo as mecânicas principais, essa é a parte do desenvolvimento que provavelmente merece a maior atenção.

E, na verdade, balancear o jogo em equipe pode ser um jogo por si só: nós nos divertimos bastante vendo qual parte eu ia descobrir que estava mas “apelona” para “abusar”, apenas para ele atualizar e “nerfar”aquilo, só para eu ir atrás de outra coisa que estivesse desbalanceada. E isso provavelmente indica que ter mais do que uma pessoa para balancear o jogo torna as coisas muito mais produtivas.

Isso, claro, é apenas um esboço de um começo de teorias sobre o assunto… o que vocês acham? Já pararam para pensar no assunto?

PS: amanhã é o aniversário de 3 anos desse blog, veja só que legal

Esse tutorial não requer que você saiba muito de JavaScript e/ou jQuery, mas ter alguma noção ajuda, e já ter programado também. Não é muita coisa para explicar, então eu vou tentar explicar tudo com detalhes para ajudar quem também está aprendendo JavaScript e/ou jQuery, OK?

De qualquer maneira, eu ainda estou aprendendo a escrever tutoriais, embora já tenha escrito alguns, então eu sempre posso esquecer de falar algo importante… se for o caso, pode perguntar nos comentários que eu respondo e, se possível, melhoro o tutorial, ok?

O Esqueleto da Aplicação: HTML e CSS

Como não é feito nada de muito avançado nem no HTML nem no CSS, vamos apenas dar uma olhada rápida na estrutura dos dois, ok?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Jogo da Mem&oacute;ria em JavaScript</title>
<script type="text/javascript" src="lib/jquery/jquery-1.3.2.js"></script>
<script type="text/javascript" src="scripts/jogo.js"></script>
<link type="text/css" rel="stylesheet" href="styles/styles.css" />
</head>
<body>
<h1>Jogo da Mem&oacute;ria em JavaScript</h1>
<div id="mesa-de-jogo">
</div>
<div id="texto-tentativas"> Tentativas: <div id="tentativas"></div></div>
</body>
</html>

Como vocês podem ver, a parte HTML desse joguinho é realmente BEM simples. Só quero ressaltar alguns detalhes:

1. São inseridos dois scripts: o script do jQuery, e o script do jogo. A ordem é importante, já que eles são carregados em ordem – se o jogo.js estivesse sendo carregado primeiro ele daria erro.
2. Estão vendo esses “div” no corpo da página? Sem entrar em aspectos técnicos, eu gosto de imaginá-los como marcações, um quadradinho colorido. Mais tarde eu vou mexer nesses “div” via CSS e via javascript e vou chamar o elemento cujo ID é mesa-de-jogo e o div certo vai ficar levantando os braços dizendo “me usa, me usa, sou eu, sou eu!” (imaginação fértil: eu tenho).
3. A parte de tentativas não está na página atual, apenas no arquivo do meu PC, mas é algo bem simples. Se você quiser implementar as tentativas, use esse div, senão, não use.

O CSS tem mais alguns detalhes, mas também é bastante simples:

body {	background-color:#363636;}
h1 {	color:#84C1C3;	text-align:center;	font-family:sans-serif;}
.carta img:hover {	cursor:pointer;}
.carta img {	margin:5px;}
.carta {	display:inline;}
#mesa-de-jogo {   display: block;   text-align:center;}
#texto-tentativas {	text-align:center;	color:#84C1C3;	font-family:sans-serif;}
#tentativas {	display:inline;}

Novamente, nada de muito impressionante, apenas alguns detalhes para deixar a página mais “bonitinha”. Olhando em cada elemento, nós podemos ver:

1. body é a página em si, foi definido só para colocar uma cor de fundo
2. h1 é o título, definido aqui apenas para definir cor, alinhamento e fonte (ou melhor, a família da fonte mas, enfim)
3. Esse ‘.carta img:hover’ dita o comportamento de quando o mouse está sobre (hover) uma imagem (elemento img) que esteja aninhado em um elemento da classe ‘carta’. Ou seja, isso será aplicado apenas a imagens desta categoria. Neste caso não faz muita diferença, já que as únicas imagens da página são aquelas do jogo, mas vale pela organização. Esse estilo serve para mudar o cursos do mouse para “pointer”, para indicar que é possível interagir com aquelas cartas.
4. Nesse caso, em “.carta img” estamos definindo um estilo para as cartas, nesse caso, uma margem de 5 pixels para elas não ficarem “grudadas” umas nas outras.
5. As duas linhas definindo o estilo de carta e mesa-de-jogo servem para que as cartas fiquem juntas… se você não definir nada, as cartas vão ficar uma em cada linha, o que não ficaria muito bonito :p Inicialmente eu havia usado tabelas para organizar isso, mas assim o código fica mais limpo (a parte de Javascript não tem de se preocupar com essa parte de layout, o que é importante). Ou seja, a mesa de jogo mostra seus elementos “filhos” em um bloco, e as cartas que estão dentro da mesa de jogo estão configuradas para serem mostradas “inline”, ou seja, serem colocadas na mesma linha e não em uma nova linha, como seria padrão em um div.
6. Bom, o text-tentativas e o tentativas não tem nada de diferente e, novamente, só são usados se você quiser fazer uma linha sob as cartas com o número de tentativas do jogo.

Uma nota sobre # e . : essas são dois marcados, usados tanto no CSS quando para manipular DOM. # serve para ID e . para classe. Não é difícil de imaginar que ID é um identificador único de um elemento na página, não é mesmo? E classe, por outro lado, pode ter vários elementos em uma página. É o caso de #mesa-de-jogo e .carta: só existe uma mesa de jogo, mas varias cartas, daí se usar mesa-de-jogo como ID e carta como classe.

A diferença pode não parecer relevante, mas existem diversas funções que encontram um elemento com um ID, por exemplo, como o document.getElementById(), que vai retornar um único elemento.

E isso encerra a parte de HTML e CSS. Agora, vamos para a parte divertida: Javascript e jQuery!

Javascript e jQuery: montando a lógica do jogo

Então, nós temos um esqueleto em HTML e CSS, mas do jogo nós ainda não temos absolutamente nada, não é mesmo? É aí que entra a parte de JavaScript e jQuery. O código é bastante simples e eu fiquei em dúvida de por onde começar a explicar… até ter a brilhante idéia de começar explicando… por onde eu comecei

(eu tenho umas sacadas geniais, eu sei)

Então, a primeira coisa que eu fiz foi mostrar as cartas na tela ao abrir a página:

$(function (){
	mesa_de_jogo.linhas = 2;
	mesa_de_jogo.colunas = 4;
	for (linha=1;linha<=mesa_de_jogo.linhas;linha++)
	{
		for (coluna=1;coluna<=mesa_de_jogo.colunas;coluna++)
		{
			$("<div class='carta'><img></img></div>").bind("click",function(){ mudarCarta(this);}).appendTo("#mesa-de-jogo");
		}
		$("#mesa-de-jogo").append("<br>");

	}
	novoJogo();

});

Por onde começar? Bom, essa função de jQuery, simplesmente $( function () { coisas } ) é carregado assim que o DOM é carregado. Ou seja, esse é, essencialmente, o nosso Main().

Serão colocadas 8 cartas, em duas linhas e quatro colunas, como pode ser visto em mesa_de_jogo.linhas e mesa_de_jogo.colunas. mesa_de_jogo é um objeto que eu criei, apenas para guardar esses dois valores de maneira significativa. Na primeira versão eu usei simplesmente as variáveis linhas e colunas e não faz diferença.

O primeiro for percorre as linhas, e o segundo for percorre as colunas, colocando cada carta na página. O código responsável por adicionar a carta à página é este:

$("<div class='carta'><img></img></div>").bind("click",function(){ mudarCarta(this);}).appendTo("#mesa-de-jogo");

A cifra é o “seletor”, a grande ferramente de jQuery: permite que eu faça inúmeras coisas com os objetos do DOM de maneira muito mais prática que usando Javascript puro.

DOM?

Eu suponho que muitos aqui já saibam o que é DOM, mas vamos a uma explicação simples para aqueles que não sabem: trata-se de uma “árvore” de elementos. Uma página HTML é montada como se fosse uma árvore, cujo tronco principal é o “html”, os dois primeiros grandes galhos são “head” e “body” e daí vão se acrescentando mais galhos e folhas a esta árvore. Por exemplo, a árvore deste nosso jogo poderia ser representada assim (só coloquei os ramos referentes à parte de carta e mesa de jogo, para simplificar):

Eu até tentei desenhar como uma árvore, para ficar mais fácil de visualizar Mexer com HTML/CSS/JS basicamente envolve mexer bastante com essa árvore, mexendo nos ramos, adicionando folhas, etc. No caso, com

$("<div class='carta'><img></img></div>")

Nós criamos um ramo, com o elemento carta, e que possui uma folha chamada img. Ao colocar isso dentro de $() nós podemos realizar operações sobre esse ramo mais facilmente.

Por exemplo, após a linha acima nós temos a seguinte função:

.bind("click",function(){ mudarCarta(this);})

O que isso faz? Basicamente faz uma conexão com o ramo. Bind funciona com .bind(evento, função). Neste caso, estamos dizendo que ao ocorrer o evento “click” sobre o ramo supracitado deve ser chamada a função mudarCarta(). “this” é passado como parâmetro da função, para que a função saiba qual carta foi clicada.

(Veremos essa função mudarCarta() mais tarde, calma, mas já é possível imaginar o que ela faz, não?).

Ou seja, já temos um ramo “carta”, que possui um evento de clique atrelado a ele. Porém, este ramo AINDA não está na árvore do documento. Ela ainda precisa ser anexada a algum elemento já existente da árvore do documento. No caso, nós queremos anexar esse ramo ao ramo “mesa-de-jogo. e a função .appendTo(elemento) faz isso. Agora, é possível entender totalmente o que faz a linha principal dessa parte do programa, não?

$("<div class='carta'><img></img></div>").bind("click",function(){ mudarCarta(this);}).appendTo("#mesa-de-jogo");

Feito isso você irá perceber que por enquanto são apenas elementos… embora exista o elemento img, ele não tem o atributo “src”, ou seja, ele não está ligado a nenhuma imagem. Isso e outras inicializações são feitas na função novoJogo(), que é chamada depois que os dois laços for são executados e todas as cartas já estão na árvore do documento:

function novoJogo(){
	cartaLadoB.sort(function() {return 0.5 - Math.random()});
	$(".carta img").attr("src","images/carta.png");
	pares_restantes = pares;
	tentativas = 0;
	$("#tentativas").text(tentativas);
}

O que essa função faz? Basicamente, quatro coisas:

1. Embaralha as cartas
2. Define a imagem do fundo da carta
3. Diz quantos pares faltam para terminar o jogo
4. Reseta o número de tentativas

Embaralhando as Cartas

Essa parte de embaralhar as cartas é feita com uma única linha:

cartaLadoB.sort(function() {return 0.5 - Math.random()});

cartaLadoB é um array que eu define com o nome das imagens dos pares. No caso, no início do documento javascript eu a declaro da seguinte forma:

var cartaLadoB =
		["bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png",
		 "bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png"];

A função sort é a responsável por “embaralhar” esse array. Se eu simplesmente chamada cartaLadoB.sort() esse array seria ordenado em ordem alfabética, mas .sort() é uma função de JavaScript MUITO BACANINHA que te permite dizer COMO você quer organizar o array.

Basicamente, você passa uma função que pode retornar < 0, 0 ou > 0, e  o sort organiza os elementos de acordo. Se você comparar os elementos a e b e retornar < 0, a função irá definir que a deve vir antes de b, se > 0, b deve vir antes de a, e se for 0 eles são considerados iguais e suas posições não mudam. Sabendo disso, é possível fazer uma infinidade de funções para fazer os mais diferentes tipos de ordenamento (como fazer uma função para ordenar pelo primeiro nome de um objeto Pessoa, por exemplo).

Para fazer um ordenamento aleatório, nós temos a seguinte função: function () { return 0.5 – Math.random() }.

Math.random() retorna um número aleatório entre 0.0 e quase 1 (não chegando a, exatamente, 1). Desta maneira, há uma chance de 50% deste número ser maior do que 0.5 e 50% de ser menor do que 0.5. Ao fazer o retorno de 0.5 – Math.random() há, portanto, uma chance de 50% do resultado ser maior do que 0, e 50% deste número ser menor do que 0. Ou seja, a ordenação de cada dois elementos é definida aleatoriamente, que é o que nós queríamos

Alterando um atributo da carta

Nós já vimos como criar uma “folha” da árvore, mas muito de Javascript não consiste em criar esta folha e colocá-la no documento, mas também modificá-la conforme necessário.

Por exemplo, ao criarmos o elemento “img” nós não definimos seu atributo src, e agora? Para isso, nós podemos alterar atributos de qualquer ramo a qualquer hora, selecionando-o conforme necessário. E melhor, podemos mexer um atributo para todos os elementos de um determinado tipo, se for necessário. Por exemplo:

$(".carta img").attr("src","images/carta.png");

Aqui o que nós estamos selecionando são os elementos img que estejam sob o ramo “carta”. TODOS os elementos, veja que não há nenhuma restrição como first, last ou qualquer outra coisa. Então, nós podemos mexer em todos os elementos de uma só vez. E então nós usamos a função .attr(atributo,valor_do_atributo) para modificar um atributo de todos esses elementos. No caso, nós estamos definindo que o atributo src deve receber o valor “images/carta.png” que é o endereço do fundo da carta.

Aqui cabe uma ressalva: eu recomendo NÃO fazer como eu fiz e colocar esse endereço hardcoded como eu fiz. Crie uma variável e coloque o valor dela conforme for necessário, e use esta variável aqui. É que mais tarde você vai fazer uma comparação com este endereço e eu perdi algum tempo até perceber que o erro que eu estava tendo se devia ao fato de ter colocado um espaço a mais em um dos endereços da imagem. Vivendo e aprendendo :p

Os outras linhas se referem a definir que o número de pares que devem ser encontrados para terminar o jogo é o número total de pares do jogo, e depois se atribui que o número de tentativas é zero, e se atribui esse valor ao ramo “tentativas” da árvore. Pronto, temos um novo jogo.

Exceto que, por enquanto, ele não faz nada além de mostrar algumas cartas bonitinhas na tela. E agora?

A função mudarCarta()

Esta é a função responsável por mudar a carta quando ela é clicada:

function mudarCarta(elemento){
	if ( ($(elemento).find("img").attr("src") == "images/carta.png" ) && (wait == 0))
	{
		$(elemento).find("img").attr("src", "images/" + cartaLadoB[$(".carta").index(elemento)]);
		if (!is_segunda_carta) {
			primeira_carta = elemento;
			is_segunda_carta = true;
		} else {
			segunda_carta = elemento;
			wait = 1;
			setTimeout(verificaPar,700);
		}
	}
}

E aí, deu para perceber o que ela faz?

Elemento é a carta que foi clicada, que é passada como parâmetro desta função. A primeira coisa que é verificada é se é o fundo que está aparecendo, para evitar que alguém fique clicando numa imagem que já foi virada, e também verifica se o jogo não está esperando (wait == 0). Esperando pelo que? Calma, já vamos ver.

Se o jogo não estiver esperando e o jogador tiver clicado numa carta que ainda não foi virada, então é verificado qual a ordem da carta que foi clicada, para alterar para a imagem de acordo com que foi definido no array cartaLadoB. Novamente, vamos analisar esta linha de código com calma:

$(elemento).find("img").attr("src", "images/" + cartaLadoB[$(".carta").index(elemento)]);

Primeiro, nós pegamos o elemento e obtemos sua folha “img”, para então alterar seu atributo src. Ou seja, até $(elemento).find(“img”).attr(“src”, … está tranquilo entender, de acordo com que nós já vimos. É importante notar que .find() também é um seletor, logo, ele irá retornar todos os elementos que estejam de acordo com os parâmetros. No caso, teremos um único elemento img sendo retornado pois cada carta possui um único ramo chamado img.

E a imagem é definida de acordo com o array cartaLado B, de acordo com “images/” + cartaLadoB[$(".carta").index(elemento)]. O índice desejado do array é o índice da carta na lista de cartas da página. Mas como saber isso? Para isso, novamente usaremos seletores: primeiro selecionamos todos os elementos de classe carta com $(“.carta”) e então verificamos, nesta seleção, qual é o índice desse elemento que foi clicado com index(element0). Pronto, temos o índice correto da imagem a ser exibida

Feito isso, temos que verificar se esta foi a primeira carta clicada, ou seja, apenas deixe a carta exposta ali, ou se já é a segunda carta, para verificarmos o par e desvirar as duas cartas se for necessário.  Isso é feito com o if (!is_segunda_carta) (que também poderia ser um if (is_primeira_carta), se você preferir :p), sendo que is_segunda_carta é uma variável booleana definida no início do documento javascript como false.

Se for a primeira carta, nós armazenamos esta carta como primeira_carta, para depois fazermos a comparação e, se for o caso, desvirá-la, e então mudamos a variável is_segunda_carta para que a próxima carta verifique o par conforme necessário.

Se já for a segunda carta, nós armazenamos essa carta na variável segunda_carta, definimos que devemos entrar em modo de espera (falei que iria explicar, não falei? :]) e chamamos a função verificaPar depois de 700 milissegundos. A função setTimeout faz justamente isso: chama uma determinada função, depois de um tempo pré-determinado. Algumas observações importantes sobre a função setTimeout, essa função malandra:

1. você deve passar o NOME da função a ser chamada, e não invocá-la, por isso colocamos verificaPar e não verificaPar(). Se for necessário passar parâmetros, crie uma função anônima ali mesmo, com function() { funcaoQueVoceQuerChamar(parametros,que,voce,quiser);}.
2. setTimeout não PÁRA o funcionamento ali. Ele joga a função para ser executada depois e continua executando as instruções do código. No caso, eu não coloquei nada depois de setTimeout mas, se existisse algo, esse algo seria executado antes de verificaPar ser executado.

Por causa desse tempo de espera eu criei a tal variável wait – ela está ali só para o jogador não ficar clicando nas cartas nesse tempo de espera. E a função é chamada só depois de 700 milissegundos para dar tempo do jogador ver a carta antes que ela seja desvirada.

A função verificaPar()

Estamos quase acabando, amiguinhos Mas ainda falta o mais importante para o jogo funcionar: ele já vira as cartas, e tudo o mais, mas ainda não consegue verificar se você acertou o par ou não. E é aí que entra a última função desse joguinho, a verificaPar

function verificaPar(){
	is_segunda_carta = false;
	if ( $(segunda_carta).find("img").attr("src") == $(primeira_carta).find("img").attr("src"))
	{
		pares_restantes--;
	} else {
		$(segunda_carta).find("img").attr("src","images/carta.png");
		$(primeira_carta).find("img").attr("src","images/carta.png");
	}
	tentativas++;
	$("#tentativas").text(tentativas);
        wait = 0;
        if (pares_restantes == 0) {
		novoJogo();
	}
}

Eu acho que aqui, mesmo que no início você não soubesse nada de jQuery e Javascript, você já consegue entender o que esse código faz, não?

Mas, claro, como eu gosto de explicar as coisas (sério, eu ainda não sei se é uma coisa boa eu explicar tudo nos mínimos detalhes em todo tutorial… eu tento deixá-los claros e fáceis de ler, estou conseguindo amiguinhos? Ou só estou conseguindo fazer tutoriais enormes? :p), vamos olhar o que esse código está fazendo para não restar nenhuma dúvida.

Primeiro, nós definimos que a próxima carta não será uma segunda carta, isto é, is_segunda_carta volta a ser false. Depois, verificamos se a imagem mostrada na primeira e na segunda cartas são iguais.

Se forem iguais, é um a menos que o jogador deve encontrar.

Se fore diferentes, desvira as duas cartas, isto é, muda a imagem de volta para o fundo da carta.

No caso aumenta-se o número de tentativas e atualiza o número de tentativas mostrado na página no ramo “tentativas”.

Wait é definido como zero, isto é, o jogador pode voltar a clicar nas cartas.

Se não houverem mais pares a serem encontrados, isto é, pares_restantes for igual a zero, o jogo terminou e, portanto, deve-se iniciar um novo jogo.

E, é isso

Só para verificar, eu não cheguei a colocar explicitamente todas as variáveis que eu declarei no início de jogo.js, então aqui vão todas elas:

var pares = 4;
var cartaLadoB =
		["bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png",
		 "bear2-card.png","bear-card.png","leaf-card.png","leaf2-card.png"];
var pares_restantes;
var is_segunda_carta = false;
var primeira_carta;
var segunda_carta;
var wait = 0;
var tentativas;
var mesa_de_jogo = new Object;

Lembrando que elas devem ser declaradas no início do documento (…eu acho).

E, bom, é isso, agora vocês tem um super hiper mega incrível demais estupendo fenomenal joguinho de memória, feito por vocês mesmos UAU EIN

Aliás, sacanagem da semana foi eu estar toda empolgada com meu joguinho da memória e o Google me AVACALHAR com o joguinho do Pac-man feito em Javascript. Vou te contar, viu :p

Mas estou com o código salvo aqui (encontrei aqui) e vou estudá-lo com calma… não parece complexo, mas está bastante longo e foram usado algo para diminuir o tamanho do arquivo, acho, e várias variáveis estão com uma única letra como identificador, so, yeah.

Conheçam o meu hiper, mega, suuuuper… jogo de memória. Feito em JavaScript. Com gráficos feitos por mim no Inkscape.

A questão é que eu me diverti bastante fazendo esse joguinho, então talvez eu faça mais alguns em JavaScript O legal é que eu fiz ele em um único fim de semana… claro, se eu já conhecesse mais de JavaScript e JQuery eu provavelmente faria bem mais rápido, e se eu não fosse tão enrolada também… (gastei algumas horas escolhendo a IDE e deixando ela mais personalizada para o meu gosto… :p). Mas enfim. Para alguém com TDAH é muito revigorante conseguir terminar alguma coisa, então eu estou bem feliz

Eu vou tentar colocar mais alguns detalhes nele (como número de tentativas e talvez a opção de escolher quantos pares terá o jogo), mas o jogo em si está pronto e vocês podem testá-lo aqui ou clicando na imagem acima.

Eu vou fazer um post explicando como eu fiz o jogo, para aqueles que também tiverem algum interesse em jogos feitos em Javascript/jQuery, mas estou colocando o jogo para vocês jogarem e me avisarem se ainda tem algum bug e tal e se tiverem alguma dúvida, que aí eu já lembro de explicar no tutorial. De qualquer maneira, vocês já podem fuçar no jogo se quiserem, já que o código está disponível e você pode até mexer nele se tiver alguma ferramente de desenvolvimento web no seu browser.

(E sim, estou numa segunda-feira bem feliz por conta disso :] )

Duas editores bastante grandes de livros técnicos, a Apress e a O’Reilly, colocam todos os dias um dos livros do seu catálogo pelo preço promocional de 10 dólares.

Os livros da O’Reilly são oferecidos em três formados: PDF, ePub e Mobi, todos sem DRM. Já a Apress apenas disponibiliza um PDF protegido por senha.

Em todo caso, eu recomendo vocês se cadastrarem nos feeds dos dois (Assine o da O’Reilly aqui e o da Apress aqui) para ficar de olho quando aparecer algo interessante.

Hoje eu acabei comprando o Dive Into Python da Apress e o Learning XNA 3.0 da O’Reilly.

O Learning XNA eu comprei hoje, mas o deal é de ontem, então se você vir isso e se interessar, corre que o cupom deve estar expirando. Para comprar o Dive Into Python com desconto, basta ir na página do Daily Deal e clicar em Purchase e o resto é uma compra normal. Já o Learning XNA você coloca no carrinho e usa o cupom de desconto DDLXN que o desconto aparece no Checkout.

Bom, é isso, se vocês não conseguirem aproveitar esses deals, sempre vale se inscrever nos feeds para aproveitar a próxima oportunidade.

E se você também está interessado em aprender Python, vale conferir o How to Think Like a Computer Scientist, que também é bem bacana e é gratuito.

UPDATE: Como o Mark Pilgrim é um cara muito legal, o Dive Into Python é distribuído de graça. Embora eu esteja me sentindo retardada por só ter visto isso agora, bom, eu não estou me sentindo tão mal porque o livro é realmente muito bom e ele deve receber pelo trabalho bem feito :p

Fazendo, por exemplo, esse capacete que é mostrado no Getting Started do Maya e que eu deixei com umas cores assim, meio Halo.

A Cindy está… ultimamente bastante doente, primeiro com uma gripe horrível e depois com uma crise de sinusite. Mas estou melhorando, e tomara que eu não pegue mais nenhuma doença que perder quase duas semanas de aula por doença logo no início do semestre não foi divertido.

A Cindy está aprendendo a fazer pixel art…

Mas a Cindy se irritou com o mouse e comprou um tablet e continuou a desenhar…

Mas aí ela percebeu que não levava muito jeito para desenho livre e voltou para o look retrô de pixel art…

De repente, ela resolveu que com seus mínimos conhecimentos de programação e desenho ela poderia tentar fazer um joguinho… enquanto se prepara para fazer seu sonhado RPG…

Mas, sempre devagar e sempre parando para se empolgar com projetos diferentes, provavelmente vai demorar para sair esse jogo, mesmo ele sendo pequeninho…

Mas o que importa é que a Cindy está feliz

O problema é quando ela se atrasava. Não, nunca aconteceu comigo aquelas cenas de filmes, da criança sozinha na escola depois que todo mundo já foi embora, com cara de “minha mãe esqueceu de mim, ela não me ama”. Falo coisa de cinco, dez minutos. Quinze quando muito. Eu começava a olhar os carros passando e começava a imaginar que uma desgraça havia acontecido, que a mãe havia batido o carro e não poderia vir me buscar. Que ela estava machucada. Que alguém mau havia ameaçado ela.

Aí, uns trinta segundos depois, mamãe aparecia e eu ia saltitando para o carro e ia embora.

A coisa ficava pior quando eu via filmes de terror. Eu demorei semanas para voltar a dormir direito depois que vi O Chamado no cinema. O pior é que eu fui ver de trouxa, um amigo falou que era bom, achei que era suspense e fui lá. Depois eu fechava os olhos e via cenas do filme se repetindo na minha cabeça.

E porque eu estou dizendo tudo isso, vocês poderiam se perguntar. Para que vocês saibam que eu sou medrosa, e que ainda assim sou incapaz de sentir medo com jogos. Não que eu nunca leve sustos mas, como vocês já devem ter percebido, não é muito difícil eu levar sustos: se eu estiver lendo e alguém me cutucar, eu provavelmente vou gritar e dar um pulo. Eu levo sustos quando coisas aparecem do nada, e eu até gosto disso, é divertido. Mas não é medo, não é nada perto disso.

Medo e Consequência

Medo e susto para mim são coisas completamente diferentes. E se jogos tem tido realmente algum sucesso na arte de dar sustos, na arte de dar medo… nem tanto.

Medo para mim é aquela eterna tensão em virar aquela esquina, em descobrir logo como fazer um puzzle… medo EXIGE consequência e, francamente, jogos não tem sido muito bons em lidar com consequências.

Eu normalmente jogo correndo para todos os lados sem me preocupar muito porque, se eu morrer, o que vai acontecer? Eu vou voltar uma ou duas salas? Quer dizer… e daí? Demon’s Souls ainda chega perto de ter alguma consequência mas, francamente, depois que você se acostuma a jogar sem seu corpo, você se importa menos em perder seu corpo, e depois que aprende a “farmar” almas você percebe que é rápido conseguir almas indo nos lugares certos. Mesmo um dos jogos mais “sacanas” dos últimos tempos ainda sabe quando parar em termos de “consequência” para o jogador – embora eu ainda esteja meio chateada comigo mesma por ter assassinado o NPC vendedor de flechas sem querer, mas tudo bem, isso não vem ao caso.

O caso é que, com tantos save points e “dicas” no decorrer do jogo, fica difícil ficar realmente preocupado. Ah, se eu não conseguir agora, consigo daqui a pouco.

Mas não seria apenas uma questão de diminuir os save points – isso certamente aumentaria a tensão, mas não o medo. “Ah, se eu morrer e tiver de refazer os últimos quinze minutos… bom, talvez eu desligue o videogame e tente de novo amanhã porque eu cansei.”

O que faria você ter medo? Eu não sei responder a essa pergunta com precisão, simplesmente porque eu não tenho nenhum exemplo para me basear. Mas, imaginando como eu me comporto com outras mídias, eu diria que eu preciso me preocupar com o que vai acontecer. É o mínimo. É preciso existir a expectativa de que algo ruim pode acontecer – como morrer no próximo corredor por conta de um zumbi gigante.

Mas embora isso seja o suficiente para dar um susto, para que esse susto se transforme em medo efetivo é necessário um outro detalhe: que seja irreversível. Afinal, como eu vou ter medo de algo que eu posso me livrar apenas dando um reload?

Medo e a Irreversibilidade

Isso é algo muito presente em filmes de terror: você está lá e SABE que algo ruim vai acontecer, mas não há absolutamente nada que você possa fazer a respeito. Pessoas vão ser torturadas, vão sofrer e morrer e rebobinar o filme não vai mudar isso. A tensão vai se construindo à medida que percebemos que algo ruim irá acontecer, até culminar com o susto e o fato.

Nos jogos, não há a irreversibilidade na maioria dos casos, a menos quando previsto no roteiro do jogo.

Ou seja, se escolhe: ou é irreversível, ou é evitável.

Há exceções, claro – dentre os jogos mais recentes, há o tão falado “Heavy Rain”, no qual certos personagens podem de fato morrer em certas passagens, e a história irá seguir sem eles. Mas isso está mais para a exceção que confirma a regra do que qualquer outra coisa.

Existem várias maneiras de coisas ruins acontecerem e o jogo prosseguir – por exemplo, alguém querido para o personagem principal pode morrer se você não chegar a tempo, você pode perder equipamentos importantes, ou pode ter de mudar o rumo de uma missão…

Em filmes, não é incomum que personagens secundários sejam mortos para imprimir mais medo e tensão à trama, e os jogos de certa maneira vem tentando imitar isso.

O problema, no ritmo frenético de um jogo, é se importar com a morte de um “NPC”, por mais cruel que ela seja.

Medo e a Empatia

Digamos que você tenha um cãozinho no seu jogo.

E ele fique contigo, mas de repente ele pode morrer. E se morrer vai ser sua culpa! Eu mencionei um cãozinho porque a maioria das pessoas se apega à animais com relativa facilidade, especialmente a filhotes como o da foto acima.

Mas enfim, digamos que você tenha um companheiro no jogo e de fato se apegue a ele – e não fique secretamente torcendo para o imbecil morrer de maneira lenta e dolorosa, como ocorre em Resident Evil 5.

E que a fragilidade dele se transforme em medo de que ele possa morrer a qualquer momento. Afinal, você tem armas e sabe correr, mas e um filhote? Uma criança? Alguém que simplesmente não pertence àquele meio de tensão?

Novamente, há de se ter cuidado – essa fragilidade por vezes se transforme em “cuide desse ser retardado e incapaz de cuidar de si próprio para continuar a fase”. Tipo Resident Evil 4 e a filha do presidente – não há empatia, não há vontade de cuidar. Há apenas o desejo de que aquela parte do jogo acabe logo para você não ter mais de cuidar daquela adolescente que não sabe nem fugir de zumbis.

No caso de Resident Evil 4, essa falha se dá tanto pelo fato de não existir esforço para que o jogador se apegue à garota, e também pelo fato de sua morte ser sempre reversível no jogo – ela morreu? Tem problema não, só voltar para o último checkpoint.

Difícil seria terminar o jogo tendo de lidar com suas falhas – “é, eu consegui me salvar… mas a que custo?”.

Criar empatia em jogos de videogame, no entanto, não é facil. Mas há alternativas. Por exemplo, digamos que você controle um homem, e que ele possua uma namorada. E em certo ponto você pode morrer, falhar miseravelmente, e nesse caso você poderia continuar o jogo com a namorada. Como mostrar o peso disso para o jogador? Uma parte do desafio foi facilitada, já que usualmente é mais fácil para o jogador ter alguma empatia com o personagem que controla, mas como mostrar isso ao jogador de forma a gerar medo?

Medo e o Roteiro

De certa forma, causar medo em jogos é um desafio tão grande quanto causar qualquer outra emoção. Mas o medo, graças aos filmes de terror,  tem suas caracterísitas já bem conhecidas: a tensão, o susto, a irreversibilidade, a fragilidade. E, francamente, a considerar os filmes de terror, não é preciso o melhor roteiro do mundo para imprimir medo às pessoas. Ou seja, o medo pode ser a emoção ideal para uma mídia que ainda está aprendendo a mostrar emoções e a mostrar roteiros primorosos.

Até certo ponto, uma vez que o medo seja melhor compreendido nas mídias interativas, sua implementação pode passar a ser semi-trivial, tal como a tensão de um jogo de ação, ou como os sustos são hoje mostrados nos ditos jogos de terror.

Ainda assim, não consigo me lembrar de um único jogo cujo roteiro tenha me feito sentir medo. Vocês saberiam dizer algum jogo no qual vocês já sentiram medo?

Esse post surgiu de mensagens trocadas no twitter, quando alguém mencionou que tinha medo de Bioshock e suas criancinhas feias. Eu comecei a perguntar sobre jogos que davam medo e, embora eu não tenha jogado todos os mencionados, como Fatal Frama, outros eu já joguei e, francamente, não consegui sentir medo, como Dead Space e F.E.A.R..

Mas, quem sabe um dia?

E, por outro lado, sabendo como eu sou realmente medrosa, será que eu quero MESMO sentir medo em um jogo? Hmmm, é de se pensar…

Mas antes de entrar no mérito de jogos, eu preciso contar um pouco sobre mim – sobre sonhos que eu tenho desde criança.

Eu sempre gostei de histórias. Eu sempre gostei de CONTAR histórias.

Certa vez, estava com alguns primos em um aniversário de família, quando alguém propôs uma brincadeira: uma pessoa se encarregava de contar uma história, que deveria contar as palavras ditas pelo resto das pessoas na mesa. Eventualmente só eu ficava contando histórias (bizonhescas, claro) envolvendo coisas como fogões e sorvetes. Eu ADORAVA, eu me divertia com a sensação de estar criando uma história naquele exato momento, de estar contando um pedaço de alguma coisa de maneira tão impulsiva.

A maior parte de vocês mal conhece esse meu lado, claro – pode até achar que eu escrevo bem no blog, mas não faz idéia de como eu escrevo HISTÓRIAS.

Minha culpa, na realidade – desde que eu entrei para a faculdade, e isso já faz quatro anos, eu não tenho mais conseguido escrever histórias. Bom, o que eu posso dizer? A faculdade tem me consumido tanto nos últimos anos que eu simplesmente não conseguia me colocar para escrever minhas histórias. Não é apenas uma questão de TEMPO, mas de ESPÍRITO – eu chegava em casa cansada e minha cabeça simplesmente se recusava a produzir mais e mais. Minha cabeça precisa de pelo menos um pouco de ócio criativo, e eu simplesmente não tenho tido isso nos últimos anos.

E eu acabei me deixando levar… e me interessei por jogos, e entrei no mesmo ciclo vicioso…

Eu começava, me empolgava, mas antes que eu conseguisse colocar as coisas no lugar, as peças nos eixos, alguma outra coisa chamava a minha atenção, chegava a época de provas da faculdade, e lá ia mais um projeto para o fundo da gaveta…

Ah, foram anos de “Hello Worlds” que ecoaram, solitários…

Mas, sabem, eu já levei muito tapa na cara por conta disso. Já perdi um ano da faculdade por conta de escolhas das quais hoje me arrependo. Ou melhor, hoje me arrependo da própria escolha de faculdade: veja bem, o que diabos eu estou fazendo numa faculdade de engenharia se o que eu gosto de fazer é contar histórias? Mas eu acho que quatro anos eu não tinha certeza disso.

Ou melhor, eu sabia disso, mas não sabia o que fazer: não existe uma faculdade para quem “gosta de contar histórias”, mesmo o curso de Cinema da UFSC não é voltado a essa parte, até onde eu sei. Então eu simplesmente fui para um curso que tinha coisas interessantes a serem aprendidos – afinal, eu também sou uma tremenda nerd, como vocês já devem ter percebido.

Mas quatro anos depois eu começo a achar que não há mais muito que eu queira aprender aqui, e ao mesmo tempo… como largar a faculdade a essa altura do campeonato? Como largar a faculdade e dizer “olha, bacana, mas agora no final do curso eu descobri que não é bem isso que eu quero”? Mais do que desapontar os outros, eu estaria me desapontando. Porque eu tenho a impressão de que sou aquela que nunca termina as coisas?

Por que aquela pilha de projetos nas gavetas se acumulam? Por que as idéias na minha mente se aglomeram?

Veja bem, eu sou inteligente o suficiente para fazer um jogo. Sou aplicada, detalhista, persistente. Sei contar histórias, criar personagens.

Mas na hora de começar a colocar isso para funcionar… eu simplesmente acho outra coisa para fazer, algo mais interessante, um jogo novo.

Porque, claro, sempre tem um jogo novo. Uma prova na faculdade. E novas idéias. E de repente… eu não consigo levar meus projetos adiante. E não há GTD que ajude quando eu não sei quanto eu posso exigir de mim mesma.

Se exijo demais, fico estressada – e eu já sou suficientemente estressada por conta da faculdade, mind you.

Se não exijo o suficiente, o projeto não anda e… vai para a gaveta.

Eu até já pensei em tentar criar um grupo de estudos para tentar ter um grupo que me mantivesse motivada, mas… será que dá certo? Eu não sei. Sem alguém para guiar… fica realmente difícil, ainda mais em uma área tão complexa quanto a de criar jogos.

E até conseguir resolver isso, fico aqui… falando sobre jogos e apreciando histórias, quando o que eu realmente quero é criar, histórias e jogos.

Mas, quem sabe um dia eu consiga, quando eu conseguir lidar com a minha mente, quando eu conseguir lidar com o turbillhão que se encontra em minha mente…

Até lá, fico com minhas crises existenciais que se abatem sobre mim a cada quinze dias…