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

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.

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.

Mecanismos disponíveis para a avaliação de aprendizes através de computadores

Por Dalton Lopes Martins

1. INTRODUÇÃO

Avaliar, sob determinada visão pedagógica, é questionar e refletir sobre o processo de transmissão da informação e a forma como essa informação transforma-se em conhecimento. A computação e a ciência da informática trouxeram a automatização de vários processos técnicos, científicos e industriais. A questão em relevância no contexto desse artigo é de que forma a avaliação pode ser encarada como um processo, de que forma a computação pode se inserir nesse processo para automatiza-lo, através dos mecanismos de que dispomos hoje.

2. EMBASAMENTO

O levantamento bibliográfico para o embasamento deste artigo levou em consideração questões que pudessem levantar reflexões a respeito do processo da avaliação, em primeiro momento. A partir disto, quando esse processo foi melhor compreendido, passou-se a pesquisar a forma como a avaliação pode ser realizada através do uso de computadores. Tendo como referência temas como agentes, lógica fuzzy, bancos de dados e analisadores de lingüísticos, o resto dos artigos complementou a informação necessária nos temas acima citados.

3. OPINIÃO

Segundo o artigo “O processo de avaliação na educação à distância”, há várias formas diferentes de se enfocar a avaliação: tradicional (utiliza de verificação de curto prazo e prazo mais longo; punição e reforço positivo), tecnicista (avaliação de comportamentos observáveis e mensuráveis, controle de comportamento face a objetivos pré-estabelecidos), libertadora (a verificação direta da aprendizagem é desnecessária, pois a avaliação ocorre da prática vivenciada entre educador/educando e a auto-avaliação em termos de compromisso assumido com a prática social), progressista (a avaliação é realizada a qualquer momento, pois sua preocupação é diagnosticar falhas e valoriza outros instrumentos que não as provas). Dentro do contexto de cada uma das formas acima mencionadas, os computadores podem ser usados.

No entanto, antes de se partir para uma análise propriamente dita dos mecanismos disponíveis para a avaliação de aprendizes através dos computadores deve-se questionar o que se deseja avaliar. Em uma abordagem generalista, o artigo “Evaluation for distance educators” enumera uma série de pontos a serem observados a esse respeito: uso da tecnologia, formato das aulas, clima do curso, quantidade e qualidade da interação com outros estudantes e com o professor, conteúdo do curso, testes, serviços de suporte, realizações dos estudantes, atitude dos estudantes e o professor. Esses tópicos oferecem variadas métricas que podem se adaptar a diferentes visões pedagógicas a respeito do processo da avaliação, rompendo a barreira limitante da visão tradicional.

Algumas ferramentas que podem auxiliar no processo de obtenção e análise dessas métricas acima mencionadas são propostas nos artigos de embasamento. O artigo “Ferramentas de análise e acompanhamento de cursos” propõe uma técnica que analisa o log (arquivo de registro de acesso de páginas http) gerado automaticamente pelos servidores e realiza uma filtragem de onde é gerado um arquivo com as informações mais relevantes (identificação do usuário, data e hora da utilização e a página acessada). Dessa forma pode-se gerar um banco de dados e analisar as informações para se levantar características comportamentais do usuário em relação ao sistema.

Já em PEREIRA RODRIGUES (2000), propõe uma técnica de avaliação através de agentes, que podem interagir com o ambiente, comunicando-se com outros agentes, influenciando o comportamento dos mesmos, ou seja, possibilitando a mudança de estratégia ou metodologia de ensino, caso se perceba um baixo desempenho do estudante.

Dessa forma, o agente interage com as ações do estudante no sistema computacional e pode auxiliar na análise de vários quesitos que não podem ser diretamente medidos através de provas e testes tradicionais. Já em ZHOU (1999), é proposta uma técnica baseada em lógica fuzzy, que está ligada a análise de situações onde não há condições de contorno bem definidas para um conjunto de atividades ou observações, dando determinados pesos a certas ações previamente estabelecidas e obtendo-se uma métrica relativa a essa análise. Essas algumas das ferramentas propostas e que somente podem ser implementadas através do auxílio de computadores.

