2013 - 2sem - Fábio Fraga Lameu

Fábio Fraga Lameu
Desenvolvimento de Jogos Multiplayer e Multiplataforma

usando HTML 5
Trabalho de Conclusão de Curso apresentado ao

Instituto Federal de São Paulo, como parte dos
requisitos para a obtenção do grau de Tecnólogo
em Sistemas para Internet.
Área de Concentração: Engenharia de Software
Orientador: Prof. M.Sc. David Buzatto
São João da Boa Vista

2013
Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer
meio convencional ou eletrônico, para fins de estudo e pesquisa, desde que
citada a fonte.
Ficha catalográfica preparada pela Seção de Tratamento

da Informação do Serviço de Biblioteca – IFSP
Lameu, Fábio Fraga.

Desenvolvimento de Jogos Multiplayer Multiplataforma
com HTML 5. / Fábio Fraga Lameu; orientador David
Buzzato. São João da Boa Vista, 2013.
Trabalho de Conclusão de Curso, IFSP, 2013.
1. Jogos I. 2. Multiplataforma. 3. Multiplayer. HTML

5.
Desenvolvimento de Jogos Multiplayer Multiplataforma com HTML 5

AGRADECIMENTOS
Agradeço primeiramente a Deus, que me proporcionou a minha vida, saúde

e a oportunidade de estar aqui.
Agradeço a minha família pela compreensão durante o período deste
trabalho e pelo incentivo durante o curso.
Agradeço aos meus colegas de turma e a todos os professores que me
acompanharam durante o curso, pois além de orientadores e fornecedores de
conhecimento, foram amigos e são pessoas que fazem parte de um dos
momentos mais importantes da minha vida.
E por fim agradeço meu orientador Prof. M.Sc. David Buzatto, por todo
apoio dado.
RESUMO
Lameu, F. F. (2013). Desenvolvimento de jogos multiplayer e multiplataforma usando

HTML 5. Trabalho de Conclusão de Curso - Instituto Federal de São Paulo, São João da Boa
Vista, 2013.
A evolução dos dispositivos móveis como tablets e smartphones, que estão mais
poderosos em capacidade de processamento, conectividade e cada vez mais acessíveis,
juntamente com a evolução das tecnologias para desenvolvimento de jogos abrem a
possibilidade da criação de jogos eletrônicos multiplayer e multiplataforma. Nestes jogos, um
usuário que possui um dispositivo móvel pode jogar com outro usuário que tenha o jogo em
um computador ou notebook. Essa possibilidade serve de motivação para este trabalho, que
possui como objetivo desenvolver um protótipo onde os usuários possam jogar entre si em
plataformas diferentes. Para o desenvolvimento deste protótipo foi realizado utilizando
HTML5, por apresentar melhorias na utilização das tecnologias JavaScript e CSS (Cascading
Style Sheets), que permitem o desenvolvimento de aplicações mais complexas, incluindo
jogos, com um desempenho satisfatório. Também pelo fato de ser compatível com uma
quantidade grande de dispositivos por ser a tecnologia padrão para o desenvolvimento de
páginas web e compatível com a maioria dos navegadores atuais. O desenvolvimento do
protótipo foi realizado utilizando o modelo de comunicação cliente-servidor por permitir o
controle do protótipo de uma maneira menos complexa em relação aos demais modelos de
comunicação. Foram utilizadas as tecnologias Node.js, no servidor da aplicação, HTML,
JavaScript e CSS, no cliente e para realizar a comunicação entre eles foi utilizada a API
Socket.IO. Ao fim do desenvolvimento do protótipo concluiu-se que as tecnologias em torno
do HTML5 estão aptas a para o desenvolvimento de jogos conforme foi proposto, mesmo
com as limitações em relação à padronização e compatibilidade, que tornam o processo de
desenvolvimento mais difícil, foi possível utilizar o jogo proposto em plataformas e
dispositivos diferentes.
Palavras-chave: Jogos. Multiplataforma. Multiplayer. HTML5. Node.js. Socket.IO

ABSTRACT
Lameu, F. F. (2013). Development of a Multiplatform and Multiplayer Game using

HTML5. Course Conclusion Project – Instituto Federal de São Paulo, São João da Boa Vista,
2013.
The evolution of mobile devices like tablets and smartphones, which are more powerful
in processing power, connectivity and increasingly accessible, along with the evolution of
technologies for game development opens up the possibility of creating cross-platform
multiplayer video games . In these games a user that has a mobile can play with another user
who has the game on a computer or notebook . This possibility serves as motivation for this
work, which has aimed to develop a prototype which users can play each other on different
platforms. To develop this prototype was performed using HTML5, by presenting
improvements in the use of JavaScript and CSS technologies (Cascading Style Sheets ), which
enable the development of more complex applications , including games with a satisfactory
performance . Also because it is compatible with a large number of devices to be the standard
technology for the development of web and compatible with most current browsers pages.
The development of the prototype was performed using the model of client-server
communication by allowing control of the prototype of a less complex compared to other
communication models. Node.js the technologies were used in the application server, HTML,
CSS and JavaScript on the client and to realize the communication between them was used
Socket.IO API . After developing the prototype was concluded that the technologies around
HTML5 are able to for game development as proposed, even with the limitations in
standardization and compatibility , which make the development process more difficult, it was
possible to use the proposed game platforms and in different devices.
Keywords: Games. Multiplataform. Multiplayer. HTML5. Node.JS. Socket.IO.

LISTA DE FIGURAS
Figura 1 – Call of Duty® Black OPS ............................................................................. 26
Figura 2 – Assassin’s Creed III ....................................................................................... 26
Figura 3 – Age of Empires II .......................................................................................... 27
Figura 4 – Diablo III ....................................................................................................... 28
Figura 5 – Batalha Naval ................................................................................................ 28
Figura 6 – Formula 1™ 2010.......................................................................................... 29
Figura 7 – Super Mario World ........................................................................................ 29
Figura 8 – Resgate das Galinhas ..................................................................................... 30
Figura 9 – Bubble Shooter .............................................................................................. 30
Figura 10 – Pro Evolution Soccer 2013 .......................................................................... 31
Figura 11 – Bruxa dos Acentos ....................................................................................... 32
Figura 12 – Exemplo arquitetura híbrida ........................................................................ 37
Figura 13 – Comparação de performance SVG vs. Canvas............................................ 39
Figura 14 – Coordenadas Canvas ................................................................................... 41
Figura 15 – Comparação entre o uso de Polling e WebSocket. ...................................... 45
Figura 16 – Comparação WebSockets e Polling............................................................. 46
Figura 17 – Event-Loop .................................................................................................. 49
Figura 18 – Código síncrono e linha do tempo de execução. ......................................... 49
Figura 19 – Código assíncrono e sua linha do tempo de execução ................................ 50
Figura 20 – Script do servidor Socket.IO ....................................................................... 52
Figura 21 – Script do cliente Socket.IO .......................................................................... 53
Figura 22 – Envio de mensagens para o cliente ou servidor........................................... 54
Figura 23 - Envio de mensagens para todos os clientes, exceto o emissor ..................... 54
Figura 24 – Tabuleiro Batalha Naval .............................................................................. 57
Figura 25 – Modelos e formatos dos navios Fonte: Elaboração do autor ....................... 57
Figura 26 – Arquitetura do Projeto ................................................................................. 59
Figura 27 – Configuração da Variável de Ambiente Fonte: Elaboração do autor .......... 60
Figura 28 – Valores da variável de ambiente.................................................................. 60
Figura 29 – Instalação API Express ................................................................................ 61
Figura 30 – Instalação API Socket.IO Fonte: Elaboração do autor ................................ 61
Figura 31 – Linhas de 6 a 23 do arquivo game_server.js Fonte: Elaboração do autor ... 62
Figura 32 – Linhas 27 a 40 do arquivo game_server.js .................................................. 63
Figura 33 – Metatag Viewport Fonte: Elaboração do autor ............................................64
Figura 34 – Importação socket.io.js Fonte: Elaboração do autor ....................................64
Figura 35 – Linhas 9 a 38 arquivo game_en.js Fonte: Elaboração do autor ...................66
Figura 36 – Linhas de 40 a 70 do arquivo game_en.js Fonte: Elaboração do autor........67
Figura 37 – Tabuleiro sem formatação Fonte: Elaboração do autor ............................... 68
Figura 38 – Função para envio de mensagens para o servidor Fonte: Elaboração do
autor ............................................................................................................68
Figura 39 – Função que receptora de mensagens no servidor Fonte: Elaboração do
autor ............................................................................................................69
Figura 40 – Função receptora de mensagens no cliente Fonte: Elaboração do autor ......69
Figura 41 – Função para envio de mensagens para o cliente Fonte: Elaboração do
autor ............................................................................................................70
Figura 42 – Adicionando um usuário à lista de usuários Fonte: Elaboração do autor ....70
Figura 43 – Envio de uma mensagem privada no lado do cliente Fonte: Elaboração
do autor .......................................................................................................71
Figura 44 – Encaminhamento de mensagens privadas no servidor Fonte: Elaboração
do autor .......................................................................................................71
Figura 45 – Fluxograma do jogo Fonte: Elaboração do autor .........................................72
Figura 46 – Media Queries Fonte: Elaboração do autor ..................................................73
Figura 47 – Tela de login resolução até 320px. Fonte: Elaboração do autor ..................74
Figura 48 – Tela de login resolução entre 321 e 1279px. Fonte: Elaboração do autor ...74
Figura 49 – Tela de login resolução acima de 1280px. Fonte: Elaboração do autor.......75
Figura 50 – Aviso orientação de tela Fonte: Elaboração do autor...................................75
Figura 51 – Tela de login smartphone Fonte: Elaboração do autor................................ 77
Figura 52 – Tela de login tablet Fonte: Elaboração do autor ..........................................78
Figura 53 – Tela de login para computadores e notebooks Fonte: Elaboração do
autor ............................................................................................................78
Figura 54 – Tela principal smartphone Fonte: Elaboração do autor ............................... 79
Figura 55 – Tela principal tablet Fonte: Elaboração do autor .........................................79
Figura 56 – Tela principal computadores e notebooks. ...................................................80
Figura 57 – Tabuleiro e painel para distribuição dos navios smartphone .......................81
Figura 58 – Tabuleiro e painel de distribuição dos navios tablet Fonte: Elaboração
do autor .......................................................................................................81
Figura 59 – Tabuleiro e painel de distribuição dos navios computador e notebook .......82
Figura 60 – Visão do jogador durante o seu turno (smartphone) ................................... 82
Figura 61 – Visão do jogador durante o turno do seu oponente (smartphone) Fonte:
Elaboração do autor.................................................................................... 83
Figura 62 – Turno do jogador (tablet, computador e notebook). .................................... 84
Figura 63 – Turno do oponente (tablet, computador e notebook). ................................. 84
LISTA DE TABELAS
Tabela 1 – Navegadores compatíveis com SVG ..................................................... 41
Tabela 2 – Navegadores compatíveis com Canvas .................................................. 42
LISTA DE SIGLAS
2D Duas dimensões
3D Três dimensões
AJAX Asynchronous JavaScript and XML
API Application Programming Interface
CSS Cascading Style Sheets (Folhas de Estilo em Cascata)
DOM Document Object Model
E/S Entrada/Saída
GPU Graphics Processing Unit (Unidade de Processamento Gráfico)
HTML Hypertext Markup Language (Linguagem de marcação de texto)
HTTP Hypertext Transfer Protocol (Protocolo de Transmissão de Hipertexto)
IETF Internet Engineering Task Force
LAMP Linux, Apache, MySQL e PHP, Perl ou Python
MMMOG Massively Multiplayer Mobile Online Game
MMOG Massively Multiplayer Online Game
MMUG Massively Multiplayer Ubiquitous Game
MySQL My Structured Query Language
PCs Personal Computers (Computadores pessoais)
PHP Hypertext Preprocessor
PSN Playstation® Network
RPG Role Playing Game( Jogo de interpretação de personagem)
SVG Scalable Vector Graphics (Gráficos Vetoriais Escaláveis)
SSL Secure Socket Layer
W3C World Wide Web Consortium
WHATWG Web Hypertext Application Technology Working Group
WS Websocket
XHTML Extensible Hypertext Markup Language
XML Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................ 17
1.1 Motivação ............................................................................................................................. 18
1.2 Objetivos ............................................................................................................................... 19
1.3 Organização do Trabalho ...................................................................................................... 19
2 PESQUISA BIBLIOGRÁFICA ....................................................................................... 21
2.1 Considerações Iniciais .......................................................................................................... 21
2.2 Jogos Eletrônicos .................................................................................................................. 21
2.1.1 Design de Jogos Eletrônicos...................................................................................... 22
2.2.1.1 ................................................................................................................Pré-Produção22
2.2.1.2 ...................................................................................................................... Produção22
2.2.1.3 ............................................................................................................... Pós-Produção23
2.2.2 Designer de Jogos................................................................................................... 23
2.2.3 Categorias de Jogos ................................................................................................ 24
2.2.3.1 .................................................................................................................... Plataforma24
2.2.3.2 ....................................................................................................................... Interface25
2.2.3.3 ....................................................................................................................... Objetivo27
2.2.3.4 ...................................................................................................Número de Jogadores32
2.3 Jogos Multiplayer ................................................................................................................. 33
2.3.1 Requisitos ............................................................................................................... 33
2.3.2 Componentes dos Jogos Multiplayer ..................................................................... 34
2.3.3 Modelos de Comunicação. ..................................................................................... 35
2.4 HTML 5 ................................................................................................................................ 37
2.4.1 Definição ................................................................................................................ 38
2.4.2 Elementos Gráficos. ............................................................................................... 38
2.4.3 Comunicação .......................................................................................................... 42

