Sendo assim, utilizando a metodologia de ensino do Sr Miyagi, vamos comentar um pouco sobre o padrão de projeto Observer.

Este padrão pertence a categoria dos padrões comportamentais e é muito utilizado em API´s gráficas como Swing do Java.

Descrição: Define uma dependência uma-para-muitos entre objetos, de maneira que quando um objeto muda de estado todos os seus dependentes são notificados e atualizados automaticamente.

Analisando o diagrama acima, podemos perceber que o padrão consiste em duas classes principais: Observable (o observado) e Observer (quem observa). A classe Observable possui três métodos importantes:

• Attach: Adiciona um observador.
• Detach: Remove um observador.
• Notify: Notifica todos os observadores chamando o método update em cada um deles.

Ao implementar uma classe Observable, o desenvolvedor normalmente implementará uma forma para o observador analisar o que foi alterado no estado da classe observada. Representado pelos métodos getState e setState no diagrama.

O processo consiste em um objeto (observado) disparar eventos de notificação para os objetos observadores poderem agir de acordo com essa mudança. Vamos analisar o diagrama de sequência para entender exatamente o fluxo.

A partir do diagrama acima, imaginemos dois objetos cadastrados como observadores de um outro. Por algum estimulo externo, o objeto observado tem seu estado modificado (1), sendo assim, o próximo passo será notificar os objetos que o observam através do método notify (1.1), que por sua vez, dispara o método update em cada um de seus observadores  passando uma referência de si mesmo como parâmetro (1.1.1 e 1.1.2). A partir deste ponto, os objetos observadores podem executar um getState para saber exatamente o que foi alterado no objeto em foco.

O uso mais comum em software deste padrão pode ser observado na linguagem Java através do uso de Listeners (outra forma de chamar os observadores). Para ouvir o teclado por exemplo, você deve cadastrar seu objeto como ouvinte do Keyboard e implementar vários métodos de notificação, tais como KeyDown, KeyPress, KeyReleased, etc. Quando o teclado é utilizado, a classe Keyboard envia notificações para todos os seus observadores passando informações sobre o evento.

Uso em Games: A utilização do padrão Observer em games é muito comum atualmente. O exemplo de software utilizado acima se encaixa como uma luva para os desenvolvedores de games, além claro que estender isso para mouse e joystick, que funcionariam exatamente da mesma forma. Além deste uso conhecido, o Oberserver pode ser utilizado com sucesso em arquiteturas de IA. Imaginem um inimigo, ou grupo de inimigos, observando as ações do jogador (player). A cada movimento dele, o grupo pode agir de uma forma ou de outra para criar uma emboscada.

Em um game como Mario, há um exemplo do clássico fantasminha que age de acordo com os movimentos do personagem. Se Mario olha em sua direção, ele se esconde e para, porém, se Mario olha na direção oposta, o fantasma se aproxima.

E ai, o que acharam desse nosso primeiro post? Procurei começar com um padrão mais simples para irmos aos poucos entendendo o todo. Aguardo o feedback de vocês para os próximos.

Grande Abraço!

O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995.
Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson  e John Vlissides, conhecidos como a “Gangue dos Quatro” (Gang of Four) ou simplesmente “GoF“. Eles não criaram especificamente as 23 soluções, a própria comunidade de software fez o trabalho na época. A sacada do grupo de quatro amigos foi organizar e dar nomes para cada uma delas .

Os padrões de projeto, segundo o GOF,  se dividem em 3 categorias: Estrutural, Comportamental e de Criação. Cada categoria trata de um tipo de solução específica. Vamos analisar:

• Padrões de Criação – Abstraem o processo de instanciação de objetos. Eles ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados. Eles dão muita flexibilidade para o que é criado, quem cria, como e quando cria.
• Padrões de Estrutura – Preocupam-se com a forma como as classes e objetos são compostos para formar estruturas maiores.
• Padrões de Comportamento – Preocupam-se com algorítimos e a atribuição de responsabilidades entre os objetos, dando um grande foco na comunicação entre eles.

Observe a tabela abaixo uma visão geral de como os 23 padrões se organizam:

Sabemos da existência de outros padrões além dos organizados pelo GOF, porém vamos focar apenas nestes 23 citados acima. Em um futuro não tão distante, abordaremos os outros aqui no Abrindo o Jogo.