No artigo “O processo de avaliação na educação à distância” é mencionado alguns sistemas de avaliação na web. Vale a pena aqui citar alguns. CyberQ é um sistema onde tem-se a implementação de uma estratégia de avaliação multi-característica e multi-método de vários alunos e em diferentes níveis, agregando um grande número de informações para avaliações futuras. Carnegie Mellon University é um sistema baseado em bancos de dados, onde é armazenado todo o conteúdo do curso, através de informações declarativas, e processadas por um sistema genérico. WebCT é um sistema que tem a capacidade de registrar conversas em um banco de dados, permitindo o monitoramento dessa conversação; também permite gerar perguntas on-line que são feitas enquanto o aluno está acessando a página.

Todos esses sistemas agregam determinadas técnicas e tecnologias que permitem várias abordagens pedagógicas e praticamente contemplam todas os pontos sugeridos como métricas para a realização de uma avaliação completa do processo educativo, permitindo-se considerar diferentes perfis de estudantes, suas capacidades e limitações, possibilitando-se dessa forma que a avaliação fuja da estigma de um processo traumático para o estudante e se torne um mecanismo de construção efetivo do conhecimento.

4. CONTRA-POSIÇÃO

Em P. de SOUZA, é dito que um sistema de perguntas e respostas por computador deve ter suas respostas bem programadas, sem a menor chance de gerar dúvidas. Acredito que isso seja um ponto consideravelmente limitante do uso computador, não permitindo e abrindo espaço para a criação de padrões novos de resposta, tornando-se o processo algo mais mecanizado e padronizado do que se deveria esperar de uma avaliação completa do processo educativo.

5. BIBLIOGRAFIA

1. O processo de avaliação na educação à distância. Universidade Federal do Rio Grande do Sul.
2. Ferramenta de análise e acompanhamento de cursos. Projeto Sapiens, Unicamp, 2000.
3. Evaluation for Distances Educators. College of Engineering, University of Idaho.
4. P. DE SOUZA. A avaliação como prática pedagógica. Associação Brasileira de Educação Agrícola Superior – ABEAS.
5. PEREIRA RODRIGUES, Alessandra, (2000). Agente avaliação de ensino e aprendizagem em EAD. Universidade Federal do Rio Grande do Sul, 2000.
6. ZHOU, Duanning, MA, Jian, QIJIA, Tian, KWOK, Ron C. W., (1999). Fuzzy group decision support system for project assessment. Proceedings of the 32nd Hawaii International Conference on System Sciences, 1999

Uso do Collaborative Virtual Environment (CVE) na aprendizagem Colaborativa

Por Dalton Lopes Martins

1. INTRODUÇÃO

Segundo LOGAN et al. (2001), os ambientes colaborativos virtuais (CVE) são formados por mundos virtuais que fornecem gráficos 3-D em tempo real, complementados com texto e/ou áudio para vários usuários conectados em uma rede de computadores. Essa abordagem fornece os elementos técnicos básicos para a aplicação dos CVEs na aprendizagem colaborativa, permitindo-se dessa forma que ocorra interação entre os diversos usuários conectados ao sistema, como já visto anteriormente, através de troca de mensagens, seja por texto ou áudio. No entanto, os CVEs permitem um avanço na forma como se dá a interação através da criação de uma nova metáfora: a interação no espaço virtual.

2. EMBASAMENTO

Para o estudo do tema em questão, alguns pontos de referência para pesquisa foram importantes de forma a permitir uma visão geral. Para tanto, temas como o que é a realidade virtual, como se dá a troca de informações em ambientes CVE, exemplos de ambientes já implementados e suas aplicações em abordagens educacionais foram pesquisados. Os artigos utilizados abordam esses temas de maneira geral, proporcionando o questionamento e a introdução necessária ao tema. Vale destacar o artigo de MANIA e CHALMERS pelo trabalho feito na catalogação e análise de alguns sistemas CVE já implementados. A parte da pesquisa sobre realidade virtual foi baseada nos textos de referência da disciplina nos semestres passados.

3. OPINIÃO

Um ambiente virtual colaborativo (do inglês collaborative virtual environments – CVE) usa a tecnologia de realidade virtual distribuída para suportar o trabalho em grupo. Um CVE deve possuir acesso simultâneo multi-utilizador a um sistema de Realidade Virtual (VR) que permita realizar trabalho cooperativo (BORGES GOUVEIA). Dessa forma, a compreensão da nova metáfora implementada pelos CVEs passa necessariamente pela compreensão do papel da realidade virtual como tecnologia de suporte à cooperação.