2.5 Node.js .................................................................................................................................. 47
2.6 Socket.IO .............................................................................................................................. 51
3 METODOLOGIA .........................................................................................................56
3.1 O Jogo ................................................................................................................................... 56
3.2 A Arquitetura ........................................................................................................................ 58
3.3 O Servidor............................................................................................................................. 59
3.4 O Cliente ............................................................................................................................... 63
4 RESULTADOS .............................................................................................................77
4.1 Gameplay .............................................................................................................................. 77
5 CONCLUSÕES .............................................................................................................87
REFERÊNCIAS ............................................................................................................89
Capítulo
17
1 Introdução
O mercado de jogos no Brasil foi o que mais cresceu no mundo no ano de 2012, em
relação a 2011, de acordo com Lannoy (2013). Este mercado teve um faturamento de cerca de
1 bilhão de reais em 2012, correspondendo a 43% de aumento em relação ao ano anterior,
segundo uma pesquisa realizada pela GfK1 (Spagnuolo, 2013). De acordo com Orrico (2012),
o Brasil é o quarto maior mercado de jogos no mundo e crescerá em média 7,1% ao ano até
2016.
As notícias sobre o mercado de jogos no Brasil mostram a evolução deste mercado no
país e dentre as principais tendências deste mercado estão os jogos on-line. Em computadores
esse tipo de jogo é comum, um exemplo é o jogo Counter Strike, lançado pela Valve no ano
de 1999 (Silva, 2011). Atualmente os jogos on-line não são mais exclusividade dos
computadores, pois com a evolução dos consoles2 é possível jogar on-line com pessoas do
mundo inteiro, como acontece com jogadores do console Playstation® 3, que utilizam a PSN
(Playstation® Network), e com os jogadores do console Xbox 360, que utilizam a Xbox LIVE.
Além dos computadores e consoles, os dispositivos móveis tem se destacado cada vez
mais como plataforma para a utilização de jogos, são incluídos nesta plataforma os
smartphones, tablets e os consoles portáteis, que graças à evolução na capacidade de
processamento e o acesso à internet em alta velocidade permitem que estes dispositivos
possam ser utilizados para aplicações mais complexas, incluindo jogos, e execute-os de forma
satisfatória. O avanço dessa plataforma é considerável, tanto que uma pesquisa realizada de
pelo Juniper Research3 afirma que os dispositivos móveis serão a principal plataforma de
jogos dentro de três anos. Garcia (2013) afirma que em 2016 o mercado de jogos para tablets
e smartphones crescerá cerca de dez vezes.
1
www.gfk.com/br
2
console é um microcomputadores dedicado a execução de videogames
3
www.juniperresearch.com
18
Além da possibilidade de se jogar on-line entre dispositivos da mesma plataforma, há a

possibilidade de jogar on-line entre dispositivos de plataformas diferentes, um exemplo dessa
utilização é na PSN, onde jogadores que possuem o console Playstation® 3 e os jogadores
que possuem o console portátil PSVita® podem jogar entre si4.
A HTML5, a nova especificação da linguagem de marcação de texto utilizada na internet,
apresenta muitas inovações em relação à versão anterior, inovações essas que permitem a
criação de aplicações mais complexas, como jogos, com um bom desempenho e sem a
necessidade da instalação de plug-ins5. Um exemplo é o jogo Angry Birds, que possui uma
versão desenvolvida completamente em HTML5, para ser jogado on-line em navegadores nos
computadores e notebooks (AVRAN, 2012).
Com o mercado de jogos em alta e as possibilidades que o HTML5 traz para o
desenvolvimento de aplicações mais complexas, viu-se a oportunidade de desenvolver o
protótipo de um jogo que pudesse ser executado em algumas plataformas, incluindo os
dispositivos móveis, sem a dependência de instalação de plug-ins e sem depender de uma
tecnologia proprietária, o que será explicado com mais detalhes na próxima sessão.
1.1 Motivação
A motivação para o desenvolvimento deste trabalho parte de três aspectos. O primeiro é o

desenvolvimento do mercado de jogos eletrônicos de uma forma geral, que se encontra
aquecido atualmente. O segundo aspecto é a evolução dos dispositivos móveis,
principalmente dos tablets e smartphones, que cada vez mais tem sua capacidade de
processamento e memória maiores e uma conexão a internet mais rápida. Por fim, o terceiro
aspecto, é a possibilidade que o HTML5 e as tecnologias que o acompanham trazem para o
desenvolvimento de aplicações mais elaboradas com um desempenho satisfatório, sem a
dependência de tecnologias proprietárias e sem a utilização de programas adicionais, pois o
aplicativo é executado no navegador do usuário.
4
http://pt.playstation.com/
5
Plug-ins são programas de computador utilizados para adicionar funções a outros programas maiores.
19
Pelo exposto, a motivação deste trabalho é utilizar uma tecnologia para atingir tanto
dispositivos móveis quanto computadores no desenvolvimento de um aplicativo que permita a
interação entre os usuários do mesmo ao usarem diversas plaformas.
1.2 Objetivos
Este trabalho tem como objetivo verificar se o HTML5 e suas tecnologias podem ser
utilizados como ferramentas para o desenvolvimento de jogos multiplayer para diversas
plataformas e se é possível desenvolver um jogo sem a utilização de plug-ins ou tecnologias
proprietárias, como acontece atualmente na maioria dos jogos para navegador existentes.
1.3 Organização do Trabalho
Este trabalho está organizado em quatro capítulos além desta introdução, sendo que estes
estão estruturados da seguinte maneira: no segundo capitulo será apresentada a pesquisa
bibliográfica que embasa este trabalho, abordando temas como alguns conceitos sobre design
de jogos, tipos de jogos e plataformas, jogos multiplayer e alguns componentes do HTML5
que podem ser aplicados no desenvolvimento de jogos. A metodologia deste projeto será
apresentada no terceiro capítulo, sendo descrita a proposta da monografia de forma mais
detalhada, quais são as tecnologias que serão utilizadas, além de todos os aspectos do
desenvolvimento da aplicação. No quarto capítulo serão apresentados os resultados obtidos
com o presente trabalho. Por fim, no quinto capítulo, serão apresentadas quais conclusões
foram obtidas no desenvolvimento deste projeto.
Capítulo
21
2 Pesquisa Bibliográfica
2.1 Considerações Iniciais
Neste capítulo será apresentada uma visão a respeito de jogos eletrônicos, sua
definição, qual é o processo para o desenvolvimento de um jogo, as principais categorias dos
jogos, uma abordagem sobre os jogos multiplayer e o HTML5 e as suas tecnologias que
podem ser utilizadas para o desenvolvimento de jogos. Os assuntos abordados neste capítulo
serão utilizados como base de conhecimento para o desenvolvimento da metodologia deste
trabalho.
2.2 Jogos Eletrônicos
Segundo Schuytema (2008), um jogo eletrônico é uma atividade composta por uma série
de ações e decisões limitadas por regras e pelo universo do jogo, ações estas que resultam em
uma condição final. As regras e o universo do jogo são apresentados por meios eletrônicos e
controlados por um programa digital, sendo que estas existem para proporcionar uma
estrutura e um contexto para as decisões do jogador. As regras também existem para gerar
situações interessantes, com o objetivo de desafiar o jogador. Com isso, todo o contexto, os
desafios, a emoção e a diversão durante a jornada do jogador podem determinar o sucesso do
jogo e não somente a obtenção da condição final do jogo, que pode ser a última fase ou elevar
seu personagem ao nível máximo.
Uma definição mais sucinta do que é um jogo é apresentada por Adams (2010), que diz
que um jogo é um tipo de atividade realizada no contexto de uma realidade pretendida, em
que um ou mais participantes podem tentar conseguir atingir uma meta de acordo com as
regras.
22
2.1.1 Design de Jogos Eletrônicos
Para Rouse (2004), o design do jogo é o que determina a forma do jogo, quais são as
escolhas que os jogadores poderão realizar no mundo do jogo, quais os desdobramentos
dessas escolhas no decorrer do jogo, como os objetos do jogo irão interagir com o jogador, o
quão difícil o jogo será, ou seja, o design do jogo determina cada detalhe de como o jogo
funciona.
Já Schuytema (2008), diz que o design de um jogo pode ser comparado a planta baixa
de uma construção, ou seja, o design é responsável por definir o que será realizado no jogo,
quais serão as etapas para este desenvolvimento e qual é a ordem de execução das tarefas no
processo de desenvolvimento de um jogo. Seguindo este princípio, Schuytema (2008) divide
o design de um jogo em três etapas: pré-produção, produção e pós-produção.
2.2.1.1 Pré-Produção
A pré-produção é o momento para se criar um conceito para um jogo, neste momento

são realizadas as discussões, os brainstorms e a avaliação dos jogos concorrentes. O designer
neste momento é responsável por fazer o brainstorm e desenvolver os conceitos, inclusive os
que serão enviados ao gerente ou ao editor do projeto. A partir do momento que há uma ideia,
a equipe de design deve descobrir como tornar o jogo diferente e emocionante. Na pré-
produção também é definida quais serão as ferramentas que serão utilizadas pelos
programadores e neste momento que são desenvolvidos os documentos de design, que
ilustrarão os conceitos de uma forma geral e também servirão como base técnica para orientar
o processo de produção (SCHUYTEMA, 2008).
2.2.1.2 Produção
Na fase de produção o jogo é construído, pois é neste momento que os programadores

desenvolvem o código e que os artistas criam os modelos dos personagens e as fases do jogo.
O marketing desenvolve a estratégia de propaganda, os testadores avaliam o jogo a cada
versão, os designers fazem o roteiro do gameplay, que servirá para avaliar vários aspectos,
23
entre eles, se o jogo é divertido e se está coerente com o documento de design. No

desenvolvimento, os documentos de design também são aperfeiçoados baseados nos
feedbacks do setor de testes, dos produtores e dos gerentes do projeto (SCHUYTEMA, 2008).
2.2.1.3 Pós-Produção
A pós-produção se inicia assim que o jogo é lançado, neste processo podem ser
incluídos ao projeto, por exemplo, conteúdo adicional para download, patches para continuar
o processo de balanceamento do gameplay, avaliação de receptividade do jogo para possíveis
sequencias ou pacotes de expansão (SCHUYTEMA, 2008).
2.2.2 Designer de Jogos
De acordo com Schuytema (2008), não há como falar em design de jogos sem falar no
principal componente do design de jogos, o designer, pois é o designer, ou a equipe de design
que irá acompanhar todo o desenvolvimento do jogo, desde a ideia para a sua concepção até o
produto final, ou seja, o jogo e as suas possíveis expansões.
Rouse (2004) define o designer como a pessoa que projeta os jogos, estabelecendo sua
forma e a sua jogabilidade. Rousse (2004) ainda diz que durante o processo de
desenvolvimento, o designer pode participar de várias tarefas, como criar ativos de arte para o
jogo, desenvolver os scripts para a fala dos personagens do jogo, desenvolver os scripts de
programação do jogo, criar os níveis ou todo o mapa do jogo, apesar de muitas tarefas e serem
executadas, estas não são suas obrigações. O designer tem como obrigação estabelecer a
forma do jogo e como será o gameplay6, mantendo sempre como principal preocupação o
projeto do jogo e a sua jogabilidade.
Pelo exposto, pode-se verificar que o processo de desenvolvimento de um jogo possui
diversas etapas. Essas etapas são as mesmas para os diversos tipos de jogos que existem,
sendo que esta classificação será apresentada na próxima seção.
6
O gameplay é a experiência verificada pelo jogador durante o jogo
24
2.2.3 Categorias de Jogos
Os jogos podem ser classificados de diversas maneiras. De acordo com Kubo (2009), os
jogos podem ser classificados de acordo com a plataforma onde são jogados, pelas suas
interfaces gráficas, pelos seus objetivos ou pela quantidade de jogadores. A seguir serão
descritos com mais detalhes cada uma destas categorias.
2.2.3.1 Plataforma
Neste trabalho, o conceito de plataforma representa um conjunto composto por hardware