De forma aleatória, começaremos o nosso interessante exercício com o padrão Observer, confira no Post seguinte clicando aqui.

O nome do jogo é Anti-Invaders. É um jogo de tiro espacial como vários outros que apareceram ao longo do tempo. É um gênero bem conhecido e de implementação relativamente simples, por isso mesmo uma boa escolha para um projeto didático.

A idéia é mostrar umprojeto simples porém completo, desenvolvido com protótipos e releases e comentando cada evolução em posts semanais. Serão decisões de game design, de arquitetura de software e de implementação que, no final, darão uma visão completa do processo.

Acredito que será útil principalmente para quem está iniciando e não tem, ainda, noção clara do processo como um todo.

Iniciaremos, então, com a primeira versão do GDD (Game Design Document), criado com base neste post do Everton, embora bem simplificado. Algumas seções não foram preenchidas – nelas está anotado o que deveria ser colocado alí. O foco deste documento é na história de base, fases (tamanho do jogo) e controles. Clique no link abaixo para baixar o PDF.

GDD_Anti_Invaders

Semana que vem teremos um protótipo do jogo para ter idéia do que querermos fazer.

Olá pessoal, desde que comecei a jogar videogame sempre tive curiosidade de saber como eles eram desenvolvidos, que tecnologia utilizavam, quantas pessoas seriam necessárias, e o mais importante, o que eu devo fazer para desenvolver o meu. É com o objetivo de responder à todas estas perguntas que inauguro hoje a coluna Abrindo o Jogo.  Nela vocês poderão conhecer um pouco dos segredos dos bastidores das maiores desenvolvedoras de games do mercado, focando desde a arquitetura de software até o Game Design. O Primeiro artigo apresenta detalhes técnicos sobre o desenvolvimento do game de guerra Shellshock Nam 67 (SSN 67), lançado em 10 de setembro de 2004 e desenvolvido pela Guerillha Games. Apesar da empresa ser mais conhecida hoje pelo sucesso KillZone 2, um dos principais títulos do PS3, foi durante o desenvolvimento de SSN 67 que a equipe adotou pela primeira vez novos Padrões de Projetos (Design Patterns), mais especificamente um grande conhecido meu, o MVC. Vamos saber mais sobre como isto ocorreu?

Mesmo atualmente pouco se fala sobre a arquitetura de software de um game, ao contrário de artigos sobre IA, Game Design e Física, este importante assunto recebe pouco destaque. Por exemplo, você sabia que a maioria das classes  de um game derivam de uma única? Normalmente chamada de Actor, Object ou Entity.

“A escolha de uma arquitetura adequada  é um ponto vital para a construção de um game, apesar disto não ser visível para o usuário final, más escolhas irão afetar muitos aspectos no processo de desenvolvimento. Uma boa estrutura reduzirá o risco e aumentará a eficiência da equipe.”

Foi com este pensamento que a equipe da Guerillha Games, antiga Lost Boys Games, (OK! o forte deles não seria criar nomes para a empresa) iniciou o desenvolvimento do game Shellshock Nam 67. Eles procuravam uma estrutura que fosse flexível suficiente para suportar todas as idéias e ainda assim, rígida para forçar uma única forma de trabalho. O desenvolvimento do seu primeiro jogo, Killzone 2004, foi considerado muito bom, entretanto tiveram uma boa oportunidade de analisar a estrutura e vislumbrar várias melhorias. Com a base similar a anterior, as novidades seguiriam os seguinte critérios:

• O sitema precisa ser ainda mais orientado a dados;
• Devemos utilizar o conhecido padrão MVC Model-View-Controller;
• A simulação do jogo rodará em uma frequência de update fixa para garantir comportamento consistente em todas as plataformas (PS2, XBOX and PC).

Entidades

Em SSN67 a classe base para todos os objetos do jogo é chamada de Entity(Entidade). A equipe deixou bem claro a distinção entre objetos do jogo que possuem um estado e os que não possuem. Por exemplo, a geometria estática do mundo e seu modelo de colisão não são entidades, nem tão pouco nuvens em movimento no céu. Um barril de óleo por exemplo, é uma Entidade porque quando ele explode isto pode ferir o jogador e influenciar o estado do jogo. Segundo Jorrit Rouwé, programador líder da equipe, utilizando uma definição como esta fica muito fácil separar objetos importante para o game dos que não teriam tanta relevância. O sistema de streaming do motor, por exemplo, pode baixar texturas sem afetar o estado do jogo.

