Olá pessoal, como é de conhecimento de todos, há três semanas atrás aconteceu na cidade do Rio de Janeiro, o maior evento sobre desenvolvimento de games do País, o SBGames 2009. Infelizmente, o Abrindo o Jogo não pode participar presencialmente desta edição, fato este que não nos impediu de conferir o que ocorreu por lá. Nesta série de posts, traremos as percepções de profissionais, oriundos de áreas distintas, sobre o evento. Começamos pelo prisma de uma educadora, Maria Isabel Timm, além de uma grande amiga, também a responsável pelo projeto QuimGame e esteve presente na edição deste ano. Vamos conferir …

O SBGames 2009, ocorrido no início de outubro, na PUC do Rio de Janeiro, consolidou a maturidade da produção de jogos educacionais no Brasil, não apenas pela qualidade das apresentações de projetos realizados por desenvolvedores das universidades e do setor privado, na trilha de cultura, mas pela presença oficial da Finep (Financiadora de Projetos), uma agência de fomento à pesquisa e inovação, do Ministério de Ciência e Tecnologia, que nos últimos dois anos financiou 13 projetos de produção de jogos educacionais. Desse conjunto, seis jogos, já finalizados, foram disponibilizados ao público, em um estande da Finep, o que permitiu integração direta com o público e com outros desenvolvedores. Além do estande, a Finep organizou uma mesa redonda, com a participação de representantes desses seis projetos, para que fossem discutidos itens relativos aos desafios de produção, às soluções encontradas, às necessidades futuras e as potencialidades de uso dos jogos educacionais.

Na mesa-redonda, entre outros temas, levantou-se a importância do aprendizado realizado por todas as equipes, que deborda o tema dos jogos, em direção a todas as questões teóricas, técnicas, pedaógicas, práticas e de gestão da tecnologia educacional contemporânea, que inevitavelmente caminha para a qualidade profissional, para a multiplicidade dos enfoques e usos integrados de jogos, vídeos, multimídia e ferramentas de comunicação, em projetos que aliam preocupações de ensino e de motivação dos alunos. Todos os grupos foram unânimes em dizer que a experiência prática do desenvolvimento de um jogo educacional obrigou-os a repensar certezas, exercitar a flexibilidade e, principalmente, buscar soluções inovadoras para dar conta das necessidades de produção, que são múltiplas, incluindo equipes, tecnologias, escolhas, dificuldades, etc.

Com o Edital que financiou o desenvolvimento dos jogos, a Finep conseguiu estabelecer uma massa crítica, dentro das universidades, que hoje consegue planejar e projetar jogos educacionais e seus usos, alguns dos quais estabeleceram uma relação madura e profícua com parceiros empresariais, para garantir a qualidade dos produtos finais, em termos gráficos, de funcionalidade dos sistemas, de jogabilidade e, principalmente, no caso desse tipo de produto, de conteúdo e seus tratamentos, de forma adequada às necessidades pedagógicas e cognitivas dos públicos aos quais se destinam. Este foi o caso do QUIMGAME, jogo desenvolvido por pesquisadores das Universidades Federal do Rio Grande do Sul (UFRGS), Federal de Ciências da Saúde de Porto Alegre (UFCSPA) e Instituto Federal de Educação Tecnológica Sul Rio Grandense (IF-Sul, de Pelotas/RS), com o valiosíssimo apoio da Gestum, empresa desenvolvedora de jogos educacionais, também de Pelotas. Uma das soluções tecnológicas adotadas pelo Quimgame, sugeridas pela Gestum, foi exatamente apostar na portabilidade do jogo, desenvolvido em Flash, para rodar, via internet, através de um LMS (plataforma de gestão de conteúdos, como o Moodle, onde está disponibilizado), sem exigência de placa de vídeo ou de um sistema mais robusto. Além disso, o Quimgame também foi muito bem recebido, porque seu conceito final (definido também com a ajuda da Gestum) foi o de uma plataforma de gestão de conteúdos multimídia, flexível, na qual os professores podem incluir seus materiais (textos, vídeos, animações, questões, etc.) e, futuramente, poderão inclusive criar novos desafios.

Enfim, além da chuva torrencial, que caracterizou esta edição do SBGames e deixou a Cidade Maravilhosa quase irreconhecível, durante os três dias do evento, os jogos educacionais certamente deverão ficar como uma marca do encontro, que já é uma tradição entre os desenvolvedores e amantes de jogos em geral, no Brasil. Infelizmente, a Finep ainda não tem nenhuma indicação concreta de continuidade do fomento, apesar de ter recebido várias sugestões a esse respeito, durante o evento e a mesa-redonta. Foi sugerido, inclusive, um edital de fomento à parceria empresa-universidade, como estratégia de consolidação do mercado de jogos educacionais, que, no Brasil, ainda é incipiente. Mas, por enquanto, não há nenhum indicativo nesse sentido.

Maria Isabel Timm

Olá pessoal, hoje trago a vocês um tema que está recebendo um grande foco, sendo aclamado como a nova onda da indústria de jogos, estou falando dos WebGames ou Browser Games.

O termo define jogos que são disponibilizados através de um navegador, tendo como principal vantagem a facilidade de distribuição e o fato de não exigir uma instalação do software em seu computador.

O que estaria por trás desta nova plataforma? Seria uma tecnologia promissora?

Em 1997 eles surgiram despretenciosos, eram jogos de forca, jogos da velha e da memória. Eram elaborados com a novidade em tecnologia na época, o Javascript. O tempo passou, as linguagens e navegadores evoluiram, com isto, uma nova linha de jogos emergiu,  representando uma nova geração no mercado. Contanto com projetos complexos e muito bem elaborados, os webgames atualmente são superiores a jogos de consoles da 5º geração (Playstation, Nintendo 64).

Uma pesquisa efetuada pela Abragames em 2008, mostra a consolidação deste nicho no Páis.

Pesquisa Abragames 2008

Mesmo reduzindo um pouco seu marketshare em 2008, devido a ascenção da nova geração no páis, o desenvolvimento de WebGames ainda representa o principal foco das empresas nacionais. Posso assegurar que isto não tem nada a ver com uma visão atrasada de nosso País em relação ao resto do mundo, pelo contrário, considero uma visão muito madura e adequada ao mercado.

Os WebGames podem ser organizados em duas categorias básicas, são elas:

1. Browser-based Game - Conhecidos também como Server-side Games, possuem o foco do processamento no servidor, utilizando tecnologias como PHP, ASP, Pearl, Python, Ruby e Java
2. Plugin-based Game- Conhecidos também como Client-side Games, eles utilizam o processamento da máquina cliente através de plugins. Dentre as tecnologias mais importantes estão Java, Unity, Silver Light e Flash Player.

A primeira categoria é representada hoje pelos famosos MMORPG da web. A fórmula de utilizar o navegador apenas como uma view, deixando para os servidores todo o gerenciamento do jogo, tem ganho novos seguidores a cada dia. Alguns exemplos deste metodologia seriam:

• Bite Fight – http://www.bitefight.com.pt
• Ikariam – http://ikariam.com.pt
• Kings Age – http://www.kingsage.com.br

Mesmo com a ascenção e popularidade dos Browser Based Game, considero os jogos baseados em plugins mais promissores e evoluídos. Inclusive, na minha opinião, esta categoria representará logo uma nova era na indústria de games.

Podemos perceber facilmente o poder de processamento dos plugins evoluindo a cada ano. Dentre os disponíveis no mercado, chamo a atenção para o Unity 3D.

Guga Tennis e Gillette Yong Guns - Ambos desenvolvidos pela talentosa empresa gaúcha Aquiris

Porém, toda esta geração de games para a web responde por um nome, FlashPlayer. O plugin da Adobe está presente em 99% dos navegadores do mundo. Sua popularidade é sinônimo de visibilidade e facilidade de distribuição.

É notório que o player ganhou maturidade  com a compra da Macromedia pela Adobe. O mesmo ocorreu com sua linguagem nativa, o Action Script, atualmente na versão 3. Totalmente orietando a objetos, muito similar a Java, a linguagem demonstra estar bem robusta e profissional.

Temos ótimas perspectivas para esta tecnologia, destaco as mais importantes:

• A Adobe durante o MAX 2009, anunciou o Flash CS5, versão que possui como principal novidade a publicação de conteúdos para o IPhone. Com isto, a empresa aumenta ainda mais a portabilidade dos aplicativos desenvolvidos em Flash. O objetivo seria abranger sua tecnologia para os 30 milhões de usuários do Smart Phone da Apple. Além disto, através da Apple Store (agora contando com sua versão brasileira), os desenvolvedores Flash podem oferecer seus games de forma simples e eficiente.

• Vocês já ouviram falar do Open Screen Project? Pois é, ele é um projeto da Adobe com várias outras empresas, entre elas NVidia e Google. Um dos objetivos seria proporcionar aceleração de hardware para o player -  é isto mesmo que vocês estão pensando… 3D de qualidade para a web.

Estamos as vésperas de uma nova era para os web games. O Abrindo o Jogo estará acompanhando e compartilhando tudo sobre a tecnologia Flash aqui com vocês. Da mesma forma que o Alessandro representa a plataforma Java, eu estarei agora representando o Action Script aqui no site. Em breve, os primeiros tutoriais e posts sobre esta promissora tecnologia.

Um grande abraço, e até lá!