e software que será utilizada para executar um aplicativo. Atualmente existem três grandes
plataformas para jogos segundo Kubo (2006 apud BATTAIOLA et. al 2001), a primeira são
os consoles, que são equipamentos dotados de um conector para o aparelho de TV e possuem
uma unidade de armazenamento contendo programas ou dados de um jogo.
Os consoles são atualmente a maior plataforma de jogos no Brasil de acordo com o
Censo Gamer 20127 e, segundo pesquisa realizada pela Gfk8, o mercado de consoles no Brasil
apresentou um crescimento de 73% no ano de 2012 em relação a 2011, com uma
movimentação de 629 milhões de reais. Esse crescimento foi impulsionado por diversos
fatores, entre os principais estão a fabricação dos consoles no país, o aumento na quantidade
de títulos disponíveis que foi de 1.221 para 1.582 (uma alta de 30%) e a queda de 27% no
preço médio (de 124,00 para 91,00 reais).
A segunda plataforma são os PCs (Personal Computers), ou simplesmente computadores.
Nesta categoria são englobados os notebooks e os desktops. Os jogos para PC são o segundo
maior mercado de jogos no Brasil, de acordo com o Censo Gamer 2012, sendo que este
mercado obteve um crescimento de 8% no mercado global em 2012 em relação a 2011
segundo a PC Gaming Alliance9, com faturamento de cerca de 40 bilhões de reais.
A terceira plataforma é a plataforma móvel, nesta plataforma estão englobados os
smartphones, tablets e consoles portáteis. Atualmente este mercado está em ascensão e
7
Censo Gamer, realizado pela InsideComm em parceria com a Associação Brasileira de Games, disponível em
www.acigames.com.br/2012/06/primeiro-censo-nacional-mapeia-o-comportamento-do-jogador-e-o-mercado-de-
videogames-no-brasil/infograficocenso/
8
www.gfk.com/br
9
www.pcgamingalliance.org
25
responde por 26% do mercado brasileiro de jogos de acordo com o Censo Gamer 2012 e é
previsto que este mercado cresça 10 vezes até o ano de 2016 segundo pesquisa divulgada pelo
Juniper Research10 alcançando uma receita de aproximadamente 3,06 bilhões de dólares.
O crescimento desta plataforma pode ser justificado por alguns fatores, entre eles estão a
evolução tanto dos smartphones quanto dos tablets em relação a poder de processamento,
principalmente processamento gráfico. Como exemplos dessa evolução são o tablet Nexus11
que possui um processador Tegra® 3 quad-core da Nvidia® com uma GPU (Graphics
Process Unity) de 12 núcleos integrada. Outro exemplo é o smartphone Samsung® Galaxy
S4 com processador Samsung Exynos 5 Octa12.
Além do aumento na capacidade de processamento, há um aumento na aquisição desses
equipamentos. Segundo levantamento feito pela Teleco13, a quantidade de tablets no mundo
chegou a 49,2 milhões de unidades no primeiro trimestre de 2013, aumentando 142,4% em
relação ao ano anterior. Quanto aos smartphones, a quantidade foi 216,2 milhões de unidades
no mundo no primeiro trimestre de 2013, aumentando 41,6% em relação ao ano anterior.
Devido à ascensão dessa plataforma, ela será um dos públicos alvos para o aplicativo que será
desenvolvido neste trabalho.
2.2.3.2 Interface
Os jogos podem também ser classificados de acordo com sua interface gráfica. De acordo
com Kubo (2006), a interface é definida pela maneira que o usuário vai perceber o jogo,
sendo assim surgem três tipos interfaces: em primeira pessoa, em terceira pessoa e top-down.
Nos jogos em primeira pessoa, a visão é dada através de um dos personagens do jogo e é
controlada diretamente pelo jogador. Sendo assim, a cena exibida representa o que os olhos
do personagem controlado pelo jogador veem. Um exemplo de um jogo em primeira pessoa é
o Call of Duty® Black OPS II, sendo que uma captura de tela deste jogo é mostrada na Figura
1.
10
www.juniperresearch.com
11
www.google.com/nexus/7/
12
www.samsung.com/global/business/semiconductor/minisite/Exynos/products5octa.html
13
www.teleco.com.br
26
Figura 1 – Call of Duty® Black OPS

Fonte: http://nerdonline.com.br/wp-content/uploads/2012/11/CoD-Black-Ops-2.jpg
Nos jogos em terceira pessoa, a visão é externa ao personagem principal do jogo. Nesse
tipo de jogo o jogador visualiza a cena e pode controlar as decisões do personagem. Um
exemplo de jogo em terceira pessoa é Assassin’s Creed III, mostrado na Figura 2.
Figura 2 – Assassin’s Creed III

Fonte: http://www.flydrs.com/wp-content/uploads/2012/12/assassins-creed-3-gameplay.jpeg
Ainda em relação a interface, existe uma terceira classificação chamada de top-down,

sendo que neste tipo de interface o jogo é visto de cima, como se o jogador estivesse vendo a
cena a partir de um helicóptero. Um exemplo deste tipo de jogo é o Age of Empires® II
apresentado na Figura 3.
27
Figura 3 – Age of Empires II

Fonte: http://pop-verse.com/wp-content/uploads/2013/04/AoE-II-screenshot-2.jpg
2.2.3.3 Objetivo
Os jogos podem ainda serem classificados de acordo com o seu objetivo ou com a
característica que se deseja ressaltar (KUBO, 2006). Nessa categoria são encontradas diversas
classificações. A seguir são descritas algumas das categorias de acordo com Kubo (2006)
apud Softex (2006) e Battaiola (2000):
 Histórias interativas: RPG (Role Playing Game) é um tipo de jogo que tem como
objetivo criar um contexto de um ambiente real. Um exemplo desse tipo de jogo é o
Diablo III, desenvolvido pela Blizzard® Entertainment. Uma captura de tela deste
jogo pode ser vista na Figura 4;
28
Figura 4 – Diablo III

Fonte: http://2.bp.blogspot.com/-xg_UwDDj6aU/T7_YnYoLSvI/AAAAAAAAALI/lxAPe
TB3m68/s1600/d3gp1.png
 Estratégia: São jogos que envolvem um maior raciocínio, podem ser jogados em
tempo real e geralmente possuem um enredo de guerra. Um exemplo desse tipo de
jogo é o Batalha Naval, apresentado na Figura 5;
Figura 5 – Batalha Naval

Fonte: http://marlonpalmas.files.wordpress.com/2008/02/batalha-naval.png
 Simulação: São jogos que possuem um nível de complexidade maior devido ao fato
de tentar simular uma situação real da forma mais fiel possível. Para atingir esse
objetivo são utilizadas simulações físicas e são necessários um grande número de
29
comandos para manipular o jogo. Um exemplo desse tipo de jogo é o Formula 1 2010,
desenvolvido pela Codemasters. Este jogo pode ser visto na Figura 6;
Figura 6 – Formula 1™ 2010

Fonte: http://i2.ytimg.com/vi/Ut682Gx6ymY/maxresdefault.jpg
 Ação: São jogos considerados menos complexos, pois geralmente possuem um
número de comandos reduzidos e objetivos bem definidos. Um exemplo desse tipo de
jogo é o Super Mario World desenvolvido pela Nintendo®. Uma captura de tela deste
jogo pode ser vista na Figura 7;
Figura 7 – Super Mario World

Fonte: http://www.brasukagames.com.br/wp-content/thumbs/super-mario-world-
1_1347644622.gif
 Infantis: Os jogos infantis são caracterizados por geralmente possuir interfaces

simples e ter caráter educacional, um exemplo desse tipo de jogo é o Resgate as
Galinhas, desenvolvido pela Gamezhero e mostrado na Figura 8;
30
Figura 8 – Resgate das Galinhas

Fonte: http://s.glbimg.com/po/tt2/bt/bc/a/3/54f07aee012d047b12313b075c91.jpeg
 Passatempo: São jogos que variam de níveis simples a níveis complexos, possuindo
como objetivo principal atingir uma pontuação alta. Normalmente esses jogos
possuem interface 2D. Um exemplo desse tipo de jogo é o Bubble Shooter apresentado
na Figura 9;
Figura 9 – Bubble Shooter

Fonte: http://www.shooter-bubble.com/bubble-shooter.jpg
31
 Esportes: São jogos que simulam esportes, como futebol, basquete, tênis, etc. Nesse
tipo de jogo o usuário pode comandar apenas um jogador ou times inteiros. Assim
como os jogos de simulação, os jogos de esporte são mais complexos por tentar
reproduzir os esportes como são na vida real. Um exemplo desse tipo de jogo é o Pro
Evolution Soccer 2013, desenvolvido pela Konami® sendo que uma captura de tela do
mesmo pode ser vista na Figura 10;
Figura 10 – Pro Evolution Soccer 2013

Fonte: http://www.moddingway.com/screenshots/files/26152/big_3.jpg
 Educação/Treinamento: Jogos educacionais são semelhantes aos jogos infantis e
podem possuir várias características dos jogos citados anteriormente, com a diferença
que o objetivo visado não é somente a diversão, mas também conceitos pedagógicos e
didáticos. Um exemplo deste tipo de jogo é o Bruxa dos Acentos, desenvolvido pelo
Escola Games e mostrado na Figura 11
32
Figura 11 – Bruxa dos Acentos

Fonte:http://websmed.portoalegre.rs.gov.br/escolas/wenceslau/paginas/professores/aline_infor
matica/jogos-2013/jogo02-bruxa-acentos.jpg
2.2.3.4 Número de Jogadores
Em relação ao número de jogadores, os jogos são classificados em monousuário, onde

apenas um jogador pode jogar, e multiusuário ou multiplayer, onde dois ou mais usuários
podem jogar simultaneamente. Os jogos multiplayer também podem ser classificados como
MMOG (Massively Multiplayer Online Game), que são jogos onde o número de jogadores
pode chegar a milhares. Nestes jogos, o ambiente é persistente o que possibilita aos usuários
jogar sem interrupções e o usuário retome o jogo da posição de onde parou (KUBO,2006).
A partir do MMOG, segundo Kubo (2006) existem outras duas categorias: os MMMOG
(Massively Multiplayer Mobile Online Game), que são jogos multiplayer em massa para
dispositivos móveis, por exemplo TibiaME (2005) e os MMUG (Massively Multiplayer
Ubiquitous Game), que são jogos onde os usuários interagem no mesmo mundo virtual a
partir de diferentes plataformas, sendo esta última categoria a que mais se aproxima do
protótipo desenvolvido neste projeto, com a diferença que o aplicativo do projeto possuirá um
número reduzido de usuários simultâneos, porém em plataformas diferentes.
33
2.3 Jogos Multiplayer
Nos jogos multiplayer, de acordo com Kubo (2006 apud BATTAIOLA et. al. 2001), cada
um dos jogadores possui uma visão própria do jogo, sendo que esta deve ser consistente e o
mais semelhante possível para todos os jogadores.
Ainda segundo Kubo (2006), para que seja elaborado um jogo multiplayer é fundamental
ter domínio sobre dispositivos, computadores ou processadores de alto desempenho,
processamento gráfico, sistemas paralelos e multiusuários, detecção de colisão, aplicações
simples e distribuídas, entre outras. Isso pelo fato de que os jogos multiplayer devem
promover a integração de recursos computacionais com o jogador, para que ele possa interagir
e manipular os objetos do jogo.
2.3.1 Requisitos
Os jogos multiplayer têm requisitos semelhantes aos requisitos de ambientes virtuais

distribuídos, de acordo com Kubo (2006) apud Van Dam (1993) e Deriggi (1998), e esses
requisitos são:
 Taxas rápidas de atualização;
 Latência14 mínima;
 Tratamento de múltiplos dispositivos de E/S;
 Simulação de um grande número de objetos e seus comportamentos;
 Representação realista do jogo;
 Distribuição dos dados a longa distância;
 Escalabilidade.
Assim como os requisitos de um ambiente virtual distribuído e de um jogo multiplayer
podem ser os mesmos, também se pode observar que há algumas características dos
ambientes virtuais distribuídos que podem ser aplicadas também em jogos multiplayer
(KUBO, 2006 apud SEMENTILLE, 1999), sendo estas:
14
Latência é o intervalo de tempo entre o momento que um evento iniciou e o momento que os efeitos iniciam.
34
 Sensação de compartilhamento de espaço: em um jogo multiplayer todos os

jogadores tem a ilusão de estarem localizados no mesmo lugar. Para isto o ambiente
deve apresentar as mesmas características a todos usuários;
 Sensação de presença: a partir do momento que um usuário entra em um local
compartilhado ele se torna um “jogador virtual”, também conhecido como avatar. O
avatar é uma representação gráfica do jogador dentro do ambiente virtual e pode
possuir características como estrutura corporal e movimentos, sendo que os
movimentos podem ser controlados diretamente pelo jogador ou não;
 Comunicação entre os jogadores: além da visualização, que é um requisito
primordial para um jogo multiplayer, muitos jogos procuram dar ao jogador a
possibilidade de se comunicar com os outros jogadores de outra maneira, dentre as
mais comuns estão a comunicação por voz e por mensagens de texto;
 Forma de compartilhamento: além dos elementos citados anteriormente é
fundamental que o jogo possa unir todos esses elementos para que os usuários possam
interagir uns com os outros e com o ambiente do jogo.
2.3.2 Componentes dos Jogos Multiplayer
Os jogos multiplayer, segundo Kubo (2006), são compostos de quatro componentes

básicos, sendo estes:
 Displays gráficos: são os responsáveis por oferecer a visão da estrutura do jogo ao
jogador, por exemplo, monitores e displays de dispositivos móveis;
 Dispositivos de comunicação e controle: são os dispositivos que o usuário utiliza
para controlar seu personagem durante o jogo, por exemplo, teclado, mouse e telas
sensíveis ao toque;
 Sistema de processamento: pois os jogos multiplayer demandam uma quantidade
considerável de processamento para receber os eventos enviados pelo jogador e
determinar qual serão as ações e o impacto que estas entradas terão no ambiente do
jogo e vice-versa;
 Comunicação: é responsável por tornar possível a interação entre diversos jogadores
e dispositivos situados em locais geograficamente distintos.
35
Estes componentes devem trabalhar em conjunto para dar ao jogador a sensação de

envolvimento e interação dentro do jogo da maneira mais realística possível mesmo em
diferentes localidades.
2.3.3 Modelos de Comunicação.
De acordo com Kubo (2006) e Kozovits (2003), os modelos de comunicação em jogos

multiplayer são divididos em:
 Cliente-servidor;
 Peer-to-peer (ponto a ponto);
 Híbrida, que mescla a solução cliente-servidor e a ponto a ponto;
Na arquitetura ponto a ponto, os jogadores se conectam diretamente entre si sem o

intermédio de um servidor. Nesta arquitetura podem ser destacados os seguintes benefícios
segundo Kubo (2006):
 Disponibilidade: se os dispositivos de algum dos jogadores pararem de funcionar os

demais jogadores continuam o jogo;
 Compartilhamento: as atividades são divididas entre os jogadores diminuindo
eventuais gargalos;
 Escalabilidade: suporta um grande número de jogadores.
Apesar dos benefícios, a arquitetura ponto a ponto é pouco utilizada, pois as aplicações
exigem um nível de complexidade alto para gerenciar a comunicação entre os jogadores, uma
vez que todos devem conhecer os endereços uns dos outros para que as mensagens sejam
enviadas diretamente de um jogador para o outro. Outro problema é que é mais complexo
controlar a entrada e saída de jogadores, pois os outros jogadores devem ser informados a
cada entrada e saída de jogadores e também se torna mais complexo o controle de versão do
jogo para todos os usuários (KUBO, 2006).
Na arquitetura cliente-servidor, todos os jogadores, denominados clientes, comunicam-se
somente com o servidor, não havendo uma comunicação direta entre os clientes, pois é o
36
servidor quem faz o direcionamento das mensagens para os mesmos. Segundo Kubo (2006),
esta arquitetura apresenta os seguintes benefícios:
 O servidor pode adicionar um processamento adicional antes de enviar as informações

