Você está na página 1de 30

Fast Game Language

Uma Linguagem Específica de Domínio para configuração de Jogos de aventura na plataforma Android

Jimens Cândido Barbosa Lima1, Vinicius Cardoso Garcia2
1

Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R. EDU
2Centro

de Informática – Universidade Federal de Pernambuco
jimenslima@gmail.com, vcg@cin.upfe.br

Abstract: This paper explores the construction of a domain specific language for creating games using a paradigm that is being investigated in industry and aims to transform the current software development, based on a simple understanding language that solves a specific problem. A case study was conducted to check the viability of the language. The specified DSL seeks to simplify the creation of a game, showing that textual languages can be used in this context. Resumo: Este trabalho, explora a construção de uma Linguagem de Domínio Específico para a criação de jogos, utilizando um paradigma que vem sendo investigado na indústria e que visa transformar o desenvolvimento de software atual, baseado numa linguagem de simples entendimento que resolve um problema específico. Um estudo de caso foi conduzido visando analisar a viabilidade da linguagem. A DSL especificada procura simplificar a criação de um Jogo, demonstrando que linguagens textuais podem ser utilizadas neste contexto. 1. Introdução De acordo com a ESA (Entertainment Software Association) [1], a indústria de jogos digitais é uma das mais bem-sucedidas do mundo, equiparando-se até mesmo às indústrias de cinema e música [2]. Desde o surgimento das lojas virtuais de aplicativos como: Apple Store, Android Market e Windows Marketplace, as aplicações geralmente

vendidas por US$ 0,99 impulsionaram este mercado. Como, exemplo, o jogo Cut the Rope [3], em apenas 10 dias, foi baixado mais de 1 milhão de vezes1. Este trabalho aborda uma nova abordagem no desenvolvimento de software que vem sendo muito discutido na indústria dos games. Serão abordados alguns conceitos e a prática de Domain Specific Languages (DSL). A Engenharia de Software e arquiteturas orientadas a objetos trouxeram vários benefícios para o desenvolvimento de jogos, como o nível de abstração, que diminui a complexidade de se construir um novo jogo, bem como a utilização de bibliotecas que auxiliam desenvolvedores que não possuem tanta experiência em construir jogos de forma mais rápida, com menos erros e seguindo um processo pré-definido [4]. 1.1. Caracterização do Problema Segundo a ESA (Entertainment Software Association) [1], a criação de um Jogo não é uma tarefa trivial, exigindo do desenvolvedor uma larga experiência e domínio de arquiteturas, plataformas, ferramentas e tecnologias envolvidas. Há evidências que o paradigma atual de desenvolvimento de software está perto do fim, e que um novo é necessário para apoiar os próximos passos da tecnologia. Na próxima década, a demanda global para produção de software vai crescer uma ordem de magnitude, impulsionada pela força da economia global, pela integração com as áreas médicas e sociais e pela reestruturação das plataformas voltadas a serviços distribuídos [5]. Sem um aumento de produtividade comparável, a capacidade total de desenvolvimento de software parece destinada a estar muito aquém da demanda total. Isto é, os métodos e práticas de desenvolvimento de software terão que mudar drasticamente para tornar os desenvolvedores muito mais produtivos. Tendo como base os dados citados, surgiu a necessidade criar uma plataforma que facilitasse o dia a dia um desenvolvedor, e como exemplo de aplicação, por não possuir tantos detalhes, foi selecionado um Jogo do tipo aventura2 para dispositivos móveis.

1 2

http://mashable.com/2010/10/15/cut-the-rope/ http://pt.wikipedia.org/wiki/Jogo_eletronico_de_aventura

2

1.2. Objetivos O principal objetivo deste trabalho é apresentar uma linguagem que ajude os desenvolvedores em geral que não possuam tanta experiência e conhecimento nas mais diversas plataformas de desenvolvimento a criar jogos de aventura de forma ágil, com alta produtividade por meio da redução do esforço do desenvolvimento e com a qualidade esperada pelo mercado de jogos. Para tal, será apresentada uma DSL para criação de deste estilo de jogo, fazendo uso da plataforma de desenvolvimento Android 3 com a Game Engine (Andengine) e o projeto do Eclipse Xtext. O domínio escolhido foi um jogo de ação por ser simples de se desenvolver, sem tantas particularidades, e que atendesse aos objetivos propostos no trabalho. Os objetivos específicos são:

Disponibilizar um plugin para o ambiente de desenvolvimento do Eclipse que auxilie a configuração de Jogos do estilo Aventura para a plataforma Android. Com ele, será possível configurar os personagens do Jogo, definir quais serão seus inimigos, a pontuação que o jogador perderá se o inimigo atingi-lo, etc.

Apresentar um estudo sobre as vantagens de se utilizar linguagens de domínio específico (DSL’s), na criação de jogos para dispositivos móveis.