Olá pessoal, posso considerar esta, uma semana de várias novidades aqui no Abrindo o Jogo. Ontem tivemos a primeira participação de um leitor, o Luis Otávio, trazendo nosso primeiro tutorial, e hoje, com muita satisfação, dou as boas vindas ao mais novo membro da equipe Abrindo o Jogo – Samuel Salomão – grande amigo que estará representando muito bem o lado artístico da indústria de games.

Vamos juntos acompanhar seu primeiro post.

Olá a todos, em primeiro lugar eu gostaria de agradecer a oportunidade de colaborar com o blog, o foco dos textos que apresentarei serão relacionados a questões visuais dos games e espero que essa experiência de troca de conhecimento contribua para o crescimento de todos nós!

Começarei esse texto com a seguinte provocação: O que nos faz optar por determinado jogo? Os gamers de hoje em dia podem ser considerados consumidores sortudos, pois é muito fácil informar-se sobre determinado título antes de adquiri-lo. É possível analisar reviews, screenshots, trocar idéia sobre games com jogadores de todas as nacionalidades e até mesmo experimentar demos jogáveis, tudo isso graças a internet, mas nem sempre foi assim. Há mais de vinte anos atrás, quando os cartuchos começaram a popularizar-se, quando esse tipo de informação não era tão acessível, como os gamers escolhiam seus títulos?

Nem sempre era possível testar os jogos antes de comprá-los, e é nesse ponto que as labels entram em ação. Para quem nunca ouviu o termo, labels são as etiquetas com ilustrações que são colados nos cartuchos ou estampadas em CD´s e DVD´s, juntamente com as “caixinhas dos games”. Era este o elemento responsável pelo apelo visual aplicado na mídia de distribuição dos jogos para atrair o público. A maior parte dos consumidores, na época, era formado por crianças, afinal, os títulos “adultos” como Burning Desire de 1982 e X-Men de 1983, realmente estavam em menor número. Com esse fator, o uso de belas ilustrações (ou não, como veremos mais adiante) eram importantes para escolha do game a ser comprado. Crianças geralmente são atraídas por elementos coloridos e divertidos ou que de alguma forma se identifiquem, como por exemplo, personagens conhecidos. Em virtude destes pontos, às vezes o consumidor acabava pagando pela ilustração e não pelo jogo.

Para exemplificar esta visão posso citar a versão do cartucho que conheci na época, Superman o  jogo. Lançado para consoles da Atari em 1978, o game apresentava o label com uma ilustração do personagem voando no espaço, no melhor estilo HQ, porém a decepção foi imediata ao jogar o game, uma vez que este era extremamente desinteressante e confuso. Em nenhum momento, o personagem atuava no espaço, como sugeria a etiqueta.

Superman o Jogo (ou quase isto)

Por outro lado havia o efeito inverso, labels muito ruins com jogos interessantes, como por exemplo, Pitfall: um dos clássicos criados para o console da Atari, era vendido aqui com uma terrível ilustração, parecendo mais um jogo do Mogli, o menino-lobo.

Pitfall, o menino-lobo

Este tipo de caso era bastante comum naquela época. Para mim, era claro que a preocupação com a estética do jogo como produto não era relevante para as distribuidoras de jogos, que pareciam acreditar que apenas o software e o fator diversão eram auto-suficientes para a venda dos cartuchos. O resultado disso é uma coleção vergonhosa de ilustrações que até hoje servem de referência para “o que não se deve fazer para vender um produto”.

Acredito que a grande lição disso é que devemos ter sempre claro que o produto final precisa apresentar uma boa aparência, mas ao mesmo tempo, também precisa cativar e ser honesto com o consumidor.

Imagens retiradas de : http://www.atariage.com

Olá pessoal, é com grande prazer que contamos com a primeira participação de um leitor aqui no Abrindo o Jogo. O Luis Otávio nos enviou um tutorial base sobre o Game Maker. Muito interessante para quem quer iniciar no desenvolvimento de jogos de uma maneira fácil e intuitiva. Vamos conferir.

Olá pessoal, meu nome é Luis Otávio e trago este artigo onde mostrarei como começar na programação de jogos usando o Game Maker. O Game Maker é um motor (Engine) desenvolvido para facilitar a criação de jogos de qualquer tipo. Com ele podemos fazer um Pac-Man ou até um Mega Man. Este motor também permite a criação de jogos 3D simples, porém para criar jogos mais complexos, como Age of Empires, você precisará dominar a linguagem do motor, denominada GML (Game Maker Language), não abordada neste meu primeiro tutorial por motivos didáticos.

Inicialmente vocês criarão jogos usando o sistema Drag and Drop (Arraste e Solte) que o Game Maker oferece.

Bom, para começar você precisa fazer o download do programa, ele pode ser baixado no endereço yoyogames.com. A instalação é bem simples, utilize a versão gratuita, apesar de possuir algumas limitações, nos possibilitará fazer jogos bem interessantes. A tela inicial do programa é mostrada abaixo:

Tela Inicial do Game Maker

Eu farei uma rápida introdução sobre a interface do programa, falando apenas sobre o necessário para o entendimento básico do Game Maker.

• Sprites
  • Nesta pasta você colocaráa as imagens dos personagens, itens e qualquer outra imagem que representara algo interativo no jogo.
• Sounds
  • Aqui irá os sons e musicas do jogo.
• Backgrounds
  • Nesta pasta você carregará os fundos de cenários e imagens que não são interativas no jogo, tais como logos, fundos de menus etc.
• Fonts
  • Nesta pasta você poderá colocar as fontes (tipos de letras) que serão usadas em seu jogo.
• Objects
  • Esta é sem duvidas uma das pastas mais importantes, é nela que fica tudo que for interativo no jogo é aqui que fica o funcionamento do jogo.
• Rooms
  • Aqui é onde ficam as salas do jogo, isso pode ser entendido como o local onde ficam a fase, a tela de game over ou a tela de título.

Para adicionar algum dos itens listados acima, você deve clicar com o botão direito sobre a pasta e selecionar Create. Vamos começar por Create Sprite.

Create Sprite

Logo surgirá a tela Sprite Properties (Propriedades do Sprite) como mostra a figura abaixo.

Load Sprite

Por enquanto não entrarei em detalhes sobre as propriedades do sprite, isto será abordado em um outro artigo. Vamos apenas clicar em Load Sprite, abrirá então uma janela de seleção de arquivos, selecione uma imagem qualquer para representar um personagem do jogo. Após selecionada a imagem, clique em ok. Repita o processo para selecionar um sprite que represente um obstáculo em nosso jogo, pode ser um cubo ou qualquer imagem que você preferir. Se você fez tudo certinho, veremos uma tela como a demonstrada abaixo.

Create Object

Por enquanto estes sprites não são nada além de imagens, ou seja, eles ainda não representam nada dentro do jogo, são apenas imagens que serão enviadas para a memória assim que o jogo iniciar. Para dar vida a nosso personagem, devemos criar um novo Object, utilizando o mesmo procedimento anterior, um clique com o botão direito sobre a pasta Objects. Ao selecionar Create Object, a janela abaixo será apresentada.

Propriedades do Objeto

Na janela de propriedades do objeto, você pode perceber que existem vários botões e abas, mas não se assuste, não será necessários ver todos eles neste momento. Bom, seguindo com a criação do personagem, na janela de propriedades do objeto, clique no botão na parte superior esquerda, referente a Sprite (marcado com um círculo verde), em seguida, selecione o que corresponde ao personagem. Agora temos um objeto com aparência, porém sem ação alguma. Para inserir movimento em nosso personagem, devemos clicar no botão Add Event, destacado na imagem acima com um círculo vermelho. As opções de ações serão apresentadas em uma nova janela, demonstrada abaixo.

Seletor de Eventos

Novamente não se assuste com a quantidade de ações, vamos nos deter apenas na opção Keyboard. Com isto, estaremos adicionando um evento que verificará se uma respectiva tecla está sendo pressionada. Quando você clicar no botão keyboard surgirá uma lista de teclas que podem ser verificadas, como na imagem abaixo.

Lista de Teclas

Selecione a opção <Left> (seta para a esquerda), desta forma, você adiciona um evento que ouvirá quando tecla for pressionada. Agora devemos vincular uma ação a este evento. Para isto, observe no canto superior direito da janela propriedades do objeto, na área que corresponde a movimento (Move), o primeiro botão (destacado em vermelho). Arraste-o para a parte em branco, correspondente a actions, marcada com um retângulo vermelho na figura abaixo.

Propriedades do Objeto

Assim que você soltar a ação selecionada, surgirá uma janela como a mostrada na imagem abaixo.

Move Fixed

Esta janela correspondente a ação Move Fixed. Esta ação faz com que o objeto se mova na direção e velocidade definidas nos campos correspondentes.

A próxima etapa será criar uma sala para testar o nosso objeto. Clique na pasta Rooms com o botão direito e selecione Create Room para criar uma nova sala, acionando a janela Room Properties, como demonstrado na imagem abaixo.

Create Room

Na janela propriedades da Room, você pode visualizar várias abas na parte superior esquerda, mas não entrarei em detalhes sobre todas, apenas a Objects. Clique no botão destacado para selecionar o objeto atual que será adicionado a sala. O próximo passo será adicionar seu personagem no mapa, para isto clique com o mouse sobre o local desejado na grade. Pronto, agora é só testar!

Para publicar/compilar seu jogos, basta clicar no botão de play verde na parte superior da interface.

Publicar/Compilar seu jogo