para o cliente, que pode ser útil em muitos aspectos, principalmente em relação à
segurança;
 O servidor pode filtrar as mensagens que serão envidas, diminuindo o tráfego na rede;
 Simplicidade no controle das atividades dos clientes;
 Protocolos de comunicação mais simples, pois só é necessária uma única comunicação
entre o cliente e o servidor;
 O controle de versões e de endereços é feito somente no servidor, tornado o
gerenciamento mais simples;
 O processamento no cliente pode ser diminuído caso tenha sido executado no servidor.
A arquitetura cliente-servidor é mais utilizada, principalmente por ser mais simples do

que a arquitetura ponto a ponto, mas tem algumas desvantagens segundo Kubo (2006). Estas
desvantagens são:
 Dependência: caso o servidor falhe o sistema para de funcionar;

 Latência: a comunicação pode ser atrasada pelo fato da mensagem ir primeiro ao
servidor para depois ser direcionada ao cliente;
 Escalabilidade: a capacidade de aumento no número de clientes é diretamente
proporcional à capacidade de processamento do servidor, o que pode tornar o servidor
um gargalo no sistema.
A arquitetura híbrida é uma combinação entre a ponto a ponto e a cliente-servidor, como

por exemplo, uma arquitetura que possui um servidor central para implementar segurança,
controle de versões e o gerenciamento de novas conexões, como proposto por Kozovits e
Feijó (2003). Um exemplo deste tipo de arquitetura pode ser vista na Figura 12.
37
Figura 12 – Exemplo arquitetura híbrida

Fonte: ftp://139.82.16.194/pub/docs/techreports/03_36_kozovits.pdf
Nesta proposta ilustrada na Figura 12, o ambiente é dividido em salas, cada sala com seu
próprio servidor. Nessas salas a comunicação é feita utilizando arquitetura ponto a ponto, o
que torna a comunicação entre os jogadores mais rápida, aproveitando um dos benefícios da
mesma. Porém há uma latência maior quando a comunicação é feita com o servidor central,
pois é necessário passar pelo servidor “local” antes.
2.4 HTML 5
Em 2004 um grupo de desenvolvedores da Apple®, da Fundação Mozilla e do navegador

Opera, descontentes com os rumos adotados pelo W3C (World Wide Web Consortium) em
ralação ao HTML (Hypertext Transfer Protocol), formaram o WHATWG (Web Hypertext
Application Technology Working Group) e se propuseram a desenvolver as especificações da
HTML 5 e outras tecnologias como a Web Forms 2.0 e a Web Controls 1.0. Após cinco anos,
em 2007, o W3C retomou os estudos para o desenvolvimento da HTML 5 e usou como base o
38
trabalho que estava sendo desenvolvido pelo WHATWG. As duas instituições continuaram a
desenvolver a tecnologia até que em 19 de janeiro de 2011, Ian Hickson, editor da HTML 5
publicou no blog da WHATWG que a especificação para a HTML 5 seria desenvolvida
exclusivamente pelo W3C (SILVA, 2011).
2.4.1 Definição
O HTML 5 é a nova versão do HTML e possui como um dos seus principais objetivos
facilitar a manipulação dos elementos da página, de uma maneira que possibilite ao
desenvolvedor modificar as características dos objetos de uma forma não intrusiva e que seja
transparente para o usuário final. Uma das principais características que torna o HTML 5
diferente das suas versões anteriores é que ele fornece ferramentas para otimizar o
desempenho e facilitar a utilização do CSS e do JavaScript na manipulação dos elementos da
página. Com isso, aplicações complexas podem se tornar mais leves (W3C, 2012).
Nesta nova versão da linguagem foram criadas novas tags e as funções de outras tags
foram modificadas, além de terem recebido novas funções para que possam ser utilizadas de
uma maneira mais eficaz. Mesmo com essas modificações, o HTML 5 tem como uma das
principais preocupações manter a retrocompatibilidade com as versões anteriores do HTML e
também com o XHTML (Extensible Hypertext Markup Language), tanto para exibir conteúdo
desenvolvido nas versões anteriores, como para conteúdo desenvolvido em HTML 5 que
serão exibidos em navegadores que não tem suporte à tecnologia (W3C, 2012).
2.4.2 Elementos Gráficos.
Um dos principais motivos que tem despertado o interesse dos desenvolvedores de jogos
para o HTML 5 é a possibilidade de criar jogos para navegadores sem a dependência de
nenhum plug-in ou de tecnologias proprietárias, o que acontece atualmente com a maioria de
jogos para navegadores, pois são feitos utilizando a tecnologia Flash, uma tecnologia
proprietária da empresa Adobe15.
15
www.adobe.com
39
Para o desenvolvimento de interfaces gráficas mais complexas, o HTML 5 disponibiliza

os elementos Canvas e SVG (Scalable Vector Graphics), que são elementos para desenhar
elementos na tela em tempo de execução (ROUSSET, 2013).
O elemento SVG, é utilizado para desenhar objetos vetoriais em tempo real em páginas
web baseado em XML (Extensible Markup Language). Por ser um elemento baseado em
XML, ele traz alguns benefícios (W3SCHOOLS, 2013):
 Imagens em SVG podem ser criadas e editadas a partir de qualquer editor de texto;
 Imagens em SVG podem ser indexadas, permitindo que ela seja pesquisável;
 Imagens em SVG podem ser impressas com alta qualidade independentemente da
resolução e podem ser ampliadas sem perda de qualidade.
Entretanto, a utilização do SVG em jogos não é recomendada, pois o tempo para

renderização16 aumenta muito em relação ao Canvas, conforme a quantidade de elementos
que serão renderizados na tela aumenta (W3C, 2013), (DENGLER, 2013). Na Figura 13 é
apresentado um gráfico comparando o desempenho do SVG em relação ao Canvas realizado
por Rousset (2013).
Figura 13 – Comparação de performance SVG vs. Canvas

Fonte: http://i.msdn.microsoft.com/dynimg/IC643115.png
16
Processo utilizado para transformar um conjunto de dados em uma representação visível
40
De acordo com o gráfico apresentado, pode se analisar que o SVG tem um desempenho
superior em relação ao Canvas quando o tamanho da tela aumenta, o que acontece pelo fato
do Canvas ser dependente de resolução. Em contrapartida, o Canvas possui um desempenho
superior ao SVG quando a quantidade de objetos que precisam ser renderizados aumenta, isto
acontece pelo fato do SVG ser manipulado através do DOM (Document Object Model) e
conforme a quantidade desses objetos aumentam o custo para processar esses elementos
aumentam.
O elemento Canvas, segundo Sheridan (2013), “[...]é uma tela bitmap dependente de
resolução que pode ser usada para a renderização de elementos ou outras imagens visuais
rapidamente[...]”, ou seja, o Canvas é um novo elemento do HTML 5, que permite que sejam
desenhados elementos gráficos, em tempo real, rapidamente usando JavaScript. Ele pode ser
utilizado para renderizar imagens, texto, gráficos e outros efeitos dinamicamente, sendo que
para isso é utilizada a API (Application Programming Interface) CanvasRenderingContext2D.
Um ponto a ser ressaltado em relação a API é que, por enquanto, ela suporta apenas
interfaces 2D e não interfaces 3D. Pelo fato de trabalhar com interfaces 2D, a área de desenho
do Canvas trabalha com coordenadas na horizontal (x) e na vertical (y) para mapear os pixels,
conforme exemplo apresentado na Figura 14, sendo que a origem das coordenadas é
localizado no ponto superior esquerdo do espaço de desenho, além de que o eixo y cresce para
baixo, ao contrário do eixo y do plano cartesiano. Para a utilização de interfaces 3D, pode ser
utilizada a API WebGL (Web Graphics Library ), desenvolvida pela Khronos WebGL
Working Group, que possui ferramentas para o desenvolvimento de elementos 3D complexos,
além de possuir recursos para aceleração de hardware utilizando o navegador17. Como o foco
deste trabalho é o desenvolvimento de um jogo em 2D, não serão apresentados maiores
detalhes a respeito desta API.
17
www.khronos.org/WebGL/
41
Figura 14 – Coordenadas Canvas

Fonte: http://i.msdn.microsoft.com/dynimg/IC652726.png
Em relação à compatibilidade com os navegadores, tanto o Canvas quanto o SVG são

suportados pela maioria dos navegadores atuais, porém se forem analisadas as versões mais
antigas dos navegadores, o SVG possui incompatibilidades com mais navegadores do que o
Canvas, conforme pode ser visto na Tabela 1 e na Tabela 2.
Tabela 1 – Navegadores compatíveis com SVG

Fonte: http://caniuse.com/#feat=SVG
42
Tabela 2 – Navegadores compatíveis com Canvas

Fonte: http://caniuse.com/#feat=canvas
Analisando as tabelas, pode-se notar que todos os fabricantes estão procurando

implementar o suporte às novas tecnologias para desenho em tela e com o aumento do suporte
destas tecnologias, torna-se possível o desenvolvimento de um número maior de aplicativos
utilizando essas novas APIs.
2.4.3 Comunicação
Em uma aplicação web em tempo real, principalmente quando se trata de um jogo

multiplayer, a comunicação com o servidor é um fator de extrema importância, pois como
visto é fundamental que um jogo multiplayer possua um tempo de resposta rápido e uma
latência baixa. Para atender estes requisitos, o HTML 5 possui a API WebSocket, que
possibilita a comunicação entre o cliente e o servidor de uma maneira mais simples e rápida
do que as técnicas utilizadas atualmente em conexões HTTP (Hypertext Transfer Protocol),
mas para entender como esta nova tecnologia funciona e quais são os seus benefícios,
primeiramente é importante saber como a comunicação entre o cliente e o servidor é feita em
aplicações web.
Usualmente, a comunicação entre o cliente e o servidor é feita através do protocolo
HTTP, que funciona da seguinte maneira, o cliente envia uma solicitação HTTP para o
servidor e o servidor retorna uma resposta à solicitação realizada pelo cliente (W3C, 1999).
Sendo assim se o cliente não fizer uma solicitação, a página permanece estática, mas a partir
de 2005 com o AJAX (Asynchronous JavaScript and XML), as aplicações web começaram a
se tornar mais dinâmicas com técnicas como o Polling, Long Polling e Streaming, que fazem
uma requisição com um longo tempo de duração e enquanto essa requisição está aberta o
43
servidor pode enviar novas informações ao cliente, criando a ilusão de que o servidor está
enviando dados sem que seja feita uma requisição (UBL e KITAMURA, 2012).
Na técnica de Polling, o navegador envia solicitações HTTP em intervalos regulares para
que o servidor responda. Esta foi a primeira tentativa para o navegador fornecer informações
em tempo real, só que esta técnica possui desvantagens, pois em muitas aplicações em tempo
real não é possível prever de quanto em quanto tempo novas informações estarão disponíveis,
por isso conexões são feitas ao servidor sem necessidade e a latência pode aumentar pois o
processo de abrir e encerrar uma conexão pode ser muito lento (LUBBERS e GREGO, 2010).
Com a técnica Long Polling, o cliente envia uma requisição ao servidor e mantém esta
requisição aberta por um período pré-determinado permitindo que o servidor envie mensagens
enquanto esta conexão está aberta. Caso o tempo se esgote, o servidor envia uma resposta
finalizando a requisição. Em algumas situações, de acordo com o tamanho da mensagem
enviada pelo servidor, não há ganho de performance em relação ao Polling e em algumas
situações o desempenho é inferior, pois o gerenciamento das requisições pode falhar gerando
loops contínuos (LUBBERS e GREGO, 2010).
Outra técnica utilizada é o Streaming, sendo que nesta técnica o cliente envia uma
requisição completa e o servidor envia a resposta, mais não a finaliza, deixando-a aberta por
tempo indeterminado, ou em alguns casos, por um tempo pré-determinado, e envia mensagens
ao cliente sempre que encontra um novo conteúdo disponível. Como o streaming está
encapsulado em uma requisição HTTP, firewalls e servidores de proxy podem modificar esta
comunicação criando um buffer, o que aumenta a latência na comunicação. Uma alternativa
para proteger o streaming é utilizar conexões SSL (Secure Socket Layer), mas em alguns
casos, o custo para montar e desmontar a segurança, acaba sendo maior do que se esta solução
não fosse empregada (LUBBERS e GREGO, 2010).
As soluções acima citadas utilizam o protocolo HTTP para simular uma comunicação em
tempo real, mas a principal deficiência da comunicação em tempo real sob este protocolo é o
fato da sua comunicação ser dada a partir de uma requisição, que gera uma resposta. Para
resolver este problema foi criada junto com as especificações do HTML 5, um novo
protocolo, o WebSocket. Este protocolo permite a criação de um canal de comunicação
persistente, onde o cliente e o servidor podem enviar dados a qualquer momento (UBL e
KITAMAJURA, 2012).
Seguindo a especificação do protocolo WebSocket do IETF (Internet Engineering Task
Force), a comunicação do protocolo é realizada em duas etapas, a primeira é o aperto de mão
44
(handshake), onde o cliente solicita ao servidor um upgrade da conexão de HTTP para WS

(WebSocket). Segue abaixo um exemplo do código utilizado pelo cliente para realizar o
handshake:
“GET /chat HTTP / 1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec- WebSocket-Key: dGhlIHNhbXBsZSBub25jQ= =
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13”
O handshake da parte do servidor é feito com o seguinte código:

“HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat”
Após realizado o handshake, a comunicação pode ser feita tanto do cliente para o
servidor quando do servidor ao cliente. E a troca de mensagens pode ser feita de modo Full-
Duplex bidirecional e de forma simultânea (LUBBERS e GREGO, 2010).
Na Figura 15 são mostrados os resultados de um estudo de caso feito por Lubbers e
Grego (2010), onde 1.000, 10.000 e 100.000 clientes necessitam da mesma informação a cada
segundo, na primeira situação descrita na coluna azul, a comunicação é feita utilizando a
técnica Polling e na segunda situação, representada na coluna laranja, a comunicação é feita
utilizando WebSockets.
45
Figura 15 – Comparação entre o uso de Polling e WebSocket.

Fonte: http://www.websocket.org/img/poll-ws-compare.gif
No gráfico apresentado na Figura 15 é mostrado que a diferença entre a quantidade de

informações enviadas é muito grande, pois na técnica Polling é necessário realizar uma
requisição HTTP completa, o que neste estudo de caso teve o tamanho de 871 bytes, em
contrapartida utilizado WebSockets o tamanho de cada mensagem é de 2 bytes, gerando um
tráfego de rede de 0,015 Mbps, 0,153 Mbps e 1,526 Mbps para 1.000, 10.000 e 100.00 clientes
respectivamente com Websockets e 6,6 Mbps, 66 Mbps e 665 Mbps com a técnica Polling.
Na Figura 16 é mostrada outra comparação realizada por Lubbers e Grego (2010). Nesta
comparação é mostrada a diferença da técnica Polling e do protocolo WebSocket no quesito
latência.
46
Figura 16 – Comparação WebSockets e Polling

Fonte: http://www.websocket.org/img/latency-comparison.gif
Como na comunicação com WebSockets o servidor pode enviar mensagens ao cliente a

qualquer momento após o handshake, a latência é diminuída consideravelmente em relação a
técnica Polling, que por sua vez necessita sempre fazer uma requisição para obter uma
resposta (UBL et. al, 2010).
A utilização de WebSockets é recente e para isso é necessário possuir um servidor que
possua suporte a esta tecnologia, pois os servidores atuais baseados em LAMP (Linux,
Apache, MySQL e PHP) não gerenciam bem muitas conexões WebSocket abertas. Para
manter uma quantidade grande de portas abertas é necessário um servidor que consiga
gerenciar alta concorrência. Atualmente existem várias implementações de servidor com
suporte a WebSockets e a várias linguagens de programação. Abaixo seguem alguns exemplos
de implementações de servidores com suporte a WebSocket (UBL et. al, 2010):
 JavaScript
o Node.js
 Socket.IO;
 WebSocket-Node;
 Ws;
47
 Java
o Jetty (container de Servlets que suporta WebSockets);
o JWebSocket;
 Ruby
o EventMachine;
 Python
o PyWebSocket;
o Tornado.
Dentre as tecnologias de servidor citadas acima ,uma tem se destacado quando o assunto
são sistemas em tempo real, esta tecnologia é a Node.js juntamente com a API Socket.IO, que
possibilitam a criação de aplicações de rede escaláveis em tempo real com mais facilidade. A
tecnologia Node.js e a API Socket.IO serão descritas com mais detalhes nos capítulos a
seguir.
2.5 Node.js
De acordo com o site oficial do Node.js18, ele é definido como uma plataforma criada
sobre o motor de execução de JavaScript do navegador Google Chrome para a construção de
aplicações de rede altamente escaláveis de maneira fácil e rápida. Para isso o Node.js utiliza
orientação a eventos e trabalha com requisições de E/S sem bloqueio (E/S não bloqueante)
tornando-o um ambiente leve e eficiente, ideal para aplicações com grande uso de dados em
tempo real e que são executadas em dispositivos distribuídos.
O conceito de utilizar JavaScript no lado do servidor, de acordo com Abernethy (2013), é
novo, uma tentativa foi feita com o Aptana Jaxer19 há alguns anos, mas não da mesma
maneira que acontece com o Node.js. Segundo o próprio fabricante do Node.js, a sua intenção
é facilitar a criação de aplicações de rede escaláveis.
Albernethy (2013) descreve o problema que o Node.js soluciona da seguinte maneira:
18
www.nodejs.org
19
http://www.aptana.com/
48
Em aplicações que utilizam as linguagens Java ou PHP, a cada nova conexão, inicia-se
um novo encadeamento20 que potencialmente é acompanhado de 2MB de memória. Em um
sistema com 8GB de memória, o número de clientes é limitado em aproximadamente 4.000
usuários simultaneamente. A medida que a quantidade de usuários aumenta e a aplicação
necessita de suporte a uma quantidade maior de usuários é necessário aumentar a memória ou
a quantidade de servidores. Esse acréscimo de recursos torna o sistema mais complexo, além
do custo com o novo hardware.
Para solucionar este problema, o Node.js altera o modo de realizar a conexão com o
servidor, em vez de iniciar um novo encadeamento no S.O., ele cria um novo processo que
não requer um bloco de memória o acompanhando, com isso o número de conexões aumenta
consideravelmente.
Nas plataformas Java, PHP, Python o processamento é paralisado toda vez que um
processo faz uma requisição de E/S. Essa paralisação é conhecida como modelo bloqueante
(Blocking-Thread), sendo que com esses bloqueios, muitas vezes o processador fica ocioso,
uma vez que o acesso ao disco ou a memória é muito mais lento do que o ciclo de
processamento do processador. O Node.js trabalha com uma arquitetura diferente das citadas
acima, pois é totalmente sem bloqueios, o que possibilita uma melhor utilização dos recursos
de processamento do servidor e faz com que os usuários não sofram mais com dead-locks,
pois não há nenhum bloqueio (PEREIRA, 2013).
Pereira (2013) diz que o Node.js segue a mesma filosofia de orientação a eventos do
JavaScript do lado do cliente, com a diferença que no servidor não existem eventos como o
keyup do teclado, o click do mouse ou qualquer outro evento HTML, sendo assim o servidor
utiliza os evento de E/S do servidor, como por exemplo o connect de um banco de dados ou o
open de um arquivo. Para escutar e emitir os eventos no sistema foi desenvolvido um agente
chamado de Event-Loop, que funciona como um loop infinito que a cada iteração verifica em
sua fila de eventos se algum evento foi emitido, caso isso aconteça ele é enviado para a fila de
execução e a partir do momento que ele esta em execução pode ser programada qualquer
lógica dentro deste evento, graças às funções de callback do JavaScript. Na Figura 17 pode-se
ver o ciclo de funcionamento do Event-Loop.
20
Método criado para que uma tarefa seja executada antes que a outra termine, também é conhecido como
pipelinig. (BEHROUZ e FIROUZ, 2013)

49
Figura 17 – Event-Loop
Outro aspecto destacado por Pereira (2013) é o ganho de desempenho em processamento

em ambientes Node.js quando a programação assíncrona é utilizada, isso ocorre pelo por ser
possível a implementação de funções de callback no código e a sua arquitetura não
bloqueante. Na Figura 18 é exibido um código síncrono e sua linha do tempo de execução:
Figura 18 – Código síncrono e linha do tempo de execução.

Fonte: Aplicações em tempo real com Node.js
50
Na Figura 19 pode-se observar o código com a mesma função, escrito de maneira

assíncrona e sua linha do tempo de execução:
Figura 19 – Código assíncrono e sua linha do tempo de execução

Os códigos exibidos na Figura 18 e Figura 19 são simples, eles fazem cinco iterações e a
cada iteração é criado um arquivo de texto com o conteúdo “Hello Node.js!”. Como pode ser
observado na linha do tempo de execução do código síncrono, cada arquivo demorou 200ms
para ser criado e como o código é síncrono, o processamento da função para criação de um
novo arquivo só e executado quando o arquivo anterior era gerado. Já no código assíncrono,
como as chamadas de E/S não são bloqueantes, a criação dos arquivos foram executadas
completamente em paralelo fazendo com que todo o processo fosse executado em um total de
200ms o que maximizou o processamento e diminuiu o tempo de execução (PEREIRA,
2013).
Ainda em relação ao código síncrono e assíncrono é importante ressaltar que no código
assíncrono não há nenhuma garantia de ordem na criação dos arquivos, diferentemente do
código síncrono onde há uma ordem garantida para a criação dos mesmos.
51
Após analisar o funcionamento e a arquitetura do Node.js, Albernethy (2013) conclui que

há alguns tipos de aplicações que o Node.js pode ser utilizado, como gerenciamento de
mensagens no Twitter, servidores de imagens e APIs RESTful, porém não é indicado para
criação de páginas dinâmicas e sistemas com banco de dados relacionais.
2.6 Socket.IO
Na seção 2.4 foi apresentado o protocolo Websocket, que permite a comunicação full-
duplex entre os clientes e o servidor. Pelo fato desta tecnologia ser nova e estar em fase de
homologação, não são todos os navegadores que dão suporte a esta tecnologia, sendo assim é
necessário utilizar outras técnicas para se conseguir uma comunicação em tempo real.
Para facilitar esta comunicação foi desenvolvida a API Socket.IO21, que segundo o site
do desenvolvedor tem como objetivo tornar possível a comunicação em tempo real em todos
os navegadores e inclusive de dispositivos móveis, sem que o desenvolvedor tenha que
preocupar com qual será a tecnologia de transporte será utilizada e foi desenvolvida 100% em
JavaScript.
Ainda de acordo com o desenvolvedor, a API pode trabalhar com as seguintes técnicas de
transmissão de dados em tempo real:
 WebSocket;
 Adobe ® Flash ® Socket;
 AJAX long polling;
 AJAX multipart de streaming;
 Forever IFrame;
 JSONP Polling;
A conexão é feita sempre priorizando a conexão Websocket, caso o navegador não suporte
esse protocolo, a própria API vai utilizar a técnica que apresentar o melhor desempenho. Com
isso a API torna possível a comunicação em tempo real nos seguintes navegadores a seguir,
de acordo com o desenvolvedor:
 Navegadores desktop:
o Internet Explorer 5.5+
21
http://socket.io
52
o Safari 3+
o Google Chrome 4+
o Firefox 3+
o Opera 10.61+
 Navegadores mobile:
o iPhone Safari
o iPad Safari
o Android WebKit
o WebOs WebKit
Pelo fato da API ser desenvolvida completamente em JavaScript, tanto no lado do cliente,
quanto no lado do servidor, sua utilização só é possível em ambientes Node.js. Na Figura 20
segue um exemplo de utilização da API no lado do servidor:
Figura 20 – Script do servidor Socket.IO

Fonte: http://socket.io/#how-to-use
No script do servidor, a variável “io” recebe a API Socket.IO e informa que o servidor
receberá conexões na porta 80. No restante do código são programadas as funções
responsáveis por escutar os eventos, por exemplo a função “io.sockets.on(‘connection’...)” é
responsável por escutar o evento de conexão no servidor, assim toda vez que um cliente se
conectar no servidor a função será executada, e segue desta maneira até o fim do código. Na
Figura 21 segue um exemplo de utilização no lado do cliente:
53
Figura 21 – Script do cliente Socket.IO

Fonte: http://socket.io/#how-to-use
No script do cliente, a variável “socket” recebe uma nova conexão com o servidor e, em
seguida, durante a conexão, é executada uma função onde é enviada a uma mensagem para o
servidor pela função “socket.send(‘hi’);”.
De acordo com Pereira (2013), os eventos da API Socket.IO são os seguintes:
 Eventos no lado do servidor:
o io.sockets.on(‘connection’, function(socket)) - Ocorre quando o servidor recebe
uma nova conexão de cliente;
o socket.on(‘message’, function(mensagem, callback)) - Ocorre quando um
cliente usa a função send();, o callback desse evento serve para automaticamente
responder o cliente no final da execução deste evento;
o socket.on(‘qualquer-nome-de-evento’, function(data)) - Eventos customizados
pelo desenvolvedor, qualquer nome pode ser apelidado aqui e o seu comportamento
é de apenas receber através do data dados enviados pelo cliente;
o socket.on(‘disconnect’) - Ocorre quando um cliente sai da área conectada ou
emite o evento disconnect para o servidor.
 No lado do cliente:
o socket.on(‘connect’) – Ocorre quando o cliente se conecta ao servidor.
o socket.on(‘connecting’) – Ocorre quando o cliente esta se conectando ao
servidor;
o socket.on(‘disconnect’) – Ocorre quando o cliente deseja se desconectar do
servidor;
o socket.on(‘connect_failed’) – Ocorre quando o cliente não conseguiu se
conectar no servidor;
o socket.on(‘error’) – Ocorre quando o cliente já se conectou, porém ocorreu um
erro grave no servidor durante as trocas de mensagens;
o socket.on(‘message’, function (message, callback)) – Ocorre quando o cliente
envia uma mensagem de resposta rápida ao servidor, cuja resposta acontece através
da função de callback;
o socket.on(‘qualquer-nome-de-evento’, function(data)) – Evento customizado
pelo desenvolvedor;
o socket.on(‘reconnect_failed’) – Ocorre quando o cliente não consegue se
reconectar ao servidor;
o socket.on(‘reconnect’) – Ocorre quando o cliente se reconecta ao servidor;
54
o socket.on(‘reconnecting’) – Ocorre quando o cliente esta se reconectando ao

servidor. (PEREIRA, 2013)
Para realizar o envio de mensagens a partir do cliente é utilizado a função socket.emit(...),

e a partir do servidor podem ser utilizadas as funções socket.emit(...) e socket.broadcast.em
it(...) (PEREIRA, 2013) .
Na Figura 22 ena Figura 23, são ilustradas troca de mensagens utilizando essas duas
funções.
Figura 22 – Envio de mensagens para o cliente ou servidor

Na Figura 22, pode ser visto o envio de mensagens utilizando a função socket.emit(...).
Esta função pode ser utilizada tanto no lado do servidor, quanto no lado do cliente. No lado
do cliente esta é a única maneira de realizar o envio de uma mensagem, já no lado do
servidor, esta função é utilizada quando é necessário enviar uma mensagem ao cliente da
conexão que está solicitando a função no servidor.
Figura 23 - Envio de mensagens para todos os clientes, exceto o emissor