Orientado à Dados

Um sistema que segue esta orientação utiliza dados ao invés de código para configurar as propriedade de um objeto. Em SSN67 eles utilizaram a classe EntityResource (Recursos da Entidade) como classe base para as propriedades de um objeto. Os recursos da entidade são definidos em um arquivo de texto e editado manualmente. O exemplo a seguir mostra como se pareceria a configuração de um NPC (Non Player Character – Personagem controlado pela máquina):

CoreObject Class=HumanoidResource
{
  Name = Ramirez
  Model = models/soldiers/ramirez
  Speed = 5
  ...
}

Quando estes arquivos textos são lidos pelo sistema de serialização deles, os objetos correspondentes são automaticamente criados e cada variável é mapeada para um atributo. Após uma EntityResource ser carregada eles validam o tipo de cada atributo e verificam se todas elas juntas formam uma configuração válida. Se as informações não forem válidas, uma mensagem de erro é mostrada e o game não roda. Em SSN67 eles não permitem entidades serem criadas sem um EntityResource. Pois isto garante que um objeto específico aja da mesma forma em todos os níveis, reduzindo significativamente a ocorrência de bugs. O Padrão de Projetos Factory (Fábrica) foi responsável por criar uma Entidade através de sua EntityResource. Isto significa que bastaria entregar uma EntityResource a fábrica para obter a Entidade correspondente, pronta para ser usada no jogo. Isto foi feito através de um  plugin para o Maya. Level Designers (Projetistas de Fases), podiam criar uma Entidade e posicioná-la em um fase apenas selecionando o arquivo da EntityResource correspondente. Entidades que necessitam de um comportamento especifico, mais dinâmico, poderiam ser criadas através da linguagem de Script LUA.

O MVC (Model-View-Controller)

O Padrão de Projetos MVC (padrão de arquitetura) é utilizado em várias áreas, desde um processador de texto há um aplicativo web. Ele basicamente define que um objeto deva ser dividido em três entidades distintas, relacionadas entre si: o Modelo, a Visão e o Controlador. Esta arquitetura encaixa como uma luva para o desenvolvimento de jogos. Compartilhando desta visão, a equipe da Guerrilha adotou o padrão relacionando o Model à Entity, a View a uma classe chamada EntityRepresentation e o Controller permaneceu com a mesma nomenclatura. Vamos ver com mais detalhes como a empresa trabalhou com cada uma delas:

O Modelo (Entity)

As Entidades devem armazenar o mínimo de estados possíveis de um objeto. Qualquer estado que for necessário apenas para a visualização, não será armazenado no Modelo. Grande parte das Entidades em SSN67 são simples máquinas de estados. Entidades por definição não deveriam saber nada sobre animações, porém infelizmente muitas animações interferem no volume de colisão do objeto e consequentemente no estado do game.  No game um Humanoid caminhando por exemplo, olha em seu EntityResource a velocidade máxima de caminhada, ao invés de observar a animação para obter esta informação. A EntityResource pré-calcula a velocidade da animação de forma que o Modelo esteja alinhado com o que o usuário esta vendo na tela, gerado pela EntityRepresentation. A equipe ainda considera que há como reduzir ainda mais a relação da Entidade com as animações

A Visão (EntityRepresentation)

A EntityRepresentation é responsável por desenhar a Entidade e todos seus efeitos. Exemplos de tarefas executadas por uma EntityRepresentation:

• Modelos 3D
• Partículas
• Decals
• Filtros de Tela
• Som

Uma EntityRepresentation, apesar de dar esta impressão, não muda o estado de uma Entidade. Ela na verdade baseia-se neste estado para criar o seu próprio. Porém há algumas exceções onde esta informação não é suficiente. Por exemplo, quando um humano é atingido o jogador espera visualizar o sangue vindo de tal ferimento. Simplesmente olhando a quantidade de energia anterior e a atual, não seria possível saber onde o personagem foi atingido. Nestes casos eles usaram um sistema de mensagens muito utilizado no MVC. Todas as mensagem derivam de uma classe chamada EntityEvent, a qual contém um Id que indica o tipo de mensagem. A Mensagem de “Ser Atingido” contém o tipo, quantidade de dano e onde o personagem foi causado. Para atingir um realismo maior, o sincronismo dos efeitos é normalmente crítico e precisa bastante código para ser gerenciado. Separando este código da lógica essencial do jogo, a equipe reduziu o risco de bugs. Uma vantagem importante desta arquitetura é se todos os objetos seguirem as regras, o estado do jogo não fica dependente da representação, ou seja, o jogo pode rodar sem elas. Este princípio pode ser muito útil para criar servidores multiplayers onde a parte visual não é necessária.