Assim que seu pseudo jogo começar, você poderá teclar seta para a esquerda e perceber o personagem movendo-se. Caso ocorra algum problema, revise o artigo até esta etapa. Se tudo funcionar direitinho, é horas de exercitar um pouco, faça seu personagem se movimentar também para as direções Direita <Right>, Cima <Up> e Baixo <Down>.

Conseguiu? Então vamos adicionar agora algum obstáculo para o personagem, clique com o botão direito sobre a pasta Objects e crie um novo objeto, marque-o para usar o Sprite correspondente ao obstáculo. Desta vez , marque a opção Solid , isso fará com que o objeto seja sólido.

Propriedades do Objeto Obstáculo

Apesar de estar marcado como sólido, o objeto ainda não representa um obstáculo para o personagem, isto ocorre porque não há ninguém detectando (ouvindo) a colisão. Sendo assim, precisamos adicionar um evento que verifica se objetos colidiram. Para isto, abra novamente seu personagem, adicione um novo evento clicando em Add Event e selecione Collision. Como demonstrado na imagem abaixo, surgirá uma lista com os objetos, marque o object1, referente ao obstáculo.

Adicionando Colisão

Após o evento de colisão ser adicionado, temos que vincular uma ação a ele. O processo será bem similar aos anteriores, porém ao invés de selecionar uma direção, você deve clicar no centro do direcional, além de configurar a velocidade para zero, observe na imagem abaixo.

Colisão com o obstáculo

Com isso você já tem um ambiente bem simples, monte um pequeno cenário, com o personagem no centro e vários obstáculos para experimentar. Após a sala criada, é só clicar no play para ver o resultado.

Bom, por enquanto é só, tente fazer outras modificações em seu pseudo jogo e vá tentando entendê-lo aos poucos, não tente fazer coisas muito complicadas sem primeiro entender o simples. Se você pretende ser um desenvolvedor de jogos, precisará aprender que só se pode passar para coisas mais complexas quando as simples estiverem completamente dominadas, falando em linguagem de games, jogue primeiro no Easy para depois experimentar o Hard .

Um grande abraço a todos do Abrindo o Jogo.

Luis Otávio

Threads são partes de um programa que executam paralelamente. Com seu uso é possível executar simultâneamente duas ou mais rotinas. Atualmente, com o barateamento dos processadores de vários núcleos (multi core), seu uso fica mais justificado. Embora eu não recomende trabalhar com threads, convém entender o que elas representam na prática.

Antes de tudo vou ressaltar: não recomendo trabalhar com threads a menos que seja o desenvolvimento de um jogo AAA, o qual não é foco deste site (digamos um Batman: Asilo Arkhan). Jogos assim, exigem intenso processamento de I.A., física e gráficos e possuem, em geral, muito dinheiro para serem feito. Isso justifica a utilização de uma forma de programação mais complexa. Ainda mais que estes jogos em geral são criados em C++, uma das piores linguagens para trabalhar com threads. Mesmo no Java, cujo uso é relativamente simples (como veremos abaixo), depurar um programa com thread é um inferno.

Além disso, projetar o código para tirar proveito de threads é tarefa para arquitetos competentes – caso contrário você vai criar um código complexo, difícil de depurar e manter e, provavelmente, vai cair em dead locks e outros problemas de concorrência . E ainda corre o risco de acabar com um código pouco eficiente, apesar do esforço adicional.

Fica então o aviso: o código abaixo serve para efeito de exemplo e não deve ser base para um jogo do mundo real.

Bom, se depois do que foi dito acima você ainda não desistiu de ler sobre threads, vamos em frente – o fato é que o conceito por trás delas, e sua correta utilização, são importantes para tirar todo proveito de uma CPU com múltiplos núcleos. Vamos ver como fazer isso com o gameloop desenvolvidos nos meus artigos anteriores. Se você não leu, filtre os posts pela tag Java e leia-os antes, ok?

Modularizando o jogo

Começo criando duas classes especializadas em atualizar a lógica do jogo (lembra do update?) e em atualizar a tela (lembra do render?). Chamarei elas de Controlador e Renderizador, respectivamente. Seu código está abaixo. Basicamente, eu tirei as rotinas update() e render() da minha classe do jogo e coloquei em classes separadas.

Arquivo Controlador.java

001package abrindoojogo.exemplos.thread;
002
003import javax.swing.JFrame;
004
005public class Controlador
006{
007    Contador contador;
008    JFrame frame;
009    Nave nave;
010
011    public Controlador(JFrame frame, Contador contador, Nave nave)
012    {
013        this.frame = frame;
014        this.contador = contador;
015        this.nave = nave;
016    }
017
018    public void update()
019    {
020        contador.contaPulso();
021        nave.x += 1;
022        if (nave.x > frame.getWidth() + 30)
023        {
024            nave.x = 0;
025        }
026    }
027}

Arquivo Renderizador.java

001package abrindoojogo.exemplos.thread;
002
003import java.awt.Color;
004import java.awt.Graphics2D;
005import java.awt.image.BufferStrategy;
006import javax.swing.JFrame;
007
008public class Renderizador
009{
010    BufferStrategy bs;
011    Contador contador;
012    JFrame frame;
013    Nave nave;
014    public boolean terminado = false;
015
016    public Renderizador(JFrame frame, BufferStrategy bs,
017                        Contador contador, Nave nave)
018    {
019        this.frame = frame;
020        this.bs = bs;
021        this.contador = contador;
022        this.nave = nave;
023    }
024
025    public void render()
026    {
027        contador.contaFrame();
028        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
029        g.setColor(Color.black);
030        g.fillRect(0, 0, frame.getWidth(), frame.getHeight());
031        int x = nave.x;
032        int y = nave.y;
033        for (int i = 0; i < nave.qtd; i++)
034        {
035            g.setColor(Color.yellow);
036            g.drawLine(x, y, x - 20, y - 5);
037            g.drawLine(x, y, x - 20, y + 5);
038            g.drawLine(x - 20, y - 5, x - 20, y + 5);
039            y += 15;
040            if (y > 550)
041            {
042                y = nave.y;
043                x += 15;
044            }
045        }
046        g.setColor(Color.white);
047        g.drawString("Pulsos: " + contador.getPulsosPorSegundo() +
048                     "  Frames: " + contador.getFramesPorSegundo() +
049                     "          naves: " + nave.qtd, 10, 20);
050        g.dispose();
051        bs.show();
052    }
053}

Veja que essas classes recebem “de fora”, no momento de sua construção, os objetos necessários para seu funcionamento. Ou seja, elas não possuem dados próprios, encapsulando apenas o algoritmo. Para que elas compartilhem os mesmos dados, criei também uma classe separada para armazenar os dados da nave:

Arquivo Nave.java

001package abrindoojogo.exemplos.thread;
002
003public class Nave
004{
005    int x;
006    int y;
007    int qtd;
008}

A classe do jogo em sí é exatamente igual à classe JogoLoopSimples vista em um artigo anterior, só que sem update() e sem render() e com o gameloop modificado conforme abaixo:

001public void gameloop()
002    {
003        initialize();
004        Controlador c = new Controlador(this, contador, nave);
005        Renderizador r = new Renderizador(this, bs, contador, nave);
006        while (true)
007        {
008            c.update();
009            r.render();
010        }
011    }

Além disso, mais uma pequena modificação: ao sair do programa (pressionar ESC), envio para o console os dados de pulsos e frames, para registro. Isso é feito com um System.out.println() chamado na rotina keyPressed():