55
Na Figura 23, pode ser visto o envio de mensagem utilizando a função

socket.broadcast.emit(...). Esta função é utilizada somente pelo servidor e é utilizada para
enviar uma mensagem a todos os clientes que estão conectados, exceto o cliente do socket que
solicitou esta função.
Neste capítulo foram apresentados os conceitos sobre jogos, suas classificações e seus
requisitos, além do que vem sendo feito a respeito do HTML5 e das suas ferramentas para
desenvolvimento de jogos. Sendo assim, no próximo capitulo, será apresentada a metodologia
de desenvolvimento do protótipo de jogo que foi desenvolvido neste trabalho.
Capítulo
56
3 Metodologia
Este capítulo está dividido em quatro seções, sendo a primeira com aspectos referentes ao
jogo Batalha Naval, suas regras e como será a versão utilizada neste trabalho. Na segunda
será exibida a arquitetura do jogo. A terceira é a aplicação no lado do servidor e a quarta é a
aplicação do lado do cliente.
3.1 O Jogo
O jogo batalha naval, de acordo com Hinebaugh (2009), teve origem no jogo francês
L'Attaque durante a I Guerra Mundial. Originalmente era jogado em um tabuleiro desenhado
em folhas de papel. É um jogo de estratégia simples, que possui como objetivo descobrir onde
estão posicionados os navios do oponente e destruí-los. O jogo possui várias versões, a
primeira versão comercial lançada foi em 1931, pela empresa Starex, com o nome de Salvo22.
A versão utilizada neste trabalho, o campo de batalha de cada jogador é composto por uma
matriz de 10 linhas por 10 colunas, conforme apresentado na Figura 24. Nesta matriz o
jogador deve organizar os seus navios da maneira que desejar.
22
The Milwaukee Journal. 01 de julho de 1931 – Disponível em: http://news.google.com/newspapers?nid=
1499&dat=19310701&id=QKtQAAAAIBAJ&sjid=KCIEAAAAIBAJ&pg=3803,4154106
57
Figura 24 – Tabuleiro Batalha Naval

Fonte: Elaboração do autor
Cada jogador terá no total 10 navios, sendo estes: um porta aviões, dois submarinos, três
cruzadores e quatro destroyers. Cada navio possui um tamanho e um formato, que são
apresentados na Figura 25. A distribuição dos mesmos no tabuleiro será controlada a partir de
um painel, que mostra a quantidade de navios disponíveis e se ele será colocado na vertical ou
na horizontal.
Figura 25 – Modelos e formatos dos navios

58
Para iniciar uma partida, o jogador deve selecionar um oponente na lista de jogadores que
aparecerá na tela, ao selecionar o oponente ele deve enviar um convite para uma partida, caso
o oponente aceite é criada uma partida e cada jogador poderá organizar os seus navios no
tabuleiro. Quando os jogadores terminarem de organizar os seus navios a partida será
iniciada. O primeiro a iniciar a partida será o jogador que realizou o desafio, caso acerte o tiro
em algum navio do seu oponente, ele poderá jogar novamente, caso erre é a vez do seu
oponente atirar, este poderá seguir atirando até que erre o navio do seu oponente. Vence a
partida quem destruir a esquadra do seu oponente primeiro.
3.2 A Arquitetura
Conforme visto na seção 2.3.3, um jogo multiplayer pode possuir diferentes modelos de
comunicação. Nesta aplicação é utilizado o modelo cliente-servidor, o que torna possível o
gerenciamento dos estados do jogo de uma maneira centralizada, facilitando a implementação
dos requisitos de segurança e torna a o controle de versões e de usuários do jogo menos
complexo em relação às outras arquiteturas. Para desempenhar o papel de servidor da
aplicação foi utilizado o Node.js, pelo fato de conseguir gerenciar de maneira escalável um
grande número de conexões, com um baixo consumo de memória e um desempenho
satisfatório em aplicações em tempo real, conforme visto na seção 2.5, o que é a proposta do
aplicativo.
As requisições HTTP são tratadas pelo framework Express23, sendo que este framework
tem como objetivo facilitar a programação dessas requisições, além de oferecer suporte a
outras tecnologias, como integração com banco de dados relacionais e não-relacionais, o que
torna a estrutura aplicação mais robusta e abre mais possibilidades em uma futura expansão
do projeto em relação ao módulo HTTP nativo do Node.js.
A conexão entre o servidor e o cliente durante a partida será gerenciada pela API
Socket.IO, pois conforme visto na seção 2.6, ele permite que de acordo com o navegador seja
escolhida a técnica de comunicação que possua o melhor desempenho, priorizando sempre a
23
http://expressjs.com/
59
comunicação utilizando o protocolo WebSocket, que permite uma comunicação full-duplex

persistente entre o cliente e o servidor, conforme visto na seção 2.4.3.
Na Figura 26 é apresentada a arquitetura do projeto.
Figura 26 – Arquitetura do Projeto

3.3 O Servidor
Conforme visto anteriormente, a tecnologia utilizada para ser o servidor da aplicação será
o Node.js. Para utilizá-lo é necessário fazer o download do instalador no site,
http://nodejs.org/download/, de acordo com a plataforma a ser utilizada.
60
A versão do Node.js utilizada na aplicação é a 0.10.20 (x64) com o gerenciador de

pacotes NPM (Node Package Manager) instalado. Após realizar o download do executável
para sistemas operacionais Windows e instalá-lo, é necessário realizar a configuração de uma
variável de ambiente no sistema operacional para tornar o ambiente de desenvolvimento
funcional. Para realizar essa configuração no Windows 8, é necessário acessar: Painel de
Controle – Sistema e Segurança – Sistema, ir na opção Configurações Avançadas do Sistema,
depois e Variáveis de Ambiente e em Novo, conforme Figura 27.
Figura 27 – Configuração da Variável de Ambiente

No nome da variável deve ser inserido o seguinte valor, NODE_ENV, e no valor da

variável, development, conforme Figura 28:
Figura 28 – Valores da variável de ambiente

61
Após realizar esta configuração, o ambiente do Node.js está pronto para ser utilizado e
seu console pode ser acessado pelo prompt de comando do Node.js. Para completar a
arquitetura da aplicação descrita na sessão anterior, ainda é necessária a instalação dos APIs
Express e Socket.IO, esta instalação é feita pelo prompt de comando do Node.js, utilizando o
NPM. A instalação é feita através do comando npm install express, conforme Figura 29, com
esse comando é feito o download dos pacotes da API do repositório oficial do NPM.
Figura 29 – Instalação API Express

Após realizar a instalação do Express, é necessário instalar a API Socket.IO, que é o

responsável pela comunicação em tempo real entre os clientes e o servidor. A instalação
também é feita pelo NPM, pelo comando npm install socket.io, conforme Figura 30.
Figura 30 – Instalação API Socket.IO

62
Finalizada a instalação do API Socket.IO, toda a estrutura necessária para o servidor da

aplicação está pronta. Conforme visto na seção 2.5, o Node.js executa JavaScript no servidor,
por isso foi criado o arquivo game_server.js, que é o responsável por ser o servidor da
aplicação. Este arquivo é uma versão adaptada do arquivo disponibilizado como material de
exemplo pelo livro HTML5 Guidelines for Web Developers. (FÖRSTER; ÖGGL, 2011)
Em relação ao arquivo original desenvolvido por Förster e Öggl (2011), foram feitas
duas modificações, a primeira foi a inclusão da API Socket.IO para gerenciar as conexões
WebSocket e a segunda foi a inclusão da API Express.js para gerenciar as conexões HTTP.
Nas linhas de 6 a 23 do arquivo game_server.js, conforme apresentado naFigura 31,
são feitas as importações dos APIs Express e Socket.IO, a criação do servidor HTTP e sua
configuração para receber conexões através da porta 8889. Também é definido um diretório
estático acessível para todos os arquivos da aplicação, de onde poderão ser importados os
arquivos CSS e Javascript e a página index.html como a página inicial da aplicação.
Figura 31 – Linhas de 6 a 23 do arquivo game_server.js

Das linhas 27 a 90 são tratadas as trocas de mensagens entre o cliente e o servidor,

começando pelo evento de conexão ao servidor, conforme apresentado na Figura 32, que
assim que o cliente realiza uma conexão o servidor envia para o cliente a lista com todos os
clientes que estão conectados, lista que está armazenada no vetor USERS, criado na linha 10.
63
Após enviar a lista ao cliente que se conectou o novo cliente é adicionado à lista de usuários e
é criada uma sala para este novo usuário.
Figura 32 – Linhas 27 a 40 do arquivo game_server.js

A criação de uma sala para cada usuário foi a técnica encontrada para que se pudesse
enviar uma mensagem privada de um usuário para o outro, uma vez que sem a utilização de
salas as mensagens são trocadas apenas entre o servidor e o cliente que fez a conexão, ou são
enviadas a todos os clientes conforme visto no capitulo Socket.IO.
O envio de mensagens privadas é necessário durante a partida, para que possam ser
enviadas aos clientes diversas informações como a posição onde será dado o tiro, o convite
para uma partida entre outras.
3.4 O Cliente
Os códigos na parte do cliente da aplicação são divididos em três arquivos, o primeiro é o

index.html, este é o arquivo que o cliente acessa no seu navegador, é responsável pelos
elementos da página web, o segundo é o arquivos game_en.js, que é o responsável por tratar a
lógica do jogo, controlando os tabuleiros dos jogadores e a comunicação com o servidor, e o
terceiro arquivo é o game.css, que é a folha de estilos, responsável pelo visual da aplicação.
Todos os arquivos citados foram adaptações dos arquivos disponibilizados como
material adicional do livro HTML5 Guidelines for Web Developers, desenvolvido por
FÖRSTER e ÖGGL (2011).
64
A primeira modificação realizada no arquivo index.html, foi a inserção da metatag24

viewport, na linha 11 como pode ser visualizado na Figura 33.
Figura 33 – Metatag Viewport

Esta tag é responsável pelo controle da área onde o site irá aparecer. No código acima a
largura da área foi definida como “device-width”, isso é necessário para sanar o problema que
existe entre o tamanho que o viewport suporta em CSS pixels e o a resolução física da tela. De
acordo com Lopes(2012), o viewport é a quantidade de conteúdo que cabe numa tela e CSS
pixels, ou seja, no viewport de um iPhone só podem ser exibidos 320px de conteúdo,
independentemente da resolução física do aparelho ser de 640px. Além de definir a largura
padrão para o viewport, foi configurada a escala inicial e escala máxima como 1.0, e o zoom
no viewport foi desativado, isto foi feito com o objetivo de tornar o tamanho da tela o mais
fixo possível, para que os elementos possam ser distribuídos de acordo com o tamanho da tela
para proporcionar mais facilidade aos usuários.
Na linha 18do arquivo index.html, é feita a importação do arquivo socket.io.js, que faz
parte do API de comunicação Socket.IO, o responsável pela comunicação websocket entre o
cliente e o servidor, conforme pode ser visto na Figura 34.
Figura 34 – Importação socket.io.js

Foi adicionada uma <div> nas linhas de 22 a 24 do arquivo index.html, o objetivo desta é
exibir uma mensagem quando o jogador estiver usando um tablet ou um smartphone para que
o aparelho seja utilizado durante o jogo na orientação paisagem, sendo assim toda vez que o
jogador utilizar seu dispositivo na orientação retrato essa mensagem irá aparecer.
24
De acordo com Gazola (2006), “Metatags fornecem informações usadas para categorizar, priorizar e rankear
websites além de controlar seu conteúdo pelos webmasters e/ou autores.”
65
O restante do arquivo é composto por alguns formulários, o primeiro é o formulário de

login, nesse formulário o jogador deverá inserir o seu nome e escolher em qual servidor ele
deseja se conectar, no momento só há um servidor disponível, mas esta escolha foi mantida
no aplicativo visando uma futura expansão. O segundo formulário é onde será desenhado o
tabuleiro do jogador. O terceiro é o responsável pelo controle da distribuição dos navios no
tabuleiro, neste formulário o jogador pode escolher qual é o navio que ele vai colocar no
tabuleiro e qual a posição, se é na vertical ou na horizontal. O quarto formulário é onde será
desenhado o tabuleiro do oponente. O quinto é responsável por listar todos os jogadores que
estão conectados ao servidor e permitir o convite para uma partida. Os demais são
responsáveis pelas mensagens de convite para uma partida, confirmar e recusar o convite.
No arquivo game_en.js é onde está armazenada toda a lógica do jogo, ele é o responsável
por criar e desenhar os tabuleiros, criar os usuários, criar os navios, possibilitar que cada
jogador possa organizar os seus navios no tabuleiro, entre outras funções.
Das linhas 9 a 38 do arquivo game_en.js (Figura 35) são feitas as declarações das
variáveis que controlam praticamente todo o jogo, nessas variáveis são armazenadas as
informações sobre a conexão websocket, os jogadores, seu tabuleiro e os navios.
66
Figura 35 – Linhas 9 a 38 arquivo game_en.js

No trecho das linhas 40 a 70 do arquivo game_en.js (Figura 36) foram implementadas

algumas funções de ajuda que serão utilizadas no decorrer do código, essas funções são
responsáveis por esconder ou exibir elementos na página, ativar ou desativar o campo de
batalha e converter uma string que será passada como o tiro para coordenadas x e y, para que
possa ser identificada a linha e a coluna do campo que foi selecionado.
67
Figura 36 – Linhas de 40 a 70 do arquivo game_en.js

O trecho das linhas 104 a 142 é parte do código responsável pela criação e digitalização
do tabuleiro, neste trecho são utilizados duas estruturas de repetição for, a primeira faz é
responsável por controlar as linhas a segunda é responsável por controlar as colunas, a cada
iteração é inserido um elemento do tipo botão na tela e no fim de todas as iterações é formada
uma matriz de 11 linhas por 11 colunas, sendo que destas uma linha e uma coluna são
utilizadas como legenda, marcando as coordenadas das linhas e das colunas, na Figura 37
pode-se ver o desenho do tabuleiro sem nenhuma formatação.
68
Figura 37 – Tabuleiro sem formatação