Segundo o trabalho de SEROLLI PINHO (1996), a realidade virtual nos permite aprender visitando lugares onde jamais estaremos na vida real, talvez porque o lugar seja muito pequeno para ser visto ou muito grande para ser examinado como um todo, ou muito caro ou muito distante. A potencialidade da realidade virtual está exatamente no fato de permitir que exploremos alguns ambientes, processos ou objetos, não através de livros, fotos, filmes ou aulas, mas através da manipulação e análise virtual do próprio alvo de estudo, sendo que dessa forma, permite-se que o estudante aprenda sobre um assunto inserido no contexto deste assunto e assim receba, a cada ação que fizer, uma realimentação desse contexto.

De tal maneira, o impacto da realidade virtual na aprendizagem colaborativa leva a uma análise de três pontos em específico: o raciocínio espacial, o nível de interesse e o aprendizado individual (AINGE). Usuários que usam a realidade virtual para explorarem perspectivas e relações espaciais auxiliam no seu próprio desenvolvimento do raciocínio espacial, o que era mais difícil antes da VR, devido ao alto nível de abstração exigido. O uso de mundos virtuais pode ser extremamente estimulante, pois estimula a fantasia, a curiosidade e o desafio. O uso da VR também auxilia no desenvolvimento da individualidade no ensino devido ao fato de serem os usuários do sistema que decidem o que fazer e quando fazer. Sendo assim, a realidade virtual pode agregar os elementos que vão permitir a efetiva cooperação, através dessa nova metáfora espacial que surge no ambiente CVE como forma de interação que traduz o contato real para um mundo virtual.

Como essa interação se dá de forma contínua no mundo real, através da aquisição de notícias sobre andamento de projetos, etapas já realizadas ou a serem realizadas de um trabalho, posição que cada membro do grupo ocupa, entre outros fatores, o mesmo torna-se necessário para dar continuidade a interação em mundos virtuais oferecidos pelos CVE. Para isso, LOGAN et al. (2001) discutem o papel dos agentes como observadores e relatores do que acontece em mundos virtuais quando um usuário não está conectado. Esses agentes têm o papel de relatarem informações de posição de usuários no mundo virtual, informações de áudio, formas de ação de outros usuários, foco de atenção, entre outras informações que possam ser relevantes ao usuário no momento em que este voltar a se conectar no mundo virtual. Essa abordagem também pode ser encontrada no trabalho de MIAO e HAAKE (2001).

Vale citar alguns sistemas, como referência, que implementam algumas das idéias acima expostas (MANIA e CHALMERS): DIVE, MASSIVE, VLNet, dVs, Active Worlds, Blaxxun, OnLive!, OZ Virtual, Community Place, Quake, Worlds Chat, SPLINE.

Pensando no novo paradigma apresentado pela aprendizagem colaborativa e pelas abordagens educacionais que o implementam, os sistemas que proporcionam um ambiente virtual colaborativo tornam-se uma ferramenta de auxílio ao ensino de fundamental importância, pois proporcionam interatividade em alto nível, proporcionando a troca de informações, experiências e a necessária validação do conhecimento até mesmo em nível espacial, ou seja, através de uma nova metáfora que permita o relacionamento espacial da informação e do conhecimento.

4. CONTRA-POSIÇÃO

Em BORGES GOUVEIA, diz-se que o uso da VR permite considerar influências da própria estrutura social de um grupo. Creio que isso seja necessário mesmo em abordagens que não utilizam a realidade virtual, pois a estrutura social determina certamente a forma de comunicação e interação de maneira geral.

No trabalho de LOGAN et al. (2001), sugere-se a criação de agentes como forma de conhecimento do que se passa com outros usuários. Isso pode gerar um problema de privacidade e a questão deve ser considerada com muita cautela, ou seja, os usuários observados devem ou não ter conhecimento desses agentes, de que forma eles são inseridos no sistema, são visuais aos usuários ou não, entre outras questões éticas que devem ser abordadas antes da implementação generalizada.

5. BIBLIOGRAFIA

1. AINGE, David J.. Virtual reality in schools: the need for teacher training.
2. BORGES GOUVEIA, Luís Manuel. Ambientes virtuais colaborativos: a procura de formas alternativas de interação. Universidade Fernando Pessoa, Porto, Portugal.
3. LOGAN, Brian, FRASER, Mike, FIELDING, Daniel, BENFORD, Steve, GREENHALGH, Chris, HERRERO, Pilar (2001). Keeping in touch: agents reporting from collaborative virtual environments.University of Nottingham, UK, 2001.
4. MANIA, Katerina, CHALMERS, Alan. A classification for user embodiment in collaborative virtual environments. University of Bristol, UK.
5. MIAO, Yongwu, HAAKE, Jorg M. (2001). Supporting problem based learning by collaborative virtual environment: a cooperative hypermedia approach. Proceedings of the 34th Hawaii International Conference on System Sciences, 2001.
6. SEROLLI PINHO, Márcio (1996). Realidade virtual como ferramenta de informática na educação. SBIE, Belo Horizonte, 1996.