001public void keyPressed(KeyEvent e)
002    {
003        if (e.getKeyCode() == KeyEvent.VK_ESCAPE)
004        {
005            System.out.println("Pulsos: " + contador.getPulsosPorSegundo() +
006                                "  Frames: " + contador.getFramesPorSegundo() +
007                                "          naves: " + nave.qtd);
008            System.exit(0);
009        }
010        ...

Executando o programa assim, temos o seguinte resultado:

Reconhece a tela? É o mesmo protótipo da nave dos outros posts. Mas perai… Uau! 460 fps! Não eram apenas 40! Como foi que ficou mais rápido?

Simples: troquei de máquina… Veja: essa é uma máquina bem mais rápida e tem um processador de dois núcleos como podemos ver no painel do gerenciador de tarefas. Note outra coisa também: apesar do jogo estar programado de forma a rodar o mais rápido possível (sem limitação de pulsos), ele utiliza apenas 50% do processamento da máquina. Nos gráficos pode-se ver claramente que o jogo está ocupando praticamente todo núcleo da esquerda, enquanto o da direita está ocioso (quase ocioso, na verdade, está atendendo o S.O. e processos de fundo, como o antivirus).

Abaixo da tela está a saída do console do NetBeans, mostrando o número de pulsos e frames registrados ao fechar o programa.

A soma das partes

Modifiquemos agora nosso gameloop comentando o update(). Assim vamos ver quantos frames conseguimos se eliminarmos o trabalho de atualizar a lógica do jogo.

A saída é a seguinte:

Veja que temos zero pulsos, já que update() nunca foi executada. Mas a quantidade de frames não mudou. Ou seja, o impacto de processamento da nossa lógica é muito pequeno. Vejamos o contrário. Vamos comentar o render().

Resultado abaixo:

Pois é, sem o render() não aparece a tela. Mas o programa está lá, rodando, como podemos ver pelo processamento. Ao pressionar ESC basta olhar para a saída para ver a quantidade de pulsos e… Caraca! Mais de três milhões e meio de pulsos por segundo! Realmente, a parte (bem) mais pesada é a atualização da tela. A atualização da lógica (nesse caso, pelo menos) é tão efêmera que esse computador consegue realizar mais de 3.000.000 em um segundos contra apenas 460 atualizações da tela no mesmo tempo.

Analisando os resultados, entram as Threads

A primeira coisa importante é ver como o render() segura o jogo quando usamos esse tipo de gameloop, que é o mais simples. A cada volta do laço temos um update() (muito rápido) e um render(), que demora e faz com que o próximo update() acabe demorando a ser executado.

Mas o que conta para este post é o seguinte: reveja as imagens acima e preste atenção no processamento. Ele nunca passa de 50%. Ou seja, meu jogo não está tirando tudo da minha máquina nova! Praticamente ele só usa o núcleo da esquerda, enquanto o outro fica com pouco processamento, oriundo das tarefas do sistema. Isso é bom, na verdade. Mas e se eu precisasse de mais processamento? Teria uma forma de usar o outro núcleo? Tem sim, com threads.

Você sabe que o S.O. é multitarefa, ou seja, executa vários programas ao mesmo tempo. Você pode ver um vídeo e ouvir música ao mesmo simultâneamente, porque o S.O dá um pouco de processador para o vídeo e um pouco para a música. É a mesma CPU, porém dividida entre dois programas.

Se tem mais de uma CPU (mais de um núcleo, como na máquina acima), o S.O. pode dar um núcleo inteiro para o vídeo e o outro núcleo para a música, ao invés de dividir a mesma CPU. Isso torna as coisas mais ágeis ainda.

As threads permitem ter esta multitarefa dentro do mesmo programa. Por exemplo, você cria uma thread para carregar os dados do jogo e outra para rodar uma animação. Assim, o S.O. dá um pouco de processamento para cada uma, e o resultado é que você pode mostrar uma animação enquanto os dados são carregados.

A modificação que faço a seguir no código vai permitir colocar o Controlador em uma thread e o Renderizador em outra, de forma a executarem paralelamente e, de quebra, rodar cada um em um núcleo, utilizando todo o poder da máquina. Se o render() sozinho dá 460 frames e update(), também sozinho, dá 3.000.000, agora deverei obter o jogo rodando simultâneamente com 3.000.000 pulsos e 460 frames.

Vamos ver se funciona:

001public class Controlador implements Runnable
002{
003    Contador contador;
004    JFrame frame;
005    Nave nave;
006
007    public Controlador(JFrame frame, Contador contador, Nave nave)
008    {
009        this.frame = frame;
010        this.contador = contador;
011        this.nave = nave;
012    }
013
014    public void run()
015    {
016        while (true)
017        {
018            Thread.yield();
019            update();
020        }
021    }
022
023    public void update()
024    {
025        ...
026
027public class Renderizador implements Runnable
028{
029    BufferStrategy bs;
030    Contador contador;
031    JFrame frame;
032    Nave nave;
033    public boolean terminado = false;
034
035    public Renderizador(JFrame frame, BufferStrategy bs, Contador contador, Nave nave)
036    {
037        this.frame = frame;
038        this.bs = bs;
039        this.contador = contador;
040        this.nave = nave;
041    }
042
043    public void run()
044    {
045        while (!terminado)
046        {
047            Thread.yield();
048            render();
049        }
050    }
051
052    public void render()
053    {
054        ...

Modifiquei o código das classes Controlador e Renderizador para que implementem a interface Runnable do Java. Para isso, também declarei o método run() e dentro dele coloquei um laço. O Renderizador tem um laço que fica chamando render(). O Controlador tem um laço que fica chamando o update().

Agora a modificação no gameloop:

001public void gameloop()
002    {
003        initialize();
004        Controlador c = new Controlador(this, contador, nave);
005        Renderizador r = new Renderizador(this, bs, contador, nave);
006        Thread t;
007        t = new Thread(c);
008        t.start();
009        t = new Thread(r);
010        t.start();
011    }

Aqui está o uso das threads, finalmente. Basta criar um objeto do tipo Thread informando para ele um objeto do tipo Runnable (o Renderizador, por exemplo). Depois chamamos o método start() da thread e ela vai chamar o método run() do objeto que lhe foi passado. O método run() será executado em paralelo ao resto do programa. Então, estamos colocando o laço do render() e o laço do update() para rodarem em paralelo.

Curioso para ver o resutado? Está abaixo:

Voilá! Um milhão e oitocentos mil pulsos e 459 frames. E usado 100% da CPU. Veja que agora os dois núcleos estão absolutamente carregados – a linha do gráfico está “cravada” no topo.

Mas porque deu valores menores do que quando rodamos cada um separadamente? Bom, é que a CPU ainda precisa atender os tais processos de fundo, S.O., antivirus, etc. Eles devem estar rodando no mesmo núcleo do update(), o que fez ele executar mais lentamente. Mas foi uma boa escolha do S.O., já que esse é o processo mais leve. Inteligentes estas máquinas modernas, não?

De qualquer forma, é um desempenho muito acima da primeira versão que eu mostrei.

Conclusão

Não usem threads.

Pelo menos não até chegar a um ponto onde não tenha mais o quê otimizar no código de vocês e ainda assim o jogo esteja lento. Uma minoria de jogos atuais faz uso intensivo de threads (menos de 20, pelo que sei), e todos especialistas concordam que não é fácil.

O que fiz no código acima, compartilhar um objeto (a nave) entre duas threads rodando paralelamente é perigoso. Nesse caso uma delas atualiza os dados e a outra apenas lê. Mas se duas threads atualizarem os mesmos dados ao mesmo tempo, as consequencias serão imprevisíveis. O Java facilita porque possui formas de sincronizar dados, impedindo sua leitura simultaneamente por duas threads. Mas não adianta sincronizar tudo, senão uma thread vai acabar esperando pela outra para poder acessar os dados e vão acabar rodando em sequencia, ao invés de em paralelo.

Por outro lado, o Java, por sí,  já tira proveito de processadores de múltiplos núcleos. Existem outros processos que a máquina virtual faz, como coleta de lixo e otimização interativa do código. A JVM (Máquina Virtual Java) faz uso de threads para separar e rodar em paralelo estas operações, melhorando o desempenhdo do seu programa sem você ter que fazer nada.

Bom, fica aí um exemplo de uso de threads para quem não conhecia.

Jogos Educacionais sempre foram sinônimo de aplicativos  simples e voltados para o público infantil. Mesmo fora de nosso País, existem pouquíssimos projetos que ajudam a contrariar este conceito, ou preconceito. Mas quais seriam os fatores que contribuem para que jogos educacionais não sejam maduros, divertidos e desafiantes?

Em 2008 eu tive a oportunidade de participar de uma equipe que ajudou a mudar este conceito. Através de uma excelente parceria entre Gestum – Tecnologia Educacional, professores/técnicos da Universidade Federal do Rio Grande do Sul (UFRGS), Universidade Federal de Ciências da Saúde de Porto Alegre (UFCSPA) e Instituto Federal Sul Riograndense de Pelotas, em julho deste ano foi apresentado à FINEP o produto final de um dos projetos produzidos para atender a um Edital de fomento a jogos educacionais. Trata-se do Química Aplicada, jogo que será utilizado para motivar os alunos do ensino médio a estudar Química Orgânica. Com isso, embora não fosse um objetivo do edital, consolidou-se uma parceria integrando empresa e universidade, a qual deverá ter continuidade em outros projetos.

O Game narra as aventuras e desafios de um repórter, que recebe informações sobre uma grande explosão em uma ilha, ao sul do Brasil. Mostra a pauta a seu editor chefe, o qual identifica as coordenadas como o local onde ocorrem pesquisas com Química Orgânica. Será que houve algum acidente? Será que há risco de contaminação ambiental na região? Será que haverá novas explosões? No percurso do jogo, o personagem deverá enfrentar vários desafios na ilha, entre eles: resolver uma emergência química no laboratório destruído; utilizar vários itens como um palmtop e um maçarico; passar por labirintos protegidas por sistemas de segurança; e até descobrir a combinação de combustíveis necessários para mover uma lancha e abandonar a ilha.

Chegada do repórter na ilha

O professor Eric Klopfer, do MIT, conta que os críticos dos games educacionais costumam chamá-los de brócolis cobertos de chocolate. A este respeito, a equipe de coordenação do Química Aplicada considera que um dos principais diferenciais deste jogo é exatamente a busca do equilíbrio entre a jogabilidade (o chocolate) e as exigências do conteúdo educacional (o brócolis). O fator mais trabalhado no Projeto de Jogo foi a forma como o conteúdo seria entregue ao aluno. Normalmente jogos educacionais deixam este evento bastante explícito, quebrando o ritmo do jogo. O segredo foi criarmos um contexto envolvendo o conteúdo, tornando-o parte da narrativa.

O conhecimento de química é exigido em vários pontos do game.

“A participação da Gestum foi fundamental, garantindo a qualidade gráfica e a fluência do game, de forma envolvente e motivadora para o aluno, que realmente joga com gosto enquanto pesquisa os conteúdos de química, para resolver os desafios.” Comenta Maria Isabel Timm, Dra. em Informática na Educação pela UFRGS e principal responsável pelo projeto.

Outro fator que considero um grande diferencial do projeto, foi a autonomia dada ao professor. O docente, através de arquivos XML, pode configurar os puzzles, enredo, conteúdo e até o desfecho da história. Esta funcionalidade visa adequar o aplicativo a forma como cada professor organiza seu conteúdo na sala de aula.

Todos os puzzles possuem um contexto, o aluno quase não percebe que está aprendendo.

Uma versão-piloto do jogo já está sendo aplicada com alunos da rede pública e privada do RS, com acesso via Internet. O jogo foi adequado ao padrão SCORM, para ser acessado através de qualquer LMS (Learning Management System), e tem total flexibilidade para futuros professores modificarem ou acrescentarem material de apoio, questões e outros desafios, adequando desta forma o game a várias possibilidades de aplicação em sala de aula.

Interessados em acessar e conhecer o jogo podem fazer contato com os coordenadores do projeto, através dos e-mails:

Olá leitores do Abrindo o Jogo, mesmo finalizando recentemente o post sobre as oportunidades do mercado nacional, achei muito apropriado continuar o assunto e comentar um pouco sobre os vencedores do programa BRGames 2009, iniciativa do governo federal para fomentar a indústria nacional. Considero este programa um dos mais importantes em vigor, a cada ano ele se mostra mais maduro e competitivo. Desta forma, considero importante entender um pouco os critérios da mesa avaliadora para o próximo ano.

Primeiramente vamos rever os vencedores, a lista foi publicada no site do programa e conta com 3 empresas estruturadas e 7 produtores independentes.

Empresas estruturadas:

1. “Night Life” – Overplay Entretenimento Digital Ltda.
2. “Robô Sucata” – 44 Bico Largo Comercial Ltda.
3. “Esther Art Gallery” – Interama Jogos Eletrônicos

Pessoas físicas:

1. “Chameleon” – Philip Sciangula Berick Mangione
2. “Dragon vs Heroes” – Tiago Monteiro Fernandes
3. “Freestyle” – Leonardo Henrique Muniz Arantes
4. “Lumaki” – Guilherme Bischoff Lopes Fonseca
5. “Luna” – Saulo Camarotti Rayol Braga
6. “O Mutualismo” – Paulo Estevão Biagioni
7. “Vovó a Solta” – Raphael Fernandes Marques

Os projetos de pessoas físicas recebem R$ 70 mil cada um, já as empresas, ganharam um contrato de co-produção de R$ 140 mil (sendo que R$ 28 mil serão investidos pela própria companhia). O recebimento da premiação está vinculado à participação obrigatória do autor, ou um representante da empresa, na “Oficina para Desenvolvimento de Projetos de Jogos Eletrônicos”.

Vamos conhecer um pouco sobre cada um dos projetos:

1.Night Life

Gerenciador de baladas que mistura elementos de “Theme Hospital” e “The Sims”. Criado pela Overplay, que já produziu títulos para Nintendo DS, permite criar casas noturnas que atraem pessoas de diversos tipos, cada uma com personalidades únicas.

2.Robô Sucata

Aventura 3D em que se deve montar máquinas para combater alienígenas. Produzida pelo estúdio 44 Bico Largo, traz de volta o herói Gustavinho, que estrelou o game “Enigma da Esfinge”, de 1996.

3.Esther Art Gallery

Jogo de ação no qual o objetivo é ajudar a garota Esther a reconstruir a galeria de arte do tio-avô e resgatar o prestígio que tinha em outros tempos. Game produzido pela Interama, responsável também pelo recente “Guitar Idol”, para Mega Drive.

4.Mutualismo

Comande a dupla Speero e Geera com teclado, mouse, microfone e outros tipos de controle e ajude-os a se tornarem deuses. Partes da aventura envolvem viagens no tempo, já que será necessário visitar o futuro para entender exatamente o que fazer no presente.

5.Freestyle Challenge

Realize o sonho de se tornar o maior jogador de futebol urbano desafiando outros times da vizinhança. Conforme enfrenta equipes, seu atleta melhora atributos e adquire novas habilidades com a bola.

6.Vovó a Solta

O herói é um militar traumatizado dos conflitos de gerra. Assim, ele protege uma doce senhora a qualquer custo de todo tipo de perigo – como prêmio ele recebe biscoitos no final da tarde.

7.Dragon vs. Heroes

Assuma o papel de um dragão que deve montar armadilhas em uma torre e impedir que os heróis salvem as princesas. Quanto mais donzelas tiver em cárcere, mais heróis a criatura atrai e assim tem mais oportunidades de juntar tesouros.

8.Lumaki

Crie criaturas e treine-as em minigames para depois competir em combates. As habilidades dos Lumakis podem ser melhoradas por meio de minigames de diversos tipos. O projeto do game almeja versões para iPhone, Xbox Live Arcade, PlayStation Network e WiiWare.

9.Chameleon

Controle um casal de camaleões por uma pista enquanto coleta cristais e resolve quebra-cabeças. A aventura conta com visual tridimensional e a mecânica exige que se controle as duas criaturas ao mesmo tempo.

10.Luna

Aventura clássica com visual 3D estrelada por uma menina em um mundo virtual. Após ter o computador hackeado, a garota Luna, de 13 anos, encarna um avatar digital capaz de manipular campos magnéticos e parte em uma jornada para resolver o problema.

Conclusão

Consigo enxergar uma grande evolução das propostas em relação aos anos anteriores (confira aqui). As empresas nacionais estão começando a enxergar o caminho certo, esquecendo um pouco de tentar criar um novo World of WarCraft, e criando propostas mais adequadas a nossa realidade. Um mercado estável se constrói aos poucos, com bons alicerces. Na minha opinião uma boa empresa não pode pensar em um game AAA antes de experimentar fazer bons jogos para celular, web ou portáteis. Até onde foi possível interpretar, os critérios da mesa avaliadora estariam alinhados com este pensamento.

Confesso que gostei mais dos projetos independentes. Destacaria Mutualismo, Dragon vs Heroes e Luna como os mais inovadores e criativos. Resta saber se o pessoal vai desempenhar um bom papel também no desenvolvimento do projeto. Ficamos todos na torcida e na espera dos Demos.

E vocês, o que acharam dos projetos?

Olá pessoal do Abrindo o Jogo,  com tudo que já comentamos sobre o tema nas partes 1 e 2, será que alguém se animaria a responder a pergunta que intitula este extenso artigo? Você já saberia a resposta? Não? Então vamos analisar a última parte, que apresenta as seções finais do documento de projeto, e tirar a conclusão juntos.

8 Diagramas de Progresso

Criar um fluxograma para mostrar o progresso do jogador no game. Este tipo de diagrama serve como um mapa não linear para uma narrativa. A imagem abaixo apresenta o mapa do game Ultima VII (1992 Origin Systems), é possível perceber as diferentes decisões a serem tomadas pelo jogador durante sua jornada.

Fluxograma - Ultima VII

O gráfico de progresso também pode ser aplicado para jogos em turnos, descrevendo detalhadamente as atividades de cada fase.

Storyboards

Para jogos com cutscenes e cinematics, identifique estas cenas no diagrama, inserindo material adicional na forma de storybords e scripts. Uma ótima referencia seria o livro Don Bluth’s The Art of Storyboard [Bluth and Goldman 04].

9 Direção de Arte

A seção de direção de arte é a combinação de textos descritivos e imagens que transmitem o estilo gráfico do jogo. Ela normalmente inclui concepções (como da figura abaixo), referência de artes de livros, instruções de uso da luz em jogos 3D, exemplo de fonts e até limitações definidas pela tecnologia atual.

Concepções de arte de Fable 2

10 Storyboards de Interface do Usuário

Para um jogo de computador, a interface do usuário é o instalador, a tela de título, menus, diálogos, HUD (Head Up Display) e qualquer outro controle ou texto. Cada um destes, deve ser devidamente projetado através de textos e um storyboard gráfico. Storyboards podem ser simples esboços que mostram os elementos da GUI (Graphic User Interface), com rótulos indicando a funcionalidade de cada elemento. Fluxogramas são necessários para descrever cada interação do jogador e a resposta do jogo para esta ação.

Storyboard de um webgame

11 Arquitetura de Software

Video games necessitam de um projeto de software complexo. Nesta seção, os documentos de arquitetura descrevem as funcionalidades de cada módulo de programação. Isto inclui o uso de APIS e algoritmos que serão usados para implementá-los, além dos padrões de projetos envolvidos na produção. Esta seção contará com vários diagramas, entre eles: diagramas de classes, diagrama de sequência, diagrama de fluxo, e o já conhecido diagrama de módulos de sistema. Observe abaixo alguns exemplos.

Diagrama de Classes

Diagrama de Sistema

Obviamente este post não destina-se a explicar como funciona cada um dos diagramas, porém outros post virão com esta finalidade.

12 Controles

Video games dependem de seus esquemas de controle. Um grande jogo pode ser um fracasso se a mecânica de entrada estiver inadequada ou destinada a um público-alvo que não é o mesmo de seu projeto. A seção Controles detalha ambos, o mapeamento dos botões para as funções do jogo e o mapeamento dos algoritmos de entrada para as ações.

13 Projeto de Níveis (Level Design)

A maioria dos games são divididos em níveis que representam uma evolução, além de uma discreta mudança na dificuldade. Um exemplo bem que isto está presente desde o início da era do videogames, seria as diferente ondas de aliens em Space Invaders. Estes níveis também podem ser representados por novos mapas ou cenários. Em jogos clássicos, como Xadrez, níveis são um tanto vagos (embora podemos considerar a abertura, meio e fim como etapas distintas).

Em jogos com uma forte progressão linear, níveis são normalmente áreas em grandes mundos.  Já para jogos com níveis baseados em locações, você deve criar um mapa para mostrar o layout e conectividade do nível. Indicando encontros, locais com itens e objetivos. Para isto, utilize os gráficos de progresso da seção anterior

Esta seção em resumo deve preocupar-se em deixar o jogo equilibrado e desafiante. Atualmente é bastante comum encontrarmos editores específicos para esta finalidade, permitindo que um profissional focado nesta área, com pouco conhecimento de programação, possa ter total autonomia para definir cada nível do game. Uma prova que esta tarefa, além de complexa, é muito divertida, seriam os jogos que permitem o próprio jogador assumir este papel.

Little Big Planet - Game que tem em sua essência a construção de níveis.

14 Análise da Mecânica

O coração deste documento é a seção de Análise da Mecânica. Ela é igualmente importante para video games, jogos de tabuleiro, títulos AAA, jogos independentes ou projetos escolares.

Mecânicas de jogo são pequenos grupos de regras que definem um conflito estratégico, inspiram uma emoção em particular no jogador, além de definirem o avanço no jogo. Acredito que alguns exemplos ajudaram a entender melhor.

Racing (Corrida) é uma mecânica clássica. Alcance a linha de chegada antes de seus oponentes. Esta mecânica coloca uma pressão de tempo no jogador, criando stress e motivação. Isto é equilibrado e justo; a escala de sucesso é definida pela relação entre o corredor mais lento e o mais rápido. Esta mecânica não consiste exatamente em carros e uma pista. Por exemplo, em um jogo de “capturar a bandeira”, a mecânica de Racing começa assim que um bandeira for pega, a partir deste ponto, ambos os lados tentarão alcançar o objetivo (ou interceptar quem pegou a bandeira) o mais rápido possível.

Shooting (Tiroteio) é uma mecânica ainda mais popular no mundo dos games. Ela envolve ações de reflexo, estratégia para atingir os inimigos e liderança quando sua equipe estiver sob fogo serrado. Shooting não necessariamente envolve armas de fogo. Vários jogos utilizam esta mecânica para atirar um personagem de uma bala de canhão, tirar fotos da vida selvagem ou arremessar e pegar uma bola.

Descreva a mecânica do seu jogo com o maior número de detalhes, mas saiba que provavelmente, ela já exista em algum outro jogo. Por este motivo, registre outros que possuam uma mecânica similar a sua, destacando as diferenças. É importante também descrever a razão de jogo de cada uma delas. Defina linhas guia para tornar a mecânica equilibrada e útil para a jogabilidade. Fundamente estes argumentos em texto, gráficos e diagramas.

Eu costumo utilizar muito a ferramenta Microsoft Excel para validar a base das mecânicas que crio. Mesmo para jogos um pouco mais complexos, a ferramenta se mostra muito útil, e com um pouquinho de “programação” é possível montar planilhas bem complexas e úteis. Fica a dica

15 Cronograma

Esta é a seção do documento onde você deve demonstrar maturidade e capacidade de gerenciamento. Aqui, é necessário traçar um cronograma bem planejado e confiável para seu projeto. Mesmo fazendo parte de uma equipe pequena, é importante demonstrar organização e uma boa gestão.

Agenda Mestre

A agenda de desenvolvimento mestre descreve o plano para produzir o jogo em dias. Ela é dividida em releases de protótipo e milestones, que por sua vez, são divididas em tarefas individuais para os desenvolvedores. Milestones descrevem quais e quando determinadas funcionalidades, e experiências de jogo, estarão disponíveis. Sua periodicidade pode variar entre semanas, meses ou até anos, dependendo da complexidade do jogo.

As tarefas devem ser interdependentes e expostas através de um gráfico de Gantt, com isto será possível analisar as consequências de um pequeno atraso durante o desenvolvimento. Para isto, a ferramenta mais conhecida seria o Microsoft Project, porém existem várias opções gratuitas no mercado, dentre eles destacaria o Dot Project.

Planejamento de pessoas

Para um game comercial, o planejamento de pessoas descreve como e quantos desenvolvedores serão contratos para atender as demandas do projeto, respeitando o cronograma de entrega. Isto pode ser descrito também com milestones indicando pontos do projeto onde determinado tipo de profissional é necessário. Aqui é sensato contemplar carga horária para contratações, entrevistas e principalmente treinamento. Obviamente este planejamento não se aplica tanto para equipes independentes ou projetos escolares.

Desenvolvedores Chave

Descreva as qualificações dos líderes de equipe, produtores e gerentes. Estas serão as pessoas que farão a gestão, tendo a responsabilidade de entregar um produto de qualidade e no prazo estipulado. Registre a formação, experiência, competências e publicações de toda a equipe.

Na indústria esta seção é o foco de toda e qualquer publisher ou investidor, portanto dê a devida atenção.

16 Orçamento

A seção Orçamento descreve o custo total de desenvolvimento. Isto contempla custo de tecnologias, salários, recrutamento e assets de arte. O marketing não é normalmente responsabilidade dos desenvolvedores, mas se você está produzindo um título independente, terá que inserir custos desta etapa também.

Conclusão

Voltamos então a pergunta título deste post, trabalhar com jogos é uma questão de sorte? Se você entende “sorte” por  algo vinculado a destino, posso afirmar que não. Trabalhar com jogos hoje no nosso país é uma questão de empenho, dedicação, estudo e principalmente, maturidade e profissionalismo. Este é um mercado que trabalha com softwares muito complexos, portanto, deve ser tratado com a devida seriedade.

Atualmente existem várias oportunidades para quem deseja ser um desenvolvedor de games no Brasil. Um grande passo para aproveitá-las, como comentado neste artigo, seria montar um Projeto de Jogo detalhado e maduro.

Para finalizar, uma dica de quem está na área há cinco anos e dedica-se da mesma forma. Comece do início, antes de correr, aprenda a equilibrar-se e a andar. Não parta logo de início para um projeto extenso e custoso,  faça jogos pequenos, vários deles, porém finalize todos.

Espero que tenham gostado, um grande abraço e até a próxima!

Links interessantes

Referências

No artigo anterior vimos o game loop em sua forma mais simples, que tem o problema de ter a taxa de pulsos e frames presas uma a outra. Isso faz o jogo correr mais lentamente em CPUs lentas e acelerar em CPU mais poderosas, impedindo uma velocidade estável em todas plataformas. Neste artigo veremos como criar um game loop que garanta uma velocidade fixa para o jogo.

Aprendemos, no post anterior, a diferença entre o pulso e o frame, sendo o primeiro relacionado à lógica do jogo e o segundo à atualização da tela. Tinhamos uma classe Main que criava um objeto do tipo JogoLoopSimples. Vamos modificar essa classe para usar agora um objeto do tipo JogoPulsoFixo.

Arquivo Main.java

001package abrindoojogo.exemplos.gameloop;
002
003public class Main
004{
005    public static void main(String[] args)
006    {
007        JogoPulsoFixo jogo = new JogoPulsoFixo();
008        jogo.gameloop();
009    }
010}

O game loop da classe JogoLoopSimples era assim (para relembrar):

001public void gameloop()
002    {
003        initialize();
004        while (true)
005        {
006            Thread.yield();
007            update();
008            render();
009        }
010    }

Uma chamada a update() e uma a render(), acopladas. Se render demora, update também demora e o jogo fica lento. Bem, vamos partir do seguinte pressuposto: é possível “aturar” uma taxa de frames baixa, mas uma taxa de pulsos baixa modifica a jogabilidade.

Imagine um jogo onde uma nave se move um pixel por pulso. Se temos 60 pulsos por segundo, ao final de dois segundos a nave terá se movido 120 pixels. Mas se a taxa cair para 10 pulsos por segundo, em dois segundos a nave vai se mover apenas 20 pixels. E mais: se o computador for muito rápido, a taxa pode subir a 100 pulsos por segundo, e a nave vai andar 200 pixels em dois segundos. A jogabilidade é totalmente afetada.

A solução que apresento a seguir tenta manter a taxa de pulsos fixa, em detrimento da taxa de frames. Ou seja, se a máquina é lenta, priorizamos os pulsos e geramos os frames conforme der. Sempre teremos 60 pulsos por segundo, embora a taxa de frames possa cair para 10.

Isso causa o seguinte efeito: a nave vai se mover sempre 120 pixels em dois segundos, independente da velocidade da máquina. Mas se a máquina for lenta, a tela estará sendo atualizada apenas a 10 frames por segundo – o jogador vai ver a imagem quadro a quadro, mas a jogabilidade não fica tão comprometida, porque não há mudança na velocidade da ação.

E se a máquina for muito rápida, ainda assim ficaremos apenas com 60 pulsos por segundo, embora possamos estar obtendo 100 frames. A atualização da tela será bem rápida, o que é bom, e a nave continua se movendo na velocidade esperada.

Eu mostro abaixo a nova classe, chamada JogoPulsoFixo. Ela é derivada da classe do artigo anterior, de forma que tem tudo igual a ela. A lógica do jogo é exatamente a mesma. Só sobreescrevi o método gameloop, para modificá-lo.

Arquivo JogoPulsoFixo.java

001package abrindoojogo.exemplos.gameloop;
002
003public class JogoPulsoFixo extends JogoLoopSimples
004{
005    long PULSOS_DESEJADOS_POR_SEGUNDO = 60;
006    double NANOS_ESPERADOS_POR_PULSO = Contador.NANOS_EM_UM_SEGUNDO / PULSOS_DESEJADOS_POR_SEGUNDO;
007
008    @Override
009    public void gameloop()
010    {
011        initialize();
012        long nanoTimeDoProximoPulso = System.nanoTime();
013        while (true)
014        {
015            Thread.yield();
016            while (System.nanoTime() > nanoTimeDoProximoPulso)
017            {
018                update();
019                nanoTimeDoProximoPulso += NANOS_ESPERADOS_POR_PULSO;
020            }
021            render();
022        }
023    }
024}

A modificação (marcada em vermelho) é simples em termos de código, mas pode ser difícil de entender como funciona. Por isso vou explicar bem detalhadamente.

Nas linhas 005, 006 são declaradas constantes. PULSOS_DESEJADOS_POR_SEGUNDO armazena a quantidade de pulsos que desejamos que o game rode. Nesse caso é 60. Não é necessário mais do que isso para a lógica de qualquer jogo. Alguns rodam a 30 ou 25.

NANOS_ESPERADOS_POR_PULSO armazena a quantidade de nanosegundos que cada pulso deve durar. Calcular isso é fácil: se queremos 60 pulsos por segundo, basta pegar a quantidade total de nanosegundos que cabem em um segundo (1e9 ou 1.000.000.000) e dividir por sessenta pulsos. Cada pulso vai durar, nesse caso, 16.666.666 nanosegundos. Em geral vai durar menos, mas queremos ter um pulso a cada 16.666.666 nanosegundos, de forma a constituir 60 por segundo.

Agora veja o game loop. A grande mudança é que temos um outro laço dentro dele, para chamar repetidamente update(). Funciona assim: inicializamos uma variável chamada nanoTimeDoProximoPulso com o valor no nanosegundo atual. Em seguida entramos no game loop e já caimos no loop do update. É feita a verificação para ver se o nanosegundo atual é maior do que o nanoTimeDoProximoPulso, o que certamente não será, já que acabamos de atribuir o tempo atual a esta variável.

Pois bem. Entramos no loop do update(), chamamos esta rotina e depois adicionamos ao nanoTimeDoProximoPulso a quantidade de nanos esperados em um pulso. Isso nos dá o momento no tempo quando deverá ser executado o próximo pulso. Não executaremos ele antes desse tempo. Por outro lado, passar muito desse tempo, executaremos ele mais de uma vez até recuperar o atraso.

Vamos analisar um exemplo volta a volta do game loop. Respire fundo antes de continuar lendo.

1. Vamos assumir que tudo iniciou com o nanoTime = 0 (zero). Executamos update(), que demora 5.000.000 nanosegundos e somamos 16.666.666 na variável nanoTimeDoProximoPulso. Isso quer dizer que o próximo pulso é esperado para ocorrer nesse tempo.
2. Como update() demorou apenas 5.000.000 nanosegundos, ainda não chegamos ao 16.666.666 e saimos do loop do update. É executado em seguida o render(), que demora mais 5.000.000 nanosegundos e voltamos ao início do game loop.
3. Nova verificação do loop do update. O tempo atual é maior do que 16.666.666? Já que update() levou 5.000.000 e render() mais 5.000.000, estamos em 10.000.000 nanosegundos, que é menor. Não entramos no loop do update, ou seja, desta vez o update() não será executado, porque ainda não está na hora esperada. Executamos o render(), que leva mais 5.000.000 nanosegundos e voltamos ao início do game loop.
4. Agora já estamos em 15.000.000, mas ainda é menor do que 16.666.666, então pulamos novamente o loop do update e vamos direto para o render. Mais 5.000.000 nanosegundos e voltamos ao início.
5. Agora sim, estamos em 20.000.000 nanosegundos e isso é maior do que o esperado para o próximo pulso, que deveria ter ocorrido em 16.666.666. Estamos atrasados, mas tudo bem – agora entramos no loop do update, executamos ele (mais 5.000.000) e somamos mais 16.666.666 na variável nanoTimeDoProximoPulso. Isso quer dizer que agora vamos esperar até o tempo chegar em 33.333.332 para executar update() novamente.

Já deu para notar que update está sendo limitado. Praticamente temos três render() para cada update(). Essa é uma máquina rápida. Vamos refazer a análise em uma máquina lenta.

1. Tudo inicia no nanoTime = 0 (zero). Executamos update(), que agora demora 10.000.000 nanosegundos e somamos 16.666.666 na variável nanoTimeDoProximoPulso.
2. Como update() demorou apenas 9.000.000 nanosegundos, ainda não chegamos ao 16.666.666 e saimos do loop do update. É executado em seguida o render(), que demora 15.000.000 nanosegundos (placa de vídeo lenta) e voltamos ao início do game loop.
3. Nova verificação do loop do update e o tempo atual é 25.000.000, ou seja, maior que o 16.666.666 esperado para o próximo pulso. Assim, entramos no loop do update e executamos ele. Mais 10.000.000 se passam e estamos então há 35.000.000 nanosegundos de jogo. Acrescentamos novamente 16.666.666 à variável, ficando com 33.333.332, que seria a hora do próximo pulso.
4. Mas veja: já estamos em 35.000.000, ou seja, já passou a hora do segundo pulso. Então ficamos dentro do loop do update (porque 35.000.000 é maior que 33.333.332) e vamos executar update mais uma vez. Se passam mais 10.000.000 e estamos em 45.000.000. Somamos novamente 16.666.666 na variável e o próximo pulso fica então esperado para 49.999.998.
5. Ok, desta vez o tempo atual (45.000.000) é menor do que o esperado para o próximo pulso (49.999.998). Então pulamos o loop do update e vamos para o render(). Executamos ele e, devido aos seus 15.000.000 ficamos em 60.000.000 e voltamos ao início.

Já deu para ver que vamos entrar novamente no loop do update porque estamos bem atrasados. Vamos acabar executando o update duas vezes novamente, ou seja, nessa máquina o update executa o dobro de vezes que o render.

Caramba, que explicação cheia de volta… Entendeu? Espero que sim. Caso contrário, leia novamente o exemplo. Experimente colocar o comando contador.sleep(X), onde X é um número de milisegundos, dentro das rotinas update() e render() no arquivo JogoLoopSimples. Isso vai simular rotinas demoradas. Use valores como 50 ou 100 milisegundos.

Esse game loop mantém a taxa de pulsos fixa (na verdade pode oscilar entre 60 e 62) e pode ser utilizado para a criação de games reais. Mas ele apresenta um problema com máquina muitissimo lentas: pode ser que o update() precise rodar 500 vezes para cada render(). Ou mais! Ou ainda, ficar rodando sem nunca chegar na taxa desejada, e assim nunca executar o update().

Alguma dica de como resolver isso? Se você achar uma solução envie para mim (nornberg no gmail). Depois publico um post citando as soluções que aparecerem.

O coração de qualquer jogo é o game loop, um laço que fica sendo repetido durante toda execução do jogo. A cada volta desse laço temos um novo frame de jogo. Mas você sabe que a taxa de frames pode variar muito de um hardware para outro. Como manter a lógica do jogo rodando a uma velocidade fixa, independente da variação nos frames?

Quando jogamos, o que vemos na tela é uma sucessão de quadros que nos dá a impressão de movimento. Isso é chamado animação e tenho certeza que você já conhece seus princípios. Em geral somos levados a crer que, a cada quadro novo que vemos, algo mudou no estado do jogo. Se uma nave está se movendo, a cada quadro ela estará, digamos, um pixel para a direita.

É o game loop, o laço principal do jogo, que emite o que podemos chamar de pulsos para atualizar o estado do jogo (update) e redesenhar a imagem na tela (render). Em sua forma mais simples, a cada volta do game loop temos um pulso para update e um para render. Mas estas duas tarefas não precisam ser sempre sincronizadas. Na verdade, é melhor que não sejam.

Vamos contruir um programa de exemplo para estudar mais a fundo o game loop. Neste post vamos ver o loop mais simples e entender sua limitação. No próximo veremos como desacoplar o update do render, de forma que o update rode sempre a uma determinada velocidade e o render rode o mais rápido que puder.

Arquivo Main.java

001package abrindoojogo.exemplos.gameloop;
002
003public class Main
004{
005    public static void main(String[] args)
006    {
007        JogoLoopSimples jogo = new JogoLoopSimples();
008        jogo.gameloop();
009    }
010}

Esta classe simplesmente cria um objeto do tipo JogoLoopSimples e chama seu método gameloop() que vai rodar o jogo. A seguir a classe do jogo em sí, que possui o game loop.

Arquivo JogoLoopSimples

001package abrindoojogo.exemplos.gameloop;
002
003import java.awt.Color;
004import java.awt.Dimension;
005import java.awt.Graphics2D;
006import java.awt.Toolkit;
007import java.awt.event.KeyEvent;
008import java.awt.event.KeyListener;
009import java.awt.image.BufferStrategy;
010import javax.swing.JFrame;
011import javax.swing.WindowConstants;
012
013public class JogoLoopSimples extends JFrame implements KeyListener
014{
015    BufferStrategy bs;
016    Contador contador;
017    int nave_x, nave_y, nave_qtd;
018
019    public JogoLoopSimples()
020    {
021        setUndecorated(true);
022        setSize(800, 600);
023        Dimension d = Toolkit.getDefaultToolkit().getScreenSize();
024        setLocation(d.width / 2 - 400, d.height / 2 - 300);
025        setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
026        setIgnoreRepaint(true);
027        addKeyListener(this);
028        contador = new Contador();
029    }
030
031    public void gameloop()
032    {
033        initialize();
034        while (true)
035        {
036            Thread.yield();
037            update();
038            render();
039        }
040    }
041
042    public void initialize()
043    {
044        setVisible(true);
045        createBufferStrategy(2);
046        bs = getBufferStrategy();
047
048        nave_x = 400;
049        nave_y = 50;
050        nave_qtd = 1;
051
052        contador.inicia();
053    }
054
055    public void update()
056    {
057        contador.contaPulso();
058        nave_x += 1;
059        if (nave_x > getWidth() + 30)
060        {
061            nave_x = 0;
062        }
063    }
064
065    public void render()
066    {
067        contador.contaFrame();
068        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
069        g.setColor(Color.black);
070        g.fillRect(0, 0, getWidth(), getHeight());
071        int x = nave_x;
072        int y = nave_y;
073        for (int i = 0; i < nave_qtd; i++)
074        {
075            g.setColor(Color.yellow);
076            g.drawLine(x, y, x - 20, y - 5);
077            g.drawLine(x, y, x - 20, y + 5);
078            g.drawLine(x - 20, y - 5, x - 20, y + 5);
079            y += 15;
080            if (y > 550)
081            {
082                y = nave_y;
083                x += 15;
084            }
085        }
086        g.setColor(Color.white);
087        g.drawString("Pulsos: " + contador.getPulsosPorSegundo() + "  Frames: " + contador.getFramesPorSegundo() + "          naves: " + nave_qtd, 10, 20);
088        g.dispose();
089        bs.show();
090    }
091
092    public void keyPressed(KeyEvent e)
093    {
094        if (e.getKeyCode() == KeyEvent.VK_ESCAPE)
095        {
096            System.exit(0);
097        }
098
099        if (e.getKeyCode() == KeyEvent.VK_UP)
100        {
101            nave_y -= 1;
102        }
103        if (e.getKeyCode() == KeyEvent.VK_DOWN)
104        {
105            nave_y += 1;
106        }
107        if (e.getKeyCode() == KeyEvent.VK_RIGHT)
108        {
109            if (nave_qtd < 1054)
110            {
111                nave_qtd += 1;
112            }
113        }
114        if (e.getKeyCode() == KeyEvent.VK_LEFT)
115        {
116            if (nave_qtd > 1)
117            {
118                nave_qtd -= 1;
119            }
120        }
121    }
122
123    public void keyReleased(KeyEvent e)
124    {
125    }
126
127    public void keyTyped(KeyEvent e)
128    {
129    }
130}

Vejamos os métodos mais importantes. O contructor faz bastante coisa de configuração, mas tudo com relação à janela do jogo. É tirada a decoração (título, borda, etc) ficando apenas um quadro centralizado no vídeo. É centralizado baseado no tamanho da tela, obtida por meio de Toolkit.getDefaultToolkit().getScreenSize().  Boa parte desse código é parecida com o que foi mostrado no post Passive VS Active Rendering. Note, no entando na criação do objeto “contador”. Ele será utilizado para contar quantos pulsos e quantos frames obteremos. Os pontos onde ele é utilizado estão destacados em vermelho.

O jogo é muito simples – na verdade nem é um jogo. O método update() incrementa a variável nave_x, fazendo ela ir até a direita da tela e então recomeçar da esquerda. Quando uma tecla é pressionada, o método keyPressed modifica a variável nave_y, fazendo a posição subir ou descer, ou aumenta/diminui a variável nave_qtd, que informa quantos sprites teremos na tela.

O método render() limpa a tela, desenha a “nave” (um triângulo feito com linhas) dentro de um loop que vai repetir o desenho tantas vezes quanto for o valor de nave_qtd. Depois mostra na tela os valores de pulsos por segundo e frames por segundos do contador.

Note que toda vez que o método update() é executado, dentro dele é chamado o contador.contaPulso(). E no método render() é chamado contador.contaFrame(). Assim estamos contando quantas vezes estes dois métodos são chamados.

Nosso game loop é a versão mais simples possível, reproduzida abaixo.

031    public void gameloop()
032    {
033        initialize();
034        while (true)
035        {
036            Thread.yield();
037            update();
038            render();
039        }
040    }

É chamado update() e depois render(), um após o outro sem nenhum controle mais elaborado. O método yield() faz o programa interromper rapidamente seu processamento para que o resto do sistema tenha tempo de CPU. Usar ele faz o programa parar um pouco para escutar o teclado. Sem ele, um pressionar de tecla pode ser perdido.

Finalmente vejamos o código do contador.

Arquivo Contador.java

001package abrindoojogo.exemplos.gameloop;
002
003public class Contador
004{
005    static public double NANOS_EM_UM_SEGUNDO = 1e9;
006    protected long pulsosPorSegundo;
007    protected long framesPorSegundo;
008    protected long nanoTimeAnterior;
009    protected long pulsosContados;
010    protected long framesContados;
011
012    public void inicia()
013    {
014        nanoTimeAnterior = System.nanoTime();
015        pulsosContados = 0;
016        framesContados = 0;
017        pulsosPorSegundo = 0;
018        framesPorSegundo = 0;
019    }
020
021    public void contaPulso()
022    {
023        pulsosContados++;
024        verifica();
025    }
026
027    public void contaFrame()
028    {
029        framesContados++;
030        verifica();
031    }
032
033    protected void verifica()
034    {
035        if (System.nanoTime() - nanoTimeAnterior > NANOS_EM_UM_SEGUNDO)
036        {
037            pulsosPorSegundo = pulsosContados;
038            framesPorSegundo = framesContados;
039            pulsosContados = 0;
040            framesContados = 0;
041            nanoTimeAnterior = System.nanoTime();
042        }
043    }
044
045    public void sleep(long miliSecondsToSleep)
046    {
047        try
048        {
049            Thread.sleep(miliSecondsToSleep);
050        } catch (Exception e)
051        {
052        }
053    }
054
055    public long getPulsosPorSegundo()
056    {
057        return pulsosPorSegundo;
058    }
059
060    public long getFramesPorSegundo()
061    {
062        return framesPorSegundo;
063    }
064}

O trabalho desta classe é interessante: cada vez que chamamos o método contaPulso(), ela incrementa o contador de pulsos e chama o método verifica() que testa se já passou um segundo desde a última verificação. Se sim, ele atribui a quantidade de pulsos contados para a variável pulsosPorSegundo. Assim, esta variável é atualizada a cada segundo com a quantidade de pulsos que ocorreram. Nesse momento o contador de pulsos é zerado para contar quantos pulsos ocorrerão no próximo segundo. A mesma coisa para a contagem de frames.

O tempo é medido em nanosegundos, que é bem menor que os milisegundos geralmente utilizados nos programas. Um segundo contém 1.000 milisegundos, ou seja, 1e3 (mil). E possui 1.000.000.000 nano segundos, ou seja, 1e9 (um milhão). Esse valor está registrado na constante NANOS_EM_UM_SEGUNDO para ser utilizado nos cálculos.

Essa classe oferece ainda um método utilitário chamado sleep(), que servirá para realizarmos alguns testes. Ele simplifica o uso do método sleep() de Thread, que precisa de um try-catch para ser usado. Ele faz o processamento parar durante os milisegundos informados.

Executando esse programa, obtenho o seguinte resultado (só mostro o canto da tela):

Conforme os dados do contador mostrados, tenho 47 pulsos por segundo e também 47 frames. Naturalmente estes números serão sempre iguais, porque dentro do loop chamo uma vez update() e uma vez o render().

Se eu desejasse 60 fps (frames por segundo), não seria possível. 47 é tudo que eu consigo no meu computador e ainda fica variando. Se eu pressiono a seta para direita, aumentando a quantidade de sprites até 1054, a taxa de frames cai mais um pouco.

Talvez seu computador seja bem mais rápid e mesmo aumentando os sprites a taxa de frames não apresente muita diferença. Vamos fazer um teste mais exagerado. Chamaremos o método contador.sleep() dentro do método render(), de forma a fazer este método demorar alguns milisegundos a mais.

001
002
003    public void render()
004    {
005        contador.contaFrame();
006        Graphics2D g = (Graphics2D) bs.getDrawGraphics();
007        g.setColor(Color.black);
008        g.fillRect(0, 0, getWidth(), getHeight());
009        int x = nave_x;
010        int y = nave_y;
011        for (int i = 0; i < nave_qtd; i++)
012        {
013            g.setColor(Color.yellow);
014            g.drawLine(x, y, x - 20, y - 5);
015            g.drawLine(x, y, x - 20, y + 5);
016            g.drawLine(x - 20, y - 5, x - 20, y + 5);
017            y += 15;
018            if (y > 550)
019            {
020                y = nave_y;
021                x += 15;
022            }
023        }
024        g.setColor(Color.white);
025        g.drawString("Pulsos: " + contador.getPulsosPorSegundo() + "  Frames: " + contador.getFramesPorSegundo() + "          naves: " + nave_qtd, 10, 20);
026        g.dispose();
027        bs.show();
028        contador.sleep(50);
029    }

Agora sim. O tempo de atualizar a tela (render) leva absurdos 50 ms (milisegundos). Absolutamente lento demais. A taxa de frames cai para 14 na minha máquina.

Agora preste atenção na parte mais importante: a taxa de pulsos por segundo cai junto com os frames, embora apenas a rotina render() tenha recebido o tempo a mais. Isso ocorre porque como uma rotina é chamada depois da outra, em sequencia, update() tem que esperar render() executar para ser executada novamente.

Rodando o jogo você percebe que não é apenas a taxa de atualização da tela que fica lenta, mas o jogo todo. A nave agora leva uma eternidade para chegar até a extremidade da tela, porque temos apenas 14 pulsos de atualização da sua posição por segundo.

Está comprovado o problema. No próximo post a solução. Até amanhã.