O código que está entre as linhas 150 e 391 é a parte mais importante do código, pois é
nesse trecho que é realizado o tratamento de todas as mensagens que chegam do servidor via
conexão WebSocket. Na Figura 38 é exibido o código da função responsável por enviar as
mensagens ao servidor, neste trecho do código a variável wsMessage recebe uma função, que
por sua vez recebe o parâmetro msg, este parâmetro é um objeto JSON25 (JavaScript Object
Notation), que a cada troca de mensagens entre o cliente e o servidor pode possuir valores
diferentes, e esta função executa outra função, que pode ser visualizada na linha 160 da
Figura 38, esta função faz parte do Socket.IO e recebe dois parâmetros, o primeiro é a função
que irá receber a mensagem e o segundo parâmetro é a própria mensagem.
Figura 38 – Função para envio de mensagens para o servidor

Na Figura 39 pode-se visualizar qual a função que receberá a mensagem no lado do

servidor, no arquivo game_server.js.
25
JavaScript Object Notation (JSON) é um formato de texto para a serialização de dados estruturados.
(RFC4627)
69
Figura 39 – Função que receptora de mensagens no servidor

Como pôde ser visto na troca de mensagens exibida anteriormente, a função

game.websocket.emit( [“nome da função destinatária”], [“mensagem”] ), é responsável por
enviar uma mensagem do cliente para o servidor, já no lado do servidor a função responsável
por receber a mensagem é a conn.on( [“nome da função emitente”], “função de callback”).
Assim que a função receptora receber a mensagem no servidor ela irá executar a função
de callback que pode ou não resultar na emissão de uma nova mensagem para o cliente. Da
mesma maneira que o servidor possui funções que aguardam o recebimento de mensagens o
cliente também as possui, como pode ser visto na Figura 40, que exibe o trecho de código
entre as linhas 174 e 186, onde a função game.websocket.on(‘toClient’, function(msg){...}); , é
a função responsável por receber as mensagens vindas o servidor pelas funções exibidas em
destaque Figura 41.
Figura 40 – Função receptora de mensagens no cliente

70
Figura 41 – Função para envio de mensagens para o cliente

Existe uma diferença entre o envio de mensagens do cliente para o servidor e do servidor
para o cliente. No lado do cliente as mensagens só podem ser enviadas utilizando a função
socket.emit(...), já no servidor as mensagens podem ser enviadas pelos métodos
socket.emit(...) e socket.broadcast.emit(...), conforme visto no capítulo Socket.IO.
A partir do momento que as mensagens são enviadas e recebidas, cada função vai receber
as mensagens e tratar na maneira como está programado, para realizar o direcionamento das
ações foram utilizadas várias estruturas de decisão, que de acordo com o valor elemento
msgTask do objeto msg, uma determinada tarefa é executada. Por exemplo, no trecho exibido
pela Figura 42, onde o valor do elemento msgTask é addUser, neste caso o cliente recebe do
uma mensagem informando que um novo usuário está conectado, com isso o cliente deve
adicionar à lista de usuários o novo usuário conectado.
Figura 42 – Adicionando um usuário à lista de usuários

Quando o valor da msg.task é ‘private’, significa que a mensagem deve ser enviada
somente para um determinado usuário. Para tornar isso possível foram utilizadas as salas do
Socket.IO, conforme visto na seção 3.3, assim que o usuário se conecta no servidor é criada
uma sala para cada cliente, esta sala é identificada pelo id de conexão do usuário, que é um
valor único para cada usuário, o que torna cada sala única e permite que a mensagem seja
71
direciona corretamente ao usuário de destino. Na Figura 43 pode ser visto um trecho do

código onde esse envio de mensagem é realizado no lado do cliente.
Figura 43 – Envio de uma mensagem privada no lado do cliente

Neste trecho de código é realizado o convite para iniciar uma partida a um outro
jogador, podemos observar que o atributo “task” do objeto “msg” possui o valor “private”,
isso significa que a mensagem será enviada somente a um usuário e este usuário é definido
pelo atributo cliente do objeto “msg”, que recebe o id do usuário selecionado na lista de
usuários conectados no servidor. Na Figura 44 pode ser visto como o servidor recebe essa
mensagem e a encaminha para o usuário de destino.
Figura 44 – Encaminhamento de mensagens privadas no servidor

No código exibido acima o servidor recebe uma mensagem privada, atribui como
emitente da mensagem o id da conexão que enviou a mensagem e envia a mensagem recebida
ao destinatário utilizando o valor do atributo msg.client para identificar o destinatário
corretamente. Na linha 75 pode ser observado o envio de uma mensagem para uma
determinada sala.
72
No restante do arquivo são implementadas a digitalização dos navios, que é feita da linha
471 a 540, e os movimentos que o jogador pode fazer referentes a batalha, como dar um tiro
por exemplo, que é feito da linha 542 a 614 do arquivo game_en.js.
Agora que foram vistos alguns detalhes do arquivo game_en.js, que é o responsável por
implementar toda a lógica do jogo, será exibido na Figura 45 o fluxograma do jogo,
mostrando todas as etapas que os jogadores percorreram durante uma partida.
Figura 45 – Fluxograma do jogo

O arquivo game.css é o responsável pelo design do jogo e é ele que determina o tamanho,
a posição e a cor de cada elemento da página. Como o objetivo do jogo é ser multiplataforma
e que possa ser jogado em dispositivos diferentes foram utilizadas os media types do CSS. De
acordo com Eis (2009), as medias types que definem o tipo de media para qual o CSS será
direcionado. Para identificar o tipo de dispositivo e outras informações a seu respeito são
utilizadas as media queries, que são uma série de condições que direcionam o CSS para um
dispositivo específico. Na Figura 46 pode ser visualizado um exemplo de utilização das media
queries.
73
Figura 46 – Media Queries

O jogo foi adaptado para três resoluções, pois foram usados três dispositivos para teste da
aplicação. O primeiro dispositivo foi o smartphone Samsung Galaxy Y Duos GT-S6102B,
com as seguintes especificações:
 Sistema operacional Android 2.3;
 Navegador Mozilla Firefox para Android versão 25;
 Resolução de 240 X 320px.
O segundo dispositivo utilizado foi o tablet CCE Motion Tab TR71, com as seguintes
especificações:
 Sistema operacional Android 4.0;
 Navegador Google Chrome versão XX;
 Resolução 800 X 400px.
E o terceiro dispositivo é um notebook Dell XPS, com as seguintes especificações:
 Sistema Operacional Microsoft Windows 8 Pro;
 Navegadores Google Chrome versão 31.0, Mozilla Firefox versão 25 e Internet
Explorer versão 10;
 Resolução de 1600 X 900px.
Para adaptar o jogo para os três dispositivos foram usadas três medias queries, a primeira
define o estilo que será aplicado para dispositivos com resolução de até 320px de largura na
orientação paisagem, a segunda define o estilo pra dispositivos com resolução entre 321px e
1279px de largura na orientação paisagem e a terceira com dispositivos de resolução maior
que 1280px de largura.
Na Figura 47 pode ser visualizada a tela de login adaptada para dispositivos com
resolução até 320px.
74
Figura 47 – Tela de login resolução até 320px.

Na Figura 48 pode ser visualizada a tela de login adaptada para dispositivos com
resolução entre 321 e 1279px.
Figura 48 – Tela de login resolução entre 321 e 1279px.

E na Figura 49 pode ser visualizada a tela de login adaptada para dispositivos com
resolução acima de 1280px.
75
Figura 49 – Tela de login resolução acima de 1280px.

Além das medias queries utilizadas para identificar a resolução da tela dos dispositivos
também foi criada outra para verificar se a orientação da tela é retrato, se estiver nessa
orientação será apresentado ao jogado uma mensagem na tela informando que o jogo só
funciona na orientação paisagem, conforme pode ser visto na Figura 50.
Figura 50 – Aviso orientação de tela

76
Com a explicação do arquivo game.css é finalizada a metodologia utilizada neste

trabalho. Após seguir os passos descritos durante este capítulo obteve-se como resultado o
jogo Batalha Naval, sendo que os resultados do desenvolvido serão descritos no próximo
capítulo.
Capítulo
77
4 Resultados
Aplicada a metodologia citada no capítulo anterior, obteve-se como resultado do projeto

o jogo Batalha Naval, conforme foi proposto como objetivo deste trabalho. O jogo pode ser
jogado a partir de dispositivos móveis, como tablets e smartphones e a partir de computadores
pessoais e notebooks. Os jogadores podem jogar entre si mesmo utilizando dispositivos
diferentes e em plataformas distintas. Para demonstrar que o objetivo de jogar em plataformas
e em dispositivos diferentes foi alcançado, foram utilizados três dispositivos para realizar os
testes do jogo. Na seção a seguir será demostrado o gameplay do jogo, exibindo a diferença
entre os três dispositivos testados.
4.1 Gameplay
Para iniciar o jogo a partir de qualquer dispositivo, o cliente deve acessar o site
http://192.168.0.3:8889 pelo navegador do seu dispositivo. Ao acessar o site ele será
direcionado para a tela de login. De acordo com o tamanho da tela será aplicado um estilo
CSS, nas Figuras Figura 51, Figura 52 e Figura 53 são apresentados a tela de login para os três
dispositivos onde o jogo foi testado.
Figura 51 – Tela de login smartphone

78
Figura 52 – Tela de login tablet

Figura 53 – Tela de login para computadores e notebooks

79
Na tela de login o usuário deve inserir o seu nome que servirá como sua identificação
no servidor. No tablet e no computador o usuário além de inserir o nome, possui a opção de
escolher um servidor caso tenha mais do que um disponível, na fase atual do protótipo há
apenas um servidor disponível.
Ao realizar o login o usuário é direcionado para a tela principal do jogo. No
smartphone, a tela principal possui apenas uma lista de usuários conectados no servidor.
Nesta lista aparece o nome do usuário e o id da sua conexão WebSocket, a partir desta lista o
usuário pode escolher qual oponente deseja desafiar para uma partida.
Nos tablets e computadores, na tela principal além da lista de jogadores é exibido o
tabuleiro do jogador. Nas figuras Figura 54, Figura 55 e Figura 56, são apresentadas as telas
principais dos três dispositivos.
Figura 54 – Tela principal smartphone

Figura 55 – Tela principal tablet

80
Figura 56 – Tela principal computadores e notebooks.

Na tela principal o jogador pode convidar outro jogador para uma partida. Para isto basta
selecionar um dos jogadores da lista e apertar o botão “convidar oponente”. Ao realizar o
convite será exibida ao jogador que foi desafiado uma mensagem perguntando se ele aceita o
desafio. Caso o oponente não aceite o jogador desafiante receberá uma mensagem informando
que o desafio não foi aceito e será exibida novamente a tela principal.
Se o desafio for aceito serão exibidos para os dois jogadores um tabuleiro e o painel de
distribuição dos navios, nesse painel são exibidos os navios disponíveis e qual é a orientação
que o navio deve ser colocado. Nas figuras Figura 57, Figura 58 e Figura 59 são apresentadas
as telas de distribuição dos navios para cada um dos dispositivos testados.
81
Figura 57 – Tabuleiro e painel para distribuição dos navios smartphone

Figura 58 – Tabuleiro e painel de distribuição dos navios tablet

82
Figura 59 – Tabuleiro e painel de distribuição dos navios computador e notebook

Assim que os jogadores terminarem de distribuir todos os seus navios no tabuleiro, o

painel de distribuição não é mais exibido na tela, e a partida é iniciada. O primeiro jogador a
dar o tiro será o que propôs o desafio. Devido ao tamanho reduzido da tela do smartphone só
é exibido um tabuleiro por vez, quando é a vez do jogador atirar o tabuleiro do seu oponente é
exibido na tela, quando é a vez do seu oponente atirar é exibido seu próprio tabuleiro na tela,
conforme apresentado nas figuras Figura 60 e Figura 61.
Figura 60 – Visão do jogador durante o seu turno (smartphone)

83
Figura 61 – Visão do jogador durante o turno do seu oponente (smartphone)

No tablet e no computador o tamanho da tela é maior, por este motivo quando a

partida é iniciada os tabuleiros dos dois jogadores são visualizados na tela ao mesmo tempo
durante a partida, no lado esquerdo da tela é exibido o tabuleiro do jogador e os seus navios,
no lado direito da tela o tabuleiro do seu oponente mostrando os tiros que já foram dados, se o
tiro acertou em algum navio do oponente aparece uma chama no lugar onde foi dado o tiro,
caso o tiro não tenha acertado o navio, aparece um ícone de uma onda, informando que o tiro
foi dado na água.
Durante o turno do jogador, no tablet e no computador, o tabuleiro do seu oponente
fica habilitado para que ele possa dar o tiro, conforme é apresentado na Figura 62 – . Durante
o turno do seu oponente o tabuleiro do mesmo fica desabilitado até que seja a vez do jogador
atirar novamente, conforme apresentado na Figura 63.
84
Figura 62 – Turno do jogador (tablet, computador e notebook).

Figura 63 – Turno do oponente (tablet, computador e notebook).

A partida continua até que um dos jogadores tenha acertado todos os navios do seu
oponente, quando isso acontece o jogador vencedor recebe uma mensagem informando-o da
sua vitória e o perdedor da sua derrota, e os dois jogadores retornam a tela principal do jogo.
Os testes foram realizados com todos os dispositivos jogando entre si, mostrando que é
possível a utilização das tecnologias abordadas neste trabalho para o desenvolvimento de
85
jogos. No capitulo a seguir, serão apresentadas as conclusões obtidas com o desenvolvimento

