Game Design Concepts – Level 3: Elementos formais dos jogos

Game Concept Design - Banner

Por Ian Schreiber (http://gamedesignconcepts.wordpress.com/)

Tradução de Bruno Salvatore Drago (www.xuti.net) – Original em http://gamedesignconcepts.wordpress.com/2009/07/06/level-3-formal-elements-of-games/ (Acesso em 26.08.2009)

Hoje marca o último dia na construção do vocabulário crítico em que se discutem os jogos. Na próxima aula iremos mergulhar diretamente no processo de design de jogos (game design). Hoje colocarei as últimas peças que faltam em seus lugares: precisamos de uma maneira de dissecar e analisar um jogo discutindo seus componentes e como eles se encaixam. Isso pode ser útil quando se fala de jogos com outras pessoas (o que seria bom se, por exemplo, mais “game reviews” profissionais fizessem isso de forma adequada), mas também é útil ao projetar nossos próprios jogos. Afinal, como você pode criar um jogo se você não sabe como todas as partes se encaixam?

Uma nota sobre a leitura de hoje

Uma das leituras de hoje foi Formal Abstract Design Tools, de Doug Church. Eu quero mencionar algumas coisas sobre isso. Primeiro, ele menciona três aspectos dos jogos que valem a pena colocar na nossa caixa de ferramentas de design:

  • Intenção do Jogador é definida como a habilidade do jogador para conceber e realizar os seus próprios planos e metas. Voltaremos a isso mais tarde neste curso, mas por hora,  perceba que isso pode ser importante em muitos jogos para permitir que o jogador forme um plano de ação.
  • Consequência Perceptível é definido na leitura como uma reação clara do jogo às ações do jogador. Clareza é importante aqui: se o jogo reage, mas você não sabe como o estado do jogo mudou, então você pode ter dificuldade em relacionar as suas ações com as conseqüências dessas ações. Indico que “conseqüência perceptível” é conhecido por um nome mais comum: o feedback.
  • História é o cerne narrativo do jogo. Note-se que um jogo pode conter dois tipos diferentes de história: a “história incorporada” (criado pelo designer) e a “história emergente” (criada por jogadores). A “história emergente” acontece, por exemplo, quando você contar a seus amigos sobre um recente jogo que você jogou e o que aconteceu com você durante o jogo: “Eu tinha assumido toda a África, mas eu simplesmente não conseguia manter o jogador azul para fora do Zaire”. A “história incorporada” é o que nós normalmente pensamos como a “narrativa” do jogo: “Você está jogando com um bravo cavaleiro aventurando-se no castelo de um mago malvado. O que Doug chama a atenção é que a história incorporada concorre com a intenção e conseqüência – isto é, quanto mais o jogo for sobre trilhas, menos o jogador pode afetar o resultado. Quando Costikyan disse em “I have no words” que os jogos não são histórias, Doug fornece o que eu acho o que é a melhor maneira de dizer o que Costikyan queria dizer.

Aqui está um exemplo do porque a “intenção do jogador” e a “conseqüência perceptível” são importantes. Considere a seguinte situação: você está jogando um jogo de tiro em primeira pessoa. Você caminha até uma parede que tem um interruptor. Você muda a posição do interruptor. Nada acontece. Bem, na verdade, algo aconteceu, mas o jogo não dá qualquer indicação sobre o que aconteceu. Talvez uma porta em algum lugar no nível abriu. Talvez você só liberou um monte de monstros na área e você vai correr para eles logo que você saia da sala atual. Talvez haja uma série de interruptores, e todas elas têm que seguir exatamente o padrão exato de ligar e desligar (ou eles têm que ser acionados na ordem correta), a fim de abrir o caminho para a saída do nível. Mas você não tem como saber, e assim você se sente frustrado que agora você deve fazer uma pesquisa exaustiva de todos os lugares que você já tenha estado no jogo… só para ver se o interruptor fez alguma coisa.

Como você poderia arrumar isso? Colocando um melhor feedback. Uma forma seria fornecer um mapa para o jogador e mostrar a localização no mapa quando o interruptor foi puxado. Ou então, mostrar um corte de cena breve que mostra uma abertura de porta em algum lugar. Tenho certeza que você pode pensar de outros métodos também.

Em outro assunto, Doug também inclui uma nota interessante no final do artigo sobre como ele valoriza beta testes, e metade de seus leitores encontraram as duas primeiras páginas lentas, assim começaram na página 3 se você está nessa metade. Este seria um exemplo de iteração na concepção deste ensaio, exatamente o tipo que falamos.

Agora, eu tenho certeza que essa nota foi, em parte, em tom de brincadeira, mas vamos levá-la literalmente. Há um pequeno problema com essa correção: você não vê a nota até que você já leu todo o artigo, e é tarde demais para fazer algo a respeito. Se Doug fizesse a iteração sobre seu design pela segunda vez, o que sugere que ele fizesse? (Eu ouvi muitas sugestões de meus alunos no passado.)

Qualidades de jogos

Foi observado nos comentários desse curso (o curso originariamente foi colocado num blog) em seu primeiro dia que eu me contradisse: Eu insisti que um vocabulário crítico era importante, e depois passei a dizer que definir plenamente a palavra “jogo” era impossível. Vamos conciliar esse aparente paradoxo.

Dê uma olhada rápida nas definições dadas no primeiro dia de curso. Separe todas as qualidades enumeradas em cada definição que podem ser aplicadas aos jogos. Vemos alguns temas recorrentes: os jogos possuem regras, conflitos, objetivos, tomada de decisões, e um resultado incerto. Os jogos são atividades, são artificiais / seguros / fora da vida cotidiana, são voluntários, contêm elementos de faz-de-conta / representação / simulação, são ineficazes, são arte, e eles são sistemas fechados. Pense por um momento sobre quais outras coisas são comuns a todos os (ou a maioria dos) jogos. Isto fornece um ponto de partida para que possamos identificar elementos individuais de um jogo.

Refiro-me a eles como “elementos formais” de novo, não porque eles têm a ver com vestir um terno e gravata, mas porque são “formais” no sentido matemático e científico: algo que pode ser explicitamente definido. “Challenges” se refere a eles como “átomos” – no sentido de que estas são as menores partes de um jogo que pode ser isolado e estudado individualmente.

Quais são os elementos atômicos de um jogo?

Isso depende de quem você perguntar. Tenho visto diversos esquemas de classificação. Como a definição de “jogo”, ninguém é perfeito, mas, olhando para todos eles, podemos ver alguns temas emergentes que podem lançar luz sobre os tipos de coisas que nós precisamos criar, como designer de jogos, se quisermos fazer jogos.

O que se segue são algumas partes dos jogos, e algumas coisas que os designers devem considerar quando se olha para esses átomos.

Jogadores

Quantos jogadores o jogo suporta? Precisa ser um número exato (4 jogadores apenas) ou um número variável (de 2 a 5 jogadores)? Os jogadores podem entrar ou sair do jogo durante a partida? Como isso afeta o jogo?

Qual a relação entre os jogadores: Eles são times ou individuais? Os times podem ser desiguais? Aqui estão algumas estruturas de jogadores. De forma alguma é uma lista exaustiva:

  • Solitário (1 jogador contra sistema de jogo). Exemplos incluem o jogo de cartas Paciência ou o video game “Campo Minado”.
  • Jogador contra Jogador (Head-to-Head). Xadrez e Go são exemplos clássicos.
  • “PvE”(Party Vs ??? – Jogadores contra o sistema de jogo). “PvE” (multiple players vs. the game system). Isto é comum nos MMOs, como o World of Warcraft. Alguns jogos de tabuleiro puramente cooperativos também existem, como o Senhor dos Anéis, do Knizia’s, Arkham Horror e Pandemic.
  • Um-contra-muitos (1 jogador contra vários jogadores). O jogo de tabuleiro Interpol[i] é um grande exemplo disso. Um jogador é o Mr. X contra um time de detetives.
  • Liberdade para tudo (Free-for-all – 1 jogador contra 1 jogador contra 1 jogador contra…). Talvez essa seja a estrutura mais comum para jogos multiplayers que pode ser encontrada em qualquer lugar, de jogos de tabuleiro como Banco Imobiliário a um “multiplayer deathmatch” de um jogo de tiro em primera pessoa de algum videogame.
  • Indivíduos separados contra o sistema (um jogador contra uma série de outros jogadores). O jogo de cassino Blackjack é um exemplo, onde a “Casa” joga como um jogador contra vários outros jogadores, mas os outros jogadores não afetam muito uns aos outros e realmente não ajuda atrapalhar ou jogar uns contra os outros.
  • · Competição de equipes (jogadores contra jogadores [contra jogadores contra…]). Essa também é uma estrutura comum, e é encontrada em muitos esportes, jogos de cartas como Bridge e Espadas, jogos em grupo online do tipo “capture a bandeira” em jogos de tiros em primeira pessoa ou numerosos outros jogos.
  • Presa-predador. Os jogadores formam um círculo (real ou virtual). A meta de todos é para atacar o jogador à sua esquerda, e defender-se do jogador à sua direita. O jogo de faculdade Assassinato e jogo de cartas Vampire: The Eternal Struggle, ambos fazem uso desta estrutura.
  • Estrela de cinco pontas. A primeira vez que vi isso foi em uma variante de cinco jogadores em “Magic: the Gathering”. O objetivo é eliminar os dois jogadores que não estão no lado oposto de você.

Objetivos (metas)

Qual é o objetivo do jogo? O que os jogadores estão tentando fazer? Isso é muitas vezes uma das primeiras coisas que você pode se perguntar ao projetar um jogo, se você está preso e não sabe por onde começar. Depois de saber o objetivo, muitos dos outros elementos formais parece que vão se definir para você. Alguns objetivos comuns (mais uma vez, isso não é uma lista completa):

  • Capture / destruir. Elimine todas as peças do seu oponente do jogo. Xadrez e Stratego são alguns exemplos bem conhecidos, onde você deve eliminar as forças opostas para ganhar.
  • Controle territorial. O foco não é, necessariamente, em destruir o adversário, mas em controlar determinadas áreas do tabuleiro. RISK e Diplomacia são exemplos.
  • Coleta. O jogo de cartas rummy e suas variantes envolvem a coleta de conjuntos de cartas para ganhar. Bohnanza envolve a coleta de conjuntos de feijões. Muitos jogos de plataformas (como a série Spyro) incluiu níveis onde você tem que coletar um certo número de objetos espalhados por todo o nível.
  • Solução de problemas. O jogo de tabuleiro Clue (ou Detetive, dependendo de onde você mora) é um exemplo de um jogo onde o objetivo é resolver um enigma. Menos conhecidas (mas mais interessante) exemplos são o Castelo da Magia e Sleuth.
  • Perseguição / corrida / fuga. Geralmente, qualquer coisa onde você está correndo em direção ou longe de algo, o jogo de playground pega-pega e o videogame Super Mario Bros são exemplos.
  • Alinhamento espacial. Uma série de jogos envolvem o posicionamento de elementos como objetivo, incluindo os jogos não-digitais Tic-Tac-Toe (jogo da velha) e “Pente” e o jogo de videogame Tetris.
  • Construir. O oposto de “destruir” – seu objetivo é avançar seu personagem(s) ou ampliar seus recursos até um determinado ponto. The Sims tem elementos fortes deste. O jogo de tabuleiro Settlers of Catan é um exemplo também.
  • A negação de um outro objetivo. Alguns jogos terminam quando um jogador realiza um ato que é proibido pelas regras, e que o jogador perde. Exemplos são os jogos de destreza física Twister e Jenga.

Regras (mecânicas)

Conforme mencionado na semana passada, existem três categorias de regras: Configuração (setup) (coisas que você faz uma vez no início do jogo), a progressão do jogo (o que acontece durante o jogo), e a resolução (que condições fazer com que o jogo termine, e como é um resultado determinado com base no estado do jogo).

Algumas regras são automáticas: elas são acionadas em um certo ponto no jogo sem escolhas do jogador ou interação (“Compre um card no início do seu turno”ou “O bônus diminui em 100 pontos a cada segundo”). Outras regras que definem as escolhas ou ações que os jogadores podem ter no jogo, e os efeitos dessas ações sobre o estado do jogo.

Vamos cavar mais fundo. “Rules of Play”, de Salen & Zimmerman classifica três tipos de regras, que eles chamam operacional, constitutiva e implícitas (esses termos não são padrão na indústria, então os conceitos são mais importantes que a terminologia, neste caso). Para ilustrar, vamos considerar as regras do Jogo da Velha:

  • Jogadores: 2
  • Setup: Desenhe um quadriculado de 3×3. Escolha um jogador para jogar primeiro com o X. O oponente será designado com O.
  • Progressão do jogo: Em seu turno, marque um quadrado vazio com o seu simbolo. O jogador então passa a vez ao seu oponente.
  • Resolução: Se você alinhar 3 de seus simbolos em uma linha, coluna ou diagonalmente, você venceu. Se o tabuleiro for completamente preenchido sem vencedores, ocorre o empate.

Essas são o que em “Rules of Play” são chamados de regras operacionais. Pense por um momento: Esas são as únicas regras do jogo?

À primeira vista, parece que sim. Mas e se eu estou perdendo e simplesmente me recuso a jogar outra vez? As regras não dão explicitamente um limite de tempo, então eu poderia “parar” por tempo indeterminado para evitar a perda e ainda estar operando dentro das “regras”, como são normalmente indicados. No entanto, no jogo real, um prazo razoável está implícita. Isso não faz parte das regras formais (operacional) do jogo, mas ainda é parte do que regras de jogo chama de “implícito” de regras. O ponto aqui é que há algum tipo de contrato social não escrito que os jogadores fazem ao jogar um jogo, e estes são entendidos, mesmo quando não declarado.

Mesmo dentro das regras formais, há duas camadas. O tabuleiro de 3 × 3, o “X ” e o “O” são símbolos específicos para o “sabor” do jogo, mas você pode tira-los. Reformulando os locais do tabuleiro como os números de 1 a 9 e realizando um alinhamento espacial em uma propriedade matemática, pode chegar até “três para quinze”. Enquanto o Jogo da Velha e “três para quinze” possuem implementações diferentes e aparências, as regras abstratas são as mesmas. Nós normalmente não pensamos nesses termos abstratos, quando pensamos em “regras”, mas eles ainda estão lá, sob a superfície. “Rules of Play” os chama de regras  “constitutivas”.

É útil fazer a distinção entre esses três tipos de regras? Eu acho que é importante estar ciente delas por duas razões:

  • A distinção entre regras “operacional” e “constitutiva” nos ajuda a entender por que um jogo é divertido, em relação a outros jogos. O clássico jogo de arcade Gauntlet tem uma jogabilidade muito semelhante ao tiro em primeira pessoa DOOM, a maior diferença é a posição da câmera. Para aqueles de vocês que jogam jogos de tabuleiro modernos, uma declaração similar é que Porto Rico é muito semelhante à Race for the Galaxy. A semelhança pode não ser imediatamente aparente porque os jogos são tão diferentes na superfície, a menos que você está pensando em termos de estados de jogo e regras.
  • Muitos jogos de tiro em primeira pessoa contém uma regra que, quando um jogador é morto, eles voltem a aparecer (“respawn”) em um local específico conhecido. Outro jogador pode ficar perto desse local e matar qualquer um que respawns antes que eles tenham a chance de reagir. Isso é conhecido como “spawn-camping” e pode ser bastante irritante para alguém que recebe. O spawn-camping faz parte do jogo (uma vez que é permitido pelas regras)? É boa estratégia, ou é trapaça? Isso depende de quem você perguntar, porque é parte das regras “implícitas” do jogo. Quando dois jogadores estão operando sob diferentes regras implícitas, você acabará por chegar um jogador acusando o outro de trapaça enquanto o outro jogador vai ficar na defensiva e dizer que eles estão jogando pelas regras, e não há motivo para que eles próprios jogarem com desvantagem quando eles estão jogando para ganhar. A lição aqui é que é importante para o designer do jogo para definir quantas dessas regras for possível, para evitar discussões de regras durante o jogo.

Recursos e gerenciamento de recursos

“Recursos” é uma categoria ampla e eu uso para significar tudo o que está sob o controle de um único jogador. Obviamente, isso inclui recursos explícitos (Madeira e Trigo no Settlers of Catan; saúde, mana e dinheiro no World of Warcraft), mas isso também pode incluir outras coisas sob controle do jogador:

  • Territórios no Risk (War)
  • Número de questões remanscentes no Twenty Questions
  • Objetos que podem ser pegos em videogames (armas, power-ups)
  • Tempo (tempo de jogo, tempo real, ambos)
  • Informações conhecidas (como os suspeitos que você eliminou em Clue)

Que tipo de recursos o jogador controla? Como esses recursos são manipulados durante a partida? Isso é algo que o game designer deve definir explicitamente.

Estado do jogo – Game State

Alguns “recursos” não são propriedade de um jogador, mas são apenas partes do jogo: Propriedades que não são de ninguém no Monopoly, as cartas comuns no Texas Hold’em. Tudo que for do jogo, junto, incluindo os recursos na posse de um jogador e tudo mais que representa o jogo em um ponto do tempo é chamado de “game state” – Estado do jogo.

Em jogos de tabuleiro, definir explicitamente um game state não é sempre necessário, mas algumas vezes ajuda para se pensar a respeito. Afinal de contas, quais são as regras pelo qual o jogo passa de um game state para outro?

Em videogames alguém tem que definir o estado do jogo, porque isso inclui todos os dados que o computador deve acompanhar. Normalmente, esta tarefa cabe a um programador, mas se o game designer pode definir explicitamente o game state do jogo e pode ser de grande ajuda na compreensão do jogo pela equipe de programação.

Informação

Quanto do estado do jogo é visível a cada jogador? Alterar a quantidade de informações disponíveis para os jogadores tem um efeito drástico sobre o jogo, mesmo se todos os outros elementos formais permanecem os mesmos. Alguns exemplos de estruturas de informação de jogos:

  • Alguns jogos oferecem total informação sobre o jogo, onde todos os jogadores veem completamente o estado do jogo (game state) o tempo inteiro. Xadres e Go Sào exemplos clássicos de jogos de tabuleiro.
  • Os jogos podem incluir algumas informações que são privadas de cada indivíduo. Pense no Poker e outros jogos de cartas onde cada jogador tem uma mão de cartas que só eles podem ver.
  • Um jogador pode ter suas próprias informações privilegiadas, enquanto os outros jogadores não. Isso é comum nas estruturas de um jogador-contra-muitos, como o Interpol.
  • O jogo em si pode conter informações que está escondida de todos os jogadores. Jogos como o Detetive(Clue) possuem condição de vitória quando um jogador descobre esta informação escondida.
  • Essas estruturas podem ser combinadas. Muitos jogos de “estratégia em tempo real” nos computadores usam o que é chamado de “névoa da guerra”(fog of war), onde certas partes do mapa são escondidos a qualquer jogador que não tem uma unidade no seu campo de visão. Algumas das informações são, portanto, escondidas de todos os jogadores. Além disso, os jogadores não podem ver uns as telas dos outros, de modo que cada jogador tem conhecimento não tem como saber da informação que está ou não disponível para os seus adversários.

Sequenciamento

Em que ordem os jogadores tomam suas ações? Como ocorre o fluxo de execução de uma ação para outra? Os jogos podem funcionar de forma diferente dependendo da estrutura vez que é usado:

  • Alguns jogos são por turnos, na essência: Num determinado momento é a vez (turn) de um jogador, onde ele pode executar suas ações. Quando ele termina, o turno passa ao jogador seguinte. A maioria dos jogos de tabuleiro clássicos e jogos de estratégia por turnos funcionam dessa maneira.
  • Outros jogos São baseados em turnos, mas com jogadas simultâneas (todos possuem a vez de jogar ao mesmo tempo, frequentemente escrevendo suas ações ou jogando uma carta de ação com a face virada para baixo, revelando suas ações todos ao mesmo tempo). O jogo de tabuleiro Diplomacia funciona dessa forma. Existe também uma interessante variante do xadrez, onde os jogadores escrevem suas ações e simultaneamente decidem as ações (duas peças que entram no mesmo espaço no tabuleiro  são ambas capturadas) o que adiciona tensão ao jogo.
  • Existem ainda jogos em “tempo real” onde as ações são tomadas o mais rápido que os jogadores podem fazê-lo. A maioria dos jogos de videogame estão nessa categoria, mas mesmo alguns jogos não digitais (como os card games “Spit” ou o “Speed”) funcionam dessa forma.
  • Existem variações: Em um jogo baseado em turnos, qual a ordem que os jogadores jogam? Obter a vez no sentido horário é comum. Obter a vez no sentido horário e então pular o primeiro jogador (para reduzir a vantagem do primeiro jogador) é uma modificação  encontrada em muitos jogos de tabuleiro modernos. Existem jogos onde o turno (vez) é aleatório a cada rodada, ou onde os jogadores pagam recursos do jogo para obterem o privilégio de jogarem primeiro (ou por último) ou ainda, onde a ordem do turno é determinada pela situação do jogador (jogadores que estão ganhando vão primeiro ou por último).
  • Jogos baseados em turnos podem ainda serem modificados adicionando um limite de tempo explícito ou outra forma de pressão por tempo.

Interação dos jogadores (Player Interaction)

Esse é um aspecto frequentemente negligenciado e muito importante a ser considerado: Como os jogadores interagem uns com os outros? Como eles influenciam uns aos outros? Algusn exemplos de interações:

  • Conflito direto (“Eu ataco você”)
  • Negociação (“Se você me apoiar para adentrar no mar negro, eu o apoiarei para conseguir o Cairo no próximo turno”)
  • Comércio (“Eu te dou madeira em troca de lã)”
  • Compartilhamento de informações (“Eu olhei o tile no último turno e te digo que se você entrar ai, cairá em uma armadilha”)

Tema (ou narrativa, “backstory”[ii] ou posicionamento)

Estes termos têm significados distintos para as pessoas que são escritores profissionais, mas para os nossos propósitos são utilizados indiferentemente para designar as partes do jogo que não afetam diretamente a jogabilidade de nenhuma forma.

Se isso não importa em termos de jogabilidade, por que se preocupar com isto? Há duas razões principais. Primeiro, o posicionamento fornece uma conexão emocional com o jogo. Acho realmente difícil se importar com os peões no tabuleiro de xadrez da mesma forma que  eu me preocupo com a meu personagem de Dungeons & Dragons. E enquanto isso não significa necessariamente fazer um jogo “melhor” do que outro, ele torna mais fácil para um jogador se tornar emocionalmente envolvido no jogo.

A outra razão é que um tema bem escolhido pode fazer um jogo mais fácil de aprender e fácil de jogar, pois as regras fazem sentido. As regras de movimento no Xadrez não têm relação com o tema e devem ser memorizadas por alguém aprendendo a jogar. Por outro lado, os papéis no jogo de Porto Rico têm alguma relação com sua função de jogo: o construtor permite construir edifícios, o prefeito recruta novos colonos, o capitão envia produtos para o Velho Mundo, e assim por diante. É fácil de lembrar o que a maioria das ações realizam no jogo, porque eles possuem alguma relação com o tema do jogo.

Jogo como um sistema

Eu gostaria de chamar a atenção duas coisas sobre estes elementos formais :

Primeiro, se você mudar um único elemento formal, ele pode tornar um jogo muito diferente. Cada elemento formal de um jogo contribui de uma forma profunda com a experiência do jogador. Ao projetar um jogo, reflita sobre cada um desses elementos, e certifique-se que cada um é uma escolha deliberada.

Segundo, perceba que estes elementos estão inter-relacionados, e mudando um pode afetar outros. Regras governam as mudanças no Estado do Jogo (game state). Informações podem às vezes se tornam um recurso. O seqüenciamento pode levar a diferentes tipos de interação entre os jogadores. Alterar o número de jogadores pode alterar os tipos de objetivos que podem ser definidos e assim por diante.

Devido à natureza interrelacionada destas partes, você pode enquadrar qualquer jogo como um sistema. (Uma definição do dicionário da palavra “sistema” é “uma combinação de coisas ou partes que formam um todo complexo)

Na verdade, um único jogo pode conter vários sistemas. World of Warcraft tem um sistema de combate, um sistema de busca, um sistema de guildas, um sistema de chat, e assim por diante…

Uma outra propriedade dos sistemas é que é difícil compreender completamente apenas definindo-os; você ganha uma compreensão muito mais profunda vendo o sistema em ação. Considere o sistema físico de movimento de projétil. Eu posso dar uma equação matemática para definir o caminho de uma bola sendo lançada, e você pode até mesmo prever o seu comportamento … mas a coisa toda faz muito mais sentido se você ver alguém realmente jogar uma bola.

Jogos são assim também. Você pode ler as regras e definir todos os elementos formais de um jogo, mas para entender verdadeiramente um jogo, você precisa jogar. É por isso que a maioria das pessoas não vê imediatamente o paralelo entre o Jogo da Velha e o “três para as quinze” até que eles tenham jogado.

Analise critica de jogos

O que é uma análise crítica e porque nos importamos com isso?

Análise crítica não é apenas um review (análise, descrição) de jogo. Não estamos preocupados com quantas estrelas de um total de 5, ou com alguma nota de 0 a 10, ou se um jogo é ou não “divertido” (seja lá o que iso quer dizer) ou ainda a auxiliar na decisão de  um consumidor se ele deve ou não comprar um jogo.

Análise crítica não significa apenas uma lista de coisas que estão erradas no jogo. A palavra “crítica”, neste contexto, não significa “encontrar uma falha”, mas sim um olhar aprofundado e imparcial no jogo.

A análise crítica é útil quando discutimos ou comparamos jogos. Você pode dizer “eu gosto do jogo de cartas Bang! porque é divertido”, mas isso não nos ajuda, como designers, a aprender o porque é divertido. Temos de olhar para as partes do jogo e verificar como eles interagem, a fim de compreender como cada parte se relaciona com a experiência de jogar.

Análise crítica também é útil quando analisar as nossas próprias obras em andamento. Para um jogo que você está trabalhando, como você sabe o que adicionar ou remover para torná-lo melhor?

Há muitas maneiras de analisar criticamente uma partida. Ofereço um processo de três etapas:

1. Descrever os elementos formais do jogo. Não interpretar a este ponto, basta indicar o que está lá.

2. Descrever os resultados dos elementos formais, quando colocados em movimento. Como os diferentes elementos interagem? Como a jogada se parece? É eficaz?

3. Tente entender porque o designer optou por esses elementos e não outros. Por que essa estrutura de jogadores em particular e por que esse conjunto de recursos? O que teria acontecido se o criador tivesse escolhido de forma diferente?

Algumas questões para se perguntar durante a análise crítica do jogo em diversos estágios:

  • Quais os desafios que o jogador enfrenta? Quais ações os jogadores podem realizar para superá-los?
  • Como os jogadores afetam uns aos outros?
  • O jogo é percebido como “justo” pelos jogadores? (Perceba que ele pode ser ou não justo. Percepção e realidade frequentemente são diferentes)
  • O jogo é “rejogável”? Existem muitos caminhos para a vitória, posições iniciais diversificadas ou regras opcionais que permitem a experiência de jogo ser diferente a cada partida?
  • Qual o público alvo do jogo? O jogo é apropriado para essa audiência?
  • Qual é o “núcleo” do jogo? A coisa que você faz e repete que representa a principal parte “divertida” do jogo?

Lições aprendidas

Cobrimos muito conteúdo hoje. Os principais pontos foram:

  • Jogos são sistemas
  • Compreender um jogo é muito mais fácil se você jogá-lo.
  • Análisar um jogo requer um olhar para todos os elementos que o compõe e imaginar como eles encaixam uns nos outros, e qual a experiência surge deles.
  • Desenvolver um jogo requer a criação de todas as partes do jogo. Se você não definiu os elementos formais do seu jogo de alguma forma, então na verdade você não possui um jogo, você apenas semeou uma idéia. Isso é bom, mas o que você precisa na verdade é desenvolvê-lo.

Homeplay

Me foi alertado que tenho utilizado a palavra “homeplay”para se referir à leitura, e que a leitura não é brincadeira, não importa como eu caracterizar isso. Essa crítica é válida: normalmente em cursos de minha sala de aula eu uso “homeplay” para se referir às atribuições de design e não leituras, e eu misturei os termos aqui em cima. Vou fazer uma tentativa para evitar essa confusão, no futuro, porque acredito que a tentativa de tratar a aprendizagem como uma atividade inerentemente não-divertida (como evidenciado pela necessidade de usar palavras que soam divertidas, para descrevê-lo) é prejudicial para o nosso bem-estar colectivo ao longo prazo. Como veremos quando chegarmos na teoria do fluxo, a realidade é o oposto.

Dito isso, aqui está uma atividade que eu espero que você encontre diversão. Baseia-se no Desafio 2-5 nono texto Challenges, com algumas pequenas alterações apenas para mantê-lo em suas mãos.

Veja como ele funciona. Primeiro, escolha o nível de dificuldade com base na sua experiência anterior com o design do jogo. “Esquiadores” podem achar isso familiar:

Aqui está o desafio:

Muitos jogos com temática de guerra tem por objetivo o controle territorial ou capturar e destruir (como descrito anteriormente). Para esse desafio, você será forçado a ir além dessas fronteiras tradicionais. Você deve desenvolver um jogo não-digital que inclui o seguinte:

O tema precisa estar relacionado a Primeira Guerra Mundial. O objetivo primário dos jogadores não pode ser controle territorial ou capturar/destruir.

Você não pode usar controle territorial ou capturar/destruir como dinâmica do jogo. É isso mesmo: No seu jogo não é permitido conter nenhum conceito de território ou morte de qualquer forma.

O mesmo que o anterior, mas os jogadores não podem se enfrentar em um conflito direto, somente indireto.

Eu criei 3 novas áreas nos foruns (um para cada nivel de jogo). Você deveria colocar suas regras de jogo nesse forum (o curso não está mais em andamento, de modo que somente é possível navegar pelas regras criadas – em ingles)

Então, quando você postar, leia pelo menos dois outros posts no seu nivel de dificuldade e ofereça uma análise construtiva e crítica. Se você está na dificuldade com o quadrado azul ou com o diamante marrom, leia ao menos dois outros posts imediatamente abaixo do seu e ofereça sua experiência para quem você pode ajudar. Tente encontrar posts que ainda não possuem respostas de modo que todos podem conseguir algum tipo de feedback.

Uma nota sobre pesquisas…

Perceba que você pode ter que fazer algumas pesquisas reais para a conclusão deste projeto (mesmo que só olhando para a Wikipédia em busca de inspiração). Isso é típico de game design em campo. Muitos iniciantes imaginam designers de jogos como essas pessoas que simplesmente sentam e pensam em sua mesa o dia todo e então, eventualmente, levantam e proclamam: “Eu tenho uma grande idéia para um jogo! Ninjas … e lasers … no espaço! Vá construí-lo, meu exército de lacaios (programadores e artistas). Eu devo sentar aqui agora até eu aparecer com outra grande idéia, ao coletar royalties de minhas últimas cinco idéias”. Isso não é nem perto da realidade. Uma grande parte do design são os detalhes: a definição das regras, certamente, mas também fazer a pesquisa para se certificar de que as regras se encaixam as restrições e são adequados para o projeto.

Uma nota sobre Propriedade Intelectual…

Neste ponto, alguns de vocês podem estar pensando que, colocando o seu jogo para o fórum, você corre o risco de que alguém vai roubar a sua Grande Idéia. Como você pode se proteger contra a ameaça de alguém que toma a sua ideia de base, transformando-o em um trabalho, jogo vendáveis​​, e deixando você sem nada?

Um dos participantes deste curso, Dan Rosenthal, gentilmente escreveu um artigo que detalha os conceitos básicos de PI (propriedade intelectual) na lei no que se refere aos jogos. O artigo admite ter como foco os EUA, mas a idéia central (o que vale a pena repetir aqui) deve ser boa, não importa onde você está:

Lembre-se, ideias não são protegidos pelos direitos de autor, eles não são registraveis, não são segredo de comércio, e ao mesmo tempo difícil e extremamente caro e proibitivo o uso de patentes. Você não pode protegê-los de qualquer maneira, e você não deveria tentar – em vez disso, você deve tentar conseguir novas idéias, e começar a trabalhar sobre as boas. Não se apavore quando vê as coisas como GameJams, ou este curso e pensar “Ian diz que eu devo postar meus trabalhos para o fórum de discussão, mas eu vim com uma Grande Idéia ™ e eu não quero que outras pessoas a roube”. Ideias são comuns em jogos, e o valor de sua idéia não é nada comparado ao valor da execução dessa idéia, sua experiência e trabalho duro em desenvolvê-lo em algo que vai lhe fazer o dinheiro real. Mas o mais importante, a nossa indústria é muito lateral, muito unida, muito colaborativa. Você vai encontrar pessoas que partilham as suas ideias na GDC, fazendo projetos de colaborativo entre os estúdios, ou usando a inspiração de uma mecânica de jogo para melhorar a outra. Não lute contra isso. Essa é a maneira como as coisas funcionam, e, abraçando aquela atmosfera aberta, você estará muito melhor.


[i] O jogo (e o texto) original se refere ao jogo Scotland Yard. No Brasil, ele recebeu o nome de Interpol. Scotland Yard também existe no Brasil, mas é um jogo completamente diferente. Preferi alterar o texto para o nome conhecido no Brasil para não ter confusões.

[ii] O termo “backstory” se refere a acontecimentos pretéritos em uma história. Não encontrei uma boa tradução ao termo que definisse o termo na mesma idéia o termos. Me foi sugerido o termo “antecedentes”. Preferi manter o termo original.

Game Design Concepts – Level 2: Game Design/Interação e prototipagem rápida

Game Concept Design - Banner

Level 2: Game Design / Interação e prototipagem rápida

Por Ian Schreiber (http://gamedesignconcepts.wordpress.com/)

Tradução de Bruno Salvatore Drago (www.xuti.net) – Original em http://gamedesignconcepts.wordpress.com/2009/07/02/level-2-game-design-iteration-and-rapid-prototyping/(Acesso em 28.08.2009)

Em nosso último encontro nós respondemos a seguinte questão: “O que é um jogo?”. Hoje, veremos uma questão relacionada a esta: “O que é, exatamente, game design?”. Em nosso último encontro fizemos um jogo simples. Dessa vez, olharemos o processo de como os jogos são feitos, de forma geral. Ainda que seja possível fazer um jogo de tabuleiro no estilo “corrida até o final” em 15 minutos, você precisará um pouco mais do que isso se você procura fazer o próximo “Settlers of Catan”[1] ou “World of Warcraft”.

Game Design

Neste curso, usaremos muito a palavra “design”. Infelizmente, esse é um termo muito utilizado, então eu esclarecerei o que quero dizer aqui. Conforme colocado no livro “Challenges”, game design é a criação de regras e conteúdo para um jogo. Não envolve programação, arte, animação, marketing ou qualquer outra tarefa necessária para se fazer um jogo. Todas essas tarefas juntas podem ser chamadas de “desenvolvimento de jogo” (Game Development) e o game design é uma parte do desenvolvimento.

Infelizmente, tenho visto o termo “design” usado (particularmente em alguns currículos de faculdades) para se referir a todos os aspectos do desenvolvimento de jogos. Quando utilizado na indústria de jogos eletrônicos (ou na indústria de jogos de tabuleiro), “game design” possui um significado bem específico, e esse é o sentido que usaremos durante este curso.

Diversos tipos de Game Design

Conforme mencionado no livro “Challenges”, existem muitas tarefas associadas ao game design: design de sistemas (system design), design de fases (level design), design de conteúdo (content design), design de interface com o usuário (user interface design), design de mundos (world building) e desenvolvimento de história. Poderíamos preencher muitos cursos com qualquer um desses tópicos, então este curso não abrangerá todo o espectro do design de jogos (game design). Abordaremos brevemente o design de interface com o usuário (user interface design – UI), desenvolvimentro de história e conteúdo, quando for relevante, mas a maior parte deste curso tem foco em design de sistema (system design, também chamado em inglês de “systems design” ou “core systems design”).

O design de sistema trata de definir as regras básicas de um jogo. Quais são as peças do jogo? Quais você pode controlar? Quais ações você pode tomar no seu turno (se existirem “turnos”)? O que acontece quando você toma uma ação e como isso afeta a situação do jogo? De forma geral, o design de sistema é a criação de três coisas:

  • Regras de configuração: Como o jogo começa?
  • Regras de progresso do jogo: Uma vez que o jogo é iniciado, o que os jogadores podem fazer e o que acontece quando eles fazem algo?
  • Regras de resolução: O que, se alguma coisa, causa o final do jogo? Se o jogo possui um resultado (como ganhador ou perdedor), como esse resultado é determinado?

Se você voltar e ver novamente o jogo “três para as quinze” perceberá que o jogo contém todas essas três partes. A criação dessas regras é o design de sistema, e é o que gastaremos a maior parte de nosso tempo nesse curso.

O que é um Game Designer?

Como você deve ter notado, o design de jogos é um campo incrivelmente amplo. Aqueles que são designers profissionais algumas vezes possuem dificuldade em explicar o que fazemos para nossas famílias e amigos. Em parte, a razão para isso é que nós fazemos muitas coisas. Aqui estão algumas analogias que tenho visto quando tentam explicar o que é um game designer:

  • Game designers são como artistas. O termo “arte” é tão difícil de definir quanto a palavra “jogo”. Mas se jogos podem ser uma forma de arte (como vimos na definição de Costikyan, pelo menos), então designer poderiam ser artistas.
  • Game designers são arquitetos. Arquitetos não constroem a estrtura física; eles criam as plantas. Designers de jogos eletrônicos também criam “plantas”, que são referenciados como “documento de design”(design doc). Designers de jogos de tabuleiro também criam “plantas” – na forma de protótipos – que em seguida são produzidos pelos editores (publishers)[2].
  • Game designers são anfitriões de festa. Como designers, nós convidamos os jogadores para o nosso espaço e fazemos o nosso melhor para que tenham um momento agradável.
  • Game designer são pesquisadores. Como veremos adiante, criamos jogos de uma forma que se assemelha muito com o método científico.
  • Game desiners são deuses. Nós criamos mundos e criamos as regras físicas que governam esses mundos.
  • Game designers são advogados. Nós criamos um conjunto de regras que outros devem seguir.
  • Game designers são educadores. Como veremos mais tarde quando começarmos a ler “Theory of Fun”, entretenimento e educação são fortemente ligados, e jogos são (ao menos algumas vezes) divertidos porque envolvem aprender novas habilidades.

Se os designers de jogos (game designer) são todas essas coisas, onde se enquadraria no currículo de uma faculdade? Game design poderia se justificar no curso de pedagogia, arte, arquitetura, teologia, direito, engenharia, ciências aplicadas e mais uma série de outras áreas.

O game designer é todas essas coisas? Nenhuma delas? A discussão está aberta, mas penso que o game design possui elementos comuns a muitos outros campos, mas ainda assim possui seu próprio campo. Você pode ver o quanto amplo é esse campo. Conforme o campo do game design avança, podemos ver o dia em que os game designers serão tão especializados que o “game design” será como o campo da “ciência” – estudantes terão que escolher uma especialidade (Química, biologia, física, etc) ao invés de apenas uma “ciência”.

Falando em ciência…

Como um jogo é concebido, criado? Existem muitos métodos.

Historicamente, a primeira metodologia de design foi conhecida como “Modelo em Cascata” (waterfall method): Primeiro você projeta o jogo inteiro no papel. Em seguida, você implementa (programando um jogo eletrônico, ou criando o tabuleiro e as peças para um jogo não-digital); O próximo passo é testar o jogo para ter certeza que as regras funcionam de forma correta. Adiciona alguns gráficos e dá um tratamento para o jogo ficar agradável visualmente e então você poderá enviar o jogo (ao editor, a seus clientes, etc).

Modelo Cascata – “Waterfall”

 

O “Modelo em Cascata” leva esse nome, pois, da mesma maneira que uma queda d’água, você pode mover-se apenas em uma direção. Se você estiver ocupado fazendo a arte final para o seu jogo e você perceber que uma das regras deve ser alterada, será uma pena. Essa metodologia não inclui uma forma de voltar uma etapa no design uma vez que ele esteja pronto.

Em algum momento, alguém percebeu que poderia ser uma boa idéia ter a opção de voltar atrás e arrumar as coisas nos primeiros passos de desenvolvimento do jogo, e criou o que algumas vezes é conhecido como abordagem iterativa. Da mesma forma que o “Modelo em Cascata”, você primeiramente faz o design do jogo. Em seguida, faz a implementação do jogo e tem certeza que funciona. Mas após este passo, colocamos um passo extra para avaliar o jogo. Jogue-o, decida o que é bom e o que precisa ser mudado. E então tome a decisão: você já terminou ou você deve voltar ao passo do design do jogo e fazer algumas mudanças? Se você decidir que o jogo é bom o suficiente, que asism seja. Mas se você identificar a necessidade de realizar mudanças, você deve voltar ao passo do design de jogo e encontrar formas de abordar os problemas identificados, implementar essas mudanças,e então avaliar o jogo novamente. Continue fazendo isso até que o jogo esteja pronto.

Método Iterativo – Método Cientifico

Se isso lhe parece familiar, é porque isso é mais ou menos o “Método Científico”:

  1. Faça uma observação (“Minha experiência jogando/fazendo jogos me mostrou que certos tipos de mecânicas são divertidos”).
  2. Faça uma hipótese (“O conjunto de regras que eu estou escrevendo fará um jogo divertido”).
  3. Crie um experimento que prove ou contrarie sua hipótese (“Organizar um playtest desse jogo para verificar se o jogo é ou não divertido”).
  4. Execute o experimento (“Jogue!”).
  5. Interprete os resultados do experimento, formando um novo conjunto de observações. Volte ao primeiro passo.

Com jogos não-digitais (cartas e tabuleiro) esse processo funciona bem porque pode ser feito rapidamente. Com jogos eletrônicos (videogames) existe um problema: A implementação (ou seja, programação e depuração) é cara e demanda grande tempo. Se você leva 18 meses para programar um jogo pela primeira vez e você possui apenas dois anos para finalizá-lo, você não terá tempo para realizar o playtest e modificar o jogo.

De maneira geral, quanto mais vezes você iterar, melhor será o jogo.

Portanto, qualquer processo de design de jogo deve envolver iteração (ou seja, passar por todo o processo de design, implementação e avaliação) tanto quanto possível, e qualquer coisa que você puder fazer para iterar rapidamente normalmente o levará a um jogo melhor como resultado final. Por essa razão, designers de jogos eletrônicos (videogames) frequentemente fazem protótipos em papel e somentem envolvem os programadores quando eles estão suficientemente convencidos que o conjunto central de regras é divertido. Nós chamamos isso de prototipação rápida.

Iteração com prototipagem rápida - Video Games
Iteração com prototipagem rápida – Video Games

Iteração e Risco

Jogos possuem deversos tipos de risco associados a eles. O risco de design é o risco do jogo que não é divertido e as pessoas não gotam dele. O risco de implementação é a possibilidade que o time de desenvolvimento possui de não ser capaz de implementar o jogo, mesmo com regras sólidas. O risco de mercado é a chance que o jogo seja maravilhoso e mesmo asism ninuém irá comprá-lo.

O propósito da iteração é diminuir o risco de design. Quanto mis vezes você iterar, mais você terá certeza que as regras serão eficientes.

Tudo isso se resume em uma só coisa: Quanto maior o risco de design de seu jogo (ou seja, se as regras não foram testadas e avaliadas), mais você precisa de iteração. O método iterativo não é essencial para jogos onde a mecânica é em grande parte obtida de um outro jogo de sucesso. Sequencias e conjunto de expanções de jogos populares são exemplos de situações onde a abordagem pelo “Método em Cascata” funciona bem.

Isto posto, a maioria dos designers de jogos possuem aspirações de fazer jogos que são novos, criativos e inovativos.

Porque este curso é não-digital?

Alguns de vocês vão fazer jogos de tabuleiro de qualquer forma e não se importam como jogos eletrônicos (videogames) são feitos. Mas para vocês que adoram jogos eletrônicos, devem estar imaginando porque gastar tempo fazendo jogos de cartas e de tabuleiro neste curso. Agora você sabe: É porque iteração é mais rápido e barato com papelão. Lembre-se da última aula: Você pode fazer um tabuleiro em 15 minutos. Programar um jogo demanda significativamente mais tempo. Quando possível, faça o protótipo em papel primeiro, pois o protótipo de 15 minutos e uma sessão de uma hora de playtest pode economizar meses de trabalho de programação.

Mais tarde neste curso vamos discutir em detalhes os métodos de prototipação em papel, tanto para os tradicionais jogos de tabuleiro quanto para vários tipos de jogos eletrônicos.

Existe ainda outra razão pela qual nos concentraremos principalmente em jogos não-digitais, em especial jogos de tabuleiro e cartas. Esse é um curso de design de sistema, ou seja, criação de regras de um jogo. Em jogos de tabuleiro as regras são expostas. Pode haver alguns componentes físicos, claro, mas a experiência de jogo é quase que inteiramente determinada pelas regras e interação entre os jogadores. Se as regras não forem convincentes, o jogo não será divertido, então, trabalhar nesse meio estabelece mais claramente uma conexão entre as regras e a experiência do jogador.

Isso não é verdade em jogos eletrônicos. Muitos videogames possuem uma tecnologia impressionante (como sistmas de física realistas), gráficos e sons, que podem ofuscar o fato que a jogabilidade é entediante. Jogos eletrônicos levam muito tempo para serem feitos (em razão da programação e criação da arte e áudio), tornando-os uma escolha impraticável para um curso de 10 semanas.

A conexão entre regras e a experiência dos jogodores também é abafada por RPG de mesa. Sei que muitos de vocês têm manifestado especial interesse no design de RPG e isso pode parecer estranho para vocês. No entanto, tenha em mente que RPG é essencialmente um jogo de “contar-histórias” colaborativo (onde o sistema de regras estabelecerá os limites do que pode ou não acontecer). Dessa forma, um sistema maravilhoso pode ser arruinado por jogadores pouco experientes e um sistema fraco pode ser salvo por jogadores mais habilidosos. Desta forma, nos manteremos longe desses gêneros de jogos ao menos nas etapas iniciais.

Provando se funciona

Pegue o jogo de 15 minutos que você fez e jogue-o se você ainda não o fez. Enquanto você joga, pergunte para você mesmo: Isso é mais ou menos divertido que o seu jogo favorito? Por quê? O que você poderia mudar no jogo para torná-lo melhor? Você não precisa jogar o jogo até o final, somente tempo o suficiente para ter uma sensação geral de como é jogá-lo.

Após jogar uma vez, faça ao menos uma mudança. Talvez você mudará as regras de movimento, ou acrescentar uma nova forma dos jogadores interagirem. Talvez mudará alguns espaços no tabuleiro. O que quer que você faça, por qualquer razão, faça a mudança e então jogue novamente. Perceba as diferenças. As mudanças tornaram o jogo melhor ou pior? Essa mudança fez você pensar em mudanças adicionais que você pode fazer? Se o jogo ficou pior, você vai apenas voltar as regras a situação anterior ou você poderia mudar as regras de uma maneira diferente?

Veremos o processo de playtest em detalhes adiante nesse curso. No momento, quero apenas que todos superem o medo “E se eu jogar o meu jogo e ele for terrível?”. Com o jogo que você fez o design na ultima parte deste curso, as chances do seu jogo ser péssimo são bem altas (sério: você espera fazer o próximo Gears of Wars em 15 minutos?). Isso não faz de você um designer ruim de forma alguma – mas isso deve tornar claro para você que quanto mais tempo você colocar em um jogo e quanto mais iterações você fizer, melhor ele se torna.

Lições Aprendidas

A grande sacada de hoje é que quanto mais você iterar o jogo, melhor ele se torna. Grandes designers não fazem o design de grandes jogos. Eles geralmente fazem um design de jogo ruim e iteragem o jogo até que ele se torne um grande jogo.

Disso decorrem 2 coisas:

  • Você deseja um protótipo jogável no desenvolvimento do jogo tão cedo quanto possível. Quanto mais rápido você fizer o playtest de suas idéias, mais tempo você terá para realizar mudanças.
  • Dada iguais quantidade de tempo, um jogo mais curto e simples dará uma melhor experiência que um jogo longo e complicado. Um jogo que lva horas para terminar dará apenas algumas iterações do que um jogo que pode ser jogado em cinco minutos. Quando começarmos o Projeto de Design adiante neste curso, mantenha isso em mente.

Homeplay

Antes da próxima aula, leia os seguintes textos. Farei referência a eles na próxima aula quando falarmos de elementos formais dos jogos:

“Challenges for Game Designers”, Capítulo 2 (Atoms). Este capítulo é uma ligação entre a última aula, onde falamos sobre vocabulário critic e a próxima aula, quando começaremos a desmontar o conceito de “jogo” em suas partes componentes.

Formal Abstract Design Tools, por Doug Church. Esse artigo baseia-se no texto de Costikyan’s / Have No Words, oferecendo algumas ferramentas adicionais pela qual podemos analisar e fazer o design de jogos. Enquanto ele usa muitos exemplos de jogos eletronicos, pense como os conceitos principais do artigo podem ser aplicados a outros tipos de jogos.


[1] No Brasil e em Portugal, o jogo de tabuleiro pode ser encontrado na livraria Devir (www.devir.com.br ou www.devir.pt), em português, sob o nome “Descobridores de Catan”. Mais informações sobre o jogo na Wikipédia. Em Janeiro de 2011, o jogo foi anunciado pela empresa Grow como “Colonizadores de Catan”.

[2] Publisher em inglês significa editor, que pode ser no sentido de empresa, ou seja, quem edita algo, ou o editor, como em jornais, que é quem define o que será ou não publicado. Jogos de tabuleiro – e jogos eletrônicos e software em geral – geralmente possuem a mesma terminologia da indústria gráfica. Preferi manter a tradução literal, mantendo a tradução do original.

Level 2: Game Design / Interação e prototipagem rápida

Por Ian Schreiber (http://gamedesignconcepts.wordpress.com/)

Tradução de Bruno Salvatore Drago (www.xuti.net) – Original em http://gamedesignconcepts.wordpress.com/2009/07/02/level-2-game-design-iteration-and-rapid-prototyping/(Acesso em 28.08.2009)

Em nosso último encontro nós respondemos a seguinte questão: “O que é um jogo?”. Hoje, veremos uma questão relacionada a esta: “O que é, exatamente, game design?”. Em nosso último encontro fizemos um jogo simples. Dessa vez, olharemos o processo de como os jogos são feitos, de forma geral. Ainda que seja possível fazer um jogo de tabuleiro no estilo “corrida até o final” em 15 minutos, você precisará um pouco mais do que isso se você procura fazer o próximo “Settlers of Catan”[1] ou “World of Warcraft”.

Game Design

Neste curso, usaremos muito a palavra “design”. Infelizmente, esse é um termo muito utilizado, então eu esclarecerei o que quero dizer aqui. Conforme colocado no livro “Challenges”, game design é a criação de regras e conteúdo para um jogo. Não envolve programação, arte, animação, marketing ou qualquer outra tarefa necessária para se fazer um jogo. Todas essas tarefas juntas podem ser chamadas de “desenvolvimento de jogo” (Game Develpment) e o game design é uma parte do desenvolvimento.

Infelizmente, tenho visto o termo “design” usado (particularmente em alguns currículos de faculdades) para se referir a todos os aspectos do desenvolvimento de jogos. Quando utilizado na indústria de jogos eletrônicos (ou na indústria de jogos de tabuleiro), “game design” possui um significado bem específico, e esse é o sentido que usaremos durante este curso.

Diversos tipos de Game Design

Conforme mencionado no livro “Challenges”, existem muitas tarefas associadas ao game design: design de sistemas (system design), design de fases (level design), design de conteúdo (content design), design de interface com o usuário (user interface design), design de mundos (world building) e desenvolvimento de história. Poderíamos preencher muitos cursos com qualquer um desses tópicos, então este curso não abrangerá todo o espectro do design de jogos (game design). Abordaremos brevemente o design de interface com o usuário (user interface design – UI), desenvolvimentro de história e conteúdo, quando for relevante, mas a maior parte deste curso tem foco em design de sistema (system design, também chamado em inglês de “systems design” ou “core systems design”).

O design de sistema trata de definir as regras básicas de um jogo. Quais são as peças do jogo? Quais você pode controlar? Quais ações você pode tomar no seu turno (se existirem “turnos”)? O que acontece quando você toma uma ação e como isso afeta a situação do jogo? De forma geral, o design de sistema é a criação de três coisas:

·Regras de configuração: Como o jogo começa?

·Regras de progresso do jogo: Uma vez que o jogo é iniciado, o que os jogadores podem fazer e o que acontece quando eles fazem algo?

·Regras de resolução: O que, se alguma coisa, causa o final do jogo? Se o jogo possui um resultado (como ganhador ou perdedor), como esse resultado é determinado?

Se você voltar e ver novamente o jogo “três para as quinze” perceberá que o jogo contém todas essas três partes. A criação dessas regras é o design de sistema, e é o que gastaremos a maior parte de nosso tempo nesse curso.

O que é um Game Designer?

Como você deve ter notado, o design de jogos é um campo incrivelmente amplo. Aqueles que são designers profissionais algumas vezes possuem dificuldade em explicar o que fazemos para nossas famílias e amigos. Em parte, a razão para isso é que nós fazemos muitas coisas. Aqui estão algumas analogias que tenho visto quando tentam explicar o que é um game designer:

·Game designers são como artistas. O termo “arte” é tão difícil de definir quanto a palavra “jogo”. Mas se jogos podem ser uma forma de arte (como vimos na definição de Costikyan, pelo menos), então designer poderiam ser artistas.

·Game designers são arquitetos. Arquitetos não constroem a estrtura física; eles criam as plantas. Designers de jogos eletrônicos também criam “plantas”, que são referenciados como “documento de design”(design doc). Designers de jogos de tabuleiro também criam “plantas” – na forma de protótipos – que em seguida são produzidos pelos editores (publishers)[2].

·Game designers são anfitriões de festa. Como designers, nós convidamos os jogadores para o nosso espaço e fazemos o nosso melhor para que tenham um momento agradável.

·Game designer são pesquisadores. Como veremos adiante, criamos jogos de uma forma que se assemelha muito com o método científico.

·Game desiners são deuses. Nós criamos mundos e criamos as regras físicas que governam esses mundos.

·Game designers são advogados. Nós criamos um conjunto de regras que outros devem seguir.

·Game designers são educadores. Como veremos mais tarde quando começarmos a ler “Theory of Fun”, entretenimento e educação são fortemente ligados, e jogos são (ao menos algumas vezes) divertidos porque envolvem aprender novas habilidades.

Se os designers de jogos (game designer) são todas essas coisas, onde se enquadraria no currículo de uma faculdade? Game design poderia se justificar no curso de pedagogia, arte, arquitetura, teologia, direito, engenharia, ciências aplicadas e mais uma série de outras áreas.

O game designer é todas essas coisas? Nenhuma delas? A discussão está aberta, mas penso que o game design possui elementos comuns a muitos outros campos, mas ainda assim possui seu próprio campo. Você pode ver o quanto amplo é esse campo. Conforme o campo do game design avança, podemos ver o dia em que os game designers serão tão especializados que o “game design” será como o campo da “ciência” – estudantes terão que escolher uma especialidade (Química, biologia, física, etc) ao invés de apenas uma “ciência”.

Falando em ciência…

Como um jogo é concebido, criado? Existem muitos métodos.

Historicamente, a primeira metodologia de design foi conhecida como “Modelo em Cascata” (waterfall method): Primeiro você projeta o jogo inteiro no papel. Em seguida, você implementa (programando um jogo eletrônico, ou criando o tabuleiro e as peças para um jogo não-digital); O próximo passo é testar o jogo para ter certeza que as regras funcionam de forma correta. Adiciona alguns gráficos e dá um tratamento para o jogo ficar agradável visualmente e então você poderá enviar o jogo (ao editor, a seus clientes, etc).


[1] No Brasil e em Portugal, o jogo de tabuleiro pode ser encontrado na livraria Devir (www.devir.com.br ou www.devir.pt), em português, sob o nome “Descobridores de Catan”. Mais informações sobre o jogo na Wikipédia.

[2] Publisher em inglês significa editor, que pode ser no sentido de empresa, ou seja, quem edita algo, ou o editor, como em jornais, que é quem define o que será ou não publicado. Jogos de tabuleiro – e jogos eletrônicos e software em geral – geralmente possuem a mesma terminologia da indústria gráfica. Preferi manter a tradução literal, mantendo a tradução do original.

 

Game Design Concepts – Level 1: Panorama/O que é um jogo?

Game Concept Design - Banner

Level 1: Panorama / O que é um jogo?

Por Ian Schreiber (http://gamedesignconcepts.wordpress.com/)

Tradução de Bruno Salvatore Drago (http://www.xuti.net)
Original em http://gamedesignconcepts.wordpress.com/2009/06/29/level-1-overview-what-is-a-game/ (Acesso em 20.07.2009)

Bem vindo ao “Game Design Concepts”! Eu sou Ian Schreiber e eu serei seu guia durante todo esse experimento. Escutei muita empolgação durante todo o processo de registro nos últimos meses, e asseguro que estou tão empolgado (e intimidado) com todo este processo como qualquer outra pessoa. Então me permita dizer que eu aprecio o seu tempo, e eu farei o meu mlehor para fazer com que o tempo que você gastar aqui valha a pena.

Panorama do Curso

Muitos campos de conhecimento possuem centenas de anos. O game design está sendo estudado por não muito mais do que dez anos. Nós não temos um grande conjunto de trabalhos para nos debruçarmos, comparado com outras artes e ciências.

Por outro lado, temos sorte. Nos últimos anos nós finalmente alcançamos o que eu vejo como uma massa crítica de escrita conceitual, análise formal e teórica e conhecimento prático para preencher um currículo de uma faculdade… ou ao menos, neste caso, um curso de dez semanas.

Tudo bem, isso não é inteiramente verdade. Atualmente existe uma enorme quantidade de material no campo do game design e muitos livros (com mais livros sendo lançados num ritmo alarmante). Mas a grande maioria deles ou são inúteis, ou possuem uma leitura tão densa que ninguém no ramo se incomoda em ler. As leituras que teremos neste curso são aquelas que, por qualquer razão, permearam a indústria. Muitos designers profissionais já são familiarizados a elas.

Este curso será dividido em duas partes. A primeira metade do curso será centrada nas teorias e conceitos do game design. Aprenderemos o que é um jogo, como quebrar o conceito de jogo em seus componentes e partes, e o que faz um jogo melhor ou pior do que outro.

A segunda metade do curso será centrada no aspecto prático de como criar do nada, um bom jogo, e os processos envolvidos na criação de seus próprios jogos. Ao longo de todo o curso, haverá um número de oportunidades para fazer o seu próprio jogo (todos não-digitais, não é necessária programação de computadores), então você poderá ver como a teoria realmente funciona na prática.

O que é um jogo?

Aqueles que leram um pouco do livro “Challenges” podem pensar que isso é óbvio. Minha definição preferida é uma atividade lúdica com regras que envolvem conflito. Mas a questão “o que é um jogo?” é atualmente ainda mais complexa que isso:

  • Por um lado, essa é a minha definição. Claro, ela foi adotada pelo IGDA Education SIG[1] (principalmente em razão de que ninguém me questionou a respeito disso). Existem muitas outras definições que discordam da minha. Muitas dessas outras definições foram propostas por pessoas com mais experiência em game design do que eu. Então, você não pode pegar essa definição (ou qualquer outra cosia) como garantida, somente porque o “Ian disse que é”.

  • Por outro lado, a definição não nos diz nada sobre como fazer o design de jogos, então nos vamos falar o que um é um jogo em termos de seus componentes e partes: regras, recursos, ações, estória, e assim por diante. Eu chamo essas coisas de “elementos formais” dos jogos, por razões que discutiremos adiante.

Também é importante fazer distinções entre os diferentes tipos de jogos. Considere o jogo Três para as quinze. A maioria de vocês jamais ouviu falar nesse jogo. Ele possui um conjunto de regras bem simples:

  • Jogadores: 2
  • Objetivo: Ficar com um conjunto de números que somados resulte no número 15.
  • Configuração Inicial: Comece escrevendo os números de 1 a 9 em um pedaço de papel. Escolha o jogador que inicia o jogo.
  • Progressão do jogo: Em seu turno, escolha um número que ainda não foi escolhido pelo outro jogador. Agora você controla aquele número. Risque o número da lista de números disponíveis e escreva o número do seu lado do papel para mostrar que ele é seu.
  • Fim de jogo: se um jogador ficar com um conjunto de exatamente três números onde a soma é exatamente 15, o jogo acaba, e esse jogador vence. Se todos os nove números forem escritos e nenhum jogador ganhou, o jogo teve um empate.

Vá em frente e jogue este jogo, contra você mesmo ou contra outra pessoa. Você o reconhece agora?

Os números de 1 até 9 podem ser arranjados em uma matriz de 3 x 3 conhecido como “quadrado mágico” onde cada linha, coluna e diagonal some exatamente 15:

6 7 2
1 5 9
8 3 4

Agora você pode reconhecê-lo. Este é o jogo da velha (ou jogo do galo, depende de onde você vive). Então, o jogo da velha é o mesmo jogo que o Três para as quinze, ou eles são jogos diferentes?(A resposta é, depende o que você quer dizer… por isso é importante definir o que é um “jogo”).

Trabalhando em direção a um vocabulário crítico

Quando eu falo “vocabulário” o que eu quero dizer é um conjunto de palavras que nos permita falar sobre jogos. A palavra “crítico” nesse caso não significa que estamos sendo críticos (no sentido de achar falha com um jogo), mas no sentido de analisar jogos criticamente (de forma a ser capaz em analisá-los cuidadosamente, considerando todas as suas partes e como elas encaixam uma com as outras, olhando os lados bons e ruins).

Vocabulário pode não ser tão fascinante quanto o jogo “robô laser ninjas” que você deseja fazer o design, mas é importante porque isso nos dá meios para falar sobre jogos. De outra forma, estaríamos presos a gestos e grunhidos e seria muito difícil para aprender qualquer coisa se não pudermos nos comunicar.

Uma das coisas das formas mais comuns ao se falar de jogos é descrevê-los em função de outros jogos. “É como Grand Thef Auto combinado com The Sims e com World of Warcraft”. Mas isso possui duas limitações. Primeiro, se eu nunca joguei “World of Warcraft”, então eu não sei o que você quer dizer. Isso requer que ambas as pessoas tenham jogado os mesmo jogos. Segundo, e mais importante, isso não compreende o caso de um jogo que é muito diferente. Como você descreveria “Katamari Damacy” [2] em termos de outros jogos?

Outra opção, frequentemente escolhida por escritores de livros de game design, é inventar uma terminologia quando necessário e usá-la consistentemente dentro do texto. Eu poderia fazer isso, e nós poderíamos ao menos nos comunicar sobre conceitos fundamentais do game design. O problema aqui é o que acontece após esse curso acabar. O jargão desse curso se tornará inútil quando estivermos falando com qualquer outra pessoa. Eu não posso forçar ou impor que a indústria de jogos adote minha terminologia.

Poderíamos imaginar: se palavras para discutir jogos são tão importantes, porque ainda não foram feitas? Porque a indústria de jogos não estabeleceu uma lista de termos? A resposta é que isso está acontecendo, mas é um processo lento. Veremos muitos desses termos emergentes nas leituras, e será um tema recorrente durante a primeira metade deste curso.

Jogos e Brincadeiras

Existem vários tipos de brincadeiras: Arremessar uma bola, jogo de “fazer-de-conta”, e é claro, jogos. Então você pode pensar em jogos como um tipo de brincadeira.

Jogos são feitos de muitas partes, como as regras, estória, componentes físicos, e por aí em diante. Brincar é apenas um aspecto dos jogos. Portanto, você pode pensar na brincadeira como uma parte dos jogos.

Como podem duas coisas simultâneamente ser um subconjunto da outra? Isso parece um paradoxo, e é algo que você é apreciado pensar por conta própria. Para nossos propósitos, não importa. O ponto aqui é que jogos e brincadeiras são conceitos que estão relacionados.

Então, o que é um jogo afinal?

Você deve ter percebido que eu nunca respondi a pergunta anterior sobre o que são jogos. Isso é porque o conceito é muito difícil de definir, ao menos de um modo que não deixe de fora coisas que são obviamente jogos (a definição é muito restrita) ou aceite coisas que são claramente um não-jogo (tornando a definição muito ampla)… algumas vezes, ambas.

Aqui estão algumas definições de várias fontes:

  • Um jogo possui “meios e fins”: um objetivo, um resultado e um conjunto de regras para chegar lá. (David Parlett)
  • Um jogo é uma atividade envolvendo decisões do jogador, buscando objetivos em um “contexto limitador” (ou seja, regras). (Clark C. Abt)
  • Um jogo possuí seis propriedades: É “livre” (jogar é opcional e não obrigatório); “separado” (ele é fixo antecipadamente no tempo e no espaço); possui resultado incerto, é “improdutivo” (no sentido de não criar bens ou riqueza – note que pode transferir riqueza entre jogadores, mas não a cria); é governado por regras; e, “faz acreditar” (acompanhada da consciência de que um jogo não é a vida real, mas uma espécie de “realidade” a parte compartilhada). (Roger Callois)
  • Um jogo é “um esforço voluntário para ultrapassar obstáculos desnecessários”. Esse é o favorito de meus alunos em aula. Parece um pouco diferente, mas inclui uma série de conceitos das definições vistas anteriormentes: É voluntário, possui objetivo e regras. A parte sobre “obstáculos desnecessários” implica na ineficiência causada pelas regras devido ao seu propósito. Por exemplo, se o objetivo do “Jogo da Velha” é obter três símbolos iguais na vertical, na horizontal ou em diagonal, a forma mais fácil de fazer isso é simplesmente escrever três símbolos de uma só vez em seu primeiro turno enquanto mantém o papel em sua posse, longe de seu oponente. Mas você não faz isso, pois as regras estão no caminho… e são dessas regras que surge o jogo. (Bernard Suits).
  • Jogos possuem quatro propriedades. Eles são um “sistema formal, fechado” (essa é uma forma elegante de dizer que jogos possuem regras; “formal” neste caso significa que pode ser definido). Jogos envolvem interação, envolvem conflito e oferecem segurança, ao menos comparado com o que representam (por exemplo, futebol americano não é algo que se chamaria exatamente de perfeitamente seguro – lesões são comuns – mas é um jogo abstrato de representação de uma guerra, e isso certamente é mais seguro do que ser um soldado no meio de um combate). (Chris Crawford)
  • Jogos são “uma forma de arte onde os participantes, denominados Jogadores, tomam decisões de modo a administrar recursos por meio de peças representativas de jogo, buscando um objetivo”. Essa definição inclui vários conceitos que não estavam presentes nas definições anteriores: Jogos são arte, envolvem decisões, gerenciamento de recursos e possuem “peças de representação” [3] (objetos físicos dentro do jogo). Existe também o familiar conceito de objetivo. (Greg Costikyan)
  • Jogos são um “sistema onde os jogadores se envolvem em um conflito artificial, definido por regras, resultando em um resultado quantificável”(“quantificável” aqui significa apenas, por exemplo, que existe uma idéia de “vencer” e “perder”). Essa definição é do livro “Rules of Play” (http://en.wikipedia.org/wiki/Rules_of_Play – em inglês) de Katie Salen e Eric Zimmerman. O livro lista também as outras definições dadas e agradeço aos autores por colocarem todas elas em um único lugar para uma referência rápida.

Examinando essas definições, nós agora temos um ponto de partida para discutir jogos. Alguns dos elementos mencionados aparentemente são comuns na maioria (senão todos) dos jogos:

  • Jogos são uma atividade;
  • Jogos possuem regras;
  • Jogos possuem conflitos;
  • Jogos possuem objetivos;
  • Jogos envolvem tomadas de decisões;
  • Jogos são artificiais, então são seguros, e eles estão fora da vida cotidiana. Algumas vezes nos referimos a isso pelo fato dos jogadores entrarem no “Círculo Mágico” ou a partilha de uma “atitude lúdica”.
  • Jogos não envolvem ganho material por parte dos jogadores.
  • Jogos são voluntários. Se você está sob a mira de uma arma de fogo e é forçado a realizar uma atividade que normalmente seria considerada um jogo, alguns diriam que isso não é mais um jogo para você. (Pense sobre isso:  Se você aceitar isso, então uma atividade que é voluntária para alguns jogadores e compulsória para outros pode ou não ser um jogo. Depende de qual ponto de vista você está observando).
  • Jogos possuem resultado incerto.
  • Jogos são uma representação ou simulação de algo real, mas eles mesmos são um “faz-de-conta”;
  • Jogos são ineficientes. As regras impõem obstáculos que impedem que o jogador chegue ao seu objetivo da forma mais eficiente;
  • Jogos são sistemas. Normalmente, são sistemas fechados, o que significa que as informações e os recursos não são compartilhados entre o jogo e o mundo exterior a ele.
  • Jogos são uma forma de arte.

Deficiências das definições

Quais das definições anteriores são corretas?

Nenhuma delas é perfeita. Se você tentar fazer a sua própria definição, provavelmente será imperfeita também. Aqui vão alguns casos extremos onde comumente causam problemas com definições:

  • Quebra-cabeças(Puzzles), da mesma forma que palavras cruzadas, sudoku, “Cubo Mágico”[4], ou quebra-cabeças lógicos. São jogos? Depende da definição. Salen e Zimmerman dizem que são um subconjunto dos jogos onde existe um conjunto de respostas corretas. Costykyan diz que isso não são jogos, embora possam estar contidos dentro de um jogo.
  • Role-playing games (RPG), como Dungeons & Dragons. Eles possuem a palavra “jogo”[5] no título, mas frequentemente não são considerados um jogo (por exemplo, porque frequentemente eles não possuem um resultado ou resolução, sem ganhadores ou perdedores).
  • Livros “Escolha a sua aventura”/”Aventuras Fantásticas” [6] (Choose-your-own-adventure books): Esses livros não são geralmente imaginados como jogos. Você geralmente diz que está “lendo” um livro, e não “jogando”. Ainda assim, ele se encaixa na maioria dos critérios sobre jogos. Para deixar as coisas ainda mais confusas, pegue um desses livros, adicone uma planilha de personagem com alguns valores numéricos, inclua uma “verificação de habilidades” em algumas páginas onde você irá rolar um dado contra as estatísticas, e chame isso de “módulo de aventura” ao invés de “Escolha a sua aventura”, e nós podemos chamar isso de jogo!
  • Histórias: Histórias são jogos? Por um lado, a maioria das histórias são lineares, enquanto jogos possuem a tendência em serem mais dinâmicos. Por outro lado, muitos jogos possuem algum tipo de história em suas narrativas. Temos até mesmo escritores profissionais em projetos de jogos milhionários. Além disso, o jogador pode contar uma história sobre a experiência dele no jogo (“Deixe-me contar para você sobre o jogo de xadrez que joguei a noite passada, foi fantástico”). De agora em diante, tenha em mente que os conceitos de história e jogo são relacionados de várias maneiras e exploraremos isso mais profundamente mais adiante neste curso.

Vamos fazer um jogo

Você deve estar imaginando como isso tudo o ajudará a fazer jogos. Não vai, diretamente. Mas nós precisamos ao menos avançar alguns passos a fim de obter um vocabulário comum para que nós pudéssemos falar de jogos com algum sentido.

Aqui vai uma coisa sobre jogos: Eu escuto muitos de meus estudantes que são receosos de não serem capazes de fazer um jogo. Eles não possuem a criatividade, a habilidade, ou o que for. Isso não tem sentido e é hora de tirarmos isso de nossas cabeças.

Se você nunca fez um jogo anteriormente, esse é o momento de deixar seus medos de lado. Você fará um jogo agora. Pegue um papel e uma caneta (ou pegue um programa de desenho como o Microsoft Paint). Isso irá levar 15 mitutos e será divertido e indolor, eu prometo.

Falo sério. Prepare-se. Vamos?

Vamos fazer o que é conhecido como um jogo de tabuleiro de “corrida até o final”. Você provavelmente jogou muito destes. O objetivo é levar sua peça de uma área do tabuleiro para a outra. Exemplos comuns desses jogos são “Cobras e Escada”s (Chutes & Ladders) e Ludo(Parcheesi). Esse é um dos tipos de jogos mais fáceis de realizar o design e você fará um agora.

Primeiro desenhe algum tipo de caminho ou trilha. Pode ser reto ou curvo. Tudo que você precisa é uma linha. Agora divida a linha em espaços. Você acabou de completar o primeiro passo de um total de quatro. Viu como é fácil?

Em seguida, traga um tema ou um objetivo. Os jogadores precisam ir de um lado do caminho para o outro. Por quê? Você está correndo para alguma ou correndo de alguma coisa. O que os jogadores representam no jogo? Quais os seus objetivos? No design de muitos jogos, é frequentemente útil iniciar perguntando qual o objetivo e muitas regras vão aparecer somente em função disso. Você deve se capaz de encontrar algo (mesmo se for muito bobo) em alguns minutos. Você já percorreu metade do caminho!

Terceiro: você precisa de um conjunto de regras que permita o jogador mover-se de espaço em espaço. Como você se move? O jeito mais simples, e que você provavelmente deve estar familiarizado, é rolar um dado em sua vez e andar o número de espaços avante. Você também precisa decidir como exatamente o jogo termina: Você precisa chegar ao espaço final obtendo o número exato de espaços ou o jogo acaba tão logo o jogador alcançar ou passar por este espaço?

Você agora tem algo que possui todos os elementos de um jogo, embora está faltando um elemento comum a muitos jogos: o conflito. Jogos costumam ser mais interessantes se você pode afetar seus oponentes, ou ajudando-os ou prejudicando-os. Pense nas formas de interagir com seus oponentes. Acontece alguma coisa quando você alcança o mesmo espaço que eles? Existe algum espaço mo tabuleiro onde você alcaná e permite fazer coisas com o seu oponente, como movê-lo para frente ou para trás? Você pode mover seu oponente de outra forma em seu turno (como por exemplo, ao tirar um determinado número ao rolar o dado)? Acrescente ao menos uma forma de modificar o lugar de seu oponente em seu turno.

Parabéns! Você acabou de fazer um jogo. Ele pode não ser particularmente um bom jogo (isso é algo que iremos tratar mais tarde nesse curso), mas é um jogo funcional que pode ser jogado, e você fez em apenas alguns minutos, sem qualquer outra ferramenta a não ser um simples pedaço de papel e caneta.

Os créditos por desenvolver este exercício vão para a minha amiga e co-autora, Brenda Brathwaite (http://bbrathwaite.wordpress.com/2008/07/09/the-easiest-game-design-exercise-ever-really/ – em inglês), que reparou que há uma barreira invisível (http://bbrathwaite.wordpress.com/2008/07/07/fear-of-the-game/ – em inglês) entre muitas pessoas e o game design, e criou este exercício como uma forma de fazer os seus alunos ultrapassar o seu medo inicial de acharem que não conseguem fazer nada.

Lições aprendidas

Se você não tirar mais nada dessa pequena atividade, perceba que você pode ter um jogo funcional em minutos. Isso não necessita de habilidades de programação, não requer uma grande dose de criatividade e não requer muito dinheiro, recursos ou materiais especiais. Não leva meses ou anos. Fazer um bom jogo pode requerer algumas ou mesmo todas essas coisas, mas o processo começa com uma idéia simples que pode ser feita num pequeno período de tempo com apenas algumas folhas de papel.

Lembrem-se como nos movemos nesse curso. Quando falamos sobre interação e prototipagem rápida, muitas pessoas têm medo de comprometer-se a um design, para realmente construir a sua idéia.  Eles têm medo que levará muito tempo, ou que a idéia não será tão boa quanto ela se parece em sua cabeça. Parte do processo envolve matar idéias fracas e torná-las fortes, fazendo e jogando o seu próprio jogo. Quanto mais rápido você tiver algo funcional e quanto mais vezes você jogá-lo, você poderá fazer um jogo melhor. Se isso te toma mais do que alguns minutos pra fazer seu primeiro protótipo de uma idéia, está demorando demais.

Homeplay

Algumas classes atribuem problemas de “lição de casa”. Eu não sei o que é menos divertido: O conceito de trabalhar em casa ou ter “problemas”. Então eu chamo tudo de “homeplay” (brincar em casa) porque eu quero que essas coisas sejam divertidas e interesantes.

Leia:

  • Challenges for Game Designers, Capítulo 1 (Basics). Essa é apenas uma breve introdução ao texto.
  • I have no words and I must design (“Eu não tenho palavras e eu preciso fazer o design” – em inglês – http://www.costik.com/nowords.html), por Greg Costikyan. Para mim (e tenho certeza que outros vão discordar), esse artigo é é o ponto de mudança, onde o design de jogos começou a tornar-se um campo de estudo. Uma vez que tudo começou aqui, ao menos para mim, penso que ele cabe no início deste curso (Existe uma nova versão aqui – http://www.costik.com/nowords2002.pdf – em inglês – se você estiver interessado, mas eu prefiro a versão original pela sua importância histórica.
  • Understanding Games 1, Understanding Games 2, Understanding Games 3, Understanding Games 4. Esses não são leituras, mas “jogos”. É uma série de jogos em Flash que procuram explicar alguns conceitos básicos de jogos, na forma de jogo. O nome é em referência ao “Desvendando os Quadrinhos” (Understanding Comics), um livro em quadrinhos que fala de histórias em quadrinhos. Cada um tem cerca de cinco minutos (em inglês).


[1] IGDA é sigla da International Games Development Association, ou Associação Internacional dos Desenvolvedores de Jogos. Education SIG significa Education Special Interest Group, ou Grupo de Interesse Especial em Educação.

[2] http://pt.wikipedia.org/wiki/Katamari_Damacy

[3] N.T.: O termo “game token” poderia ser traduzido como “fichas” ou componentes de representação. Preferí manter o termo como pe;cas, por ser mais abrangente e no meu entender, mais próximo da idéia de “game token”, que podem ser qualquer coisa, inclusive fichas. Componentes entendo que pode causar algum tipo de má interpretação, uma vez que o autor também fala em componentes ou elementos do jogo, onde as peças (físicas) são uma delas.

[4] O nome correto é “Cubo de Rubik”, mas no Brasil é conhecido desta forma.

[5] Role-playing games (RPG) possui tradução literal como “jogo de interpretação de papéis”. No Brasil, é conhecido pela terminologia inglesa.

[6] Esses livros foram publicados no Brasil pela editora Ediouro.

Game Design Concepts – Programa e Cronograma

Game Concept Design - Banner

Programa e Cronograma

Por Ian Schreiber (http://gamedesignconcepts.wordpress.com/)

Tradução de Bruno Salvatore Drago (http://www.xuti.net)
Original em http://gamedesignconcepts.wordpress.com/2009/04/21/syllabus-and-schedule/ (Acesso em 20.07.2009)

Cronograma

Este curso durará de Segunda-feira, 29 de junho de 2009 até Domingo, 06 de Setembro de 2009. As publicações no site serão feitas as segundas e as quintas-feiras toda semana, ao meio-dia. Discussões e trocas de idéias serão feitas durante todo o tempo.

Livrotexto

Este curso possui um livro obrigatório e dois livros recomendados, que serão referenciados em vários lugares e fornece um bom “próximo passo” após o curso.

Livrotexto de referência:

“Challenges for Game Designers”, por Brathwaite & Schreiber. Este livro cobre muito das informações básicas, prática e teórica, de game design, e nós usaremos intensamente, adicionando algumas leituras de outras fontes online. Sim, eu sou um dos autores. A razão para que eu e Brenda escrevêssemos este livro foi porque nós queríamos um livro para usar em nossas aulas e não existia nada parecido naquele tempo. Então fizemos nosso próprio livro. (Livro somente em inglês)

Livros recomendados:

  • Desvendando os Quadrinhos, de Scott McCloud (Understanding Comics: The Invisible Art, by McCloud). Enquanto este livro chama a atenção por tratar-se de quadrinhos, muitas de suas lições podem ser aplicadas ao game design e outras formas de art. Além disso, o livro também é uma história em quadrinhos e divertido para ler.
  • “A Theory of Fun for Game Design”, de Raph Koster (site official – http://www.theoryoffun.com/ – em inglês). Este livro mostra as similaridades entre o game design e educação, com uma boa discussão sobre o conceito de Fluxo. Parte texto, parte quadrinho, este pequeno livro de leitura agradável pode ser lido em uma ou duas tardes.

Descrição do Curso

Este curso fornecerá aos estudantes uma compreensão teórica e conceitual do campo do game design, em conjunto com uma exposição prática do processo de criação de um jogo. Os tópicos abordados incluem interação, prototipagem rápida, mecânica, dinâmica, teoria do Fluxo, a Natureza da diversão, balanceamento de jogos, e design de interface. O foco principal são os jogos não digitais.

Objetivos do curso:

Neste curso, discutiremos jogos e “game design”. Descobriremos o que são os components de um jogo, e quais partes dos jogos são influenciados por seu design. Vamos aprender várias formas de desenvolver um jogo, os processos e as melhores práticas para prototipagem, playtesting e balanceamento de um jogo depois que ele foi imaginado.

Espectativas do estudante com este curso

Ao final deste curso, você estará familiarizado (ao menos um pouco) com a forma de trabalho aceita na indústria de jogos como fundamentação teórica do game design. Você também se sentirá confortável o suficiente com o processo para começar a desenvolver seus próprios jogos[1], bem como uma análise crítica de jogos de outras pessoas.

Nota sobre mudanças no curso

Como este curso é um experiment, o cronograma e o programa estão sujeitos a alteração baseado nas necessidades dos estudanetes e no andamento geral do curso.

Programa

Data Tópicos
29.06.2009 Visão geral sobre jogos e design

Vocabulário Critico: O que é um jogo?

02.07.2009 O que é game design?

Interação e prototipagem rápida

06.07.2009 Elementos formais dos jogos
09.07.2009 Visão geral do processo de game design

Geração de Idéias, brainstorming, e prototipação no papel

13.07.2009 Mecânica e dinâmica
06.07.2009 Jogos e Arte
20.07.2009 Tomada de decisão; Tipos de decisão

Teoria do Fluxo

23.07.2009 Formas de Diversão

Tipos de jogadores

27.07.2009 Elementos dramáticos em um jogo
30.07.2009 Roteiros não lineares
03.08.2009 O processo de game design em detalhes

Introdução ao Projeto de design para este curso

06.08.2009 Técnicas de teste solo

Projeto de design: Teste solo

10.08.2009 Técnicas de teste do designer; Analise crítica

Projeto de design: Testando o design

13.08.2009 Técnicas de teste do jogador

Projeto de design: Teste de jogadores

17.08.2009 Técnicas de “duplo-cego” (blindtesting)

Projeto de design: “duplo-cego” (blindtesting)

20.08.2009 Técnicas de balanceamento de jogos

Projeto de design: Balanceamento

24.08.2009 Design de Interface com o usuário

Diferenças entre Interface com o usuário digital e não-digital

27.08.2009 Projeto de design: Interação de Interface de Usuário.
31.08.2009 Projeto de design: Material final e apresentação

Análise crítica dos designs de projetos

03.09.2009 Principais pontos do curso

Próximos passos


[1] N.T: “Game Design” em algumas situações pode significar melhor, em português, desenvolvimento de jogo. A tradução literal, porém, muitas vezes traz ambigüidade em português, uma vez que desenvolvimento de jogos traz a idéia de um processo mais genérico do que o “game design”, em inglês, pode significar (a expressão é utilizada no português também, justamente pela abrangência do termo). As expressões serão algumas vezes alternadas de modo a melhor entendimento do texto e da idéia original.

Game Design Concepts – O que é o “Game Design Concepts”? – Tradução

Game Concept Design - Banner

O que é o “Game Design Concepts”?1

Por Ian Schreiber (http://gamedesignconcepts.wordpress.com/)

Tradução de Bruno Salvatore Drago (http://www.xuti.net)
Original em http://gamedesignconcepts.wordpress.com/2009/03/31/what-is-game-design-concepts/ (Acesso em 20.07.2009)

Quem sou eu?2

Meu nome é Ian Schreiber. Tenho trabalhado na indústria de videogame desde a virada do milênio, primeiro como programador, e depois como game designer. Tenho realizado aulas de “game design” desde o ano de 2006. Para outras informações, você pode buscar meu nome no Google.

O que é este blog?

Este blog é um experimento em “game design” e pedagogia. Durante o verão de 2009, eu publicarei neste blog uma série de aulas, notas de curso, leituras e desafios com o tema game design.

Este blog é um curso de game design (especificamente, design para sistemas não digitais).

  • Quanto custa? Nada. Este curso3 é aberto para todos.
  • Pré-requisitos: Nenhum. A minha intenção é fazer este curso acessível a todos, com os mais diversos níveis de experiência, enquanto forneço recursos adicionais úteis aqueles que possuem conhecimento mais avançado.
  • Duração4 : Segunda, 29.06.2009 até Domingo, 06.09.2009. Publicarei os textos duas vezes na semana. Você pode ler no seu próprio ritmo. O curso dura dez semanas.
  • Público: Qualquer um interessado em Game Design. Isso inclui estudantes que são interessados no tema; professores que lecionam alguma disciplina de “Game Design” e desejam comparar o material de curso; desenvolvedores de jogos com interesse em design ou desejo de ver um exemplo do que os estudantes estão aprendendo hoje em dia; ou, pessoas de alguma forma relacionadas a “game designers” e são curiosas sobre o que essas pessoas fazem o dia inteiro.

Dois níveis de participação5

Se você deseja apenas ver o conteúdo, tudo o que você precisa fazer é colocar o site6 em seus links favoritos e ler. Você pode até mesmo deixar comentários.

Porque estou fazendo isso?

Eu tenho muitas motivações para iniciar esse projeto, algumas são egoístas outras são altruístas. Algumas eu adianto a seguir:

  • Game design é minha paixão e eu adoro compartilhar isso com qualquer um e com todos;
  • Tenho lecionado em sala de aulas tradicionais e algumas online, e quero experimentar métodos alternativos de ensino;
  • Expondo o meu material de curso e observando os comentários e discussões, eu posso melhorar o curso quando leciono por dinheiro;
  • Faço uma mudança em minha carreira. Se este curso for bem sucedido, me dará uma grande visibilidade em meu campo e promoverá meu nome como uma marca.

Isso é realmente, totalmente, 100% grátis?

A leitura do blog é grátis, bem como o registro . Existm alguns custos:

  • Existe um livro de referência obrigatório. Pode ser encontrado por cerca de US$25.
  • Parte do curso envolverá a criação de um inteiro projeto não-digital, então você precisará comprar os materiais para isso. O valor pode variar entre US$25 e US$50, dependendo do jogo.
  • Isso é ainda mais barato que a mensalidade de uma faculdade.

Onde consigo mais informações?

Visite o site http://gamedesignconcepts.wordpress.com/ (em inglês).

Nota de tradução (N.T.): O texto apresentado neste post, bem como nos subsequentes que estarei publicando, foram TODOS autorizados pelo Autor. Pelo fato do Blog original ser escrito essencialmente em 1a pessoa, procurei manter o texto mais fiel possível ao original, mas cortei comentários pontuais, aplicados principalmente ao contexto da época em que foi escrito. Os textos são de Junho de 2009. Todas as traduções serão acompanhadas de suas explicações em notas próprias.
[1] N.T. : O termo “Game Design Concepts” significa “Conceitos de Design de Jogos”. No entanto, somente serão traduzidos os termos onde a expressão tiver o seu literal significado. Aqui, entendemos que a expressão é usada de forma ambígua pelo autor, significando também o nome do curso, de modo que decidimos por manter inalterado. Os nomes em inglês não serão modificados, nem expressões comuns ao desenvolvimento de jogos, como “design”,”brainstorming” e outros termos em inglês já consagrados pelo uso, no Brasil, e que seria de difícil ou maior dificuldade encontrá-los em livros ou mecanismos de buscas.
[2] N.T.: O presente texto foi publicado no Blog do Autor e traduzido com autorização do mesmo.
[3] N.T.: Pela adaptação do texto ao tempo que está sendo traduzido, os termos classe e curso, em inglês, estão sendo traduzido como “curso”, de forma indiscriminada, uma vez que não é mais possível participar do curso, como participante.
[4] N.T.: O curso não aceita mais inscrições na data desta tradução.
[5] N.T.: Ver nota anterior. A referência a como se inscrever no curso foi omitida propositadamente.
[6] N.T.: Site e blog serão traduzidos indistintamente, sendo tratados como sinônimos.
[7] N.T.: Para inscrever-se no blog, vá ao endereço eletrônico http://gamedesignconcepts.wordpress.com/ – Os comentários devem ser enviados em inglês

Revista EGW #107

Capa - Revista EGW #107
Capa - Revista EGW #107
Capa - Revista EGW #107

Está nas bancas a revista EGW número 107. Citamos a revista pois, além de ser uma revista legal, nós da XUTI fomos matéria de 2 páginas na revista, na matéria “Game como inclusão social“, que fala sobre nossas atividades de desenvolvimento de jogos nas unidades do SESC no Rio de Janeiro, em parceria com o amigo Fabiano Sampaio.

Para comprar a revista, vocês podem ir a uma banca ou clicar AQUI.

Se conseguir autorização, coloco a matéria online depois que a revista sair das bancas.

Game Zone Especial

Revista Game Zone
Revista Game Zone
Revista Game Zone

Está nas bancas a revista GAME ZONE ESPECIAL. Citamos a revista pois, além de ser uma revista legal e acessível aos mais leigos em programação, nós da XUTI auxiliamos na revista com textos e tutoriais. Espero que gostem.

Para comprar a revista, vocês podem ir a uma banca ou clicar AQUI.

Como instalar o MingW com o Allegro no Windows ?

O propósito deste texto é descrever detalhadamente a instalação do MinGW (http://www.mingw.org/) conjuntamente com a biblioteca para desenvolvimento de jogos Allegro (http://www.talula.demon.co.uk/allegro/ ou http://alleg.sourceforge.net/).

O MinGW é, grosseiramente, uma versão do compilador C da GNU (GCC – http://gcc.gnu.org/) para Windows, permitindo então compilar programas C/C++ neste ambiente de forma muito eficiente.

O Allegro é uma biblioteca multiplataforma que inclui muitas funções úteis no desenvolvimento de jogos, como funções gráficas (2D e 3D), áudio, controle de teclado/mouse/joystick e timer. Funciona de forma muito simples e permite a geração de códigos praticamente idênticos em todas as plataformas em que está disponível, dentre as quais Windows, Linux e DOS.

Conjuntamente com um editor de textos (nossa preferência pessoal é pelo XEmacs – http://www.xemacs.org/ pois tem uma funcionalidade única para escrever o código, mas outra forte indicação é o Dev-C++ – http://www.bloodshed.net/ que é um ambiente integrado que funciona com o MinGW; mas qualquer outro editor de sua preferência serve) temos um ambiente de desenvolvimento de jogos básico completo.

Parte I – O que devo pegar?

Para instalar o MinGW e o Allegro, você deverá baixar os seguintes pacotes:

i) A distribuição completa do MinGW, atualmente em um único arquivo de instalação, que se encontrava na época deste texto em http://prdownloads.sourceforge.net/mingw/MinGW-1.1.tar.gz

ii) Os seguintes utilitários adicionais portados para MinGW:

  • fileutils: consiste em utilitários para lidar com arquivos muito úteis, principalmente na linha de comando ou makefiles. Pegue a versão disponível em ftp://ftp.franken.de/pub/win32/develop/gnuwin32/mingw32/porters/Mikey/fileutils316-ming.tar.bz2
  • sed: é necessário pra compilar o Allegro. Pegue em ftp://agnes.dida.physik.uni-essen.de/home/janjaap/mingw32/binaries/sed-2.05.zip
  • bzip2: você vai precisar pra abrir o fileutils acima. Pegue em http://prdownloads.sourceforge.net/mingwrep/bzip2-1.0.1-20011028.zip

iii) O Allegro propriamente dito com o arquivo para fazer interface com o DirectX no Windows. Vá à página de download da última versão estável do Allegro (4.2) – http://alleg.sourceforge.net/wip.html – e baixe os seguintes arquivos com source para windows:

  • all400.zip (http://prdownloads.sourceforge.net/alleg/all420.zip?download)

E APENAS UM dos arquivos abaixo, dependendo da versão do DirectX que você deseja dar suporte:

  • dx70_mgw.zip (não confunda com dx70_min.zip!) – http://alleg.sourceforge.net/files/dx70_mgw.zip
  • dx80_mgw.zip – http://alleg.sourceforge.net/files/dx80_mgw.zip

Parte II – Configurando o MingW e preparando para instalar o Allegro

Comece pela instalação do pacote do MinGW, descompactando o arquivo no diretório que deseja que ele fique instalado. O usual é algo como c:mingw32 (pessoalmente prefiro c:mingw pois mingw32 é um nome ultrapassado do projeto). Este arquivo pode ser descompactado com o Winzip. De agora em diante, vamos assumir que a instalação foi feita em c:mingw.

O diretório c:mingwbin deve ser incluído no início do seu path (caso você use DJGPP também: antes da inclusão do diretório dele!), sendo que isso pode ser feito de várias formas, sendo as mais comuns:

  • Windows 9x: editando seu arquivo c:autoexec.bat alterando a linha do path ou simplesmente incluindo no final deste arquivo a linha “path c:mingwbin;%PATH%”
  • Windows NT (inclui 2000,XP e Me): abra o Painel de Controle, vá em “Sistema” e então na aba “Avançado” e finalmente no botão “Ambiente”. Selecione PATH= e adicione “c:mingwbin”.
  • Da mesma forma, a seguinte linha deve ser inserida no c:autoexec.bat : “set MINGDIR=c:mingw”. (Caso você utilize Windows XP ou NT, no mesmo menu descrito no ítem anterior, crie uma variavel denominada MINGDIR e atribua a ela o valor c:mingw. Não utilize autoexec.bat).

Após estas alterações nos arquivos de inicialização será necessário que você reinicie o computador. Vá então em uma janela DOS/CONSOLE e digite a seguinte linha para testar a instalação: “gcc -v”. O resultado deve ser algo como:”Reading specs from C:MINGWBIN..libgcc-libi386-mingw32msvc2.95.3specs gcc version 2.95.3 20010726 (release)”.

Instale agora o pacote sed e bzip2, descompactando-os para o diretório do MinGW (aponte o winzip para c:mingw portanto). Em seguida, na janela DOS, vá ao diretório onde está o arquivo do fileutils e rode o comando “bunzip2 fileutils316-ming.tar.bz2” (este comando deverá funcionar se você descompactou direito o arquivo bzip2 e incluiu c:mingw no seu PATH adequadamente e irá descompactar o arquivo fileutils316-ming.tar.bz2 para fileutils316-ming.tar o qual o Winzip pode lidar). Então descompacte com o Winzip o arquivo fileutils316-ming.tar gerado por este último comando para o diretório do MinGW como acima.

Descompacte da mesma forma os arquivos do Allegro para o diretório do MinGW (c:mingw), e quando for descompactar o arquivo dx70_mgw.zip (ou o dx80_mgw.zip – depende de qual arquivo você pegou) e sobrescreva todos os arquivos existentes.

Pronto! Basta agora configurar o Allegro e então compilá-lo!

Parte III – Compilando o Allegro

Se você chegou até aqui, não deverá ter mais problemas (estamos considerando apenas a instalação padrão. Se você quer algo mais sofisticado, certamente sabe do que está falando e não precisa deste tutorial!).

Os comandos a seguir devem ser executados em uma janela DOS/CONSOLE. Para compilar o Allegro devemos preparar os arquivos de configuração para avisar de que a compilação será com o MinGW e então mandar compilar o mesmo. Para isso, basta seguir os seguintes passos, digitando os comandos entre aspas na linha de comando:

1. Vá ao diretório do Allegro: “cd c:mingwallegro”
2. Rode o arquivo de configuração do allegro: “fix.bat mingw32”
3. Finalmente vamos compilar o Allegro: “make”
4. Tome um café…(dependendo da sua máquina, considere jogar uma partida de xadrez)
5. Basta então mandar instalar a biblioteca: “make install”

Pronto! O Allegro está instalado! Você poderá ver vários exemplos no diretório c:mingwallegroexamples e uma demo muito interessante em c:mingwallegrodemo . A documentação básica do Allegro está no diretório c:mingwallegrodocs e é muito indicado que você veja o link de tutoriais na página da biblioteca, principalmente o Vivace se você for iniciante.

Caso você deseje informações mais detalhadas, este texto foi feito com base no processo que usei para instalar no meu computador, mas foi fortemente influenciado pela documentação nos sites citados e na documentação da configuração e instalação do Allegro,constantes do diretório de documentação que acompanha a biblioteca.

Bom código!

Castlevania: Simphony of the night

Castlevania - Simphony of the night

logotipo - jogo Castlevania

CASTLEVANIA é a série de jogos produzidos pela empresa japonesa de jogos KONAMI, que narra a história da família Belmont. A peculiaridade desta família é que em toda geração, um de seus membros torna-se um CAÇA-VAMPIROS!

A “aparente” falta de criatividade do enredo do jogo acaba quando se percebe que nenhuma outra empresa foi tão feliz quanto a Konami e a saga dos Belmont contra Conde Drácula. Os poucos jogos jogos de vampiros existentes por aí são, no mínimo, chatos, diferentemente dos bem-bolados-porém-já-manjados-jogo-de-plataforma.

É exatamente essa falta de compromisso é que faz o jogo tão atraente. O jogo, evoluído desde a sua primeira versão até as mais recentes versões para PlayStation® e N64®, o jogo não tem preocupações em ter gráficos 3D, como anda essa febre ultimamente de QUAKE e DOOM´s por aí. O jogo se mantém, ao menos até agora, a sua “cara” original. (NOTA: Este texto foi originalmente escrito em 2002. Hoje já existe versões em 3d do jogo).

Konami logotipo - Vampire Killer
Konami logotipo – Vampire Killer
Logotipo - Vampire Killer
Logotipo – Vampire Killer
Konami logotipo - Castlevania SotN
Konami logotipo – Castlevania
Logotipo - Castlevania
Logotipo – Castlevania

O primeiro jogo a ser lançado foi no computador MSX2, em 1986 e respectivamente, no console NES. O sucesso foi imediato e o jogo, a medida que a empresa KONAMI foi crescendo, foi ganhando novas versões para outros consoles e novas aventuras com outros membros da família Belmont. Alguns computadores e consoles que ganharam versões do jogo CASTLEVANIA:

  • MSX
  • NES
  • SNES
  • SEGA GENESIS
  • PlayStation
  • PlayStation 2
  • N64
  • GameBoy
  • GameBoy Advanced

O jogo CASTLEVANIA – Symphony of the Night – é uma das exceções que aconteceram durante a série de jogos. O “heroi” do jogo não é um membro da famíla Belmont, mas Alucard, um meio-homem, meio-vampiro, que foi investigar o desaparecimento de Ritcher Belmont (Ritcher desapareceu no jogo Drácula X, no ano de 1788). Alucard volta a CASTLEVANIA (Nome do castelo) em 1793, disposto a descobrir o que aconteceu a Ritcher Belmont. A primeira aparição de Alucard, foi no ano 1476, no jogo “Dracula´s Curse”, para NES.

Aqui vão alguns “Screen Shots” do game para PlayStation e outros do jogo original, de 1986, “Vampire Killer”:

Castlevania - Simphony of the night - Grande jogo de Playstation 1
Castlevania – Simphony of the night – Grande jogo de Playstation 1
Castlevania - Simphony of the night - Allucard Vs dracula
Castlevania – Simphony of the night – Allucard Vs Drácula
Castlevania - Simphony of the night
Castlevania – Simphony of the night
Vampire Killer - MSX
Vampire Killer – MSX: Boa jogabilidade até hoje.
Vampire Killer - MSX
Vampire Killer – MSX
Vampire Killer - MSX
Vampire Killer – MSX: Inspiração e o começo de uma série que dura até hoje.

O espetáculo do jogo é a trilha sonora, digna de cinema. Completamente orquestrada, o jogo para PlayStation ganhou inúmeros prêmios internacionais pela sua excelente trilha sonora. Felizmente, é possível ter uma pequena amostra. Segue alguns arquivos em MP3 e MIDI que deixarão você realmente louco. (NOTA: Não disponibilizamos mais na área de download do site as musicas do jogo, em respeito aos Direitos Autorais da empresa)

Para finalizar, o jogo de PlayStation não é possível disponibilizá-lo da Internet, por ser um CD, além de ser protegido por direitos autorais. Ah, claro, você precisará de um console também, ou de um emulador para o computador, apesar de exigir configurações nada modestas.

O jogo VAMPIRE KILLER você pode conseguí-lo em algum site de emulação, onde seja possível baixar ROM de computadores MSX. Também será necessário um emulador. Recomendamos o BlueMSX. Você pode baixá-lo em http://www.bluemsx.com/ gratuitamente.

Inno Setup: Faça uma instalação profissional para seu programa

Inno Setup - Seu projeto personalizado

Ao se desenvolver um jogo, uma das coisas mais comuns na hora de distribuí-lo em seu site é pegar aquele monte de arquivos e formar um belo e vistoso arquivo ZIP para ser “baixado” na sua página. Até aí tudo bem. Mas você já parou para pensar que isso pode ser um tormento ao jogador? Ou pior, isso pode mostrar certo amadorismo de sua parte?

Tudo bem, eu reconheço: Saber mexer no WinZip, WinRAR ou 7Zip é quase tão essencial quanto saber a usar um “Office-like” para o seu escritório. Mas convenhamos, pode ser uma coisa muito ruim para o jogador que caiu de para-quedas na sua HP e que depois de um dia exaustivo de trabalho, resolveu testar o jogo que você fez. O que ele quer é apenas se divertir e ele pode desistir se ele achar “meio complicado” a descompactação do arquivo, ou ainda, se ele simplesmente por qualquer motivo não conseguir rodar o programa porque determinada biblioteca está sem querer em um lugar errado. Dependendo de suas pretensões, isso pode parecer até mesmo algo não-profissional.

Distribuir jogos e programas diretamente no formato ZIP não é algo simplesmente que nunca ocorreu antes na vida de ninguém. Mas e se distribuíssemos nosso programas de uma forma mais “profissional”? Quer dizer, e se nós fizéssemos uma instalação para o nosso jogo? Não seria melhor? Seria uma ótima forma de você, desenvolvedor de jogos, mostrar seu trabalho da melhor forma possível e causar uma boa impressão.

Existem diversas ferramentas que fazem, e bem, este trabalho. Podemos destacar, entre outros, o Install Shield da Macrovision Software. O Install Shield é um programa já renomado e que é uma referência nesse tipo de aplicação. Mas temos um problema: Ele cu$ta caro. E muito.

Para os nossos propósitos, e muitos de nós estamos apenas começando no desenvolvimento de jogos, programas como o Install Shield são inviáveis pelo preço. Desta forma, optamos por uma ferramenta que esteja ao alcance de todos e que faça o trabalho. Em outras palavras, o prograva deve fazer aquilo que se propõe e ao mesmo tempo, ser acessível financeiramente. No nosso caso, uma ferramenta gratuíta!

De todas as ferramentas que testamos, sem dúvida alguma o programa Inno Setup é o melhor de todos pois, além de ser grátis, ele tem um aspecto bem profissional o que pode solucionar diversos problemas.

Inno Setup - Antigo
Inno Setup: Versão para Windows 3.1
Inno Setup - Versão Nova
Inno Setup – Aspecto da versão 5.1.6, mais atual, compativel com Windows 98, 2000 e XP

Neste breve tutorial, explicaremos como fazer uma instalação com o Inno Setup e como alterar algumas das configurações padrão.

ONDE PEGAR E O QUE FAZER?

O Inno Setup é um programa que gera instalações para seus jogos ou programas. Você pode baixar inteiramente grátis do site do autor o programa, que, ao tempo deste tutorial estava na versão 5.1.6. Ele é desenvolvido pela Jr Software (http://www.jrsoftware.org). Você encontrará também o Inno em diversos sites de download, como o Super Downloads ou Donwload.com.

1. Baixe a versão 5.1.6 (isetup-5.1.6.exe)

2. Rode o programa (isetup-5.1.6.exe)

3. Você verá a seguinte caixa de dialogo:

Inno Setup - Janela de Instalação
Inno Setup – Janela de Instalação

4. Em seguida, você verá os termos de licensa do Software. É aconselhavel a leitura, não só neste, mas em todo software. Na dúvida, lembre-se: “We don´t speak english”, então simplesmente aceite e não esquente a cabeça com essas coisas, pois o programa é grátis e pode ser usado até mesmo para fins comerciais(Isso é um belo resumo da licença). Clique no Botão NEXT.

5. Selecione o diretório onde deseja instalar o Inno.

6. Em seguida, dê o nome que aparecerá no menu do windows (ou no botão Inciar, como queira).

7. Você tem a opção de criar um atalho no desktop para o programa, e asociar as extensões “.iss” ao programa. Recomendamos deixar a instalação padrão, criando o atalho e associando os arquivos.

8. Aparecerá um menu para você confirmar o que foi digitado, tal como diretório onde será instalado o programa e opções adicionais.

9. Espere a cópia dos arquivos e você deverá ver a seguinte mensagem se tudo foi feito com sucesso:

Inno Setup - Instalação feita com sucesso
Inno Setup – Instalação feita com sucesso

Parabéns! Se você chegou até aqui, você conseguiu instalar o Inno Setup sem problemas (O que não é nenhum grande mérito). Vamos agora começar a fazer o nosso script de instalação. Clique “Finish” e execute o programa (ele deverá iniciar automaticamente).

O PRIMEIRO SCRIPT E O SCRIPT WIZARD

Ao executarmos o programa pela primeira vez, nos deparamos com a janela “Welcome”. Essa janela possui duas partes. A primeira oferece a possibilidade de criar um código script, ou partindo do zero, na opção “create a new empty script file” ou a partir do Script Wizard, em “Create a new empty script file with Script Wizard” (É lógico que só poderia ter esse nome nessa opção, né?). A segunda parte é para você abrir arquivos salvos. Existem 3 arquivos de exemplo que você pode abrir a qualquer momento. Recomendo a leitura desses arquivos ao terminar de ler este tutorial.

Para o nosso tutorial, baixe o nosso pacote ZIPADO com o programa e código exemplo para realizar este tutorial. Contém um executável, um ícone, uma licença de uso, uma nota de versão e um FAQ. Pegue o arquivo indo na seção DOWNLOADS da página, na subpasta DOCUMENTOS. (Este documento não está mais disponível: Assim que se tornar disponível um substituto para o arquivo, colocaremos a disposição).

O Script Wizard auxiliará você a preencher um script básico, para qualquer instalação. Não é minha intenção esgotar as possibilidades do programa, mas dar uma idéia de como funciona cada item do script e auxiliá-lo nas principais funções para personalizá-lo (além, é claro, de esperar nunca mais ter uma dor-de-cabeça ao baixar um jogo de alguém e ter aquela bagunça em um arquivo ZIP.. 🙂 e dar uma aparência profissional ao seu programa). Vamos utilizar o Script Wizard:

1. Crie um scripr com o Script Wizard. Após a mensagem do Wizard, clique NEXT.

2. A primeira janela pedirá, respectivamente: Application Name (Nome do Programa), Application name including version (nome do programa e versão), Application publisher (Nome da empresa) e Application Website (Website da empresa). Os dois primeiros ítens são obrigatórios. Os dois ultimos não. Preencha o nome do programa como INNO TEST, o nome e versão como “INNO TEST v1.0”, nome da empresa como “XUTI GAME DEVELOPMENT” e website como “http://www.xuti.net/”. (Lógico que invariavelmente você pode escrever o que desejar. Só tome cuidado para sem querer, não se perder no código depois, ok ?). Clique em “NEXT”.

3. A próxima opção é a escolha do DIRETÓRIO que se vai copiar o programa. O título “Application destination base directory” diz para qual diretório BASE você quer copiar o programa. São duas opções: A primeira e padrão (e eu particularmente recomendo que se deixe assim) do programa é “Program Files Directory”. Em português para o nosso Windows entender: Diretório “Arquivos de Programas”. Nesta opção, o Inno irá instalar no diretório “Arquivos de Programas” do Windows em Português. Normalmente todos os programas se instalam dentro desse diretório e o nosso não deverá ser diferente. Entretanto, podem surgir situações em que você NÃO deseja instalar o programa nesse diretório. Você pode querer criar o diretório “GAMESFROMXUTI”, por exemplo. Neste caso, utiliza-se a segunda opção: “custom”. No espaço que segue, você cria o novo caminho e ele NÃO será instalado no diretório “Arquivos de Programas”.

4. O título “Application directory name” nada mais é que o diretório de destino propriamente dito. No nosso exemplo, onde nós não alteraremos o default que lá está (deve ser algo como “INNO TEST” com espaço, ou algo semelhante, de acordo com o que você digitou) o diretório final deverá ser “C:Arquivos De ProgramasINNO TEST”. Depois da instalação, você pode conferir.

5. Por último ainda, nesta tela, existe uma checkbox permitindo ou não que o usuário mude o diretório padrão. Essa é a opção que, apesar de opcional, SEMPRE DEVE ESTAR ACIONADA. É lógico, ninguém melhor que o próprio usuário para saber onde ele quer instalar o programa. Um último checkbox indica que o programa não precisa de diretório(Eu não consegui imaginar uma utilidade para isso. Deixe-a desativada). Clique “NEXT”.

6. A tela abaixo é uma das mais importantes, e, dependendo do número de arquivos que o seu programa possui, será o lugar onde você gastará a maior parte do tempo fazendo essa instalação. Veja a figura:

Inno Setup - Colocando os arquivos que serão instalados
Inno Setup – Colocando os arquivos que serão instalados

Neste ponto que você irá escolher os arquivos que farão parte de sua distribição, assim como a estrutura de diretórios que fará parte de seu programa. O título “Application main executable file” pede a localização, no seu disco rígido, do arquivo executável. Procure o innotest.exe que estava no pacote que você baixou há pouco e que, provavelmente, você esqueceu de DESCOMPACTAR para executar este tutorial. 🙂

O checkbox que aparece na tela permite que o seu aplicativo inicie logo após a instalação do mesmo ter sido finalizada.

Uma vez colocado o executável, vamos colocar agora todos os arquivos de suporte de seu programa. Veja bem, arquivos de suporte pode ser qualquer coisa. Pode ser uma DLL que deva ser instalada junto com o seu programa, um conjunto de imagens, um conjunto de sons no formato WAV ou MP3, uma página em HTML, ou qualquer outra coisa que você imagine. “Clique” em “Add file(s)” e selecione os arquivos FAQ.txt e clique em “OK”. Repita para os arquivos licença.txt, notas.txt e Console.ico. Selecione na caixa, o arquivo “FAQ.txt”. O Botão “Edit” deverá ficar disponível. Vá em “Edit”.

Nesta janela você poderá otimizar onde cada arquivo que você adicionou a sua instalação deverá ficar. O valor padrão é “Application directory”(diretório padrão do aplicativo), mas você, dependendo do tipo de arquivo, poderá mudar neste mesmo menu, para o diretório default do windows, para o diretório “system32” do windows, caso seja uma DLL, entre outras coisas. No nosso caso, vamos deixar os arquivos no diretório padrão do aplicativo e vamos especificar uma pasta chamada docs dentro do diretório padrão. Para gerar esse diretório, basta colocar “docs” na caixa de texto entitulada “Destination Subdirectory”. Depois de repetir a operação para os outros arquivos. por uma questão prática, mantenha o arquivo “Console.ico” no diretório padrão do aplicativo, clique em “NEXT”.

7. Na próxima tela, estaremos dando uma espécie de ajuste fino na instalação. A primeira coisa que você deve definir é o nome da pasta que aparecerá no menu INICIAR do seu computador. No total, são 6 checkboxes que estarão disponíveis e tem o seguinte significado, de cima para baixo:

  • Permitir que o usuário mude o nome da pasta do menu INICIAR.
  • Permitir que o usuário DESATIVE a criação da pasta no menu INICIAR
  • Criar um atalho de Internet na pasta do programa no menu INICIAR
  • Criar um ícone de DESINSTALAÇÃO na pasta do programa do menu INICIAR
  • Permitir a criação de um ícone no Desktop
  • Permitir a criação de um ícone na Barra de Inicialização Rápida.

Para efeito de aprendizagem, deixe todas as opções acionadas. Em especial, recomendo SEMPRE deixar ativado, em qualquer instalação, a possibilidade de DESINSTALAR o programa. É muito, mas muito chato você instalar um programa, não gostar, e ter que ficar buscando os arquivos para sumir com eles…. :-). Clique em “NEXT”.

8. Estamos quase no final do Wizard. Nesta tela, você vai colocar as informações necessárias para o seu programa poder ser distribuído de forma correta. São 3 arquivos, todos opcionais: “License file” (Arquivo de licença), “Information file shown before instalation” (Arquivo de informações a ser mostrado antes da instalação) e “Information file shown after instalation” (Arquivo de informação a ser mostrado depois da instalação). Basicamente, são arquivos em “.txt” ou mesmo “.htm” que você deverá escrever caso tenha alguma restrição no uso do programa (licença), e informações de ultima hora que devem ser mostradas antes e/ou depois da instalação, como alterações do sistema e outras informações úteis. É importante lembrar que, apesar do arquivo a ser anexado aqui ser um “. txt”, o Inno reconhece endereços de internet começados por “http://”. Então, sinta-se à vontade para colocar endereços de internet na instalação. No nosso caso, coloque o arquivo “licença.txt” no lugar apropriado a licença e “notas.txt” em ambos os campos de informação (Não é um problema isso).

9. Clique “NEXT” e logo em seguida, “FINISH”. O Inno Setup perguntará se você deseja compilar o script nesse momento. Clique sim. Ele pedirá um nome de arquivo para salvar o script. Salve ele no mesmo diretório do nosso PACOTE DE PROGRAMAS. O SCRIPT será compilado. A instalação estará dentro de uma pasta chamada “OUTPUT” neste diretório.

O SCRIPT

Se você fez tudo direito, deverá ter um script parecido com o abaixo (algumas coisas devem estar diferentes, como os diretórios):

[php][Setup]
AppName=INNO TEST
AppVerName=INNO TEST v1.0
AppPublisher=XUTI GAME DEVELOPMENT
AppPublisherURL=http://www.xuti.net/
AppSupportURL=http://www.xuti.net/
AppUpdatesURL=http://www.xuti.net/
DefaultDirName={pf}INNO TEST
DefaultGroupName=INNO TEST
AllowNoIcons=yes
LicenseFile=C:Documents and SettingsBrunoDesktopinno testelicença.txt
InfoBeforeFile=C:Documents and SettingsBrunoDesktopinno testenotas.txt
InfoAfterFile=C:Documents and SettingsBrunoDesktopinno testenotas.txt[/php]

A seção [setup] tem os parâmetros referentes a instalação em si, como o nome do programa, nome de diretório padrão, e links para a página do produtor do programa. Em especial, existem 3 link iguais na instalação padrão: AppPublisherURL, AppSuportURL e AppUpdatesURL. Não me lembro se todas estas opções estão disponíveis sob windows 98/Me, mas sob WindowsXP eles tem diferença. O AppPublisherURL é a página que estará no atalho a ser criado na instalação. O AppSupportURL e AppUpdateURL são, respectivamente, as URL para Suporte do programa e Updates deles. No Windows XP, você pode acessar essa páginas através da janela “Adicionar/Remover programas”.

[php][Tasks]
Name: "desktopicon"; Description: "Create a &desktop icon"; GroupDescription: "Additional icons:"
Name: "quicklaunchicon"; Description: "Create a &Quick Launch icon"; GroupDescription: "Additional icons:"; Flags: unchecked[/php]

A seção [tasks] é onde estão as informações sobre ícones a serem criados na instalação.

[php][Files]
Source: "C:Documents and SettingsBrunoDesktopinno testeinnotest.exe"; DestDir: "{app}"; CopyMode: alwaysoverwrite
Source: "C:Documents and SettingsBrunoDesktopinno testeFAQ.txt"; DestDir: "{app}docs"; CopyMode: alwaysoverwrite
Source: "C:Documents and SettingsBrunoDesktopinno testelicença.txt"; DestDir: "{app}docs"; CopyMode: alwaysoverwrite
Source: "C:Documents and SettingsBrunoDesktopinno testenotas.txt"; DestDir: "{app}docs"; CopyMode: alwaysoverwrite
[/php]

A seção [files] é a relação dos programas que você irá instalar na máquina do usuário. Os diretórios que aqui estão são referentes a *SUA* máquina. A TAG DestDir é o diretório onde os arquivos serão instalados na máquina do usuário.

[php][INI]
Filename: "{app}innotest.url"; Section: "InternetShortcut"; Key: "URL"; String: "http://www.xuti.hpg.com.br"[/php]

A seção [INI] cria o atalho para a página do produtor.

[php]
[Icons]
Name: "{group}INNO SETUP"; Filename: "{app}innotest.exe"
Name: "{group}INNO SETUP on the Web"; Filename: "{app}innotest.url"
Name: "{group}Uninstall INNO SETUP"; Filename: "{uninstallexe}"
Name: "{userdesktop}INNO SETUP"; Filename: "{app}innotest.exe"; Tasks: desktopicon
Name: "{userappdata}MicrosoftInternet ExplorerQuick LaunchINNO SETUP"; Filename: "{app}innotest.exe"; Tasks: quicklaunchicon
[/php]

A seção [Icons] cria a pasta dentro do menu INICIAR do windows.

[php]
[Run]
Filename: "{app}innotest.exe"; Description: "Launch INNO SETUP"; Flags: nowait postinstall skipifsilent[/php]

A seção [Run] cria o atalho para o arquivo executável.

[php][UninstallDelete]
Type: files; Name: "{app}innotest.url"
[/php]

A seção [UnistallDelete] cria o atalho para o programa que fará a desinstalação do programa.

UMA PEQUENA PERSONALIZAÇÃO

Para COMPILAR o script, clique na tecla RUN, na parte de cima do programa (Ela parece uma tecla PLAY de um video cassete). Você poderá instalar o seu programa na sua máquina nesse momento se assim desejar e testar a instalação.

Algumas coisas fiz de propósito. Alguém reparou que o programa não possui ícone, apesar dele estar no diretório?(Ao menos pedi para que vocês o incluísse na instalação…).

O Inno não associa diretamente os ícones e outras coisas ainda precisam ser personalizadas. Esse script é uma forma geral dele, e ele deverá ser modificado. Existem vários comando para isso, bastando separar por ponto-e-vírgula. Alguns deles são:

  • WorkingDir: “{app} (directory)” : Esse comando, colocado no final do arquivo, na seção [Icons], criará o diretório em que o programa/arquivo trabalhará. No nosso script, poeria ser algo como:

Name: “{userdesktop}INNO SETUP”; Filename: “{app}innotest.exe”; Tasks: desktopicon; WorkingDir: “{app}”

Significa que o nosso programa usará, como padrão, o seu próprio diretório. Devo lembrar que isso é especialmente útil se você estiver pensando em distribuir seu programa para computadores com Windows XP. Normalmente, o Inno NÃO faz isso automaticamente no XP e isso pode causar alguns bugs indesejáveis.

  • IconFilename: “{app}(Icon)”: Esse comando irá associar um ícone ao arquivo em questão. Também é usado normalmente na seção [Icons]. No nosso programa, alterando a mesma linha anterior, ficaria(lembre-se que, quando você associar um icone, deverá fazê-lo para cada arquivo manualmente. No exemplo é para ícone do desktop):

Name: “{userdesktop}INNO SETUP”; Filename: “{app}innotest.exe”; Tasks: desktopicon; WorkingDir: “{app}”; IconFilename: “{app}Console.ico”

  • WizardImageFile=myimage.bmp : Na seção [Setup], personaliza a figura no início da instalação. Coloque esse comando no seu script e associe ao arquivo Inno.bmp que está no pacote qu você baixou. O tamanho da figura que você criou pode ter no máximo164x314 de dimensões. Deverá ser no formato BMP.
  • MessagesFile=compiler: (file.isl) : Com esse comando na seção [Setup] você pode personalizar as mensagens da instalação. O default é usar mensagens em inglês. Com o arquivo apropriado NO DIRETÓRIO DO PROGRAMA, você poderá TRADUZIR a sua instalação.

Existem outras opções que você poderá utilizar para personalizar suas instalações. No momento, manterei apenas estas. Consulte o HELP do programa para uma lista completa das funções.

Inno Setup - Seu projeto personalizado
Inno Setup – Seu projeto personalizado

O que é um adventure?

Apprentice I

O jogo de aventura, ou simplesmente adventure, termo em inglês como é conhecido, é o tipo de jogo mais próximo de uma narrativa que você encontrará por ai.

Narrativa? Sim, pense num filme. Imagine que você é o ator principal deste filme e que você deve ter determinadas ações e que por isso, obterá respostas deste filme. Você já está com o início da idéia do adventure em sua cabeça.

COMEÇANDO PELO COMEÇO

Existe alguma controvérsia acerca de qual foi o primeiro adventure publicado num computador, mas a grande maioria das pessoas aceita (e deve ser verdade) que o primeiro adventure publicado foi o Colossal Caves  (também conhecido como advent) de Will Crowther, em 1976.

O jogo, inteiramente em modo texto, fez muitos fãs e conquistou muitos usuários tentando desvendar seus mistérios e fez história: Um dos jogos mais conhecidos do console ATARI foi inspirado nele. O nome do jogo? Adventure .

Mas foi Scott Adams quem popularizou o gênero. Aliás, ele mesmo se intitula “o criador da Indústria de jogos para computadores”, não somente popularizou o gênero adventure, mas seus adventures popularizaram os jogos de computador de forma geral. Sua empresa, a “Adventure International” funcionou de 1978 a 1984, portando seus adventures para as mais variadas plataformas. Seus jogos clássicos podem ser baixados, gratuitamente, em sua página na Internet .

Uma empresa que nasceu nesta mesma época e que conhecemos (e sobreviveu) até os dias atuais é a Sierra  Entertainment, que começou com o nome de Sierra On-line, em 1980, e hoje um dos grandes selos de jogos de computador.

Em terras tupiniquins, o jogo primeiro jogo de adventure no Brasil foi o Amazônia, desenvolvido por Renato Degiovani . Aliás, não só o primeiro adventure, mas é considerado o primeiro jogo comercial brasileiro.

MAS AFINAL, O QUE É UM ADVENTURE?

Expliquei sobre a origem, mas acabei por não explicar o que é um adventure. Adventure é um jogo onde existe uma história onde você é direcionado a participar dela, não apenas como um pano de fundo, mas de uma forma imersiva, que pode até mesmo ser comparada a experiência de ler um livro ou assistir a um filme.

O adventure faz com que o jogador, ao mesmo tempo em que está imerso num determinado ambiente de jogo, pode explorá-lo, realizando ações e vendo suas conseqüências. Ou seja, é um jogo baseado em ações, que, diferentemente dos jogos estilo DOOM, não basta fazer algo, mas compreender como determinada coisa funciona.

Jogos de adventure tratam de estórias, resolver problemas e charadas, além de explorar mundos, seja ele qual for. Logo, não se trata de atirar indistintamente nos inimigos na tela, mas um jogo, geralmente mais cadenciado, onde a inteligência e perspicácia do jogador são avaliadas a cada momento.

Podemos conceituar então que adventure são jogos com objetivo em resolver problemas dentro de um foco narrativo. Existe algum elemento de ação nos adventures, mas eles não são essenciais e nem mesmo obrigatórios.

O importante é o enfoque do jogo. O que difere os adventures de outros gêneros de jogos é que a principal razão de ser do jogo é resolver um problema, em um mundo a ser explorado.

É inegável que muitos jogos podem conter (até mesmo propositadamente) elementos de adventure. Puzzles/Enigmas são inseridos em muitos jogos até mesmo para poder ter um conteúdo e uma história que entretenha o jogador. Contudo não se pode dizer que o clássico Mario Bros, apesar de ter um mundo a ser explorado e existir algumas tarefas/puzzles a serem feitos, seja um adventure, pois o enfoque dele não são os problemas, mas o jogo de ação com habilidade no controle do jogo.

Também não devemos confundir o adventure com um RPG, apesar de sua tênue diferença. Não são os elementos comuns que os distinguem, mas os elementos que o RPG tem a mais que o diferencia.

O RPG possui um sistema de pontuação e nível dos participantes onde você não pode fazer determinada tarefa simplesmente porque você não possui o nível desejado, ou seja, necessita desenvolver o seu personagem sendo este, inclusive, um dos objetivos maiores do jogo para poder prosseguir e desenvolver a história. No adventure não existe nível do jogador, mas um mundo inexplorado e que, para ter acesso a uma determinada área, pouco importa se você possui nível 8 ou 80, mas apenas se você é capaz de desenvolver e resolver determinado problema.

ELEMENTOS DE UM ADVENTURE

Podemos, portanto, definir três características presentes em todos os adventures, variando, de caso em caso, o enfoque maior em um ou outro elemento:

  • NARRATIVA: Nos adventures a linha narrativa é de vital importância. Dentro de determinado foco, o jogo se desenrola e o faz o jogo ter determinada direção. Ajuda, inclusive, ao jogador esperar por determinado tipo de puzzle. No jogo “The Dig” o objetivo é sair de um planeta desconhecido onde você foi transportado, após uma escavação no espaço. No jogo Amazônia, o objetivo é achar a saída da floresta após um acidente aéreo, evitando índios e outros problemas da floresta. No jogo “Laisure Suit Larry”, você é um estudante universitário que precisa conseguir garotas. Enfim, a gama de histórias em adventures são gigantescas, passando da vida pós morte até detetive de eventos paranormais. Adventures possuem a  (ótima) fama de terem histórias realmente criativas.
  • PUZZLES/PROBLEMAS: Os problemas são o grande enfoque dos adventures. Diversos são os tipos de problemas, como os puzzles de inventário, onde você deve arrumar itens que você possui a sua disposição com outros, encontrando a resposta desejada; puzzles de diálogos, onde a grande sacada é conseguir informações conversando ou persuadindo personagens a dar alguma direção ou resposta que você deseja; puzzles não contextuais são os puzzles existentes no jogo que necessariamente não possuem relação com a trama/história, como por exemplo, um jogo de xadrez onde você deve fazer alguns lances. As regras do xadrez não dependem se o jogo é sobre piratas ou de alienígenas invadindo o planeta. Ele é resolvido independentemente de história.
  • EXPLORAÇÃO: Jogar um adventure requer exploração de um território/local para que ele possa se desenvolver. O quanto essa exploração é necessária depende de cada jogo e da forma como ele foi concebido. As interfaces mais antigas de adventures, baseadas em texto, normalmente utilizavam indicações como “norte”, “sul”, “oeste” para indicar a movimentação do jogador. Em grande parte das vezes, os objetos estão visíveis nos lugares onde o jogador passa ou não são muito complexos de se encontrar.

Em adventures mais modernos, com interfaces gráficas, é possível encontrar objetos de uma forma mais sofisticada, como dentro de caixas, onde somente é possível verificar a existência deste objeto se você “tocar” o local correto (hotspot).  Em adventures 3d, é comum a exploração mais acurada de objetos e salas, sendo , muitas vezes, necessário circundar determinada coisa para encontrar o hotspot apropriado.

ONDE COMEÇAR A JOGAR E ALGUNS CLÁSSICOS

Alguns jogos fizeram história e devem ser mencionados aqui, ainda que a título de registro apenas. Nos títulos dos jogos, você poderá encontrar um link para o jogo, disponível na internet:

A lista de jogos é enorme. Colocamos aqui somente alguns jogos disponíveis de forma gratuita. Recomendamos também jogos como Maniac Mansion 2 – Day of the Tentacle, Indiana Jones and fate of Atlantis, The Dig, Full Throttle, Grim Fandango e a série Monkeu Island, todos da Lucas Arts . Alguns outros títulos também merecem ser citados, como as séries Leisure Suit Larry, King’s Quest e Space Quest, todos da Sierra.

Se você conseguir alguns desses jogos, em vários casos estes não funcionarão em sistema recentes, como Windows XP. No caso dos adventures da Lucas Arts, é possível contornar isso utilizando o ScummVm , um projeto Open Source visando emular o engine Scumm, que é o motor dos adventures da Lucas Arts.

GOSTOU? QUER FAZER O SEU?

Se você gostou das histórias, talvez você possa contar suas próprias histórias. Como foi possível perceber, jogos do tipo adventure comportam qualquer tipo de história, onde a criatividade de quem faz o jogo é o limite.

Convenhamos: fantasmas, agentes secretos, salvar reinos, entre outros, são grandes temas, mas muitas vezes soam um pouco falsos seja porque a história é mirabolante demais, seja porque o jogo é importado e às vezes algumas piadas não pegam bem aqui como lá fora. Que tal você fazer um jogo com a sua cara?

Talvez trabalhar como agente do FBI não seja a coisa mais interessante do que um moto boy tentando entregar um pacote num prédio de escritórios ou a aventura de um trabalhador que precisa simplesmente chegar ao trabalho, indo da Zona Leste de São Paulo até a Zona Oeste. O que você acha?

Apresentamos aqui duas alternativas para você criar o seu próprio adventure: O Sistema Editor e o Adventure Game Studio(AGS).

ADVENTURE GAME STUDIO

Desenvolvido principalmente por Cris Jones, o Adventure Game Studio  ou simplesmente AGS é um sistema de edição de adventures com um nível de complexidade médio. A boa notícia é que ele é gratuito. A má notícia é que para fazer adventures nele é necessário algumas boas horas de estudo para conseguir efeitos realmente bonitos.

Adventure Game Studio
Adventure Game Studio

É um bom sistema para fazer jogos “point and click” e até mesmo jogos com interface texto. Entretanto, esqueça resultados rápidos. O jogo requer imagens e um jogo bem feito, sincronizado e com efeitos, digamos, nos padrões que ele exige, requer tempo. Enfim, é uma ótima escolha se você se dá bem com scripts e programação em geral e tem um mínimo cuidado gráfico. O jogo ‘apprentice’ recomendado anteriormente foi inteiramente desenvolvido no AGS se destacando, de forma geral, entre uma grande parte dos desenvolvedores independentes de Adventures. Além do Apprentice, citamos o excelente FATMAN e vários jogos que estão ainda em desenvolvimento. Vale a pena conferir a seção de links e jogos do site do AGS.

Adventure Game Studio – http://www.adventuregamestudio.co.uk/

SISTEMA EDITOR

O sistema Editor é quase tão antigo quanto o jogo Amazônia. Desenvolvido por Renato Degiovani (TILT – http://www.tilt.net), o sistema Editor é uma ferramenta brasileira que promete auxiliar a você que deseja fazer seu próprio adventure de uma forma sem complicação e com poucas linhas de código.

Sistema Editor - da brasileira Tilt
Sistema Editor – da brasileira Tilt

Com absoluta certeza o grande diferencial deste editor é que ele fala a nossa língua. Em outras palavras, o criador do jogo fala Português sem sotaque. Isso significa que qualquer dificuldade com o programa e mesmo sugestão de novos recursos podem ser feitos diretamente com o autor, de modo a facilitar não somente o suporte do programa, como no próprio desenvolvimento de seu jogo e sua idéia.

O jogo cria interfaces de texto e gráficos onde, com auxílio de imagens, você poderá criar seu adventure. O jogador expressa sua vontade por meio de textos, geralmente usando verbo e substantivos, como “PEGUE A CANETA”. É um sistema interessante para quem não tem tanta intimidade com programação e ainda assim quer fazer seu jogo.

Convidamos o leitor a conhecer esse sistema que por um preço bem acessível (na época deste texto, com valor inferior a R$10,00) para os padrões brasileiros, você poderá adquirir o Editor e fazer seu próprio jogo.

TILT – http://www.tilt.net

FINALIZANDO

Existem muitas opções de adventures na internet, passando de meros grupos independentes que gostam do gênero até complexos jogos de empresas como ATARI e Sierra. Para quem gosta de jogos desafiadores, esse realmente é um gênero que merece especial atenção e, se você desejar, já tem a indicação para criar o seu próprio adventure. Boa sorte!

—————

NOTAS DO TEXTO

1. Este documento é protegido pela Lei 9.610/98 (Lei dos Direito Autorais) e foi escrito unicamente para os leitores da página da XUTI GAME DEVELOPMENT (http://www.xuti.net). Apesar de distribuído gratuitamente na página em questão, é terminantemente proibida a inclusão deste texto em qualquer produto distribuído de forma paga ou gratuita, sob qualquer título, sem a expressa autorização do autor.

2. Tipos de puzzle extraído do texto “What are adventure games?” de Marek Bronstring, disponível no seguinte endereço eletrônico: http://www.adventuregamers.com/article/id,149 (Acesso em 13 de Outubro de 2005).

Extreme Programming em Programação de Jogos (Com comentários a filosofia GNU)

Extreme Programming (usualmente chamado de XP) é uma “nova” metodologia para o desenvolvimento de programas e que tem conquistado muitos adeptos recentemente.

Mas o que de fato há de novo nessa metodologia? O que podemos ganhar com ela? Como podemos aplicar seus preceitos fundamentais ao desenvolvimento de jogos? Quais as suas relações com o método de se desenvolver programas usados pela filosofia GNU, que também tem repercutido muito nesses últimos tempos?

É para tentar responder tais perguntas e, acima de tudo, desmitificar o XP que escrevemos esse pequeno texto. Para isso, vamos explicar inicialmente alguns dos conceitos que julgamos fundamentais no XP, mostrando aplicações e possíveis modificações a produção de jogos, que sabemos possui suas próprias particularidades.

A metodologia XP pode ser resumida como uma coletânea de boas práticas no desenvolvimento de programas, que normalmente todo desenvolvedor profissional já conhece, mas que raramente encontrávamos em prática sistematicamente.

É esse, provavelmente, o grande mérito dessa nova metodologia: ela sistematizou a aplicação de procedimentos reconhecidamente produtivos e chamou atenção para isso. Entre esses procedimentos estão todos os seus pilares teóricos: a coletânea de histórias dos usuários, a programação aos pares, os testes sistemáticos e o acesso total do código a todos os desenvolvedores.

COLETÂNEA DE HISTÓRIAS DOS USUÁRIOS

Todos sabemos que um bom programa deve satisfazer as necessidades do usuário. Entretanto, outras técnicas tradicionais como as de se criar inicialmente uma interface e design com a ajuda do usuário para então codificar-se as rotinas propriamente ditas têm como grande problema o fato de que inúmeras vezes o usuário acaba esquecendo alguns itens importantes e/ou incluindo alguns que ele julga serem necessários em um sistema, sem de fato estar pensando em sua utilização. Com isso, são gerados muitos ciclos de retrabalho, com elevados custos.

Com a metodologia XP, tenta-se manter essa idéia de voltar-se para as necessidades do usuário, mas de uma forma indireta, evitando assim muito do retrabalho. Para isso, são documentadas histórias dos usuários sobre como utilizam o sistema e/ou realizam suas tarefas, e estas são então usadas como guia para o trabalho em si.

Esse tipo de pensamento está também incluído, em geral, na filosofia de desenvolvimento GNU. Os programas assim desenvolvidos costumam justamente surgir da necessidade de alguém automatizar uma tarefa e/ou mudar a forma como ela é feita com base em alguns relatos. Ainda, a manutenção de tais programas costuma contar com a cooperação de diversos usuários que utilizam o programa e fazem assim a requisição de novas funcionalidades, em um ciclo parecido com o descrito, embora mais informal e certamente mais distribuído.

Esse é, também, o ponto mais complicado para uma aplicação imediata à programação de jogos. Enquanto continua válido para aspectos comuns do desenvolvimento de jogos, como as partes técnicas de entrada de dados, configuração dos jogos, etc.; esse ponto é muito dificilmente aplicável ao núcleo do jogo e sua história em si, pois um jogo assemelha-se nesse ponto mais a uma “obra de arte” do que a um software comum.

PROGRAMAÇÃO AOS PARES

É, talvez, o ponto em que realmente poderíamos dizer que a metodologia é nova. Encontrar programadores trabalhando realmente aos pares, codificando juntos uma mesma parte de um projeto é realmente raro. Certamente é mais raro ainda na filosofia GNU, pois nesta normalmente os grupos de desenvolvimento estão espalhados pelo mundo.

Programar com um parceiro pode parecer, inicialmente, um processo altamente ineficiente. Entretanto, como a nossa própria experiência mostra, mostra-se de fato uma saída eficiente e com muitas vantagens agregadas. Nesse contexto, o código costuma ser mais claro e eficiente, pois ele é melhor planejado e discutido e também evitam-se “acomodações” na implementação, pois seu parceiro está acompanhando. Consegue-se também evitar a criação de “ilhas de código”, onde apenas um programador tem conhecimento de como funciona determinada fatia do código.

Esses pontos são fundamentais no desenvolvimento de jogos também, onde a equipe de programadores é usualmente pequena, e assim a perda de qualquer membro pode ser altamente perigosa para o progresso do projeto.

É interessante notar que na filosofia GNU essa prática é muito rara, mas ainda assim, dada a grande exposição do código – que fica aberto ao mundo – e a um uso freqüente de fóruns/listas e a divisão do trabalho em grupos pequenos, conseguem-se efeitos similares em diversos projetos. Entretanto, os aspectos motivacionais da criação e desenvolvimento nesses dois contextos são muito distintos, e assim mereceriam maior atenção em uma análise mais profunda.

TESTES SISTEMÁTICOS

Fundamentais, e usualmente deixados como um “último passo”, os testes são uma ferramenta extremamente poderosa de se detectar falhas e também funcionalidades esquecidas mas extremamente importantes. Por isso, uma filosofia de testes periódicos e detalhados deve ser planejada. Além disso, não se deve quebrar o código, i.e., não se deve permitir alterações no código que o reprove nos testes até aquele ponto.

Essa prática pode ser implementada de diversas formas. No desenvolvimento de jogos implica, normalmente, em ter versões de desenvolvimento do seu jogo até determinado ponto e um grupo de voluntários para testá-lo e fornecer o feedback sobre todos os itens importantes, como a jogabilidade, aparência do jogo, desenvolvimento da história, estabilidade do programa, etc.

Em programas segundo a filosofia GNU, ela é posta em prática imediatamente: cada versão do programa está sempre disponível para testes e uso tão logo quanto criada, e há grupos de usuários que testam exaustivamente os programas. Além disso, muitas vezes são criados também scripts e testes padrão para o desenvolvimento de versões iniciais e/ou novas funcionalidades.

Uma rotina de testes bem definida possibilita, assim, um desenvolvimento estável e diminui sensivelmente o risco de ser preciso reprogramar grandes partes do projeto por ter se identificado perto do final algum grande problema ou funcionalidade vital que foi deixada para trás.

ACESSO TOTAL AO CÓDIGO DOS DESENVOLVEDORES

Este ponto é cada vez mais comum aos desenvolvedores com o fortalecimento da filosofia GNU no mundo, pois nela o código está totalmente acessível a qualquer pessoa interessada.

As vantagens são muito interessantes, mesmo quando o código é disponível somente à equipe do projeto. Possibilitando que o código seja totalmente acessível, aumenta-se a integração do código e da equipe, e diminui-se implementações duplicadas para funções comuns, por exemplo. Também torna mais uniforme a estrutura e apresentação do código, bem como evita que o trabalho de um grupo quebre o de outro.

Mas não é só para a leitura do código que usamos a palavra “acesso”. Qualquer programador pode atuar em qualquer parte do código, possibilitando assim que partes complicadas recebam maior atenção e que otimizações e novas idéias venham da equipe como um todo. Também torna ainda mais difícil a criação de “ilhas de código”, e de forma muito eficiente, ainda mais quando praticada em conjunto com a programação aos pares.

Todas essas vantagens são claras também no desenvolvimento de jogos.

OUTROS ASPECTOS IMPORTANTES E LIMITAÇÕES

Deve-se notar que utilizamos muitas vezes as palavras “desenvolvimento” e “programação” nesse texto sem uma distinção precisa. De fato, os pontos citados da metodologia XP visam principalmente a programação e não o desenvolvimento de um programa, com exceção da coletânea de histórias dos usuários.

Principalmente para o desenvolvimento de jogos, então, devemos notar que é uma distinção muito relevante, e que mostra muitas limitações da metodologia XP, principalmente quando notamos que a coletânea de histórias dos usuários é justamente o ponto menos relevante da metodologia no desenvolvimento de um jogo. Jogos requerem muitos outros trabalhos: roteiros, gráficos e efeitos especiais, sons, etc. Isso torna o desenvolvimento de jogos muito longe de simplesmente programação, ao contrário de um grande número de tipos de softwares por aí, e torna portanto a metodologia XP limitada a somente uma parte do ciclo de desenvolvimento.

Além disso, vemos que pode-se realmente pensar que há poucas novidades na metodologia XP, até se comparada à filosofia GNU de desenvolvimento, pois os principais preceitos da filosofia GNU já incluem a grande maioria dos pontos destacados pela metodologia XP. Entretanto, a metodologia XP consolida diversos aspectos importantes para a programação profissional e, principalmente fora do “mundo GNU”, chama a atenção para diversos pontos que são usualmente esquecidos.

Isso não significa que devamos ignorar essa metodologia e jogá-la em uma lata de lixo. Programar continua sendo uma das partes fundamentais do desenvolvimento de um jogo, e uma boa metodologia para a mesma possibilita inclusive uma maior integração com os demais itens do desenvolvimento, possibilitando resultados finais muito melhores. Este pensamento é particularmente verdade quando pensamos que muitos dos desenvolvedores de jogos nacionais são grupos onde os programadores não são “só″ programadores.

Dicas para se fazer um jogo de computador

ANTES DE COMEÇAR…

Lembre-se de que jogos de computador são o conjunto de várias artes diferentes formando uma só. A idéia de arte é altamente subjetiva, por isso você nunca irá agradar a todos. Entretanto tenha em mente de que se a sua intenção for criar um jogo por remuneração, e não prazer, seu trabalho terá que ter um público alvo e satisfazê-lo. Defina seu objetivo e seu público alvo antes de começar.

Preocupe-se em descobrir suas limitações antes de começar a criar seu jogo. Se você não sabe fazer algo necessário ao seu projeto, você tem que aprender a fazer ou aliar-se imediatamente a quem saiba. O seu trabalho ficará muito mais difícil se você tiver que aprender algo ou procurar por algum talento durante a fase de produção. Meu projeto levou três meses para ser concluído, mas acredito que poderia ser feito em menos da metade do tempo caso eu já tivesse os elementos que faltavam antes do início da produção: conhecimento sobre efeitos sonoros e música.

Comece um projeto com a certeza de que você pode terminá-lo. É melhor um Jogo da Velha completo do que um Doom IV em seus sonhos. Você precisa de uma boa estrutura de produção e de boas idéias. Entretanto tenha em mente que você pode compensar a falta de idéias com uma ótima estrutura de produção (é o que acontece com praticamente todas as empresas de softwares profissionais criando clones dos mesmos jogos de sempre só que com mais tecnologia), ou a falta de estrutura de produção com ótimas idéias (Tetris). Se você não tiver nem idéias, nem estrutura de produção, o máximo que você conseguirá é um jogo com gráficos e sons fracos e sem nenhuma jogabilidade. Não tente fazer sem dinheiro, sem conhecimento técnico e sem tempo, um trabalho igual ao de uma empresa com recursos, meses disponíveis e profissionais especializados.

Um jogo de computador é composto de ENTRADA / PROCESSAMENTO e SAÍDA, assim como qualquer coisa em informática. Você deve saber receber os dados via teclado, mouse e/ou joystick (entrada), atualizar os dados do jogo em função da entrada recebida (processamento) e por último mostrar as imagem e o som (saída). Contudo, estes devem ser vistos apenas como os conhecimentos básicos. Tenha em mente que é fácil fazer um efeito de vídeo, ou tocar um som, ou receber a entrada de dados do joystick, etc. O que é realmente difícil é sincronizar todas as rotinas de maneira perfeita, impedindo uma entrada de dados errada (não captar o movimento do jogador, por exemplo), um processamento errado (ativar algo fora da hora, não detectar uma colisão, etc.), ou uma saída errada (imagens fora do lugar, som fora de hora, etc).

Um jogo inicializa seus dados, carrega o que precisa, vai para a tela de título e de lá ou começa o jogo ou volta para o sistema operacional. Ao acabar o jogo, voltará para a tela de título. Isto é o básico da lógicade programação de jogos. Se você pretende incluir mais coisas (menu de opções, galeria de imagens, recordes, etc.), é melhor imaginar o fluxograma antes de começar. Mas isso não é tudo, lembre-se de que o bloco principal do jogo é a parte mais complexa de toda a estrutura.

Planeje sempre, escrevendo tudo o que puder antes de começar a trabalhar. Você pode remendar seu código para implementar uma característica nova no jogo depois, mas tenha em mente que remendar dá muito mais trabalho do que escrever algo que já estava em seus planos. Ex.: meu jogo teria modo de dois jogadores, que não foi implementado porque ao me lembrar disso, o programa estava em um estado de montagem que teria que ser praticamente reconstruído para suportá-lo.

Ao colocar uma estrutura FOR, IF, WHILE, REPEAT, etc., automaticamente feche o final da sua estrutura e depois comece a escrever sua parte interna, tudo devidamente indentado. Tive diversos problemas ao esquecer de fechar uma estrutura, e depois procurar atentamente por toda a listagem do programa até descobrir onde estava o erro. Afinal, devo ter até umas cinco estruturas uma dentro da outra em algumas partes do meu jogo.

Grave seu trabalho em mais de um diretório, em mais de um meio de armazenamento, e se possível, em mais de um lugar (em casa e no trabalho). Grave cada dia de alteração de seu fonte em um arquivo diferente (e diretório, preferencialmente). Assim, você não perderá muito trabalho no caso de uma alteração em seu código comprometer seu funcionamento.

Faça o seu programa o mais modular possível. É mais fácil corrigir ou melhorar algo que apareça freqüentemente em seu programa se estiver em uma função separada.

Opções de jogo (dificuldade, volume de som e música, etc.) devem obrigatoriamente ser variáveis globais. Assim, estarão disponíveis para alteração a cada momento com facilidade, e servirão bem para a construção de um menu de opções no seu jogo.

Ao incluir a entrada de dados em seu jogo, não se esqueça de incluir teclas para avançar de fase automaticamente, conceder imunidade, vidas, etc. Isso vai poupar muito na hora de depurar os erros (i.e.: você não perderá tempo até chegar em uma fase para checar se ela está como você quer). Se quiser, faça estas teclas atreladas a uma variável global no início do programa, para que você possa ativar ou desativar os macetes rapidamente na hora de compilar uma versão final do software.

Seu jogo pode ficar muito mais divertido com apenas um simples ajuste nos valores das variáveis (dificuldade, velocidade dos inimigos, número de vidas, etc.).

Ao incluir um novo elemento de jogo, trace uma “teia mental” de quais outros elementos podem ser afetados por sua inclusão. Você deverá imediatamente checar toda esta teia. Muitas vezes uma pequena alteração praticamente invalidou outras partes do jogo.

Você não deverá ser o único beta-tester de seu jogo. Outras pessoas irão inspecionar seu jogo melhor do que você (para o pai, o filho vai ser sempre o mais bonito), e irão jogar de maneira diferente de você. Não tenha dúvidas de que irão achar erros que você não acharia.

Gaste parte do seu tempo desenvolvendo ferramentas para seu programa. É proveitoso gastar um dia inteiro trabalhando para resolver o trabalho de uma hora, se você faz o trabalho de uma hora várias vezes.

Quando algum colega vê o seu software, existem vários tipos de reação possível a ele… “interessante”, “maneirinho”, e “c******! Tem até o …”. O “interessante” significa fraco. O “maneirinho” quer dizer regular. E se alguém diz “C****** ! Tem até o detalhezinho da mosquinha pousando em cima da mesa!” ou frase parecida, significa que seu jogo está realmente ficando bom.

Quanto aos gráficos e som: assistindo ao jogo, as pessoas analisam detalhes. Jogando, elas vêem o jogo como um todo. Tenha em mente que gráficos e sons detalhados chamam a atenção do jogador antes de começar, e o ajudam a manter imerso no jogo após começar. Gráficos são particularmente importantes para jogos comerciais: ninguém compra um jogo com imagens feias na embalagem. Ou seja, os gráficos não são tão importantes quanto uma boa jogabilidade, mas com certeza eles vendem o jogo.

Gaste mais tempo concentrando-se na jogabilidade do que na tecnologia. Aquele jogo com altíssima tecnologia em 3D em tempo real, som surround, atores de Hollywood e controles que não respondem direito jamais vai ser tão divertido quanto um jogo de Atari.

Se você quer fazer um jogo para se divertir, faça-o do jeito que você gosta. Se você quer fazer um jogo para ser vendido, faça-o do jeito que os outros gostam.

Todo mundo gosta de jogos de computador. Aquela pessoa que diz que odeia jogos de computador muito provavelmente não conhece o jogo que gosta.

Seja original no seu jogo. Ninguém joga aquilo que já enjoou. Há alguns anos atrás, li em uma matéria na antiga revista CPU MSX uma frase que guardo até hoje: “Não digo que você não possa fazer o seu próprio PacMan. Faça-o, mas de uma maneira diferente do que todos nós já conhecemos”. Lembre-se de que os jogos no mesmo estilo de sempre podem até vender, mas os jogos recordistas eram diferentes do conhecido: Tetris, Wolfenstein 3D, Asteroids, Space Invaders, Grand Theft Auto, etc.

No seu jogo, nunca mostre todos os elementos disponíveis de cara. Vá gradualmente introduzindo novas características… Este é o melhor caminho para manter o jogador preso. No momento em que as novidades acabarem, o jogo acaba para o jogador.

No caso de um jogo em que o usuário assume um personagem, é fundamental ter um bom personagem e um bom cenário. Ninguém irá querer personificar alguém sem graça, e nem tampouco entrar em um mundo sem nada de interessante.

– Este texto é de autoria de Leandro Correia, escrito em dezembro de 2003. Este texto pode ser distribuído livremente em qualquer meio, comercial ou não, desde que exibido sem alterações.

Fontes: Aprenda a usá-las

Imagem Artigo Fontes 02

Por Alessandro Straccia

Na computação gráfica, a tipologia representa uma área vasta e importante. Desde a primeira prensa de tipos móveis de Guttemberg, lá pelos idos de 1400, o assunto vem evoluído até os dias atuais.

Escolher uma fonte para seu design é uma escolha séria e necessita de um estudo aprofundado em relação às sensações que você quer passar, tipo de material a ser utilizado, peculiaridades da mídia, etc.

Primeiramente, vamos apresentar os tipos de fonte e suas características:

Fontes Script

As fontes Script se aproximam da escrita humana, cursiva. Elas passam uma maior sensação de humanização. Algumas fontes Scripts são mais rebuscadas, sofisticadas, como aquelas que encontramos em diplomas ou certificados. Nesse caso, por serem elegantes, passam também uma sensação de sofisticação e bom gosto. Alguns exemplos:

Imagem Artigo Fontes 01
Fonte Script

Entretanto, por se tratarem de fontes mais rebuscadas, temos um certo problema de leitura. Elas demoram mais para serem lidas. Podem também ser utilizadas para reproduzir a escrita humana, como numa carta à mão livre, ou um rabisco no papel.

Fontes Serifadas

Chamamos de serifa os detalhes que encontramos nas extremidades das letras. São encontradas principalmente na imprensa, sendo que a mais famosa é conhecida como Times. Elas passam uma sensação de solidez, de verossimilhança. Dependendo da forma da fonte e da serifa, conseguimos também uma sensação de elegância e tradição.

Imagem Artigo Fontes 02
Fontes Serifadas

Fontes Não-Serifadas

São fontes mais cruas, mais simples, como a que estamos utilizando neste texto. Sua principal característica é a facilidade e rapidez de leitura: a falta de serifas ou rebuscamentos tornam-na bem simples e eficiente.

Imagem Artigo Fontes 03
Fontes não-serifadas

No entanto, algumas fontes não-serifadas mais finas e com um formato diferenciado conseguem transmitir uma sensação de bom gosto e elegância. Temos o exemplo abaixo:

Imagem Artigo Fontes 04
Fonte elegante

É o tipo de fonte ideal para utilizar quando necessitamos de uma leitura mais rápida ou à distância.

Fontes Fantasia

Sua característica em comum é justamente não ter muitas características em comum! São fontes que representam um tema, uma idéia, em sua própria forma. Podemos encontrar no tema “terror” por exemplo, fontes que suas bordas são “escorridas”, como sangue. Ou então em forma de balão de festa, e por aí vai. Por serem muito específicas, geralmente são de pouco uso nos materiais em geral. É importante que sejam utilizadas com cautela, pois dependendo do tipo de aplicação, fogem completamente ao tema. E outra: geralmente são de baixa leitura. Nem pense em escrever um texto inteiro com essas fontes!

Outros Tipos

Como o assunto é muito vasto, e podemos encontrar fontes de todo o tipo (você pode fazer a sua, se quiser!), teríamos que fazer um estudo muito mais aprofundado sobre o tema!

Fontes Symbol: não podemos considerar como um tipo específico de letra, pois não representam letras! Como o próprio nome diz, representam símbolos, notas musicais, desenhos, ícones, etc. Para o design em geral são importantíssimas, pois servem de referência para a construção de logotipos, criação de ícones e por aí vai.

Imagem Artigo Fontes 05
Fontes Symbol

Fontes Gothic: escrita gótica, são fontes muito rebuscadas e elegantes. Dão a sensação de tradição, de elegância. Sua leitura é muito baixa, cuidado!

Imagem Artigo Fontes 05
Fontes Gothic

Agora, vamos dividir em dois passos a escolha da tipologia.

1. Assunto/sensação

É a sensação que você quer passar, o tema que você está explorando. É necessário uma boa memória para lembrar das fontes (mas nada que o Mapa de Caracteres do Windows não resolva…!), e saber as características das fontes que serão utilizadas. Por exemplo, fontes serifadas (principalmente as da família Times) passam uma sensação de verossimilhança, enquanto fontes script passam uma sensação de humanização.

Procure fazer o seguinte: após analisar a sensação que você quer passar, abra a arte (ou design, ou tela, como preferir) no Photoshop ou no seu editor de imagens preferido. Escreva o texto necessário, e vá alterando as fontes, uma a uma, não deixando cada uma muito tempo na tela (talvez uns 3 segundos para cada esteja bom). Vá analisando as sensações que as mudanças causam em você. Anote os nomes das fontes que se encaixam melhor. Após escolher uns 5 tipos diferentes (ou até esgotar seu “estoque” de fontes), faça o mesmo, só que analisando mais detalhadamente cada fonte escolhida. No começo pode ser uma tarefa meio chata, mas com o tempo você irá se acostumar, e em 5 minutos já terá escolhido a fonte ideal; nada que um bom treino não ajude!

2. Tipo de mídia utilizada

Onde será “veiculada” a sua criação? Será um cartão de visitas, um panfleto, uma página de revista? Ou quem sabe um cartaz, um outdoor, ou até mesmo na internet? É muito importante escolher a fonte certa de acordo com o material a ser criado. Em materiais impressos não temos tantas ressalvas, pois se trata do meio mais difundido. Como o meio geralmente é opaco, não necessita de uma escolha muito específica de tipologia. Só devemos tomar cuidado com duas coisas:

  • Tamanho da fonte: cuidado, fontes muito pequenas ou finas geralmente “borram” em papéis mais porosos (como o de jornal, por exemplo), além de dificultar muito a leitura.
  • Textos muito extensos: além do tamanho da fonte, que deve dar uma leitura gostosa e não forçar a vista do leitor, tome cuidado com os espaçamentos entre as letras, palavras e parágrafos. É sempre bom colocar uma linha em branco entre cada parágrafo, para dar um descanso à vista do leitor. Artifícios visuais, como fotos, gráficos ou ícones também ajudam à deixar a leitura mais leve e mais prazerosa.

Para materiais como panfletos, folders, etc, a regra é a mesma, mas procure utilizar o tamanho das fontes para dar destaque às partes mais importantes do texto.

Cartazes, outdoors e materiais, cuja leitura será feita principalmente à distância: atenção ao tamanho e tipo de letra. Um cartaz escrito com uma fonte gothic dificilmente será lido à distância! Estudos dizem que um outdoor, para ser bem percebido, precisa chamar a atenção em 1 segundo, e ser lido em no máximo 6 segundos. Não adianta encher um outdoor de texto, pois ninguém conseguirá lê-lo no trânsito em apenas 6 segundos!

Por fim, temos os meios eletrônicos, como internet e TV. Nesses dois temos peculiaridades que vamos caracterizar abaixo:

  • TV: meio de baixa resolução, geralmente os textos “pulam” na tela. Não é bom utilizar textos muito grandes ou com fonte muito pequena.
  • Internet: por ser um meio mais informativo e de alta resolução que a TV (além do fato de estarmos sempre perto do monitor), podemos utilizar fontes menores.

Em ambos os meios, devemos atentar ao seguinte fato: o monitor de computador e a tela da TV são meios que emitem luz. Isso já força a vista naturalmente, bem mais que um meio opaco como uma página de revista, por exemplo. Por isso temos que tomar cuidado com textos muito grandes e sem “descanso”. Fontes não-serifadas também são muito utilizadas, por forçarem menos a vista. A fonte Verdana foi desenvolvida especialmente para o uso na internet, lembre-se disso ao formatar seu website!

E sempre vale a dica: use a tipologia com cautela. Aqui também vale a máxima: menos é mais. Não encha um texto com 274 tipos de fontes diferentes, provavelmente vai deixar o leitor zonzo com tanta informação visual diferente! Procure observar os anúncios, revistas, jornais (mas por favor, meios consagrados como Veja, IstoÉ, Folha, Estadão, etc… Está havendo um Boom de novas publicações, e muitas delas sem nenhuma noção visual!). Procure algo que se tenha a ver com o seu objetivo, e observe como foi feito, tente analisar o porquê da utilização de cada fonte. Não copie, utilize como referência apenas!

Esta também é importante: cuidado com os erros de português!! Gramática e concordância são importantíssimos para dar credibilidade ao seu texto. De que adianta um cartaz bem feito, com a tipologia bem aplicada, e um erro de português bem no slogan? É jogar seu trabalho por água abaixo!

Um bom local para achar diferentes tipos de fontes são os CD’s extra que vem com o Corel Draw ou outros programas de desenho. Uma procura básica no Google também pode te ajudar a achar fontes legais.

Uma visão semiótica sobre jogos

Por Dalton Lopes Martins

INTRODUÇÃO

O que diabos tem semiótica a ver com jogos de computadores? Mais ainda, o que significa semiótica? Bem, esse texto tem a pretensão de ser uma contribuição conceitual sobre o que significa semiótica e de que forma esse conhecimento pode influenciar a forma como temos desenvolvido nossos jogos, além de tentar levantar uma análise crítica sobre aquilo que consideramos um campo ainda pouco explorado nos estudos realizados pela equipe de projetos da Xuti: o projeto de interfaces gráficas.

No desenvolvimento de um projeto computacional, muitas vezes partimos diretamente para a implementação do código e nos esquecemos, ou achamos desnecessário, aquela etapa chata e, de certa forma, extenuante, que é a especificação propriamente dita do projeto. Hoje, temos um vasto universo de metodologias, técnicas que se preocupam com essa etapa. No entanto, a maior parte delas se preocupa muito pouco em compreender realmente os fatores humanos relacionados ao projeto e já partem para a especificação de questões essencialmente técnicas, ou seja, de implementação, como a especificação de classes, definição do fluxo de informação, casos de uso, entre outras.

A semiótica possibilita a construção de um corpo teórico conceitual que nos permite analisar a forma como tentamos nos comunicar através de nossos sistemas de informação, aos quais um jogo não deixa de se enquadrar. Através de seu ramo direto, a semiótica organizacional, adquirimos uma série de métodos capazes de nos auxiliarem a identificar esses fatores humanos relacionados a um determinado projeto e que podem trazer uma evolução qualitativa na implementação do próprio projeto, através da forma como encaramos a relação usuário-sistema.

O QUE É SEMIÓTICA ?

A semiótica é a ciência geral das linguagens, segundo Lucia Santaella. Tá, e daí? A questão central aqui é entender o que consideramos linguagem e, provavelmente, expandir esse conceito para que possamos compreender a que a semiótica se propõe. O conceito de linguagem é bastante genérico para que possamos considerar que uma interface computacional é uma linguagem buscando interagir com o usuário, muitas vezes, através de uma metáfora. Como exemplo, podemos citar o caso do ambiente gráfico do Windows, que é uma metáfora de um desktop, ou seja, de uma mesa de trabalho. Essa linguagem se expressa através de signos, como as letras do alfabeto, a morfologia das palavras, a semântica e a sintática na linguagem escrita. Podemos identificar alguns signos como caráter ilustrativo: a lixeira (simbolizando uma lixeira (!!!) onde jogamos papéis inúteis, ou seja, documentos que desejamos apagar), a pasta de diretório (simbolizando um “lugar” onde podemos armazenar nossos documentos), enfim, a lista poderia ser interminável, mas o mais importante nesse momento é se fixar na idéia de signo substituindo algo do mundo real e nos possibilitando interagir através da interpretação pessoal que podemos ter de um determinado signo ou conjunto de signos. É aqui que a coisa fica interessante.

Pois é, certamente se você é um usuário constante de programas de computador já deve ter se deparado com algum símbolo pela frente e não ter a menor idéia do que ele representa. Bem, aqui surge a semiótica como ferramental de análise que pode explicar o por que desse símbolo não ser compreendido, quais são as suas deficiências, e, principalmente, o que poderia ser sugerido como contraposição para tornar a interface e seus símbolos mais intuitivos, mais diretos e, portanto, de uso mais simples e imediato.

Dessa forma, fica mais fácil percebermos que os símbolos dispostos numa interface computacional constituem uma linguagem e, portanto, podemos imaginar que existem situações em que um mal “texto” é produzido, tornando-se difícil a compreensão e leitura do que se deseja transmitir, dificultando, dessa forma, a interação entre usuário-sistema.

SEMIÓTICA ORGANIZACIONAL

Esse é um ramo da semiótica dedicado ao estudo das organizações através da lente da semiótica. Por organização, podemos entender qualquer grupo que se organize socialmente em torno de algum objetivo em comum, ou seja, desde a família até uma multinacional.

O que é proposto aqui é a questão de que no ambiente de uma organização, além dos signos que utilizamos cotidianamente na comunicação, a própria organização é um agente vivo e produz em seu interior uma forma subjetiva e objetiva de comunicação, portanto, de utilização de signos própria, que têm significado apenas dentro do contexto da organização. O estudo desses signos explicita a forma como a organização é estruturada, os fluxos de informações decorrente dessa organização, os gargalos do sistema onde há conflitos em potencial, a dependência ontológica entre os agentes, os padrões de comportamento que são esperados e as normas que regem a codificação dos signos dessa organização.

A semiótica organizacional oferece uma série de metodologias que permitem levantar os pontos acima ressaltados e possibilitar uma visão global e profunda daquilo que entendemos por uma organização. Essas metodologias abordam aspectos desde o estudo da linguagem descritiva utilizada pela organização, a infra-estrutura da mesma e auxiliam a despir o significado subjetivo que há por trás de certas convenções de uma determinada organização, como, por exemplo, horário para tomar café, forma de atender ao telefone, etc.

A grande vantagem desta metodologia é a questão do levantamento das necessidades e requisitos do usuário de um determinado sistema de informação. Em primeiro lugar, a metodologia torna o usuário participante ativo de todas as etapas de análise do problema, evitando assim, a falta de coesão entre o que a equipe de análise pensa e o que o usuário espera. Em segundo lugar, as etapas são recursivas, ou seja, conforme avançamos no projeto, percebemos que faltava alguma coisa e voltamos para complementar a modelagem, evitando, dessa forma, simplificações que possam resultar em falta de coesão ao final do processo.

TA, E DAI ?

Bem, chegamos até aqui e temos já uma noção do que é a semiótica e do que é a semiótica organizacional. Mas, ainda fica a questão de como tudo isso se relaciona com jogos de computadores e de que forma podemos implementar os conceitos acima citados.

  • Um jogo é um sistema de informações
    Podemos iniciar essa discussão definindo um jogo como um sistema de informações, ou seja, um sistema computacional que recebe informações definidas pelo usuário, as processa e gera saídas que procuram responder aos estímulos da entrada. Podemos pensar nisso como um conjunto de sensores lendo informações do ambiente, um processamento dessas informações (que pode ser central ou distribuído, mas isso já é outra discussão) e atuadores que irão modificar as condições do ambiente.
    Sendo assim, podemos entender um jogo como um sistema de informações, logo, como um sistema que se utiliza de uma linguagem para se comunicar, seja internamente com seus sensores e atuadores, seja externamente com o usuário. Para fins dessa discussão, somente nos interessa a comunicação com o usuário. Logo, essa linguagem de comunicação é carregada de símbolos que procuram traduzir interpretações e gerar significados compreensíveis para os usuários do sistema.
  • A linguagem e sua coerência
    O que buscamos aqui é determinar as regras de construção, portanto de coerência, da linguagem gráfica de comunicação. Por exemplo, dissemos no início que o Windows utiliza-se de uma metáfora de mesa de escritório para compor seu ambiente de trabalho. Essa linguagem busca, de uma forma ou de outra, ser coerente com sua proposta ao longo de todas as interfaces do sistema, alcançando sucesso em alguns momentos e confundindo o usuário em outros.
    Há muitos sistemas de informação que simplesmente não se preocupam em definir uma coerência estética em sua codificação e, por não tornar esse preocupação explícita, com suas regras e normas, o sistema acaba se tornando incoerente e de difícil interação com o usuário.
  • Simulando organizações
    Determinados jogos se propõem a simular organizações do mundo real, seja o mercado financeiro, imobiliário, um hospital ou até mesmo o gerenciamento e desenvolvimento de uma cidade ou planeta. Logo, os métodos propostos pela semiótica organizacional poderiam ser extremamente úteis na própria compreensão do funcionamento dessas organizações e na construção do jogo em si, já que definem normas, relações e dependências relacionadas à organização.

CONCLUINDO

Esse artigo fornece apenas uma discussão inicial e uma proposta de uso da semiótica na construção de jogos de computador. Seria necessário ainda uma discussão mais profunda do assunto, com o detalhamento dos métodos citados e exemplos interativos que pudessem servir de subsídio às idéias desenvolvidas. No entanto, como proposta inicial, esse artigo visa despertar o interesse pelo assunto e chamar a atenção para novas possibilidades no campo do desenvolvimento de jogos ainda não exploradas.