A comunicação mediada por computador como ferramenta de aprendizagem colaborativa.

1. INTRODUÇÃO

Segundo Polesel Filho (2001), a comunicação mediada pelo computador (CMC) possui diferentes funções: entretenimento, comércio, informação. É usada nas comunicações interpessoais, como meio de comunicação de massa, como suporte para fóruns e grupos de discussão, alcançando as mais variadas aplicações. No âmbito deste trabalho, estamos interessados em abordar a comunicação mediada por computador que parte de um indivíduo para um outro ou de um indivíduo para um grupo em relação a aprendizagem colaborativa.

Em seu trabalho “Estudos Sociológicos”, Piaget (Teixeira Filho) afirma que “cooperar na ação é operar em comum, isto é, ajustar por meio de novas operações (qualitativas ou métricas) de correspondência, reciprocidade ou complementaridade, as operações executadas por cada um dos parceiros.” Dessa forma, tenta-se desenvolver e estudar a CMC no âmbito da educação.

2. EMBASAMENTO

O trabalho de pesquisa centrou-se na análise de textos que pudessem proporcionar uma visão da CMC como instrumento de construção do conhecimento e de uma espécie de validação entre os pares da informação adquirida e refletida em um curso, seja ele presencial ou não.

3. OPINIÃO

A comunicação mediada por computador (CMC) assume um papel de extrema importância quando se dimensiona sua capacidade e rapidez na troca de informação, formação de opinião e troca de experiências. No âmbito educacional colaborativo, segundo Matos Coelho, a CMC designa troca textual (principalmente) interativa em redes de aprendizagem, que são constituídas por professores e estudantes, que se comunicam uns com os outros em tempo real, sincronicamente ou em tempos diferentes, seqüencial e assincronicamente.

Há várias formas desenvolvidas pela tecnologia em que essa troca pode ocorrer. Vejamos algumas, segundo o trabalho de Teixeira Primo:

1. e-mails: permite uma discussão assíncrona entre no mínimo duas pessoas, podendo expandir para várias. Certas mensagens não-verbais, como fisionomia ou entonação de voz não podem ser valorizadas em e-mails. Daí, surgem os emoticons, que oferecem pistas de como se sente o redator da mensagem.

2. Lista de discussão: é um serviço que recebe e distribui mensagens de todos os seus “assinantes”. Permite interações mútuas entre diversas pessoas. Permite discussões de muitos-para-muitos. São conhecidas como “comunidades virtuais” e dão a impressão que as pessoas se conhecem muito, mesmo sem terem jamais se encontrado.

3. Chats ou salas de bate-papo: oferecem um ambiente para a livre discussão em tempo real, ou seja, de forma síncrona. Oferecem um palco para diálogos de alta intensidade e para a aproximação de interagentes sem qualquer proximidade física.

4. Vídeo conferência: incorpora as vantagens do chat somando os recursos de emissão e visualização de imagens em vídeo dos interlocutores.

5. Quadro branco: trata-se de um programa que pretende simular o uso de um painel onde todos possam escrever e desenhar.

Em todas essas formas de comunicação, com exceção do e-mail de um-para-um, pode haver o papel do moderador, segundo Matos Coelho, tem seu papel identificado e relacionado com a forma com que os estudantes respondem e participam. O moderador tem o papel de motivar, não deixar dispersar e orientar em muitos casos as discussões. Possui um estilo pedagógico e funções organizacional, social, intelectual, técnica e a familiarização com a tecnologia de comunicação em uso.

Através do cenário acima exposto, pode-se compreender de forma mais clara a maneira pela qual a CMC pode se dar num ambiente de aprendizagem colaborativa, ou seja, as várias maneiras como os estudantes podem trocar informações e se ajudarem mutuamente no processo de validação dessa informação, contribuindo na construção do conhecimento. Mas fica a questão: funciona ou não funciona ?