O Controlador (Controller)

O Controlador prove abstração de entrada (input) para uma Entidade. Tendo isto como premissa, a equipe criou para cada Entidade  uma classe base que define as partes controláveis. A partir desta versão eles puderam derivar um Controlador para A.I. e um para o player. Por exemplo, um Humanoid tem um HumanoidController que serve de Super Classe para HumanoidAIController e HumanoidPlayerController. A versão do player ainda poderia dividir-se entre prover suporte a mouse e teclado (PC) ou joystick (XBOX e PS2). O objetivo do Controlador é especificar o que a Entidade deverá fazer, porém não pode mudar diretamente seu estado. A cada update o Controlador é requisitado pela Entidade e ela tenta seguir suas instruções. Por exemplo, ele nunca iria chamar o método MoveTo() em um Humanoid, mas sim o Humanoid iria sondar o método GetDesiredSpeed() (pegar velocidade desejada) do Controlador e então tentar alcançar esta velocidade enquanto executa a detecção de colisões para ter certeza que não esbarrará contra uma parede. Para fazer um Humanoid interagir com uma arma, por exemplo, o HumanoidController implementa a função chamada GetUseObject(). Esta função é acionada a cada update pelo Humanoid. Para um NPC, a A.I. usa o raciocínio para determinar se isto é benéfico ou não. Já para o player, o HumanoidPlayerController detecta que o objeto está ao alcance e dispara a lógica do menu de uso. A HUD [1] encarrega-se de desenhar as opções na tela. Após o jogador selecionar uma opção, esta informação retornará através do GetUseObject() na próxima requisição do Humanoid ao HumanoidController (o próximo pulso).

[1] HUD (Head Up Display) É um instrumento inicialmente desenvolvido para utilização em aeronaves visando fornecer informações visuais ao piloto sem que este tenha que desviar os olhos do alvo. No mercado de games ele refere-se as informações que estão dispostas na tela para o jogador, como por exemplo: Energia, Tempo, Número de Vidas, etc.

Um Simples Exemplo

Imaginemos o conceito de MVC aplicado a um Tanque. Primeiramente ele seria dividido em Entity (Tank), EntityRepresentation (TankRepresentation) e um Controller (TankController). O TankController tem funções como GetAcceleration(), GetSteerDirection(), GetAimTarget() e Fire(). A I.A. guia o tanque usando um TankAIController e o jogador através de TankPlayerController. A classe Tank acompanha o estado físico do veículo, os danos e direção. A TankRepresentation além de desenhar o tanque, cria as partículas de fumaça quando o tanque atira e reproduz um rastro onde o veículo passou. Também é comum a View tratar dos sons, neste exemplo ela trataria do som correspondente quando o tanque colide por exemplo. Uma curiosidade comentada pela equipe é que a representação teria uma certa independência da Entidade para movimentos de rotação, como adequar-se a um terreno irregular, desde que isto não interfira no volume de colisão do tanque.

Simplificação do Estado de Jogo

Vamos, através de um exemplo,  entender melhor como a Guerrilha desenvolveu o sitema de estados de SSN 67. Quando um Humanoid atira com uma arma, o game mostra a bala saindo do cano, porém esta simples ação pode representar problemas. Cada arma tem sua própria animação, ligeiramente diferente. Pistolas ficam na altura dos ombros, escopetas na linha da cintura, e armas mais pesadas, como rifles e bazucas, precisam ser apoiadas em algo para serem utilizadas. Estas diferenças podem levar a inconsistencias do cálculo de posições feitos pela AI. Por exemplo, um NPC pretende encontrar um posição coberta para poder atirar, a AI faz o cálculo envia o agente para logo atrás de uma pedra, que por sua vez possui metade de seu tamanho. Se a arma utilizada for uma pistola, não haverá problema, porém se for uma escopeta, a bala deveria atingir a pedra quando utilizada. Para solucionar este problema eles separaram o algoritimo de atirar da parte visual. As balas de todas as armas agora saem de um ponto fixo (próximo ao ombro), baseado somente na posição corrente e postura do Humanoid. O rastro é manipulados pela EntityRepresentation e sai do cano da arma (como na animação) movendo-se na mesma direção. Os dois cálculos, animação e lógico, lentamente convergem para o ponto de impacto.

