fast game language - uma linguagem específica de domínio para configuração de jogos de...
Post on 29-Jul-2015
267 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related