Em Berge e Collins (1995), algumas pesquisas indicam como resultados que o professor conectado em rede interage mais com seus alunos do que em situações normais, sem perder contudo o contato face-a-face com seus alunos. Em Archee (1993), algumas pesquisas indicam que a CMC causa como efeito uma espécie de camaradagem entre os estudantes que os ajuda formar sua identidade, propósitos de vida e sentimento coletivo.

No entanto, essas são apenas algumas formas de se analisar a questão proposta, pois a profundidade do assunto parece inesgotável já que, por exemplo, não podemos isolar artificialmente um e-mail num laboratório e analisa-lo sem considerar aspectos sociais, políticos, religiosos, filosóficos, entre outros (December, 1995).

Porém, temos alguns indícios e pistas sobre qual caminho trilhar para obter a efetiva interação desejada no paradigma proposto pela aprendizagem colaborativa.

4. CONTRA-POSIÇÃO

Em Teixeira Primo, é dito que os webdesigners que não abrem em seus sites possibilidades de diálogo limitam a interação ao clássico modelo de transmissão de informações. Isso não é necessariamente correto, pois fatores como a inteligência artificial e agentes podem formar as respostas dinamicamente nos sites e, de uma certa forma, se adaptarem ao perfil de cada usuário, transmitindo informações dinâmicas e não estáticas.

Em Archee (1993), é dito que a habilidade para facilitar o consenso da CMC é ilusória. Acredito que isso depende muito do papel do mediador, que deve motivar os que não se expressam e nortear os que fogem do proposto, sendo dessa forma, instrumento de extrema importância no caminho do consenso.

5. BIBLIOGRAFIA

1. ARCHEE, Ray (1993). Using computer mediated communication in an educational context: educational outcomes and pedagogical lessons of computer conferencing. University of Western Sydney, 1993.
2. BERGE, Zane, COLLINS, Mauri (1995). Computer-mediated communication and the online classroom in higher education. Computer Mediated Communication Magazine, Volume 2, Number 3, 1995.
3. DECEMBER, John (1995). Transitions in studying computer-mediated communication. Computer Mediated Communication Magazine, Volume 2, Number 1, 1995.
4. MATOS COELHO, Maria Inês de. Educação a distância, comunicação mediada por computador e a comunidade de aprendizagem: explorando a prática para formação-ação de docentes. Projeto BH2-EAD-UEMG (Protem-CNPq-RNP).
5. POLESEL FILHO, Pedro (2001). A comunicação mediada pelo computador: diferentes formas de contato e aprendizagem. XXIV Congresso Brasileiro da Comunicação, 2001.
6. TEIXEIRA PRIMO, Alex Fernando. Ferramentas de interação na WEB: travestindo o ensino tradicional ou potencializando a educação através da cooperação. Universidade Federal do Rio Grande do Sul.

Agentes de Software: uma breve introdução

Por Dalton Lopes Martins

Após a explosão do uso doméstico da Internet, na metade dos 90, uma tecnologia tornou-se a coqueluche dos desenvolvedores de software para ambientes de rede e sistemas distribuídos: os agentes de software. No entanto, agentes não são programas que rodam apenas em ambientes voltados para redes, como veremos a seguir, mas podem ser utilizados em várias situações, como agentes de interface (lembram-se do “chato” clip do Word?), gerenciadores de desktop, entre outras aplicações.

Mas, o que define, o que determina que um programa seja um agente de software? Um agente é, antes de mais nada, um programa desenvolvido em uma linguagem de programação qualquer. No entanto, há algumas características na implementação de um agente que o diferenciam de um programa clássico.

O agente deve possuir alguns requisitos necessários para que seja considerado como tal: um ciclo de vida contínuo no tempo, um ambiente de atuação, sensores que recolham informações do ambiente, atuadores que causem mudanças no ambiente e autonomia, ou seja, funcionamento independente da interferência do usuário. Agora, podemos definir melhor cada um desses requisitos.

O ambiente é a área de atuação do agente e pode ser, teoricamente, qualquer parte independente que possamos identificar num sistema. Podemos considerar como ambiente o sistema de arquivos local onde podemos ter rodando um agente de mirror, que espelha o conteúdo de um diretório em outro; podemos considerar como ambiente a Internet no caso de agentes spider, que caminham de site em site verificando a validade de links; podemos considerar como ambiente uma LAN (Local Area Network) no caso de um agente que verifique os usuários conectados e as aplicações que usam; ou, até mesmo podemos considerar um ambiente a própria área de desktop do sistema operacional no caso de um agente de interface.