O Frame Work Completo

O Diagrama abaixo apresenta o framework completo utilizado em SSN67.

Diagrama de Classe demonstrando a relação entre cada objeto

O EntityManager é um container para todas as Entidades, ele dispara uma atualização para todas elas em um frequência fixa. Todas as Entidades que participam do game devem estar cadastradas no EntityManager, que dentre várias funções, facilita a procura por elas. A equipe definiu que Entidades pudessem ser atualizadas por outras Entidas em alguns casos especiais, onde a ordem de update fosse relevante. Quando um jogador prepara-se para atirar, é fundamental que o player seja atualizado depois da arma. Caso contrário o sistema apresentará um jitter[2]. Nestes casos a arma pode setar uma flag no jogador para que ele não receba atualizações de pulso da EntityManager. O RepresentationManager mantém todas as EntiyRepresentations em uma hierarquia espacial que torna fácil e rápido a definição do que está ou não visível. Ele recebe uma notificação do EntityManager logo que uma Entidade é adicionada ou removida, com isto cria ou destrói a Representação correspondente. Quando recebe um pulso de frame, a RepresentationManager desenha todas as GameViews. A GameView é responsável por desenhar o mundo para um jogador, ela acompanha a câmera ativa e usa a hierarquia espacial da RepresentationManager para desenhar todas EntityRepresentations visíveis, além de desenhar também as Não-Entidades, como o mundo estático e a HUD sobreposta a todos eles. O  SSN67 poderia possuir o modo multiplayer com a tela dividida, porém esta feature não foi desenvolvida por questões de tempo.

[2] Jitter é uma variação, um retardo na entrega de dados criando uma inconsistencia, termo também muito utilizado em redes de computadores.

Conclusão

Eu ouvi falar em Model View Controller pela primeira vez em 2004, nesta época eu já havia desenvolvido o motor que a empresa utilizava para construir nossos Serious Games. Porém quando fiquei a par das vantagens que esta arquitetura traria ao desenvolvimento, não pensei duas vezes, comecei a construir outro Engine do zero utilizando seus conceitos. Atualmente não consigo imaginar como seria desenvolver um game sem utilizar a arquitetura MVC. Fiquei muito contente em saber que na mesma época uma grande empresa como a Guerrilha Games estava pensando a mesma coisa, percebendo as grandes vantagens deste ótimo Padrão de Projeto. Segundo Jorrit Rouwé, esta nova arquitetura inclusive facilitou o gerenciamento de prazos da equipe, já que induziu a divisão das tarefas em blocos de código menores e intuitivos. Eles afirmam que utilizam esta arquitetura em todos seus projetos, inclusive no atual grande sucesso da empresa, o “sucessor” de Gears of War, KillZone 2.

Um abraço e até a próxima matéria da Abrindo o Jogo. Não esqueçam de deixar seus comentários e críticas

Ilustrações: Inara Cavichioli

Referências Bibliográficas:

Projeto de um Serious Game

Everton Vieira [1]

Luiz Alessandro Nörnberg [1]

[1] Gestum Ltda

{everton.vieira, alessandro.nornberg}@gestum.com.br

Resumo

Esta apresentação pretende incentivar o desenvolvimento na área de Serious Games ao mesmo tempo em que alerta para a importância da etapa de projeto e no que este difere-se de outros projetos de jogos.São abordadas todas as etapas de um projeto, a metodologia educacional utilizada e a metodologia de desenvolvimento.

Palavras Chave: Serious Games, Desenvolvimento de jogos, Metodologia

1. Introdução

Os Serious Games, principalmente os realizados como jogos de computador, encontram um mercado crescente no Brasil com a maturidade das corporações em relação ao e-learning. Conforme as empresas apostam em treinamentos não-presenciais, à distância e com forte base na tecnologia da informação, os Computer Serious Games passam a integrar o leque de recursos que temos disponíveis para a execução de um treinamento.