deste trabalho.
Capítulo
87
5 Conclusões
Ao fim do desenvolvimento do protótipo foi possível concluir que o HTML 5 pode ser
utilizado como ferramenta para a criação de jogos, principalmente se o publico alvo do jogo
incluir os dispositivos móveis.
O protótipo foi desenvolvido e testado em um ambiente controlado, com uma conexão de
rede local de alta velocidade, sendo assim, não é possível afirmar que o comportamento do
aplicativo será o mesmo em uma conexão com uma velocidade inferior, ou qual será o
impacto de outros componentes de rede como, servidores de proxy na execução do aplicativo.
No ambiente testado o protótipo foi capaz de atender o objetivo proposto por este trabalho de
maneira satisfatória.
A incompatibilidade de alguns navegadores, principalmente dos dispositivos móveis, foi
um dos obstáculos encontrados. Pois os navegadores nativos dos dispositivos testados não dão
suporte ao protocolo WebSocket, e sem o suporte ao protocolo o aplicativo utilizava outras
técnicas para a comunicação, a utilização destas outras técnicas reduziu o desempenho do
aplicativo o que afetou a jogabilidade, pois se tornou perceptível ao jogador o aumento da
latência e em algumas situações a partida era interrompida antes do seu término. Ao utilizar as
versões atualizadas dos principais navegadores do mercado, nos dispositivos móveis, no
computador e no notebook, foi possível constatar que o suporte as tecnologias do HTML 5
estão bem desenvolvidos, pois testando o protótipo nesses navegadores não foram
encontrados problemas.
Outro obstáculo encontrado foi em relação a interface gráfica, conforme apresentado na
seção 2.4.2, o objetivo era utilizar o Canvas ou o SVG para o desenvolvimento da interface
gráfica do protótipo. Foram testadas algumas APIs, entre elas MelonJS26 e EaselJS27, mas não
26
http://melonjs.org/
27
http://www.createjs.com/#!/EaselJS
88
foi possível chegar a uma interface gráfica satisfatória para o desenvolvimento do protótipo,
principalmente pela dificuldade de trabalhar com diferentes resoluções e tamanhos de tela.
Com a dificuldade de criar a interface gráfica utilizando as tecnologias propostas no
inicio do projeto, foi necessário desenvolver uma interface mais simples, para isso foi
utilizado o CSS, ele foi o responsável pelo design do jogo e por adaptá-lo a diferentes
resoluções. No CSS a maioria dos recursos são implementados da mesma maneira em todos
os navegadores, mas em alguns casos ainda é necessário utilizar algumas técnicas para que
um determinado estilo seja aplicado de forma correta em determinados navegadores.
Em relação à tecnologia utilizada no servidor, o Node.js, e a API utilizada para gerenciar
a comunicação WebSocket, a Socket.IO, pode-se concluir que ambas apresentam um bom
desempenho e que tornam o desenvolvimento de aplicações que necessitam de uma
comunicação em tempo real, ou próximo disso, mais simples.
O suporte ao JavaScript em todos os navegadores testados foi satisfatório, houve apenas
algumas diferenças na forma que os elementos eram desenhados na tela, mas isso não
comprometeu a jogabilidade ou o desempenho do protótipo.
Por fim pode-se concluir que apesar das limitações, principalmente por falta de
compatibilidade, o HTML 5 e as tecnologias que o acompanham podem ser utilizadas de
maneira satisfatória para o desenvolvimento de jogos multiplayer e multiplataforma.
Como sugestão para trabalhos futuros pode ser feito a criação de um banco de dados para
armazenar as informações dos jogadores, para assim gerar informações como ranking, tempo
que os jogadores estão conectados, público do jogo, entre outras. Também pode ser
desenvolvida uma interface gráfica utilizando Canvas ou SVG e com isso sejam incluídos
animações e efeitos multimídia. E como última sugestão fica o desenvolvimento de um chat
para promover uma interação maior entre os jogadores do aplicativo.
89
REFERÊNCIAS
ABERNETHY, M. O que exatamente é o Node.js? Disponível

em<http://www.ibm.com/developerworks/br/library/os-nodejs/>
ADAMS, E. Fundamentals of Game Design. Berkeley: New Riders, 2010. 696p.
AVRAM, A. Portando o Angry Birds para HTML5: uma entrevista com Joel Webber, criador
do GWT. Disponível em:<http://www.infoq.com/br/news/2012/02/angry-birds-HTML5>.
Acessado em 11/11/2013.
DENGLER, P. Thoughts on when to use Canvas and SVG. Disponível em<http://blogs.msdn
.com/b/ie/archive/2011/04/22/thoughts-on-when-to-use-canvas-and-svg.aspx>. Acessado em
28/04/2013.
EIS, D. Introdução sobre Media Queries. Disponível em <http://tableless.com.br/introducao-

sobre-media-queries/#.UpNNw8Rtjy8> Acessado em 20/11/2013
FÖRSTER, K; ÖGGL, B. HTML5: Guidelines for Web Developers. Boston: Addison-

Wesley, 2011. 322p.
GARCIA, G. Mercado de games mobile crescerá 10 vezes até 2016. Disponível em <
http://info.abril.com.br/noticias/extras/mercado-de-games-mobile-crescera-10-vezes-ate-
2016-06052013-13.shl >. Acesso em: 16/05/2013
GAZOLA, A. Utilizando meta tags. Disponível em:< https://developer.mozilla.org/pt-

PT/docs/utilizando_meta_tags > Acessado em: 16/05/2013
GODOY, L. Mercado brasileiro de consoles para videogames movimenta cerca de 1 bilhão de

reais em 2012. Disponível emhttp://www.gfk.com/br/news-and-
events/news/paginas/mercado-brasileiro-de-consoles-para-videogames-movimenta-cerca-de-
1-bilh%C3%A3o-de-reais-em-2012.aspx>. Acessado em: 16/05/2013
HINEBAUGH, J. P. A Board Game Education. R&L Education. Nova Iorque: Rowman &
Littlefield, 2009. 188p.
IETF. The application/json Media Type for JavaScript Object Notation (JSON). Disponível
em<http://tools.ietf.org/html/rfc4627> Acessado em 17/11/2013
KOZOVITS, L. E.; FEIJO, B. Arquiteturas para Jogos Massive Multiplayer. Disponivel em<
ftp://139.82.16.194/pub/docs/techreports/03_36_kozovits.pdf >. Acessado em: 09/05/2013
KUBO, M. M. FMMG: um framework para jogos multiplayer móveis.2006. 113 f. Tese

(Doutorado) – Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia
da Computação e Sistemas Digitais, São Paulo. 2006.
90
LANNOY, C. Brasil lidera crecimento do mercado de jogos eletrônicos em 2012. Disponivel

em <g1.globo.com/jornal-da-globo/noticia/2013/05/brasil-lidera-crescimento-do-mercado-de-
jogos-eletronicos-em-2012.html>. Acesso em: 31/05/2012.
LUBBERS, P.; GREGO, F. HTML5 Web Sockets: A Quantum Leap in Scalability for Web.
Disponivel em< http://peterlubbers.ulitzer.com/node/1315473>. Acessado em: 23/05/2013.
ORRICO, A. Mercado Brasileiro de games já é o quarto maior do mundo e deve continuar a

crescer. Disponível em <www1.folha.uol.com.br/tec/1165034-mercado-brasileiro-de-games-
ja-e-o-quarto-maior-do-mundo-e-deve-continuar-a-crescer.shtml>. Acesso em: 31/05/2013
LOPES, S. Tudo que você precisa saber sobre resoluções, telas retina, devicePixelRatio, DPI,
CSS pixels e etc. Disponível em < http://sergiolopes.org/resolucoes-dpi-pixel-ratio-retina/>.
Acessado em 20/11/2013
PEREIRA, R. C. Aplicações web real-time com Node.js. São Paulo: Casa do Código, 2013.
143p.
PEREIRA, R. C. Node.js para leigos - Explorando real-time. Disponível em <

http://udgwebdev.com/node-js-para-leigos-explorando-real-time/> Acessado em: 10/11/2013
PEREIRA, R. C. Node.js para leigos – Introdução. Disponível em: <

http://udgwebdev.com/nodejs-para-leigos-introducao/> Acessado em 14/11/2013.
ROUSE, R. Game design: Theory & Practice. Plano: Wordware Publishing, 2004. 698p.
ROUSSET, D. HTML 5 – O guia completo para criação de jogos HTML 5 com Canvas e
SVG. Disponivel em < http://msdn.microsoft.com/pt-br/library/jj937876.aspx >Acessado em:
19/05/2013
SCHUYTEMA, P. Design de Games: Uma abordagem prática. São Paulo: Cengage Learning,
2008. 472p.
SILVA, M. S. HTML 5: A linguagem de marcação que revolucionou a web. São Paulo:

Novatec Editora Ltda. 2011. 320p.
SPAGNUOLO, S .Mercado de consoles de videogames cresce 43% no Brasil, atinge R$ 1 bi.

Disponivel em <br.reuters.com/article/internetNews/idBRSPE92K06L20130321>. Acesso
em: 31/05/2012
SILVA, A. A história de Counter-Strike – Disponível em: <http://www.techtudo.com.br/jogos
/noticia/2011/08/historia-de-counter-strike.html >. Acesso em: 31/05/2013
SHERIDAN, M. HTML5: Guia do desenvolvedor para o HTML 5 Canvas. Disponível em <

http://msdn.microsoft.com/pt-br/library/dn151487.aspx>. Acessado em 19/05/2013.
UBL, M.; KITAMURA, E. Apresentando WebSockets: Trazendo soquetes para a web.

Disponível em: <http://www.html5rocks.com/pt/tutorials/websockets/basics/>.Acessado em
28/04/2013
W3C. Inline SVG in HTML5 and XHTML. Disponivel em:<http://dev.w3.org/SVG/proposals

91
/svg-html/svg-html-proposal.html>. Acessado em: 18/05/2013
W3SCHOOLS. SVG Introduction. Disponível em:

<http://www.w3schools.com/svg/svg_intro.asp>. Acessado em: 10/12/2013

2013 - 2sem - Fábio Fraga Lameu

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2013 - 2sem - Fábio Fraga Lameu

Hochgeladen von

Copyright:

Verfügbare Formate

Fábio Fraga Lameu

Desenvolvimento de Jogos Multiplayer e Multiplataforma

Trabalho de Conclusão de Curso apresentado ao

Área de Concentração: Engenharia de Software

Orientador: Prof. M.Sc. David Buzatto

São João da Boa Vista

Ficha catalográfica preparada pela Seção de Tratamento

Lameu, Fábio Fraga.

Trabalho de Conclusão de Curso, IFSP, 2013.

1. Jogos I. 2. Multiplataforma. 3. Multiplayer. HTML

Desenvolvimento de Jogos Multiplayer Multiplataforma com HTML 5

Agradeço primeiramente a Deus, que me proporcionou a minha vida, saúde

Lameu, F. F. (2013). Desenvolvimento de jogos multiplayer e multiplataforma usando

Palavras-chave: Jogos. Multiplataforma. Multiplayer. HTML5. Node.js. Socket.IO

Lameu, F. F. (2013). Development of a Multiplatform and Multiplayer Game using

Keywords: Games. Multiplataform. Multiplayer. HTML5. Node.JS. Socket.IO.

1.1 Motivação ............................................................................................................................. 18

1.2 Objetivos ............................................................................................................................... 19

1.3 Organização do Trabalho ...................................................................................................... 19

2 PESQUISA BIBLIOGRÁFICA ....................................................................................... 21

2.1 Considerações Iniciais .......................................................................................................... 21

2.2 Jogos Eletrônicos .................................................................................................................. 21

2.1.1 Design de Jogos Eletrônicos...................................................................................... 22

2.2.1.2 ...................................................................................................................... Produção22

2.2.1.3 ............................................................................................................... Pós-Produção23

2.2.2 Designer de Jogos................................................................................................... 23

2.2.3 Categorias de Jogos ................................................................................................ 24

2.2.3.1 .................................................................................................................... Plataforma24

2.2.3.2 ....................................................................................................................... Interface25

2.2.3.3 ....................................................................................................................... Objetivo27

2.2.3.4 ...................................................................................................Número de Jogadores32

2.3 Jogos Multiplayer ................................................................................................................. 33

2.3.1 Requisitos ............................................................................................................... 33

2.3.2 Componentes dos Jogos Multiplayer ..................................................................... 34

2.3.3 Modelos de Comunicação. ..................................................................................... 35

2.4 HTML 5 ................................................................................................................................ 37

2.4.1 Definição ................................................................................................................ 38

2.4.2 Elementos Gráficos. ............................................................................................... 38

2.4.3 Comunicação .......................................................................................................... 42

2.6 Socket.IO .............................................................................................................................. 51

3.1 O Jogo ................................................................................................................................... 56

3.2 A Arquitetura ........................................................................................................................ 58

3.4 O Cliente ............................................................................................................................... 63

4.1 Gameplay .............................................................................................................................. 77

Além da possibilidade de se jogar on-line entre dispositivos da mesma plataforma, há a

A motivação para o desenvolvimento deste trabalho parte de três aspectos. O primeiro é o

1.3 Organização do Trabalho

2.1 Considerações Iniciais

2.2 Jogos Eletrônicos

2.1.1 Design de Jogos Eletrônicos

A pré-produção é o momento para se criar um conceito para um jogo, neste momento

Na fase de produção o jogo é construído, pois é neste momento que os programadores

entre eles, se o jogo é divertido e se está coerente com o documento de design. No

2.2.2 Designer de Jogos

2.2.3 Categorias de Jogos

Neste trabalho, o conceito de plataforma representa um conjunto composto por hardware

Figura 1 – Call of Duty® Black OPS

Figura 2 – Assassin’s Creed III

Ainda em relação a interface, existe uma terceira classificação chamada de top-down,

Figura 3 – Age of Empires II

Figura 4 – Diablo III

Figura 5 – Batalha Naval

Figura 6 – Formula 1™ 2010