Os sensores são os mecanismos que utilizamos para captar as mudanças que ocorrem no ambiente, como os sockets (mecanismo que cria uma conexão entre duas máquinas através de uma porta de comunicação e do IP de ambas) e os métodos que permitem obter informações do sistema, como rotinas para obtenção de data, hora, listagem de um diretório, etc.

Os atuadores são os mecanismos que utilizamos para efetuar alguma alteração no ambiente, como os próprios sockets (a conexão criada é bi-direcional, permitindo tanto ler quanto escrever), métodos para apagar arquivos, para desenhar algum objeto na tela, exibir informações, etc.

O ciclo de vida de um agente representa o tempo em que ele se encontra em execução no objetivo de realizar uma determinada tarefa. Após esse tempo, o processo que executa o agente irá morrer ou ficará “dormindo” durante outro intervalo de tempo. Como exemplo, podemos imaginar um agente que realiza backup de um servidor FTP para o disco local da máquina de um usuário. Se o agente ficar o tempo todo lendo o servidor, a máquina do usuário irá ficar praticamente paralisada. No entanto, o agente lê as informações de arquivos do servidor, atualiza no cliente e dorme por um tempo, retornando após para novamente procurar por mudanças no ambiente.

A autonomia é a principal característica de um programa que o torna um agente. Ela indica que o programa será executado independente da intervenção do usuário, ou seja, ele será capaz de controlar seu próprio fluxo de ações.

Desta forma, temos caracterizado os requisitos que tornam um programa um agente. A partir disso, podemos imaginar diferentes aplicações e tecnologias que possam servir como motivação e base de apoio no desenvolvimento de programas orientado a agentes na programação de jogos de computador.

Agentes de software e desenvolvimento de Jogos

No desenvolvimento de jogos, um fator importante e essencial é a inteligência que há por trás da interface, ou seja, o mecanismo que vai processar as ações tomadas pelo usuário e gerar uma reação por parte do sistema ao usuário. A programação clássica dessa inteligência se dá através do paradigma comportamental, ou seja, o programa supõe uma série de comportamentos possíveis por parte do usuário e, com base nisto, irá gerar uma reação também previamente determinada. O problema dessa forma de lidar com a inteligência do sistema é que ela limita as ações possíveis por parte do usuário e permite que o mesmo descubra o padrão de análise de movimentos utilizado pelo programa, gerando aquelas cômicas situações onde o usuário cria mecanismos para burlar o sistema e assim avançar no jogo.

Os agentes podem ser utilizados para resolver esses problemas e criar jogos mais dinâmicos e interativos. A autonomia de execução de um agente pode ter vários níveis de complexidade, permitindo desde o nível mais básico onde o agente possa controlar suas próprias ações, até o nível mais alto, onde o agente possa tomar decisões orientado a metas específicas e utilizar mecanismos de análise para verificar se está sendo bem sucedido ou não.

Esse nível de programação exige por parte do programador o conhecimento de alguns conceitos que possam auxiliar no modelamento do agente, como processamento distribuído, threads que permitam a execução paralela de pedaços de um programa, construção paralela de sensores e atuadores que permitam o nível de interação desejada, entre outros fatores.

Iremos trabalhar cada um desses conceitos ao longo do tempo e fornecer exemplos de aplicações desenvolvidas na linguagem JAVA. Por enquanto, fica a idéia e a motivação inicial para se considerar uma nova forma de programação no desenvolvimento de jogos para computadores.

É preciso desenvolver um engine para o seu jogo?

UMA ABORDAGEM PELA PROGRAMAÇÃO ORIENTADA A OBJETOS VERSUS PROGRAMAÇÃO ESTRUTURADA

Quando se tem em mente o desenvolvimento de um software, deve-se passar necessariamente pela fase de projeto, onde as idéias a respeito do que se quer fazer são confrontadas com as possibilidades técnicas do grupo de desenvolvimento e uma síntese entre intenção e realidade irá nortear o processo de construção do código. Em se tratando de jogos, a coisa pode se tornar ainda mais complicada, pois geralmente esperamos muito mais de nossos programas do que aquilo que somos realmente capazes de realizar em curto prazo.

