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

1Centro 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

2

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 http://mashable.com/2010/10/15/cut-the-rope/ 2 http://pt.wikipedia.org/wiki/Jogo_eletronico_de_aventura

3

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

4

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 Justificativas Artigos e Livros 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

5

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

6

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.

7

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

8

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;

9

• 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.

10

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 Itemis – http://www.itemis.com 5 Java Virtual Machine

11

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, code-

coloring, 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 http://www.osgi.org 7 http://www.uml.org/ 8 http://www.w3.org/XML/

12

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].

13

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 http://www.omg.org/ 10 http://www.omg.org/mda/

14

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.

15

• 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,

16

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

17

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 http://en.wikipedia.org/wiki/Sprite_(computer_graphics) 12 http://www.oracle.com/br/technologies/java/index.html 13 http://www.gnu.org/licenses/lgpl.html

18

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.

19

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.

20

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].

21

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/

Características Funcionalidades

Gráficos Carregar imagens, textos, etc.

Som Carregando, Iniciar, Parar, Pausar.

Entrada de Dados Mouse e Teclado

Objetos Diferentes formas, tamanhos e posições.

Mundo O mundo do jogo e as regras das formas no mundo.

Interação Interação entre os objetos e o mundo do jogo.

Controle do Usuário A forma que o usuário interage com o mundo do jogo.

22

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

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/

Ferramentas Formato de Distribuição

Licença Plataforma DSL’s Implementadas

SharpLudus Plugin do Visual Studio .NET

Ms-PL Windows SharpLudus, Game Modeling Language (SLGML)

GameMaker Plataforma Própia Paga(99.00) Multiplataforma Configuração,comportamento e ações dos personagens

ViGL XML GPL Multiplataforma Configuração,comportamento e ações dos personagens

GameKa Plataforma Própia GPL Multiplataforma Configuração, Edição de Cenários

GameSalad Plataforma Própia Paga(99.00) Mac OSX Configuração,comportamento e ações dos personagens

AndEngine Bibliotecas GPL Multiplataforma N/A

23

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.

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

AlexKid  

FGL  

Xtext   AndEngine  

Android  

24

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.

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.

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?='[]')?;

25

Item Descrição

Game O nome do Jogo e suas propriedades. Config As configurações do jogo, resolução, cor de fundo, etc. Type Variáveis que podem ser utilizadas no jogo. Entity Entidades do Jogo. Property 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.

26

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.

27

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

28

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;

[2] - Sharpludus: Improving Game Development Experience Through Software Factories And Domain-Specific Languages, Dissertação de Mestrado de André Wilson Brotto Furtado, 2006.

[3] - Cut the Rope – http://macmagazine.com.br/2010/10/14/cut-the-rope-e-um-game-fofo-inteligente-e-lucrativo-um-novo-angry-birds/ Acessado em 19/01/2012

[4] - Advantages of Rapid Application Development

http://www.buzzle.com/articles/advantages-of-rapid-application-development.html

[5] - Moving to Software Factories http://blogs.msdn.com/b/askburton/archive/2004/09/20/232021.aspx

[6] - Game Maker - http://www.yoyogames.com/make - Acessado em 21/10/2011;

[7] - 2010. RPG Maker VX: Role Playing Game Maker. http:// www.rpgmakerweb.com

[8] - Gameka: Uma ferramenta de desenvolvimento de jogos para não programadores. Igor Augusto de Faria Costa, SBC - Proceedings of SBGames 2011.

[9] - PARR, Terrance. The Definitive ANTLR Reference: Building Domain Specific Languages.

Pragmatic Programmer, 2007 [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

29

[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 Main- tenance, 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

30

[32] - Eric Evans. Domain-Driven Design: Tacking Complexity In the Heart of Software. Addison-Wesley 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