1.3. Justificativa Atualmente, existe uma grande quantidade de ferramentas (Game Maker [6], RPG Maker VX [7], GakeKa [8] e engines para criação de Jogos para programadores e não programadores, porém, poucas se detém ao o comportamento real de criação de um jogo, tampouco que simplificam o entendimento necessário para criação de jogos. Portanto, surge a necessidade de desenvolver uma linguagem que seja extensível, de fácil adaptação, que agilizasse a configuração de um jogo, que entregue um produto de
3

http://www.android.com

3

qualidade e que levasse pouco tempo desde a fase de concepção até a entrega do jogo. 1.4. Contribuição A principal contribuição do trabalho é a DSL que auxilia e acelera a construção de um jogo partindo do zero. Além disso, a ferramenta faz reuso de componentes / frameworks, algo muito explorado na indústria de software. 1.5. Metodologia O estudo deste artigo foi realizado através de pesquisas de frameworks, dissertações, sites de pesquisa, livros especializados no assunto abordado, técnicas de desenvolvimento de software. A Tabela 1 descreve os itens pesquisados e suas justificativas.

Itens Pesquisados
Artigos e Livros

Justificativas
Embasamento na construção de uma linguagem de domínio específico para o desenvolvimento de jogos, e de como acelerar a entrega dos mesmos.

Tecnologias

Demonstrar

como

linguagens

de

domínio

específico (DSL’s) ajudam no entendimento e resolução de um problema específico. Componentes Auxiliar os desenvolvedores de Games a criar jogos de uma forma efetiva e com qualidade numa única plataforma de desenvolvimento. Ferramentas Utilizadas na criação, definição e modelagem do Jogo.
Tabela 1. Metodologia de pesquisa

4

2. Fundamentação Teórica Como descrito por Terrance Parr [9], uma linguagem de domínio específico (DSL) significa que a linguagem é adaptada a um domínio de destino. Sendo uma DSL, a forma clara de se definir uma idéia que deseja expor, um problema específico a ser solucionado. Como exemplo, a NASA utiliza DSL’s para criar os softwares que são utilizados nas missões espaciais, para melhorar a confiabilidade, reduzir os riscos, custos e aumentar a produtividade no desenvolvimento [4]. A vantagem da criação de uma linguagem específica é o aumento da abstração do domínio que é fornecido pela linguagem para aumentar a sua expressividade. Podemos compará-la com Linguagens de Propósitos Gerais (GPLS). Com uma DSL é possível expressar soluções para problemas de domínio específico fazendo um menor esforço. As DSL’s podem variar em diversas formas, tanto na sintaxe quanto na semântica, e também na forma com que elas são criadas que podem ser por meios visuais ou textuais [10]. Uma DSL melhora a capacidade de leitura e escrita dos artefatos, permitindo que um grupo maior de pessoas com menos experiência em programação seja mais produtivo, além disso, diminuição nos erros e também nos custos de manutenção. Ao focar na estrutura do domínio, a DSL torna uma representação mais legível do que se trata o domínio. Quando o domínio é mapeado em linguagens de programação comuns o código possui vários detalhes intrínsecos, que não são relevantes para o entendimento do domínio do problema, no entanto são imprescindíveis para o desenvolvimento da solução. Existem muitas DSL’s no meio computacional, que utilizamos no nosso dia-a-dia sem mesmo percebermos. Exemplos dessas linguagens são HTML, XML, linguagens de banco de dados como SQL e PLSQL, estas possuem uma ligação direta com a plataforma que se destinam e criam uma maior familiaridade para o desenvolvedor que precisa desenvolver algum requisito para a mesma. Existem dois tipos de DSL, externas e internas. Uma DSL interna está totalmente ligada às linguagens de programação e podem ser similares quanto à semântica e sintaxe. Uma DSL externa não está relacionada com linguagens de programação, têm a sua sintaxe personalizada e parsers para processá-los. Há uma tradição muito forte de fazer isso na comunidade Unix. Muitas configurações XML acabaram como DSL’s 5

externas, tal como o DTD (Document Type Definition), apesar da sintaxe XML não ser adequada para esta finalidade [10]. A produtividade e a manutenibilidade é aumentada devido a um domínio apropriado e por ter uma linguagem específica. Uma linguagem de domínio específico (DSL) é mais adequada para programadores que possuem um determinado foco, tal como: desenvolver algo para web, criar uma procedure no Oracle, etc. Os especialistas são capazes de entender, validar, modificar e desenvolver dentro da linguagem uma melhor legibilidade e uma maior abstração. Os ganhos podem ser medidos quantitativamente e qualitativamente. A validação quantitativa das vantagens de uma DSL é um campo em curso de investigação [11].

Figura 1: Domain-specific languages (Adaptado de MARJAN MERNIK, 2005).

A Figura 1, apresenta uma comparação dos custos da metodologia convencional de desenvolvimento de software (C1), com uma metodologia baseada em DSL (C2). O custo de criação inicial da (C2) é mais alto, porém, no decorrer dos ciclos da construção do software, a (C1) se torna mais custosa, justamente por não utilizar técnicas adotadas na metodologia (C2). O custo inicial para construção de uma nova linguagem está totalmente relacionado com a complexidade da mesma, bem como o tempo necessário para deixa-la matura o suficiente para produzir um produto aderente ao que se propõe.

6

2.1. A necessidade de um novo paradigma O instituto Standish Group [12], revela uma queda acentuada nas taxas de entrega de projetos: com (32%) entregues no prazo, dentro do orçamento previsto e com todas as funcionalidades, (44%) com muito atraso, acima do orçamento e / ou com poucas funcionalidades implementadas como prometidas e (24%) dos projetos falharam ou nunca foram utilizados. Embora as causas do fracasso estejam relacionados às tecnologias limitadas ou equipes desqualificadas, quase todas as causas reais estão relacionadas com a forma que os usuários e clientes estão envolvidos durante um projeto de desenvolvimento de software [4]. Algumas das principais causas de fracasso são: • • • • Falta de integração entre ferramentas Separação entre negócio e Tecnologia Falta de rastreabilidade Falta de objetividade

Uma DSL procura resolver alguns dos itens acima citados, trazendo ao usuário da mesma maior clareza quanto ao que será produzido. De acordo com Jack Greenfield [13], a maior parte dos softwares desenvolvidos hoje é criada a partir do zero, e grande parte dos mesmos tendem ao insucesso. Para o desenvolvimento massivo de um software é preciso aumentar tanto a capacidade de produção escalável, quanto a reusabilidade de componentes pré-existentes. 2.2. Economia em escala e escopo A reutilização sistemática pode gerar economias de escala e escopo. Esses dois efeitos são bastante conhecidos em outras indústrias. Embora ambos reduzam tempo e custo, e aprimorem a qualidade do produto pela produção coletiva e não individual de diversos produtos, diferem na forma como produzem esses benefícios [13]. Segundo André Furtado (2006), para notar os benefícios do reuso, uma metodologia mais madura deve ser adotada. Esta deve envolver a identificação de subproblemas comuns em um determinado domínio e criar melhorias para o processo

7

proposto. A esta abordagem dá-se o nome de reutilização sistemática, onde se espera aumentar o retorno sobre os investimentos com os artefatos criados a partir da metodologia definida. A economia em escala é atingida quando projetos idênticos podem atender a diversos nichos, produzido em equipes distintas e não individualmente [2] [14].

Figura 2. Escala e economia [2]

A economia de escala surge quando vários componentes idênticos de um único projeto são produzidos coletivamente, e não individualmente, como ilustrado na Figura 2. 2.3. Utilização de DSL’s De acordo com Neighbors, J. M. (1984), DSL’s abrangem vários domínios, tais como: produtos financeiros, arquiteturas de software, bancos de dados, drivers de placas de vídeo, sistemas operacionais, computação nas nuvens, manipulação de imagem, animação 3D, telecom, protocolos de comunicação, simulação, agentes móveis, controles de robôs, equações diferenciais, etc [15]. A adoção de uma DSL envolve riscos e oportunidades. DSL’s bem projetadas, conseguem encontrar as seguintes vantagens: • Permitem que soluções sejam expressadas numa linguagem de alto nível de abstração relacionada ao domínio do problema e, consequentemente, especialistas do domínio podem entender, discutir, validar, modificar, e muitas vezes até mesmo desenvolver DSLs; 8

Aumentam a produtividade, confiabilidade, facilidade de manutenção e a portabilidade [16] [17];

Se incorporam ao conhecimento do domínio, e assim permitem a conservação e reutilização deste conhecimento;

Permitem a validação e otimização no nível do domínio [18,19, 20]; Em contrapartida, uma DSL não tem apenas vantagens, mas também falhas

potenciais. Uma desvantagem é que inicialmente é preciso um alto esforço de desenvolvimento necessário para criação de uma nova linguagem. O desenvolvedor da DSL precisa ter menos experiência no propósito geral da linguagem e mais conhecimento sobre o domínio alvo, deixando de lado uma fase necessária no entendimento do modelo. Ele precisa encontrar um bom equilíbrio entre uma GPL e uma DSL. A utilização de DSL’s é algo relativamente novo e não existem muitas ferramentas, padrões e processos que implementem todos os seus requisitos de forma completa. Outros problemas são as ferramentas, o custo do treinamento para os usuários. Apesar de linguagens de propósito gerais, como Java ou C #, terem várias ferramentas para acelerar o desenvolvimento, IDE’s como o Eclipse ou Visual Studio oferecem uma integração profunda com estas linguagens como editores poderosos, análise do código, integração avançada com os compiladores e depuradores. Criar um ambiente que se integre a uma ferramenta para a criação de uma DSL leva um determinado tempo, que dependendo da demanda pode se tornar demorado e aumentar os custos causados pela definição de uma nova linguagem. Todos os riscos de custos de formação do desenvolvedor, tempo de aprendizado e adaptabilidade da DSL, devem ser mitigados já no início do planejamento do software.

9

2.4. Estratégias adotadas para criação da DSL para Games Inicialmente é preciso identificar todos os pontos fracos para construção de um Jogo, quais os artefatos mais complexos de serem desenvolvidos, o tempo que cada artefato leva para ser produzido e elencar o que será abordado pela linguagem. Marjan Mernik (2005), cita que na fase de análise do desenvolvimento da DSL os problemas inerentes ao domínio precisam ser identificados e detalhados. Fontes de dados para criação da DSL também precisam ser explicitadas, tais como: documentos técnicos, conhecimentos fornecidos pelos especialistas no domínio, códigos e bibliotecas de propósito geral (GPL’s). 2.5. Projeto Xtext: Para seleção da ferramenta adequada, os critérios de familiaridade e menor curva de aprendizado foram levados em consideração: nesse contexto, o projeto Eclipse Xtext[21] foi a alternativa selecionada, por possuir mecanismos que ajudam definir, validar e executar uma nova linguagem de domínio específico (DSL). Desta forma, criar Jogos pode tornar-se uma tarefa não tão árdua. Além de aumentar a produtividade e abstrair alguns comportamentos da criação de um jogo, a DSL visa facilitar a forma que as ações ocorrem, embora em alguns casos Game Engines (Cocos2d [22], AndEngine [35]) atendessem a estes requisitos, a DSL que será proposta aborda uma abstração independente de uma Engine. O projeto Xtext surgiu da necessidade de se criar linguagens como DSL’s, mas também pode ser adotado para criação de linguagens de propósito geral, GPL’s. Com o Xtext é possível criar sua própria linguagem num curto espaço de tempo e totalmente integrada ao ambiente de desenvolvimento Eclipse. A empresa mantenedora do projeto 4, define o Xtext como um framework para desenvolvimento de linguagens. O Xtext provê um conjunto de DSL’s para descrever diferentes aspectos da nova linguagem de programação, que se integram totalmente com a JVM5 e são reutilizáveis.

4 5

Itemis – http://www.itemis.com Java Virtual Machine

10

Os componentes do compilador de sua linguagem são independentes do Eclipse ou OSGi 6 e podem ser utilizados em qualquer ambiente Java. Eles incluem ferramentas como analisadores léxicos, sintáticos, etc. Estes componentes de tempo de execução são baseados no EMF (Eclipse Modeling Framework), que permite utilizar o Xtext integrado com outros diagramas como o GMF (Graphic Modeling Framework).

Figura 3. Eclipse Xtext

A Figura 3 descreve a utilização de uma nova linguagem fazendo uso de recursos pré-existentes do Eclipse, tais como: auto-imports, beautifier, code-completion, codecoloring, outline. Estes recursos tornam a IDE adaptada à nova linguagem e mais agradável para o desenvolvedor. 2.6. Eclipse Modeling Framework Project (EMF) O projeto EMF é um framework de modelagem que facilita a geração de código para diversas plataformas. O modelo de dados Ecore [23] é utilizado para modelar e construir a arquitetura desejada como descrito na Figura 4. O EMF unifica as definições UML7, XML8 e Java. Estas definições são utilizadas para a criação de um meta-modelo. Por exemplo, imagine que se deseja construir uma aplicação para manipular alguma estrutura específica XML. Provavelmente se começaria com um esquema de mensagem.
6 7

http://www.osgi.org http://www.uml.org/ 8 http://www.w3.org/XML/

11

Com o EMF é possível pressionar um ou dois botões, e obter um diagrama de classes UML, pressionar outro botão, e ter um conjunto de classes Java para manipular o XML [24].

Figura 4. Diagrama da Fast Game Language do tipo Ecore

A Figura 4 contém as definições do modelo utilizado para criação da linguagem FGL. Todos os atributos, relacionamentos e cardinalidades são definidos no Ecore. 3. Model Driven Develelopment (MDD) Segundo Douglas Schmidt (2006), MDD é uma metodologia de desenvolvimento de software que está focada na criação de modelos ou abstrações. Assim, MDD está mais relacionada ao problema específico que a conceitos computacionais. É utilizada para aumentar a produtividade e a compatibilidade entre sistemas, simplificando o processo de design e facilitando a comunicação entre os stakeholders. O paradigma MDD só é considerado eficaz se os seus modelos fizerem sentido para a implementação do software. Os modelos são desenvolvidos através da comunicação ampla entre os gerentes do produto, designers e desenvolvedores. Para que o MDD seja instanciado com sucesso é preciso lidar com vários aspectos de forma integrada [25].

12

3.1. Domain Specific Modeling Language (DSML) O principal intuito de uma DSML é formalizar a estrutura e o comportamento de uma aplicação, as necessidades dentro de domínios específicos, tais como: serviços de financiamento online, gerenciamento de data warehouse, ou até mesmo plataformas middleware. DSMLs são descritas usando meta-modelos que definem as relações entre os conceitos de um domínio específico. Desenvolvedores utilizam DSMLs para criar aplicações que utilizam elementos que foram descritos no modelo [26]. 3.2. Aumentando a produtividade com MDD e DSL’s Richard C. Gronback (2009) descreve que linguagens de domínio específico (DSL) e o desenvolvimento dirigido ao modelo (MDD), oferecem aos desenvolvedores de software formas eficazes de melhorar a produtividade, a qualidade e isolar sistemas de mudanças tecnológicas bruscas. As abstrações definidas no MDD tornam eficaz o modelo de desenvolvimento de uma DSL, sendo possível trabalhar com uma arquiteturas desacopladas. No MDD, os modelos não são utilizados apenas como rascunhos, mas sim como artefatos primários a partir dos quais, outros artefatos serão criados [27]. O grupo OMG9, que é responsável pela UML (Unified Modeling Language), que também se encarregou de definir os padrões do MDD, criou a iniciativa MDA10 (arquitetura dirigida à modelos). A MDA é uma implementação da abordagem MDD. Conforme definido pelo OMG, MDA é uma forma de organizar e gerenciar arquiteturas corporativas, apoiada por ferramentas e serviços automatizados. A MDA possui três objetivos principais: Portabilidade, Interoperabilidade e Reusabilidade [28]. 4. Engines de transformação e geradores O papel das engines é analisar certos aspectos dos modelos e validar, em forma de restrições lógicas (logical constraints), o que foi descrito pelo modelo, e em seguida, agrupar os demais tipos de artefatos, como código fonte e arquivos de configuração. A capacidade de sintetizar artefatos a partir de modelos ajuda a garantir a consistência
9 10

http://www.omg.org/ http://www.omg.org/mda/

13

entre implementações do software e a análise funcional dos requisitos de QoS (Quality of Service) capturado pelos modelos. O processo de transformação automática é muitas vezes referenciado como "correct-by-construction", que depende de dois pontos: a implementação estará de acordo com o modelo, ou seja, se o modelo contiver erros, a implementação herdará os mesmos, e outro mais crítico ainda, a engine de transformação tem que ser devidamente certificada caso contrário pode gerar / introduzir erros no código gerado automaticamente, em oposição ao processo convencional de desenvolvimento artesanal "construct-by-correction" que é entediante e propenso a erros [29]. Uma característica importante do modelo é a que ele possa ser lido por uma máquina, de forma que seu conteúdo possa ser acessado de maneira automatizada. A leitura e interpretação do modelo são imprescindíveis para que os artefatos necessários possam ser gerados a partir do mesmo [30]. Em MDD os modelos não são usados apenas como diagramas e matrizes do projeto, mas como artefatos em que implementações eficientes de software usando padrões são geradas a partir de transformações de modelos em código ou outros artefatos. MDD permite uma automação que vai além da geração de código. Fazendo uma analogia aos padrões utilizados, podemos comparar o Human Work com um PSM (Platform Specific Model), pelo fato de um PSM conter parte do que seria escrito manualmente, ao invés do PIM (Platform Independent Model), que descreve quais serão os comportamentos dos casos de uso. A partir de um único modelo é possível acelerar a criação e alteração de alguns tipos de artefatos, tais como: • Documentação: Um dos grandes problemas em um ambiente tradicional de desenvolvimento é documentação. Mantê-la em dia com o projeto é uma tarefa que demanda tempo e recursos que poderiam estar desenvolvendo outras tarefas para a evolução do software. Ao adotar MDD é possível sincronizar o modelo de negócio com o projeto, pois ela pode ser gerada a partir do modelo. Toda e qualquer alteração precisará ser feita no modelo e replicada para a aplicação.

14

Casos de teste: É possível gerar de testes unitários básicos até testes de integração, a partir dos modelos com suporte a frameworks reconhecidos como JUnit ou outros, dependendo de qual ferramenta de testes é adotada pela empresa.

Scripts de build e implantação: Descritores da construção do software e de implantação também podem ser gerados, tirando mais um trabalho das mãos dos desenvolvedores.

Camadas da aplicação: No ciclo de desenvolvimento existem várias etapas como análise, projeto e implementação, e para cada etapa usa-se um tipo de modelo diferente; também há modelos que representam as diferentes partes de um sistema, interface de usuário, lógica de negócio, administração do sistema, e também há modelos que representam diferentes tarefas como testes e implantação. Dependendo do modelo é possível gerar “sub-modelos”, ou algum deles, a partir de parte do modelo original.

• Aplicação de padrões: Padrões são soluções comuns para problemas recorrentes na indústria de software. Com MDD é possível guiar a geração para que certos padrões sejam seguidos, resultando em um produto final que está de acordo com o padrão escolhido. MDD tem um grande diferencial para as empresas de desenvolvimento de software, por poder melhorar bastante o processo de produção de software. Algumas das principais vantagens são: • Manutenção: Mudanças tecnológicas podem ser rapidamente resolvidas, pois a modelagem do sistema é feita independente da plataforma final. • Reuso: MDD permite o reuso de padrões, arquitetura e componentes devido à geração de código estruturada sempre da mesma forma e do uso de componentes necessários para a aplicação. • Adaptabilidade: Mudanças em funcionalidades e regras de negócio podem ser adaptadas mais facilmente, pois não é necessário alterar o sistema inteiro,

15

somente nos pontos onde se aplicam as regras, deixando as alterações mais técnicas por conta das transformações de modelos. • Consistência: Executar alterações manualmente é uma prática que pode levar a introdução de erros no sistema. Com MDD é possível diminuir a quantidade de erros e tornar o produto final mais consistente uma vez que tudo que se baseia no modelo é sempre regerado. • Melhoria na comunicação entre stakeholders: Com o uso de modelos de alto nível, que retratem melhor o domínio e omitam os detalhes técnicos, é possível criar uma linguagem única entre os stakeholders do projeto [31]. Retardo na decisão sobre tecnologia: Muito do esforço na criação do projeto está presente na modelagem e na arquitetura do sistema, portanto decisões técnicas de qual tecnologia e plataforma serão usadas podem ser feitas mais adiante no processo [32]. 5. Trabalhos relacionados Nesta seção será apresentada uma breve visão sobre o trabalho já realizado de quatro ferramentas para criação de Jogos baseadas no conceito de DSL’s. Na seção 3.7 será apresentado o projeto SharpLudus, uma DSL para criação e definição de Jogos, que utiliza os conceitos de DSL visual e textual. Na seção 3.8, será apresentado o Game Maker, software escrito por Mark Overmars, que facilita a criação e modelagem de Jogos 2d. Na Seção 3.9 a DSL ViGL (Video Game Language), uma linguagem para criação de Jogos 2d e finalmente na Seção 3.10, a GameKA, uma ferramenta de jogos para não programadores. 5.1. Ferramentas para criação de Jogos O uso de APIs para desenvolver jogos requer alguns conhecimentos de programação e pode não ser uma tarefa trivial, especialmente para iniciantes. Com a intenção de simplificar o desenvolvimento do jogo e torná-lo mais acessível a uma gama mais ampla de comunidades, ferramentas para criação visual de jogos se tornaram

16

populares. Elas visam a criação de jogos completos sem nenhuma programação. O usuário final é auxiliado por interfaces gráficas ricas em características do Jogo, sendo possível definir o comportamento dos personagens, o fluxo jogo , adicionar sons, menus, etc. 5.2. AndEngine O primeiro passo para criação da linguagem foi a escolha de um framework para desenvolvimento de jogos que já agregasse características comuns para construção de um jogo, tais como: Sprites 11, tratamento de sons, cenários, física, controles de colisão, etc. A AndEngine é uma API para criação de Jogos 2D, foi construída na plataforma de desenvolvimento Java12 e possui licença GPL13. A API foi escolhida por ter pela familiaridade cuja plataforma foi implementada, encurtando a curva de aprendizado e acelerando o desenvolvimento da DSL. Com ela é possível criar jogos como descritos na Figura 5.

Figura 5. Jogos criados com a AndEngine [35].

11 12

http://en.wikipedia.org/wiki/Sprite_(computer_graphics) http://www.oracle.com/br/technologies/java/index.html 13 http://www.gnu.org/licenses/lgpl.html

17

5.3. SharpLudus O projeto SharpLudus [2] ilustra como a industrialização sistemática de um software, orientada a previsibilidade e produtividade, pode ser aplicada em domínios caracterizados pela inovação, criatividade e dinamismo. O projeto explora a integração entre o desenvolvimento de jogos, uma disciplina inerentemente criativa, com fábricas de software, que estão preocupadas com o paradigma de desenvolvimento de software, baseado em habilidade e com o processo de criação. Abrange: DSL’s visuais, validadores semânticos e geradores de código, fazendo com que os desenvolvedores e designers trabalhem de forma mais produtiva, com um maior nível de abstração e mais próximo do domínio da aplicação.

Figura 6. IDE SLGML (SharpLudus Game Modeling Language)

A Figura 6 ilustra o funcionamento do SharpLudus. Do lado esquerdo, os componentes GML (Graphic Modeling Language) do domínio do Jogo, que são utilizados para criação do Jogo em si, na parte inferior, caso exista algum erro no diagrama do diagrama, será exibido com um ícone vermelho com o aviso.

18

Figura 7. Jogo criado pelo SLGML [2].

O jogo Ultimate Berzerk (Figura 7) é baseado no jogo Berzerk, criado para o console Atari 2600, onde o jogador controla um personagem principal que se move em torno de um labirinto composto por salas conectadas, cada uma contendo inimigos (robôs) que podem ser atingidos pelo personagem principal [2].

5.4. Game Maker O projeto GameMaker [6], Figura 8, é uma IDE para criação de Jogos 2D. Todos os elementos (som, imagens, gráficos, etc) são integrados. Também utiliza o conceito de drag-and-drop. O GameMaker não é focado num tipo específico de Jogo. Além das funcionalidades visuais disponíveis, também é fornecido uma linguagem de Scripts GML (Game Maker Language) para otimização do jogo. Um jogo criado com o Game Maker, consiste em três elementos principais: • • • Dados: personagens, sons, backgrounds e fontes. Controle: Objetos, timelines, scripts e animações. Níveis do jogo, ou como a equipe do Game Maker define, rooms.

O Game Maker utiliza o paradigma de Orientação a Objetos. Cada objeto pode ser herdado, modificado, todos eles representam objetos de um jogo real.

19

Figura 8. Game Maker [6].

5.5. ViGL ViGL (Video Game Language) é uma DSL que tenta capturar os artefatos em comum entre diversos jogos 2d. Ela permite ao desenvolvedor prototipar rapidamente jogos 2d. O código criado pela DSL pode ser reutilizado para criar outros jogos. A ViGL é muito simples de se compreender, inicialmente os criadores optaram por defini-la totalmente baseada no XML, posteriormente, viram que com XML, não se podia lidar com todas as características de uma linguagem. Se decidiu criar um junção de XML (como uma linguagem declarativa) e um código embarcado (a própria DSL textual). A Tabela 2, descreve as funcionalidades implementadas no ViGL [33] [34].

20

Características Gráficos Som Entrada de Dados Objetos Mundo Interação Controle do Usuário

Funcionalidades Carregar imagens, textos, etc. Carregando, Iniciar, Parar, Pausar. Mouse e Teclado Diferentes formas, tamanhos e posições. O mundo do jogo e as regras das formas no mundo. Interação entre os objetos e o mundo do jogo. A forma que o usuário interage com o mundo do jogo.

Tabela 2. Visão geral das funcionalidades da ViGL [19].

5.6. GameKa uma ferramenta de desenvolvimento de jogos para não programadores O recente estudo conduzido por Igor Augusto (2011) para a SBGames14 apresenta ferramentas que tem como objetivo viabilizar o desenvolvimento de jogos pelo público não programador. Diversas ferramentas de apoio foram criadas. Por meio destes softwares é possível criar um jogo mesmo que o usuário possua pouco ou nenhum conhecimento de programação, simplesmente arrastando objetos para um cenário e determinando seus comportamentos através de menus [24]. Pode-se destacar que uma ferramenta para auxiliar não programadores possui ao menos três funcionalidades: um editor de objetos, um editor de cenários e um editor de eventos.

Figura 10. Gameka [24].

14

http://www.sbgames.org/

21

A ferramenta Gameka (Figura 10) é um software de apoio ao desenvolvimento de jogos 2D voltado ao público não programador, cujas principais características são: open-source, multiplataforma e direcionada ao desenvolvimento de gêneros diversos. A ferramenta possui um ambiente de desenvolvimento completamente visual e disponibiliza ao desenvolvedor diversas funcionalidades prontas para a criação dos mais variados gêneros de jogos 2D, tais como aventura, shooter, nave, corrida e puzzle. 5.7. Matriz comparativa

Ferramentas
SharpLudus

Formato de Distribuição
Plugin do Visual Studio .NET Plataforma Própia

Licença
Ms-PL

Plataforma
Windows

DSL’s Implementadas
SharpLudus, Game Modeling Language (SLGML) Configuração,comportamento e ações dos personagens Configuração,comportamento e ações dos personagens

GameMaker

Paga(99.00)

Multiplataforma

ViGL GameKa GameSalad AndEngine

XML Plataforma Própia Plataforma Própia Bibliotecas

GPL GPL Paga(99.00) GPL

Multiplataforma

Multiplataforma Configuração, Edição de Cenários Mac OSX Multiplataforma Configuração,comportamento e ações dos personagens N/A

Tabela 3. Matriz comparativa das ferramentas utilizadas e pesquisadas no trabalho.

6. Fast Game Language Criar um Jogo não é uma tarefa trivial, além da alta complexidade, não existe uma forma pré-estabelecida para se idealizar um. Apesar do número de ferramentas existentes para não programadores (GameSalad15, GameKa, Game Maker, etc), surge a necessidade de criar uma linguagem, auxiliando desenvolvedores que não possuem tanta experiência em ferramentas de desenvolvimento de jogos, e automatize a criação de componentes do jogo. Ela precisa ser simples, que seja familiar para os desenvolvedores

15

http://gamesalad.com/

22

Java e que num curto espaço de tempo se possa criar um jogo de ação para a plataforma Android. A linguagem segue os seguintes critérios: • • Ser compatível com a IDE Eclipse (por ser muito utilizada pela comunidade livre) Poder ser utilizada em qualquer Sistema Operacional.

AlexKid   FGL   Xtext   AndEngine  

Android  
Figura 11. Tecnologias e ferramentas utilizadas na criação da linguagem.

A Figura 11 elenca as arquiteturas e frameworks utilizados para a criação da FGL (Fast Game Language). Para validação de conceito, um jogo de aventura foi criado na plataforma AndEngine [35]. A partir da FGL é possível configurar algumas particularidades do jogo, de forma a selecionar os personagens que vão interagir, bem como pontuação, orientação da tela, etc. 6.1. Definição textual da linguagem O primeiro passo para criação da linguagem é ter em mente quais problemas serão resolvidos pela mesma. Fazendo uso do Eclipse Xtext [37], a linguagem textual do

23

FGL foi definida, de forma que apenas algumas particularidades do jogo serão controladas. As características da linguagem estão descritas nas Figuras 10 11.
grammar org.fgl.core.dsl.FGDsl with org.eclipse.xtext.common.Terminals generate fGDsl "http://www.fgl.org/core/dsl/FGDsl" Model: 'Game' name=STRING '{' (imports +=Import)* (elements += Type)* (configs += GameConfig)* '}';

GameConfig: 'config' name=ID '=>' configName=ConfigName ; ConfigName: ID ('.' ID)* ; Import : 'import' importURI=STRING; Type: SimpleType | Entity; SimpleType: 'type' name = ID; Entity : 'entity' name=ID ('extends' extends=[Entity]) ? '{' properties+=Property* '}'; Property: 'property'name=ID ':' type=[Type] (many?='[]')?;

Figura 10 – Definição da linguagem textual FGL.

A Figura 10 descreve a gramática textual utilizada na definição da linguagem FGL. A nomenclatura da linguagem está definida na própria biblioteca do Xtext. Com ela é possível expressar detalhes internos do código, tais como: o Jogo pode possuir N entidades, N configurações, etc.

24

Item Game Config Type Entity Property

Descrição O nome do Jogo e suas propriedades. As configurações do jogo, resolução, cor de fundo, etc. Variáveis que podem ser utilizadas no jogo. Entidades do Jogo. Propriedades do Jogo.
Tabela 4: Propriedades da Linguagem FGL

6.2. Linguagem FGL Após a definição da linguagem, é possível executá-la na IDE de destino, no caso do Xtext, o Eclipse. Sendo possível utilizar todos os recursos já disponíveis na plataforma. Tais como: Outline, code-completion, code-coloring,problems etc.

Figura 11 – Linguagem do FGL.

25

A Figura 11 é a própria implementação do jogo usando a FGL, com ela é possível definir os detalhes que serão utilizados para criação do jogo. A linguagem FGL é utilizada como um Script para a Engine do Jogo, definindo as configurações do mesmo. 6.3. Jogo criado a com a linguagem FGL Para criação do estudo de caso, a arquitetura de referência para o jogo foi criada com o AndEngine, a FGL faz uso deste framework para configurar os personagens, bem como os recursos do jogo. A linguagem pode ser melhorada para suportar diversas características do jogo que não foram viabilizadas, tais como: Cenários, Multi-touch, níveis, etc.

Figura 12. Jogo criado com auxílio da FGL.

26

A Figura 12 apresenta uma adaptação do Jogo AlexKid16, Sega Master System, 1986, com o intuito de validar a linguagem FGL. Observa-se que características como o nome do jogo, orientação da tela, personagens e inimigos foram definidos na Figura 11. 7. Considerações finais Este artigo especifica uma linguagem para criação rápida de Jogos de forma simples, de fácil entendimento e manutenção, onde os artefatos que são gerados a partir dela, estão “embarcados na própria DSL” sendo possível modificá-los sem muita complexidade. O propósito de construir uma DSL foi o de facilitar a vida de um desenvolvedor que deseja criar um determinado estilo de Jogo. As ferramentas apresentadas demonstram alguns de artefatos utilizados na criação de um jogo, porém algumas se detém à um sistema operacional específico e ao estilo de jogabilidade (ação, estratégia, rpg). Uma das que mais se destacou foi a engine SharLudos, por fornecer duas perspectivas de desenvolvimento (visual e textual) onde o desenvolvedor pode interagir com ambas. O objetivo deste estudo foi demonstrar a utilização do projeto Eclipse Xtext juntamente com o framework AndEngine, que se uniram perfeitamente, por utilizarem a mesma base tecnológica (Java) e permitir uma melhor extensibilidade dos componentes e a construção de outros. 7.1. Trabalhos futuros Em versões futuras da linguagem o objetivo é criar famílias de jogos para dispositivos mobile como Angry Birds17, Mega Jump18, etc. Além de permitir que a DSL seja especificada para diversas plataformas (iOS, Windows Mobile, etc) como descrito por Dean Kramer [36]. 7.2. Agradecimentos

16
17

http://pt.wikipedia.org/wiki/Alex_Kidd http://www.rovio.com/en/our-work/games/view/1/angry-birds 18 http://itunes.apple.com/us/app/mega-jump/id370398167?mt=8

27

A Deus, a Carol Vasconcelos, minha esposa, ao meu filho que está por vir (Luciano), ao meu orientador Vinícius Cardoso Garcia, que me incentivou e me deu subsídios necessários para realização deste trabalho e a todos da minha equipe do mestrado (Marcela Oliveira, Walter Felipe, Richardson Oliveira, Cesar e Iberê), que por e-mails, discussões e reuniões, incentivaram e sugeriram melhorias para os trabalhos individuais. 8. Referências Bibliográficas
[1] ESA - Entertainment Software Association, Essential Facts about the Computer and Video Game Industry, 2005; Sharpludus: Improving Game Development Experience Through Software Factories And DomainSpecific Languages, Dissertação de Mestrado de André Wilson Brotto Furtado, 2006. Cut the Rope – http://macmagazine.com.br/2010/10/14/cut-the-rope-e-um-game-fofo-inteligente-elucrativo-um-novo-angry-birds/ Acessado em 19/01/2012 Advantages of Rapid Application Development http://www.buzzle.com/articles/advantages-of-rapid-application-development.html Moving to Software Factories http://blogs.msdn.com/b/askburton/archive/2004/09/20/232021.aspx Game Maker - http://www.yoyogames.com/make - Acessado em 21/10/2011; 2010. RPG Maker VX: Role Playing Game Maker. http:// www.rpgmakerweb.com Gameka: Uma ferramenta de desenvolvimento de jogos para não programadores. Igor Augusto de Faria Costa, SBC - Proceedings of SBGames 2011. PARR, Terrance. The Definitive ANTLR Reference: Building Domain Specific Languages. Pragmatic Programmer, 2007

[2] [3] -

[4] -

[5] -

[6] [7] [8] -

[9] -

[10] - A model-driven framework for domain specific languages demonstrated on a test automation language http://karlsch.com/frodo.pdf Acessado em 17/02/2011 [11] - Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ACM Comput. Surv., 37(4):316–344, December 2005. ISSN 0360-0300. http://portal.acm.org/citation.cfm?id=1118890.1118892 [12] - The Standish Group, 2009 Standish Chaos Report, http://www1.standishgroup.com/newsroom/chaos_2009.php - Acessado em 21/10/2011 [13] - O caso das fábricas de software - Jack Greenfield - Microsoft Corporation http://msdn.microsoft.com/pt-br/library/aa480032.aspx [14] - Eclipse Modeling Framework: A Developer's Guide - Addison Wesley. August 11, 2003

28

[15] - NEIGHBORS, J. M. 1984. The Draco approach to constructing software from reusable components. IEEE Trans. Softw. Eng. SE-10, 5 (Sept.), 564– 574 [16] - Acelerando o processo de desenvolvimento de Software com Arquiteturas Dirigidas por Modelo (MDA). Monografia da Pós-Graduação em Tecnologia da Informação Jimens Lima – 2009. [17] - Kieburtz, R. B.; McKinney, L.; Bell, M.; Hook, J.; Kotov, A.; Lewis, J.; Oliva, D. P.;

Sheard, T.; Smith, I.; Walton, L. A software engineering experiment in software component generation, in Proceedings of the 18th International Conference on Software Engineering, 1996;
[18] - Van Deursen, A.; Klint, P. Little languages: Little maintenance?, Journal of Software Maintenance, 1998; [19] - Menon, V.; Pingali, K. A case for source-level transformations in MATLAB, in Proceedings of the second USENIX Conference on Domain-Specific Languages, 1999; [20] - Bruce, D. What makes a good domain-specific language? APOSTLE, and its approach to parallel discrete event simulation, in First ACM SIGPLAN Workshop on Domain-Specific Languages, 1997; [21] - Eclipse Xtext - http://www.eclipse.org/Xtext/ [22] - Cocos2d - http://www.cocos2d-iphone.org/ [23] - Eclipse Modeling Framework Project (EMF) - http://www.eclipse.org/modeling/emf/ [24] - Addison Wesley, Eclipse Modeling Framework: A Developer's Guide - Capítulo 5. Ecore Modeling Concepts Página 103. [25] - Model-Driven Product-Line Architectures for Mobile Devices - Douglas C. Schmid Vanderbilt University [26] - 4GT – Four Generation Techniques http://en.wikipedia.org/wiki/Fourth-generation_programming_language [27] - Richard C. Gronback, Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. 2009 [28] - GARDNER, T.; YUSUF, L. Explore model-driven development (MDD) and related approaches: a closer look at model-driven development and other industry initiatives. v. 2008, 2006. http://www.ibm.com/developerworks/library/ar-mdd3 [29] - Domain-Specific Modeling http://www.visualmodeling.com/DSM.htm (Acessado em: 20/10/2011) [30] - Applying Model-Driven Development to Reduce Programming Efforts for Small Application Development http://sunsite.informatik.rwth -aachen.de/Publications/CEUR-WS/Vol-455/paper03.pdf [31] - GARDNER, T.; YUSUF, L. Explore model-driven development (MDD) and related approaches: a closer look at model-driven development and other industry initiatives. v. 2008, 2006. http://www.ibm.com/developerworks/library/ar-mdd3

29

[32] - Eric Evans. Domain-Driven Design: Tacking Complexity In the Heart of Software. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. ISBN 0321125215. [33] - A. B. Sutman J. M. Schementi. Video game language. Master’s thesis, Worcester Polytechnic Institute, 2005. [34] - Jeroen Dobbe, A Domain-Specific Language for Computer Games, Master’s thesis, Department of Software Technology Faculty EEMCS. [35] - AndEngine - http://www.andengine.org/ - Acessado em 21/10/2011 [36] - Gameka: Uma ferramenta de desenvolvimento de jogos para não programadores. Igor Augusto de Faria Costa, SBC - Proceedings of SBGames 2011 [37] - MobDSL: A Domain Specific Language for multiple mobile platform deployment

30