Neste cenário, este tipo de produto pode contribuir de forma muito efetiva no treinamento, embora para isso deva estar integrado a ele da melhor forma possível. Assumindo o treinamento como uma atividade educacional, concluímos que o jogo deve ter a mesma fundamentação, além de relação com conteúdo. Um Serious Game construído com base em uma metodologia educacional definida tem maiores chances de suprir essa necessidade.

Por outro lado o mercado de treinamentos demanda, cada vez mais, soluções personalizadas que precisam conter informações específicas da empresa, informações que muitas vezes são, inclusive, privadas. Assim, soluções de prateleira não servem e é necessário desenvolver cada produto de forma personalizada. Fazer isto dentro do tempo esperado pelo mercado é um desafio que só pode ser superado com a melhor organização da parte tecnológica, e é ai que entra a necessidade de se ter as ferramentas certas e um projeto muito bem estruturado.

Não pretendemos, nas seções a seguir, defender uma ou outra metodologia ou framework, mas sim um projeto que é sustentado por estes pilares. Nosso principal objetivo é chamar a atenção para a importância de se ter uma metodologia fundamentada e framework próprios para o desenvolvimento de Serious Games. Apresentaremos algumas informações sobre a metodologia EBT e o framework do Ludus Gestum apenas a título de exemplo.

2. Primeiro pilar: Metodologia

Para que se chegue ao grupo de processos ideal no desenvolvimento de um Serious Game, existe a necessidade de uma metodologia que fundamente nossas decisões, uma metodologia que sirva de pilar para o produto. Com este foco, A Gestum desenvolveu a EBT – Entertainment Based Training). Sua premissa é proporcionar, através da interatividade e do entretenimento, um treinamento lúdico e participativo, levando à maior absorção e retenção das informações, construção de conhecimento e estimulo de trabalho em equipe. Surgiu inspirada pelos estudos sobre a forma como a pessoa melhor retém o que aprende. É comprovado que, quando participamos ativamente do processo de aprendizagem, a assimilação é maior.

Um gráfico conhecido, em várias versões um pouco diferentes (o estudo original é da universidade John Hopkins), mas sempre na mesma linha, nos diz que a maior assimilação das informações e conseqüente geração de conhecimento só é alcançada pela pessoa quando esta faz parte do processo, experimentando, agindo. E mesmo assim o grau de assimilação é de cerca de 90%. A EBT assume que a retenção de 100% (apropriação do conhecimento) só é alcançada quando gostamos do que fazemos.

Ela parte do princípio de que todos treinamentos possuem, intrinsecamente, um componente educacional. Um jogo aplicado a este treinamento precisa ter o mesmo componente.

Isto vale, inclusive, para treinamentos com foco informativo onde, pelo menos, se espera que a informação seja retida pelo treinando. Porém é quando temos foco formativo que a componente educacional é mais marcante. Com este foco espera-se que o treinando construa conhecimento sobre determinado assunto e para isso, a importância da metodologia educacional é inquestionável.

Naturalmente não são todos Serious Games que demandam esta atenção. Quando são utilizados desvinculados de um treinamento, como, por exemplo, jogos aplicados para seleção de recursos humanos, não há uma necessidade real de abordagem pedagógica. Afinal, neste caso, não se espera que o jogador aprenda algo ao jogar – ou pelo menos não é este o foco do seu uso.

No exemplo acima, um jogo para seleção de recursos humanos cumpre o papel de testar as pessoas sobre competências que elas já devem possuir. E isto nos remete a uma utilização importante dos Serious Games, que é a avaliação sobre um conhecimento adquirido. Porém, sendo utilizado em um treinamento, a força do Serious Game pode e deve ser utilizada também na própria etapa de aprendizagem, como incentivo e como forma de incorporar o aspecto lúdico, que desperta o gosto do treinando e facilita o estudo e a retenção das informações.

A importância da metodologia educacional no projeto, surge porque um jogo é um espaço dinâmico onde a abordagem pedagógica pode tornar-se bem evidente. No entanto, a utilização da abordagem incorreta ao público ou ao propósito, ou mesmo a mistura de abordagens que não são complementares, pode comprometer sua efetividade.

Utilizaremos uma abordagem behaviorista e daremos uma recompensa a cada ação correta do jogador? Ou vamos seguir a linha humanista e permitir a reflexão sobre o resultado da ação para determinar se foi correta? O jogo será construtivista, partindo do conhecimento que a pessoa já tem? Estas são decisões importantes para um jogo que deve ser utilizado para treinamento.