Essa fase de projeto de software pode ser traduzida em um detalhamento mais fino das atividades, entradas e saídas que o sistema irá comportar. Isso passa necessariamente por uma escolha primordial: programação estruturada ou programação orientada a objetos. A programação estruturada é aquela que nos permite detalhar o funcionamento de um programa através das funções e procedimentos que o compõem. A programação orientada a objetos nos permite uma outra hierarquia, mais rica e mais complexa, de estruturação, com classes que comportam métodos que podem herdar características de outras classes e assim consecutivamente. A ênfase que se dá ao projeto em programação estrutura é em relação à ação que uma determinada função ou procedimento irá executar, já na programação orientada a objetos a ênfase na fase de projeto se dá ao tipo de dados que se deseja obter e a forma como esses dados serão tratados pelo programa. São dois enfoques bem diferentes e que têm implicações de projeto que resultam em conceitos diferentes para um mesmo software.

Bem, deixemos momentaneamente a questão da programação estruturada e da orientação a objeto de lado para colocar em questão o que se entende por engine e qual deve ser o seu papel.

A palavra engine pode ser traduzida como “motor” ou “máquina”. Um engine pode ser entendido, de tal forma, como uma coletânea de código orientada à ação (execução de ações por parte dos elementos do sistema) que visa ser genérica o suficiente para que possa ser reaproveitada na construção de outros sistemas, enfim, de outros jogos que executem ações semelhantes. Veja que quando falamos de ação, não estamos apenas nos referindo a jogos de ação, mas sim a como um programa toma decisões em tempo de execução com base numa interação por parte do usuário. Essa definição difere consideravelmente do que podemos considerar uma biblioteca de software propriamente dito: uma lib é orientada ao suporte de tarefas de mais baixo nível que dão muito trabalho se forem reescritas a cada novo sistema desenvolvido, ou seja, não tem essa preocupação se ser orientada à ação.

Tomemos como exemplo jogos de RPG e pensemos no papel que um engine pode ter. Essencialmente, a estrutura de programação desses jogos é a mesma, mudando apenas o conjunto de regras que irá nortear o comportamento dos usuários e a forma como os mesmos irão interagir com o sistema. Se tivermos um código genérico o suficiente para passarmos como parâmetro as regras do jogo e as formas de interação, teremos um construído um engine que, de forma geral, pode nos auxiliar em todo o desenvolvimento de jogos desse tipo.

Visto isso, voltemos agora aos conceitos de programação estruturada e orienta a objetos.

A orientação a objetos surgiu como um novo paradigma em programação visando justamente resolver o problema de reaproveitamento de código e da manutenção desse código por pessoas diferentes. Como dissemos acima, a própria ênfase da orientação a objetos se dá nos dados que uma classe deve tratar, ou seja, nos dados que devem ser recebidos como parâmetros e aqueles que devem retornar de um método encapsulado por uma classe, o que torna a tentativa de generalizar o código muito mais eficiente do que na orientação estruturada.

É evidente que tal forma de programação exige disciplina e experiência, já que sempre iniciamos nosso estudo em programação pela forma estruturada e levamos certo tempo até compreender a forma como as classes podem ser estruturadas e vantagem que isso traz ao código final. Também é evidente que para desenvolvermos pequenos jogos, a forma estruturada é mais simples e, diria mais, até mais útil. Mas, a questão que fica, é que se pretendermos desenvolver um trabalho a longo prazo, visando produtividade de construção de código, parâmetros de qualidade na fase de análise do projeto, teste e manutenção, devemos sim nos preocupar em construir engines que sejam orientados a objeto e possam ser constantemente revisados para trazer o nível de generalidade que pretendemos alcançar. Logo, a resposta ao título do texto é: depende do porte e do desenvolvimento a longo prazo do projeto que se pretende criar.

Recursos da/na web que permitem a disponibilização de conteúdos e processos educacionais

Por Dalton Lopes Martins

1. Introdução

Há várias maneiras de se enxergar uma abordagem para o tema recursos da/na web que permitem a disponibilização de conteúdos e processos educacionais. Pode-se falar, por exemplo, de recursos físicos como perfil de hardware desejado, topologia de rede de dados, voz sobre IP, softwares de autoria e tecnologias que, independente da plataforma, sejam voltadas a proporcionar maior interação entre o usuário e a web. Esse artigo, por entender que disponibilização de conteúdo implica a capacidade de acessar e interagir com a informação, escolheu esta última opção para centrar seu foco de estudo

2. Embasamento