3. Simulação versus Jogabilidade

Uma segunda etapa no projeto seria identificar o grau de simulação deste serious game. Um Serious Game pode ter duas orientações principais, sendo mais simulador ou mais jogo. Estas são duas orientações antagônicas e nem sempre o meio termo é viável. Por isso é necessário que o projeto leve em conta a avaliação de qual orientação é melhor para cada caso.

Em geral o simulador busca a reprodução fiel da realidade, contextualizando o assunto do treinamento e permitindo que o treinando explore possibilidades reais em um ambiente bem próximo do que ele vai encontrar, digamos, no desempenho de sua função.

A orientação para a simulação favorece a geração de conhecimento tácito, aquele que é pessoal e subjetivo, provindo da experiência prática. Entretanto o ponto forte do simulador é permitir a um treinando que ele aplique na prática o que aprendeu, ou seja, exige que algo tenha sido aprendido de antemão. Um dos casos mais extremos é o simulador de vôo, onde pouco se faz se não houver uma instrução anterior sobre como operar os controles.

Mudando para os Serious Games, com melhor jogabilidade, eles são mais intuitivos porém não focados em reproduzir a realidade. Aproximando-se, assim, dos jogos no sentido mais tradicional. Com eles temos mais liberdade no uso de metáforas. Por exemplo, podemos ter um jogo de marketing onde o objetivo do jogador, como “aranha do marketing” é prender todo público alvo na sua teia de ações publicitárias. Falhas nas ações – como a falta de um outdoor em ponto freqüentado pelo público alvo – seriam buracos na teia.

Nesta orientação, podemos passar o próprio conteúdo a ser aprendido dentro do jogo, não havendo restrições quanto a interromper a ação em tempo real ou utilizar recursos de fantasia para explicar conceitos.

Vemos que, tratando da aplicação em treinamento, ambas orientações podem ser utilizadas com sucesso – mas sempre com o componente educacional levado em conta. No caso do simulador talvez seja importante que ele sempre seja utilizado no fim do treinamento, para avaliar o que foi aprendido; ou então, no início, para conscientizar o treinando da necessidade do estudo. Seja como for, esta é uma decisão que deve ter um embasamento coerente e estar prevista no projeto

4. Segundo pilar: Framework

Comentamos que os Serious Games possuem um mercado crescente quando integrados com treinamentos para empresas. Mas é importante lembrar que a tendência é que as empresas sejam compradoras de treinamentos feitos sob encomenda, sob medida, embora demandando a agilidade de desenvolvimento que só é encontrada em jogos de prateleira, esperando disponibilidade quase imediata.

Hoje o desenvolvimento de um curso tradicional para treinamento on-line é feito em um tempo curto dentro das expectativas do cliente. Ao contrário, um serious game completo, de qualidade, exige uma equipe numerosa para tentar alcançar esta marca. Visando diminuir esta diferença a fim de oferecer um Serious Game como parte de um treinamento, precisamos diminuir seu tempo de desenvolvimento ao máximo sem perder a qualidade.

O desenvolvimento de um Serious Game não é exatamente igual ao desenvolvimento de jogos em geral, isto é fato. Entre outras, a natureza instrucional do Serious Game e a necessidade de atender a objetivos específicos de treinamento são duas diferenças cruciais que destacamos.

A solução para isto é a utilização de um framework que contemple:

1. Alto reaproveitamenteo de tecnologia;
2. Alta facilidade de auditoria e legibilidade;
3. Ferramentas específicas de desenvolvimento;

O reaproveitamento de que falamos, em geral é de código – ou melhor, de objetos levando em conta que a utilização de um framework não orientado a objetos simplesmente não é realidade hoje em dia. Se a orientação a objetos é uma ótima forma de lidar com a complexidade em software, um jogo é por natureza um software complexo. Se outros sistemas vão crescendo em complexidade com o tempo, o jogo já nasce complexo, fazendo uso de recursos, entre outros, de computação gráfica só para termos algo na tela.

É importante ressaltar que a orientação a objetos é geralmente tida como lugar comum, mas em algumas tecnologias atuais (jogos feitos com tecnologia Flash, por exemplo), ela ainda é desconsiderada.

Facilidade de auditoria refere-se à capacidade do sistema de ser entendido por alguém que não seja a pessoa que o escreveu. Esta característica, infelizmente ainda incomum no desenvolvimento de software, é importante também devido a complexidade do sistema, que na realidade acaba se tornando difícil de entender até mesmo pelo seu criador.

Temos hoje padrões de projeto consolidados na comunidade de desenvolvimento e que ajudam a modelar quase todos aspectos de um sistema. Por serem conhecidos, estes padrões são facilmente identificáveis na implementação e facilitam o entendimento do funcionamento e relação entre as partes. Um desenvolvedor, que conheça os padrões de projeto, leva um tempo menor para começar a produzir ao ser adicionado a um projeto que esteja assim orientado.

5. Etapas do projeto

Com base nas informações descritas nas seções acima, podemos enumerar cada uma das etapas que compõem um projeto de Serious Game. Elas são ilustradas no diagrama abaixo.

Etapas de um projeto

Inicialmente é necessário um estudo aprofundado do conteúdo a ser abordado no Serious Game. Em geral a empresa cliente disponibiliza documentação sobre os processos, estudos de caso, apostilas de treinamento e outros materiais que o jogo deve abranger. Este material deve ser analisado por todas as partes envolvidas (game designer, direção de arte, designer instrucional) (Etapa 1: Ler Documentação).

Durante esta análise, muitas idéias surgem para o Serious Game. Elas devem ser apresentadas em uma reunião de brainstorm entre os envolvidos, onde vai se delinear o jogo. Nesta etapa são definidos pontos como:

1. Orientação do produto jogo ou simulador;
2. Ambientação e metáfora utilizada (se houver);
3. Jogabilidade de forma geral;
4. Objetivos do jogador com relação ao conteúdo;
5. Forma de interação com o conteúdo (será mostrado em pontos específicos do jogo? Deve ser estudado à parte?);
6. Indicadores de avaliação: como medir o desempenho do jogador no conteúdo;
7. Pontuação e evolução do jogador no jogo, como será modelada a dificuldade;

6. Alinhamento com o cliente

A criação de um anteprojeto é fundamental em projetos deste tipo.

Em um jogo de prateleira existe apenas a pesquisa de mercado – os clientes irão comprar o jogo se gostarem. Caso contrário, irão ignorá-lo. Já em Serious Game, em geral feito sob encomenda, o cliente precisa gostar, ou não existe negócio.

O Anteprojeto é a forma de alinhar o produto com as necessidades do cliente, apresentando para ele os pontos levantados na etapa anterior. É uma fase de desenvolvimento de requisitos.

Após este alinhamento é iniciado o projeto propriamente dito. Nesta etapa é descrito em detalhes os requisitos levantados no anteprojeto e dá-se inicio ao desenho da jogabilidade. Este é representado através de um diagrama de storyboard.

Nele é possível, não só visualizar todos os pontos de interação do usuário, como também todas as decisões que podem ser tomadas no jogo.

7. Reaproveitamento

A etapa seguinte é a análise das classes que devem ser desenvolvidas para este projeto. É aqui que ocorre um estudo de reusabilidade dos objetos já construídos em jogos anteriores. Como o reaproveitamento de classes é uma das bandeiras da OO, é importantíssimo identificar processos já simulados em jogos anteriores para reduzir o custo e tempo de entrega.

8. Participação do cliente

A cada ciclo de desenvolvimento um protótipo é montado e antes de ser entregue ao cliente direto, este é submetido à testes com o usuário final (público alvo do jogo). É feito uma análise de comportamento perante a interface e através dos resultados alterações são iniciadas.

Só então o protótipo é disponibilizado ao cliente para um alinhamento do produto.

9. Conclusão

O principal critério que leva o desenvolvimento de Serious Games, ser diferenciado em relação aos demais jogos, seria o fato deste respeitar um mercado exigente, que procura por um produto personalizado e único, capaz de capacitar um determinado público alvo num espaço curto de tempo. Outro fator que deve ser lembrado é o envolvimento de questões educacionais, pois antes de ser um jogo ele deve ser um curso, cujo objetivo é capacitar o jogador.

Por estes motivos o projeto é uma etapa fundamental para alinhar e configurar todos os requisitos necessários. Isto garante ao produto a qualidade necessária para alcançar as expectativas do cliente.