Considero que a pesquisa realizada para o tema proposto foi a mais difícil até o presente momento do curso. Tive dificuldades para encontrar um foco dentro da vasta gama de opções que o tema permite. Isso somente foi resolvido com a leitura do texto “Interação na Web” (ver bibliografia), que permitiu encontrar um caminho de pesquisa. A partir deste ponto, a necessidade de se aprofundar em algumas tecnologias levou ao encontro dos outros textos utilizados; explorando-se dessa forma temas como PHP, Servlets, JAVA, CORBA e JSP.

3. Opinião

Segundo Raposo et al. (1999), as grandes vantagens em se desenvolver aplicações disponibilizadas via web estão associadas à fácil acessibilidade: as aplicações ficam disponíveis a uma cada vez mais ampla gama de usuários da web e elas podem ser acessadas de praticamente qualquer lugar (de casa, do trabalho, ou mesmo em trânsito, através da computação móvel); somada a estas vantagens, ainda existe a independência de plataforma das aplicações web.

Para tornar viável as vantagens acima citadas, deve-se disponibilizar a informação, o conteúdo, de forma eficiente e inteligente, de maneira a maximizar um dos maiores interesses na web: a interação. No caso educacional, objeto deste estudo, a interação torna-se ainda mais importante, pois segundo os novos paradigmas da educação, o aprendizado é um processo construído pelo aluno e com intensa realimentação por parte do educador via os recursos disponíveis.

A partir disto, torna-se necessária a disponibilização de tecnologias que implementem esse nível de interação desejado entre o usuário e o objeto de seu estudo. No entanto, as tecnologias básicas da web (HTTP e HTML) ainda impõem algumas limitações no que diz respeito à interação com as aplicações: falta de controle sobre a aparência da interface, o protocolo HTTP não suporta conceito de sessão (possibilita maior controle da comunicação), lentidão de realimentação, não garante taxa de transmissão mínima, entre outros (Raposo et al., 1999).

Porém, a web tem evoluído de sua antiga estrutura estática (o servidor web enviava ao usuário apenas páginas previamente construídas e com conteúdo estático) implementada apenas com hipertexto puro para aplicações mais dinâmicas (o servidor web é capaz de gerar páginas dinamicamente conforme informações obtidas através do usuário, inclusive realizando processamento na máquina local), que permitem intensa troca de informação entre o usuário e o servidor web. Essa evolução tem ocorrido graças a tecnologias como a CGI (Common Gateway Interface), ECMAScript, Java, Java Servlets, Java Beans, Java 2D, Java 3D, JSDT (Java Shared Data Toolkit), CORBA, PHP, VRML, entre outras.

Segundo Volkheimer (2001), Servlets são programas que rodam no lado do servidor e são capazes de gerar conteúdo dinamicamente, ou seja, eles recebem dados do usuário, realizam um determinado processamento e retornam uma página HTML específica para os dados de entrada. Isso, como se pode imaginar, permite implementar processos educacionais como, por exemplo, análise da resposta do usuário a uma determinada questão e uma realimentação por parte do software educacional com base nos dados de entrada.

Já a PHP é uma linguagem de script que é acoplada ao HTML e é interpretada no lado do servidor. Ela é mais direcionada ao trabalho com bancos de dados, já que se relaciona com Oracle, Sybase, Informix, entre outros (Brockmeier, 2000). A PHP auxilia na disponibilização de consultas a bases de dados e no cruzamento de informações, suportando pesquisas e estudos relacionados aos dados analisados. A tecnologia CORBA pode ser utilizada com o mesmo propósito, no entanto, ela possui a vantagem de gerenciar um grande número de usuários ao mesmo tempo, sendo portanto importante no suporte a aplicações que possuem alta demanda de acesso.

Portanto, pode-se concluir que essas tecnologias facilitam e tornam possível a disponibilização de conteúdo e processos educacionais na web, tornando-se dessa forma viável a implementação dos novos paradigmas educacionais através da interação proporcionada pela web.

4. Contra-posição

Os textos utilizados para a elaboração do artigo apresentam as tecnologias e suas características, portanto, não possibilitam margem para contra-posição a algum argumento conceitual.

5. Bibliografia

1. BROCKMEIER, Joe (2000). Introduction to PHP. Linux Magazine, 2001.
2. MORGAN, Bryan (1997). CORBA meets Java. JavaWorld.com, 1997.
3. RAPOSO, Alberto B., MAGALHÃES, Léo P., RICARTE, Ivan L. M. (1999). Interação na WEB. Proposta JAI’99, 1999.
4. VOLKHEIMER, Jeff (2001). Introduction to Servlets, JSP and Servlet Engines. Site DevCentral, 2001.