Mesmo com um pouco de atraso, trazemos mais um episódio do nosso podcast sobre desenvolvimento de games, o PodAbrir. Neste episódio eu, sem poder contar com o meu companheiro de trabalho, falo sobre um tema bastante acesso aqui no blog – a Inteligência Artificial em games. O objetivo aqui é introduzir as principais técnicas utilizadas pela indústria de games.

Participantes

Links comentados neste episódio

Visitem nossa página no Facebook

Graças ao leitor Otávio Ortiz, temos o primeiro Leitor no Controle de 2012. Expert no assunto, Otávio traz dicas de como montar um game side scrolling utilizando o engine Game Maker, que aliás recentemente ganhou uma nova versão compatível com HTML5.

Reforço que os demais leitores podem – e devem, seguir o exemplo do Otávio enviando o seu artigo ou tutorial para contato@abrindoojogo.com.br

Como fazer o efeito side scrolling no game maker

E é isso, agora é só executar e ver a câmera seguindo o seu objeto,  este efeito é conhecido com side scrolling. Espero ter ajudado, um abraço a todos e qualquer sugestão utilize os comentários. Para dúvidas sobre esta técnica ou qualquer outra, utilizem o fórum  do AoJ, lá tem um área só sobre Game Maker a qual sou moderador. Até

Otávio Ortiz

Veremos como separar a lógica do jogo da renderização, fazendo a lógica rodar a uma taxa fixa (e baixa) e atualizando a tela o mais rápido possível. Embora esta seja uma técnica genérica, útil em qualquer tecnologia, é especialmente aplicável em jogos HTML onde o ideal é atualizar a lógica do jogo mais lentamente.

Continuaremos com o exemplo da parte anterior, sendo que os arquivos aojcanvas.js e aojinput.js permanecem inalterados. Nossa maior modificação não será no motor em sí, mas na própria página do jogo, onde temos a divisão do pulso em update() e render().

No entanto o motor recebe uma pequena modificação. Iniciaremos por ela.

Substituindo setInterval por setTimeout

Na conclusão da parte anterior, comentei sobre um problema que pode afetar o jogo caso a lógica demore muito para executar. No caso, o problema ocorre se a lógica levar mais tempo para executar do que o esperado para cada pulso.

Imagine que o pulso está agendado (com setInterval) para ser chamado a cada 50 milisegundos, mas por algum motivo nossa lógica leva 60 milisegundos. Ela ainda vai estar executando quando for disparado um novo pulso, iniciando novo processamento da lógica do jogo. Isso gera duas execuções em paralelo, diminuindo ainda mais a performance, piorando o prolema.

Para resolver isso, trocamos o uso de setInterval por setTimeout. A diferença entre elas é a seguinte:

• setInterval agenda chamadas contínuas para a rotina informada. Ou seja, fica chamando a rotina automaticamente a cada X milisegundos.
• setTimeout agenda apenas um execução da rotina. Ou seja, chama a rotina daqui a x milisegundos e só. Para executar a rotina novamente, precisamos agendar com um novo setTimeout.

A mudança que faremos, então, consiste em trocar a chamada de setInterval presente em aojStartGameLoop(), como também adicionar uma chama semelhante dentro de aojPulse. Veja abaixo.

function aojStartGameLoop() {
       ... // mesmo código de antes
       setTimeout('aojPulse()', 0); // trocamos setInterval por setTimeout
       // isso vai chamar aojPulse apenas uma vez, então dentro dela precisamos de outros setTimeout
}
 
function aojPulse() {
        ... // mesmo código de antes
        setTimeout('aojPulse()', 0); // adicionamos uma chamada a setTimeout - a cada pulso agendamos outro
    }
}

Bem, se você tiver prestado atenção, percebeu que o código acima não é exatamente equivalente ao que tínhamos antes. Estamos passando zero milisegundos para o setTimeout, o que faz com que a próxima execução seja agenda para imediatamente – ou, na prática, para tão logo seja possível. Ou seja, não respeitamos mais o limite de FPS informado, rodando, ao invés disso, na velocidade máxima possível.

Se colocarmos esse game loop nos exemplos anteriores, sem modificá-los, teremos a ação deles acelerada, porque neles a lógica roda a cada pulso, sem nenhum filtro. Mas a modificação que faremos nos exemplos dará conta disso.

Separando update() e render()

Vamos lembrar como era a relação entre nosso pulso e as rotinas update() e render() no exemplo anterior.

function pulse() {
    update();
    render();
}
 
function update() {
    ... // lógica do jogo
}
 
function render() {
    ... // atualiza a imagem na tela
}

Não poderia ser mais simples. A cada pulso executamos um update e um render. Vejamos agora o que muda. O código está abaixo e logo após a explicação.

var _lastMilisecond = 0;
var _updatesCount = 0;
var _updatesInLastSecond = 0;
var _lastUpdateMilisecond = 0;
var _frameCount = 0;
 
function pulse() {
    var d = new Date();
    if (d.getTime() - _lastMilisecond > 50) {
        _lastMilisecond = d.getTime();
        update();
        _frameCount = 0;
    }
    _frameCount ++;
    render(_frameCount / (_aojPulsesInLastSecond / _updatesInLastSecond));
}
 
function update() {
    _updatesCount ++;
    var d = new Date();
    if (d.getTime() - _lastUpdateMilisecond > 1000) {
        _lastUpdateMilisecond = d.getTime();
        _updatesInLastSecond = _updatesCount;
        _updatesCount = 0;
    }
    ... // lógica do jogo
}

Vamos analisar a rotina pulse() primeiro. Em linhas gerais, agora ela executa update() a cada x milisegundos e executa render() sempre, ou seja, a cada pulso. O filtro para update é feito com o seguinte algoritmo:

1. A cada pulso é obtido o tempo atual;
2. Se a diferença entre o tempo atual e o tempo armazenado anteriormente (_lastMilisecond) for maior do que 50 milisegundos:
   1. Armazenamos o tempo atual em _lastMilisecond;
   2. Zeramos _frameCount (explicada abaixo);
   3. Chamamos update();

O efeito disto é que update() é chamado a cada 50 milisegundos. Ignorei a rotina de informar o FPS desejado e utilizei o valor fixo 50, mas poderia ter feito algo configurável. Executando um update a cada 50 milisegundos terei 20 updates por segundo. Na realidade, teremos um pouco menos, porque a estes 50 milisegundos somamos o tempo de execução da própria rotina update().

O código colocado dentro da rotina update é comum e serve para contar quantas vezes por segundo ela é chamada. É o mesmo código que tínhamos dentro de aojPulse() no exemplo anterior.

A variável _frameCount serve para contar quantos frames (que nesse caso são iguais a pulsos) ocorrem entre duas chamadas de update. Por isso é zerada quando ocorre um update e a partir daí vai sendo incrementada a cada pulso.

Veja no gráfico abaixo como se comporta essa variável. Vamos assumir que a duração aqui seja 1 segundo, ou seja, temos 20 pulsos por segundo. As linhas vermelhas mostram os pulsos onde update é chamado (aqui temos apenas 4 updates por segundo, para simplificar).

Já a chamada de render é feita sem nenhum controle, ou seja, é chamada em todos pulsos. E veja que ela recebe um valor como parâmetro. Vejamos o que ele significa.

Esse valor é calculado da seguinte forma: primeiro a quantidade de pulsos ocorridos no último segundo é dividida pela quantidade de updates no mesmo período. Na figura acima, que representa 1 segundo, ocorreram 20 pulsos e 4 updates. Então temos 20/4 = 5.

Esse número (5) é a quantidade de pulsos que ocorre entre dois updates – e vem a ser a quantidade de vezes que render() é chamada entre dois updates.

Para completar o valor do parâmetro de render, dividimos o valor de _frameCount pela quantidade de pulsos entre dois updates, de forma a obter um valor normalizado entre 0 e 1. Por exemplo, quando _frameCount é 1, teremos 1/5 = 0.2; quando _frameCount é 2, teremos 2/5 = 0.4; quando _frameCount for 5, teremos 5/5 = 1. Veja na figura abaixo.

Interpolação

A interpolação consiste em obter valores intermediários entre dois valores conhecidos. Por exemplo, dados os valores 10 e 20, se fizermos a interpolação entre eles com três passos, teremos os valores (12.5, 15.0, 17.5). Se fizermos com 7 passos teremos (11.25, 12.5, 13.75, 15.0, 16.25, 17.5, 18.75).

Nosso objetivo aqui é interpolar as posições dos nossos sprites de forma a gerar posições intermediárias que não são calculadas pelo update. Por exemplo, digamos que no último update ocorrido nosso sprite tenha ficado na posição x=150 e no próximo update, ele vá para a posição x=180. Se nada for mudado em render, veremos nosso sprite saltar diretamente da posição 150 para a 180.

Lembre-se que entre estes dois updates tivemos (conforme a figura acima) 5 chamadas a render. Se não tivermos interpolação implementada, o que ocorre é que as cinco chamadas vão mostrar o sprite na posição 150, até que ocorre o próximo update e a posição muda para 180 – e os próximos cinco render mostrarão ele na posição 180, e assim por diante.

Com a interpolação, no entanto, calcularemos dentro de render posições intermediárias. Sabemos que são 5 render entre os updates. Assim, o primeiro render deverá mostrar o sprite a 1/5 (0.2) do caminho entre 150 e 180; o segundo update mostrará a 2/5 (0.4) do caminho; e o quinto mostrará a 5/5 (1.0) do caminho, ou seja, bem no 180.

Os valores 0.2, 0.4, etc, como vimos, são aqueles passados para render no parâmetro, que chamaremos de delta. Como usamos esse delta para afetar o x do sprite? Basta multiplicar o delta pela distância entre as duas posições (180 – 150 = 30) e somar na primeira posição (150).

Ou seja, a fórmula é essa: x = x1 + (x2 – x1) * delta, onde, no exemplo, x1=150, x2=180 e delta = 0.2, 0.4, 0.6, etc.

Os valores de x serão assim:

1. Primeiro update
   x = 150 + (180-150) * 0.2;
   x = 150 + 30 * 0.2;
   x = 150 + 6;
   x = 156;
2. Segundo update
   x = 150 + 30 * 0.4;
   x = 150 + 12;
   x = 162;
3. Terceiro update
   x = 150 + 30 * 0,6;
   x = 150 + 18;
   x = 168;
4. Quarto update
   x = 150 + 30 * 0,8;
   x = 150 + 24;
   x = 174;
5. Quinto update
   x = 150 + 30 * 1,0;
   x = 150 + 30;
   x = 180;

Veja como este recurso é poderoso: ele nos permitiu mostrar o sprite em 6 posições diferentes (150, 156, 162, 168, 174 e 180), embora a lógica do jogo tenha calculado apenas duas (150 e 180). Isso nos permite rodar o jogo a uma baixa taxa de updates, mas mostrar uma animação suave, tanto mais suave quantos forem os frames entre os updates.

Quanto melhor o desempenho do computador do jogador, mais vezes render vai ser chamada entre os updates e assim mais passos teremos em nossa interpolação, melhorando a animação.

Vejamos, então, como ficou o código da rotina render:

function render(delta) {
     aojFillRect(0, 0, aojCanvas().width, aojCanvas().height, 'gray');
     var x = carro.lastX + ((carro.x - carro.lastX) * delta); // x = x1 + (x2-x1) * delta
     var y = carro.lastY + ((carro.y - carro.lastY) * delta);
     aojDrawImage(carro.sprite, x, y);
     aojFillRect(57,5,50,20, 'blue');
     aojSetFont('');
     aojDrawText(_updatesInLastSecond + ' tps', 65, 20, 'yellow');
}

Mas que atributos são esses: “lastX” e “lastY”? Bem, estes são atributos adicionados ao sprite para armazenar a posição anterior dele – afinal, agora precisamos de duas posições para fazer a interpolação. Sempre que update muda o valor de x, armazena o anterior em lastX. Veja abaixo o código completo de update:

function update() {
      _updatesCount ++;
      var d = new Date();
      if (d.getTime() - _lastUpdateMilisecond > 1000) {
           _lastUpdateMilisecond = d.getTime();
           _updatesInLastSecond = _updatesCount;
           _updatesCount = 0;
      }
      carro.lastX = carro.x;
      carro.lastY = carro.y;
      carro.x += carro.dx;
      carro.y += carro.dy;
      if (carro.x < 0 || carro.x > aojCanvas().width) {
           carro.dx *= -1;
      }
      if (carro.y < 0 || carro.y > aojCanvas().height) {
           carro.dy *= -1;
      }
}

Está implementada assim a interpolação da posição do sprite entre updates, criando um movimento mais suave e contínuo do que tínhamos no exemplo anterior.

Conclusão

Como dito no início deste post, a interpolação é uma técnica genérica, que pode ser utiliza em qualquer motor para melhorar a aparência do movimento dos sprites. Mas é especialmente bem vinda em jogos para navegadores, já que o desempenho do javascript ainda não é tão alto. Assim, é bom podermos rodar o jogo a uma taxa de atualização mais baixa, dando mais tempo para a lógica dentro de update ser executada, sem, no entanto, ter a animação prejudicada.

Uma coisa interessante de notar nessa técnica é que o que vemos na tela está sempre um passo atrás da lógica do jogo. Veja vem: quando o update coloca o sprite na posição 180, recém inicia a apresentação dele entre 150 e 180. Quando ele chegar no 180, já teremos outro update que colocará o sprite mais para frente, digamos x=210. Agora o render vai interpolar entre 180 e 210.

Isso não causa nenhum problema visível na maioria dos jogos, mas naqueles cuja ação é muito rápida (geralmente shooters), poderão ser percebidas discrepâncias com relação aos controles – afinal, o input está sendo processado pelo update, levando em conta a posição atual, enquanto o render vem atrás, interpolando a partir da posição anterior.

Nesses casos extremos não podemos usar a posição atual com relação à anterior. É preciso, de alguma forma, usar a posição atual com relação à próxima, que ainda não foi calculada! Para isso usamos a extrapolação ao invés da interpolação – basicamente é seguir o calculo da interpolação passando do valor de destino. Mas essa já é outra história. Fica como lição de casa…

• Visualizar o exemplo do game loop
• Visualizar o exemplo de input
• Baixar o código fonte do exemplo

Nesta segunda parte ampliaremos nossa biblioteca adicionando um motor simples, com um gameloop bem básico e tratamento de entrada (mouse e teclado).

Na parte anterior criamos um biblioteca básica para utilização do <canvas>, a qual ficou em um arquivo chamado aojcanvas.js. As rotinas dela servem de atalhos para procedimentos que requerem mais de uma linha de código, como desenhar um retângulo preenchido ou desenhar uma imagem rotacionada na tela.

No entanto isso tudo referia-se apenas ao uso básico do objeto canvas, sem nada que lembrasse um jogo de fato.

A arquitetura comum de um jogo sempre consiste em uma repetição onde temos o tratamento da entrada, atualização da lógica do jogo e atualização da parte visual (mostrar o jogo na tela). Estes procedimentos ficam sendo repetidos indefinidamente, até que o jogo seja desligado. A esta repetição chamamos de game loop e cada volta que este loop dá chamamos de pulso.

Dito isso, vejamos como criar um game loop em javascript para rodar no navegador.

Game loop

O nosso “motor”, por assim dizer, ficará em um arquivo chamado aojgame.js e nele teremos o código abaixo.

var _aojFPS = 25;
var _aojPulseCallback = null;
var _aojPulsesCount = 0;
var _aojPulsesInLastSecond = 0;
var _aojLastMilisecond = 0;
 
function aojFPS(optionalNewValue) {
    if (optionalNewValue) {
        _aojFPS = optionalNewValue;
    }
    return _aojFPS;
}
 
function aojSetPulseCallback(callbackFunction) {
    _aojPulseCallback = callbackFunction;
}
 
function aojStartGameLoop() {
    if (!_aojPulseCallback) {
        alert('É preciso especificar a função a ser chamada a cada pulso, com aojSetPulseCallback. GameLoop não iniciado.');
    } else if (!_aojCanvas) {
        alert('É preciso especificar o canvas a ser usado, com aojSetCanvas. GameLoop não iniciado.');
    } else {
        _aojLastMilisecond = new Date().getTime();
        setInterval('aojPulse()', 1000 / _aojFPS);
    }
}
 
function aojPulse() {
    if (_aojPulseCallback) {
        _aojPulsesCount ++;
        var d = new Date();
        if (d.getTime() - _aojLastMilisecond > 1000) {
            _aojLastMilisecond = d.getTime();
            _aojPulsesInLastSecond = _aojPulsesCount;
            _aojPulsesCount = 0;
        }
        _aojPulseCallback();
        aojFillRect(6,5,50,20, 'blue');
        aojSetFont('');
        aojDrawText(_aojPulsesInLastSecond + ' fps', 10, 20, 'yellow');
    }
}

Temos apenas quatro rotinas, sendo as duas primeiras apenas de configuração.

aojFPS() serve para indicar qual a taxa de frames por segundo desejada para o jogo. Importante notar que este motor simples não tem separação entre update e render – ele chama apenas uma rotina de pulso.

O nome da rotina de pulso é definido por você, fora do motor, e passado como parâmetro para a segunda rotina de configuração que temos: aojSetPulseCallback().

Callback é como chamamos a técnica de, ao chamar uma rotina (geralmente de uma biblioteca), passar para ela uma rotina nossa para que seja chamada de volta (daí o nome call back). No caso deste nosso motor, a rotina informada em aojSetPulseCallback será chamada a cada pulso.

A terceira rotina do código acima é aojStartGameLoop(), que verifica se temos um callback e um canvas especificados e em caso positivo, utiliza o método setInterval (padrão do Javascript) para agendar a execução do método aojPulse a cada X milisegundos.

X, neste caso, equivale a 1000 dividido pela taxa de FPS informada, resultado no tempo de duração de cada pulso. Por exemplo, se informamos 20 FPS, X será 1000/20 = 50 milisegundos. Ou seja, ocorrerá um pulso a cada 50 milisegundos para manter a taxa de 20 por segundo.

Note que não é a nossa rotina de callback que é passada para o setInterval, mas sim outra rotina, interna ao motor, chamada aojPulse(). De dentro de aojPulse é que é chamada nossa callback.

Isso é feito assim porque o motor tem algumas ações a serem feitas a cada pulso, além de chamar nossa rotina própria. Estas ações consistem em calcular a taxa real de frames por segundo e mostrar essa informação na tela.

A contagem de pulsos é feita da seguinte maneira (conforme podemos ver no código de aojPulse):

1. A cada pulso incrementamos um contador (_aojPulsesCount);
2. A cada pulso obtemos o tempo atual e verificamos sua diferença para o tempo armazenado anteriormente (_aojLastMilisecond). Se a diferença é maior que 1000, ou seja, se 1 segundo se passou, então:
   1. Armazenamos o tempo atual em _aojLastMilisecond;
   2. Armazenamos a quantidade de pulsos contada pelo contador na variável _aojPulsesInLastSecond;
   3. Zeramos nosso contador, reiniciando a contagem para o próximo segundo.

Veja que após fazer isso, a rotina aojPulse chama a callback (que vai executar a lógica do jogo) e depois mostra o valor de _aojPulsesInLastSecond na tela com aojDrawText.

Usando o game loop

Para usar este game loop, criamos uma página HTML e inserimos os dois scripts que temos até agora:

<script src="aoj/aojcanvas.js"><!--mce:0--></script>
<script src="aoj/aojgame.js"><!--mce:1--></script>

E dentro da tag <body> declaramos a tag <canvas> com o ID que desejarmos (no exemplo abaixo usei “canvas” mesmo).

Se tiver dúvidas sobre isso, reveja a primeira parte do tutorial.

Na página HTML declaramos também uma seção de script para a lógica específica do nosso jogo. Veja o exemplo abaixo (que está disponível dentro do ZIP no final do post).

        <script type="text/javascript"><!--mce:2--></script>

Vamos analisar este código. Inicia com a declaração de um objeto chamado carro, que contém variáveis utilizadas para manter a posição e a direção de movimento de um sprite na tela.

Em seguida vem uma rotina chamada pulse(). Esta é nossa rotina de callback, que será chamada pelo motor. Dentro dela chamamos duas outras, update() e render(), que utilizamos para separar a lógica da parte de desenho na tela.

Dentro de update temos o código clássico para mover o objeto, fazendo ele rebater nas extremidades da tela. Cada coordenada do carro (x e y) são incrementadas com seu incremento correspondente (dx e dy). Quando atingem o limite da tela, dx (ou dy) tem o sinal invertido e o movimento naquela direção se inverte. Assim temos o efeito de rebater no canto da tela.

Dentro de render() limpamos a tela com aojFillRect() e desenhamos o sprite com aojDrawImage(). O sprite é desenhado na posição (x, y) armazenada no objeto carro.

O próximo código do script é a definição de uma função para ser chamada no evento onload da janela. Nela utilizamos aojNewImage() para carregar a imagem do carro. Lembre-se que esta rotina recebe uma outra como callback, que será chamada quando a imagem for completamente carregada. Nossa rotina de callback para esse caso é imagemCarregada() (a última do script).

Dentro de imagemCarregada() temos o código de inicialização, que consiste em informar o FPS desejado, a callback do pulso, o canvas a ser utilizado e finalmente dar o start no game loop.

Importante notar como essa inicialização não é feita no onload da janela, mas sim após a imagem carregar. Sempre precisamos primeiro carregar as imagens (e outros recursos) do jogo antes de colocar ele para rodar. Isso evita que o game loop começe, eventualmente chamando render() que tentaria desenhar o sprite que ainda não teria sido carregado.

Veja esse exemplo em execução aqui.

Entrada com teclado e mouse

Passamos para a parte de input. Os navegadores expõem alguns eventos em Javascript para obtermos acesso ao teclado e mouse (em breve teremos para controles de jogo também). Estes eventos são:

• document.onkeydown, chamado sempre que uma tecla é pressionada. Neste evento vamos armazenar o código da tecla pressionada em uma variável;
• document.onkeyup, chamado quando uma tecla é solta. Neste evento limparemos a variável que tinha o código desta tecla.
• document.onmousedown, quando o botão esquerdo do mouse é pressionado. Neste evento armazenaremos essa informação em uma variável;
• document.onmouseup, quando o botão do mouse é solto. Neste evento limparemos a variável acima;
• document.onmousemove, ocorre quanto o mouse se move. Neste evento vamos atualizar duas variáveis que armazenarão a posição X e Y do mouse.

Veja que quando ocorrem os eventos acima, não executamos nenhuma lógica de jogo. Ao invés disso, armazenamos as mudanças de estado das teclas em variáveis. Estas variáveis serão depois acessadas em nosso update, para saber o estado de determinadas teclas.

Para armazenar o estado das teclas (solta ou pressionada), ao invés de um monte de variáveis soltas teremos um array com 6 posições. Armazenaremos as setas, um botão de ação e o botão do mouse.

Para saber em qual posição do array está cada informação, definimos algumas variáveis da seguinte forma:

var AOJ_KEY_UP = 0;
var AOJ_KEY_DOWN = 1;
var AOJ_KEY_LEFT = 2;
var AOJ_KEY_RIGHT = 3;
var AOJ_KEY_ACTION = 4;
var AOJ_MOUSE = 5;
var _aojKeys = new Array();

A posição do mouse é armazenada em um objeto chamado _aojMousePos que contém as propriedades x e y.

var _aojMousePos = {
    x:0,
    y:0
};

Para facilitar o uso, criamos rotinas para retornar o estado das teclas e posição do mouse. São elas:

function aojIsPressed(key)
{
    return _aojKeys[key];
}
 
function aojIsReleased(key)
{
    return !_aojKeys[key];
}
 
function aojMouseX() {
    return _aojMousePos.x;
}
 
function aojMouseY() {
    return _aojMousePos.y;
}

Estas rotinas apenas retornam o valor armazenado no array. Quem modifica este valor são as rotinas dos eventos listados acima. Sua implementação completa é simples e pode ser vista no arquivo aojinput.js que está no ZIP no final do post.

Utilizando o input

No ZIP temos também uma página HTML que utiliza o teclado para controlar o sprite do carro. O código da página é igual ao do exemplo acima, com diferença apenas no objeto do carro e na rotina update(). Ah, e claro, ele inclui o script que contem as rotinas de input:

<script src="aoj/aojinput.js"><!--mce:3--></script>

O objeto carro possui algumas propriedades a mais, para armazenar a rotação (direção em que o carro se moverá) e a velocidade de movimento.

A rotina update(), ao invés de mover o sprite rebatendo pela tela, agora utiliza a leitura da entrada para determinar para onde mover o carro.

function update() {
    if (aojIsPressed(AOJ_KEY_UP) || aojIsPressed(AOJ_MOUSE)) {
        // se tecla para cima pressionada, aumenta a velocidade do carro
        carro.speed += 0.5;
        if (carro.speed > 10) // limita a velocidade em 10
            carro.speed = 10;
    } if (aojIsPressed(AOJ_KEY_DOWN)) {
        // se tecla para baixo pressionada, diminui a velocidade do carro
        carro.speed -= 0.5;
        if (carro.speed < -5) // limita em -5 - com velocidade negativa o carro vai dar marcha ré
            carro.speed = -5;
    } else {
        // se nem acima nem abaixo estão pressionadas, diminui um pouco a velocidade.
        carro.speed -= 0.1;
        if (carro.speed < 0)
            carro.speed = 0
    }
    if (aojIsPressed(AOJ_KEY_LEFT)) {
        // Se pressionada para esquerda, muda a rotação de acordo
        carro.rotation -= Math.abs(carro.speed) / 100;
        if (carro.rotation < 0)
            // Se o angulo diminuir de zero, recomeça em uma volta inteira (2 * PI radianos)
            carro.rotation = Math.PI * 2;
    }
    if (aojIsPressed(AOJ_KEY_RIGHT)) {
        carro.rotation += Math.abs(carro.speed) / 100;
        if (carro.rotation > Math.PI * 2)
            carro.rotation = 0;
    }
    // calcula a nova posição aplicando rotação ao ponto
    carro.x += Math.cos(carro.rotation) * carro.speed;
    carro.y += Math.sin(carro.rotation) * carro.speed;
}

O código é padrão para movimento de veículos, com velocidade e rotação. Se você tiver dificuldades para entender, dê uma olhada nos nosso posts sobre rotação e aceleração.

Conclusão

Neste artigo vimos um motor de pulso muito básico feito em Javascript. Atenção para o fato de não termos um loop de fato, mas sim um agendamento utilizado o recurso de timer do navegador (setInterval). Um loop real (for, while), infinito como teria que ser, não é aceito pelo navegador. Sempre que encontra um loop destes, que tem o potencial de trancar o processamento da página, o navegador aborta o script. É uma questão de segurança, para impedir o uso deste recurso por páginas maliciosas.

No entanto o setInterval não é a melhor forma de fazer isso. Usei-o aqui por ser mais simples, porém ele apresenta um problema em máquina mais lentas (ou jogos mais pesados). Entenda porque: o setInterval agenda chamadas regulares à rotina aojPulse(), a cada X milisegundos. Até aí tudo bem, é isso que querermos para que nosso jogo pulse a cada X milisegundos.

Mas o que ocorre se a máquina for lenta a ponto da rotina aojPulse demorar mais de X milisegundos para executar? Uma nova chamada será feita a ela e por alguns milisegundos teremos duas aojPulse rodando – o que vai deixar a coisa ainda mais lenta. Com isso, dalí a X milisegundos, outra vez será chamada a rotina e isso vai acabar causando um acúmulo de rotinas em paralelo que vão degenerar totalmente o desempenho do jogo. Sem falar que as cópias da rotina rodando em paralelo estarão acessando as mesmas variáveis globais, e isso certamente vai causar todo tipo de comportamento estranho na lógica do jogo.

Na próxima parte veremos como fazer isso de uma forma diferente. Veremos também como melhorar a aparência do movimento mostrado na tela. Faremos isso deixando o render() independente do update() e utilizando interpolação das posições. Isso nos permitirá roda a lógica do jogo a taxa baixas enquanto a atualização da animação roda no máximo que a máquina permitir.

Até lá.

• Visualizar o exemplo do game loop
• Visualizar o exemplo de input
• Baixar o código fonte do exemplo

Nesta parte 1 aprenderemos como inicializar o canvas e carregar e exibir imagens.

A primeira coisa que precisamos saber para criar jogos em HTML 5 é… bem, HTML! É necessário o conhecimento básico de tags e de como criar pelo menos uma página vazia para conter o jogo.

A segunda coisa é um pouco de CSS, que serve para configurar os elementos inseridos na página (bordas, cores, tamanhos, etc). Jogos mais avançados em HTML utilizam muitos elementos fora do <canvas>, que vamos ver nesse tutorial, tirando proveito de outros elementos HTML para apresentar dados e de CSS para formatar este dados.

Finalmente, precisamos saber também Javascript (JS) para fazer a programação da lógica do jogo. A sintaxe é parecida com Java ou C++ e oferece suporte a objetos, embora não seja de fato uma linguagem orientada a objetos. Não oferece, por exemplo, recurso para herança, embora seja possível simular isto com construções mais avançadas.

Vou assumir que você entende pelo menos o mínimo de HTML e CSS e que sabe incluir scripts em uma página. Mas a necessidade disto é tão pequena para este tutorial que é até possível você aprender o necessário só estudando os exemplos.

Dito isso, vamos em frente.

O elemento <canvas>

Uma das novidades que a versão 5 da HTML trouxe foi a tag <canvas>, que cria na página um elemento que permite o desenho direto. Antes disso, para exibir imagens era preciso inserir um elemento <img> para cada uma. Ess elemento cria um objeto gráfico no navegador para armazenar e apresentar a imagem – este tipo de objeto consome recursos do sistema. Se todas imagens fossem sprites animados, teríamos um página bem pesada para o navegador renderizar. Com o canvas, no entanto, podemos desenhar nele todas imagens necessárias e o navegador só vai renderizar o canvas – como se fosse uma única imagem.

Além disso, com o canvas podemos desenhar primitivas gráficas, como linhas, retângulos e texto, além de ter efeitos de composição na aplicação das imagens. A grosso modo, o canvas é como uma imagem cujo conteúdo pode ser modificado. Utilizamos ele como se fosse a tela, desenhando nele cada quadro do jogo.

A inclusão de um elemento canvas na página é feita com a tag <canvas>>. No exemplo de código abaixo temos uma página HTML que contém esta tag e também um elemento <div> acima do canvas, dentro do qual vai uma informação textual.

<html>
    <head>
        <script src="aoj/aojcanvas.js"></script>
    </head>
    <body>
        <div id="info">Abrindo o Jogo - exemplo de uso do elemento canvas</div>
        <canvas id="canvas1" width="960" height="600"></canvas>
    </body>
</html>

Note que esta página inclui dois arquivos externos:

css/estilos.css: Contém o código CSS de formatação dos elementos. Esse código se refere aos elementos pelo seu ID, sendo que o div possui o ID “info” e o canvas possui o ID “Canvas1″.

O conteúdo deste arquivo é o seguinte:

body {
    margin: 0px;
    border: none;
    background-color: black;
}
#canvas1 {
    position: absolute;
    left: 50%;
    top: 50%;
    margin-left: -480px;
    margin-top: -300px;
    background-color: white;
}
#info {
    background-color: blue;
    color: yellow;
    font-family: Arial;
    font-size: 14px;
    font-weight: bold;
    padding: 5px;
    text-align: center;
}

Basicamente o código deste arquivo muda o fundo da página para preto, centraliza o canvas na tela e aplica estilo de fundo, cor e fonte ao div que apresenta o texto. É comum colocarmos os arquivos de estilo dentro de uma pasta “css”.

aoj/aojcanvas.js: este arquivo de script possui o código para inicialização e uso do canvas, contendo algumas rotinas criadas para facilitar a programação. Veremos como usar o canvas a seguir.

Usando o elemento canvas

Para obter uma referência ao elemento canvas, usamos o comando document.getElementById(), passando o ID que especificamos para nosso canvas. Obtemos a referência e atribuímos para uma variável, assim:

    var _aojCanvas = document.getElementById(canvasId);

Para desenhar algo nele, precisamos obter um contexto gráfico, o que é feito com o método getContext do canvas. Esse método requer um parâmetro que, atualmente, só pode ser “2d”.

Depois de obter o contexto, atribuindo ele a uma variável, usamos os métodos dele para desenhar. Veja abaixo:

window.onload = function() {
    var _aojCanvas = document.getElementById('canvas1');
    var ctx = _aojCanvas.getContext('2d');
    ctx.beginPath(); // inicia um desenho.
    ctx.fillStyle = 'blue'; // especifica a cor de preenchimento.
    ctx.strokeStyle = 'red'; // especifica a cor de contorno.
    ctx.rect(10, 10, 200, 100); // especifica um retângulo.
    ctx.rect(220, 10, 50, 50); // especifica outro retângulo.
    ctx.stroke(); // contorna o desenho (dois retângulos).
    ctx.fill(); // preenche o desenho (dois retângulos).
    ctx.beginPath(); // inicia outro desenho.
    ctx.strokeStyle = 'black'; // muda a cor de contorno.
    ctx.rect(50, 50, 100, 100); // especifica um retângulo.
    ctx.stroke(); // contorna o desenho (um retângulo).
}

O código acima desenha dois retângulos preenchidos de azul dentro do canvas. Cada desenho é iniciado com beginPath. Se este método não fosse chamado na segunda vez, o terceiro retângulo especificado ainda seria parte do primeiro desenho e o comando stroke iria contornar os três retângulos.

Perceba que o código foi colocado dentro de uma função atribuída ao evento onload da janela, para que seja executado apenas depois dela carregar completamente. Isso é importante porque se não for feito, o código executaria assim que fosse baixado – o que poderia ocorrer antes mesmo da declaração do canvas ter sido carregada – o que resultaria em erro porque o objeto canvas não existira ainda na página.

Métodos de atalho

A utilização do canvas para desenhar é algo de baixo nível. São precisos vários comandos para desenhar um retângulo na tela, por exemplo.

Para facilitar a programação, é interessante criar funções auxiliares que incluem todas chamadas necessárias para realizar determinadas ações. Assim criamos uma biblioteca própria. O arquivo aojcanvas.js é um exemplo de biblioteca deste tipo, embora incompleta.

Vejamos algumas funções deste arquivo para entender essa prática:

function aojSetCanvas(canvasId) {
    _aojCanvas = document.getElementById(canvasId);
}
 
function aojFillStyle(optionalNewValue) {
    var ctx = _aojCanvas.getContext('2d');
    if (optionalNewValue)
        ctx.fillStyle = optionalNewValue;
    return ctx.fillStyle;
}
 
function aojFillRect(x, y, w, h, optionalFillStyle) {
    var ctx = _aojCanvas.getContext('2d');
    ctx.beginPath();
    if (optionalFillStyle) {
        ctx.fillStyle = optionalFillStyle;
    }
    ctx.rect(x, y, w, h);
    ctx.fill();
}

A função aojSetCanvas() é usada para informar à nossa biblioteca qual elemento canvas desejamos usar – podemos ter mais de um canvas na nossa página. Passamos o ID como parâmetro e o elemento é obtido é armazenado em uma variável global, acessível para todas as demais funções.

aojFillStyle() permite obter o estilo de preenchimento atual, e também modificá-lo. Se for passado um parâmetro, ele é usado para modificar o estilo, que em seguida é retornado. Se não for passado o parâmetro, o estilo atual não é modificado, apenas retornado.

E a função aojFillRect() serve para desenhar um retângulo preenchido. Ela pode usar o estilo previamente definido, mas também aceita um quarto parâmetro opcional que, se informado, é usado como estilo para o retângulo.

Este tipo de comando permite mudar nosso exemplo para o seguinte:

window.onload = function() {
    aojSetCanvas('canvas1');
    aojFillRect(10, 10, 200, 100, 'blue'); // preenche um retângulo azul.
    aojFillRect(220, 10, 50, 50, 'blue'); // preenche outro retângulo azul.
    aojStrokeRect(10, 10, 200, 100, 'red'); // contorna um retângulo vermelho.
    aojStrokeRect(220, 10, 50, 50, 'red'); // contorna outro retângulo vermelho.
    aojStrokeRect(50, 50, 100, 100, 'black'); // contorna um retângulo preto.
}

Este exemplo ficaria ainda mais claro e resumido se criássemos uma função para desenhar um retângulo preenchido e já contornado. Até que ponto devemos ir na criação de nossa própria biblioteca de funções vai depender da natureza de cada projeto – aqueles procedimento que são repetidos muitas vezes são os que devem ser transformados em funções. Não recomendo tentar criar uma porção de funções de antemão porque você acabará com muitas que nunca vai utilizar, e mesmo assim não eliminará o risco de precisar de uma que não lembrou.

Desenhando imagens no canvas

É importante saber como desenhar primitivas gráficas no canvas, mas o principal recurso ainda é a apresentação de imagens, afinal, quase todo jogo é feito de sprites.

Para carregar uma imagem, basta criar um objeto do tipo Imagem e atribuir a URL do arquivo para o atributo “src”. Opcionalmente podemos atribuir uma função para o atributo onload – esta função será chamada quando o arquivo de imagem for carregado. Este é um recurso importante de usar em jogos com muitas imagens, para garantir que todas tenham sido carregadas antes de iniciar o jogo.

Novamente, para facilitar o trabalho, criamos uma função na nossa biblioteca:

function aojNewImage(imgURL, optionalLoadCallback) {
    var img = new Image();
    img.src = imgURL;
    img.onload = optionalLoadCallback;
    return img;
}

Esta função recebe a URL do arquivo da imagem e opcionalmente uma função de callback, que será chamada quando a imagem for carregada.

Para desenhar uma imagem no canvas, temos outra função:

function aojDrawImage(img, x, y) {
    var ctx = _aojCanvas.getContext('2d');
    ctx.drawImage(img, x - img.width / 2, y - img.height / 2);
    if (_aojShowImageCenter) {
        ctx.arc(x, y, 2, 0, 2*Math.PI, false);
        ctx.fill();
    }
}

Nesta função, apenas as duas primeiras linhas são responsáveis por desenhar a imagem no canvas. O IF é usado para desenhar um círculo no ponto (x,y) onde a imagem é desenhada, de forma a enxergarmos onde fica esse ponto. É útil para debugar posicionamento.

Transformações geométricas

O canvas oferece métodos para aplicar transformações geométricas no que é desenhado nele. Por exemplo, podemos rotacionar ou aumentar e diminuir uma imagem no momento de desenhá-la.

É importante saber, no entanto, que uma vez especificada uma transformação, ela fica em efeito para tudo que for desenhado depois. Portanto, depois de aplicar uma rotação, por exemplo, e desenhar a imagem desejada, é preciso aplicar a rotação inversa para deixar o canvas no estado normal antes de desenhar as próximas imagens.

Abaixo está uma função para desenhar uma imagem com transformação de escala. Como parâmetros ela recebe o objeto imagem, a posição (x, y) onde ele deve ser desenhado e os fatores de escala sx e sy.

Veja que para o efeito ser aplicado corretamente é preciso usar uma outra transformação em conjunto – a translação. Fazemos a translação para que a posição da imagem seja transferida para a origem (ponto (0,0)) e então a escala é aplicada. Depois de desenhada a imagem, desfazemos a escala e a translação aplicando estas transformações com o valor inverso.

function aojDrawImageScale(img, x, y, sx, sy) {
    var ctx = _aojCanvas.getContext('2d');
    ctx.translate(x, y);
    ctx.scale(sx, sy);
    ctx.drawImage(img, -img.width / 2, -img.height / 2);
    ctx.scale(1/sx, 1/sy);
    ctx.translate(-x, -y);
    if (_aojShowImageCenter) {
        ctx.arc(x, y, 2, 0, 2*Math.PI, false);
        ctx.fill();
    }
}

No arquivo aojcanva.js existem outras funções deste tipo. Este arquivo e os demais estão no Zip no final da página.

Conclusão

Neste artigo vimos o basico da utilização do canvas para mostrar imagens.

No site abaixo há um guia de referência do canvas para ser impresso, com todos os comandos. O Autor (Jacob Seidelin) também escreveu um livro sobre jogos em HTML 5.
http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html

No próximo artigo veremos como implementar um game loop e utilizar o teclado e mouse.

• Visualizar o exemplo funcionando
• Baixar o código fonte do exemplo

Parece incrível e é, mas a configuração do ambiente ainda é um desafio para quem não está acostumado a trabalhar com Git, Maven, Ant e outros diretamente. Nesse curto passo a passo mostramos como configurar PlayN no Eclipse.

O projeto PlayN está passando por modificações neste exato momento. Por isso este passo a passo acabou demorando mais do que eu gostaria – depois que prometi ele, o PlayN simplesmente parou de funcionar em função da atualização da API do Android. Hoje este problema está resolvido, mas para isso o PlayN não vem mais com o pacote de samples – demonstrações do uso da plataforma. Eles poderão ser baixados separadamente em breve – quando ocorrer, informamos aqui.

[ATUALIZAÇÃO]

O PlayN está agora disponível no Maven Central, que é um repositório público. Isso facilita muito o processo todo, já que não é preciso baixar todos os fontes do PlayN para a máquina para poder utilizá-lo – só é preciso criar um novo projeto do tipo Maven e basear ele no arquétipo desejado do Maven Central.

Incluí abaixo o how-to para criar um novo projeto do PlayN no NetBeans, que é mais amigável que o Eclipse, mas o processo é praticamente o mesmo para ambos.

Todo o processo é feito em uma máquina limpa, sem nada previamente instalado. Utilizei o Netbeans 7.0.1 recém instalado e com todas atualizações aplicadas.

Os dados para o arquétipo de projeto são os seguintes:

Segue post original.

Este how-to está longe de ser à prova de falhas – muita coisa depende da configuração da sua máquina se você já tiver o Eclipse ou Maven instalado. Se você não tem nada disso, é provável que a coisa funcione sem problemas.

Um problema que tive foi o Eclipse rodar com JRE, que é run-time do Java para usuários finais, não para desenvolvimento. E com isso não conseguir compilar algumas coisas. Se você desconfiar que seu problema é esse, recomendo desinstalar temporariamente o JRE e deixar instalado apenas o JDK (versão de desenvolvimento do Java). Se o Eclipse não iniciar, por não achar mais o Java, abra o arquivo eclipse.ini (que fica na pasta do Eclipse) e acrescente a ele as seguintes linhas (são duas):

-vm
C:\Program Files\Java\jdk1.7.0_01\jre\bin\client\jvm.dll

O caminho do Java pode variar conforme sua configuração, principalmente a versão.

• Clique aqui para ver a apresentação do how-to e boa sorte.

Sites citados:

• Eclipse

• PlayN
  • Endereço do repositório para obter o PlayN:

    https://code.google.com/p/playn

• Plugin do Google para o Eclipse
  • Endereço para instalação de novo software no Eclipse:

    http://dl.google.com/eclipse/plugin/3.7

• Plugin de integração do Maven com o Web Tools Plataform do Eclipse
  • Endereço para instalação de novo software no Eclipse:

    http://download.jboss.org/jbosstools/updates/m2eclipse-wtp

• Plugin ADT (Android Development Tools) para Eclipse (não necessário para o tutorial acima)
  • Endereço para instalação de novo software no Eclipse:

    https://dl-ssl.google.com/android/eclipse/

Há quem diga, até, que o futuro dos webgames seja o HTML 5 em detrimento do Flash, mas embora isso seja discutível, é fato que a tecnologia merece consideração e tem aplicação imediata nos projetos atuais.

HTML é a linguagem utilizada na criação de páginas web. Durante muito tempo a criação de jogos para web podia ser feita apenas com tecnologias separadas do HTML, como Flash, applets Java, Untity3D ou outra, todas embutidas nas páginas por meio de plugins. Estes plugins são a saída que o programador web tem para a criação de aplicativos e jogos para web, mas ao mesmo tempo que permitem isso, possuem também uma fraqueza: sua implementação é inconsistente nas várias plataformas existentes. Mesmo plugin do Flash, o mais difundido de todos, apresenta diferenças em sua versão para Linux, sem falar que não esta presente nos smartphones e tablets da Apple – tablets que estão substituindo o netbook entre os executivos e profissionais liberais – e sim, eles são consumidores de jogos!

A última especificação do HTML, a versão 4.01, tem mais de 10 anos – já era hora de ter uma atualização. A versão 5 ainda está em desenvolvimento nesta data, mas alguns recursos já são considerados estáveis e seguros para uso. Este é o caso do elemento <canvas>, que oferece uma área onde podemos desenhar livremente e assim cai como uma luva para o desenvolvimento de jogos. Este é o recurso do HTML 5 que propiciou uma grande onda de jogos em HTML puro, alguns indistinguíveis de jogos em Flash.

No entanto a atualização do padrão, por si, não serviria de nada se os navegadores não implementassem ele. Felizmente desde as versões do ano passado dos navegadores, vários recursos do HTML 5 já estão disponíveis. Com relação ao <canvas>, a exceção é o Internet Explorer. Enquanto os demais (Chrome, Firefox, Safari e até mesmo o Opera) já oferecem o <canvas> até mesmo com aceleração por hardware (WebGL), o IE ainda sequer oferece o elemento.

Mas isto não quer dizer que usuários do IE ficam de fora, já que é possível adicionar suporte a <canvas> nele. Ninguém fica de fora mesmo! Esta tem sido uma das principais vantagens dos jogos em HTML 5, principalmente para quem trabalha com jogos criados sob encomenda, para o mercado de advergames por exemplo. O cliente espera que o jogo que ele encomendou funcione em todas plataformas, e falamos aqui de navegadores, sistemas operacionais, smartphones e tablets. Não é ficção a situação onde o cliente (executivo) avisa que vai revisar o jogo no final de semana, em casa, e na segunda feira vem reclamando que o jogo nem abriu. “Mas como, qual seu navegador?”, você pergunta e ele responde: “Heim? Não sei… é um iPad 2!”.

E aí, como explicar que o gadget do momento, que custa milhares de reais, e pelo qual ele trocou o antigo netbook, não roda seu jogo? Como fazer para rodar? Flash não vai… applet java? Também não. Programar tudo de novo em objective-C? Pode ser impossível porque, além do trabalhão que vai dar (para suportar apenas uma plataforma), você precisaria ter um computador Mac e um iPad ou iPhone para testar – se esta não é sua plataforma atual de desenvolvimento, é um investimento grande.

Nem preciso falar que a solução é o HTML 5. Embora os smartphones mais comuns não sejam os melhores exemplos de desempenho, os dispositivos Android mais modernos, o iPhone e iPad possuem capacidade para rodar este tipo de jogo. Android pode rodar jogos em Flash, mas os dispositivos da Apple não. Aliás, se tomarmos por base o post do leitor Fabricio Boemeke, ele cita duas desvantagens dos web games: no caso de baseados em plugins, são mais rápidos mas mesmo assim não tanto quanto jogos nativos. Com aceleração por hardware do WebGL, o HTML 5 deixa isso no passado. E no caso de jogos baseados apenas no navegador, cita a desvantagem de serem apenas on-line, de forma que a pessoa precisa estar conectada para jogar. O Angry Birds que está na loja de aplicativos do Chrome mostra que isso também não é mais uma limitação, sendo instalado localmente, ficando acessível dentro do Chrome mesmo quando levamos o notebook para férias na praia, onde fica desconectado.

Mas falar apenas em HTML é metade da história. O HTML é uma linguagem de marcação, que permite incluir elementos em uma página. Campos de formulário, texto, imagens, vídeos, etc. Mas isso tudo é estático, ou seja, com o HTML você especifica onde uma coisa é inserida e lá ela fica. A ação toda precisa ser escrita em uma linguagem de programação – e aí entra o Javascript (JS). Com sintaxe baseada em C++ e Java, porém com suporte apenas parcial à orientação a objetos, o Javascript é uma linguagem poderosa o suficiente para a criação de jogos.

Novamente o papel dos navegadores é importantíssimo. Sendo o Javascript uma linguagem interpretada (em oposição a compilada), sua velocidade de execução depende da máquina interpretadora que o navegador possui. Atualmente o Chrome talvez seja o navegador mais rápido para execução de código em Javascript, mas nenhum dos outros vai fazer feio, Internet Explorer, Firefox, Safari ou Opera.

E no quesito bibliotecas e frameworks? Existe facilidades para criação de  jogos em HTML 5? Sim, existe. Ainda não temos uma grande quantidade de frameworks completos e como isto é um diferencial no mercado, os melhores são pagos. Mas bibliotecas específicas, como bibliotecas de física, existem – geralmente são bibliotecas conhecidas que foram portadas para o Javascript. Inclusive nosso leitor Luiz Otávio Afonso, que mexe bastante como Game Maker, já nos informou que este software vai gerar jogos em HTML 5.

Mas veja que a programação de um jogo em Javascript não é nada complicada. Pode ser comparada a Java ou Action Script 3 – em certos casos, é ainda mais fácil, porque permite que alguns elementos, como HUD e outras partes da interface sejam feitas diretamente com HTML padrão.

Quer ter uma idéia do que é possível fazer com HTML 5? Abaixo cito alguns links que vão mostrar isso.

• Existem muitos “joguinhos” por aí, mas vamos começar com os produtos mais bem acabados. Quem está por dentro de jogos certamente já ouviu falar de Angry Birds, o sucesso do iPhone e depois do Android. Já faz um tempo que é sucesso também na loja de aplicativos do Chrome e hoje é um dos melhores exemplos de jogo em HTML 5:
  • http://chrome.angrybirds.com/
  • Roda nos principais navegadores, menos o Opera.

• Já que o Opera foi deixado de fora do Andry Birds, segue uma iniciativa própria:
  • http://operasoftware.github.com/Emberwind/

• Outro exemplo de produto bem acabado é este jogo de bilhar. Ele faz bom uso do HTML puro para elementos da interface:
  • http://agent8ball.com/

• Aqui um concurso da Mozilla para jogos em HTML5. Tem vários exemplos:
  • https://gaming.mozillalabs.com/

• Os dois sites abaixo possuem excelentes exemplos:
  • http://www.effectgames.com/effect/
  • http://www.canvasdemos.com/type/games/

• Finalmente, dois sites que aceitam jogos em HTML5 para publicação:
  • http://html5games.com/
  • http://www.html5games.net/

Ficou interessado?

Bem, este post serviu para apresentar a tecnologia para quem não conhecia e talvez motivar quem conhecia mas não tinha dado a devida importância. Estamos planejando também um tutorial sobre a criação de jogos em HTML 5 – se você está interessado, e gostaria de ver esse tutorial o mais rápido possível, faça seu comentário! Com uma quantidade maior de interessados, o tutorial sai mais cedo…

quinta-feira é dia de podcast e aqui estamos para mais um episódio do PodAbrir. Hoje será um programa especial. Estamos iniciamos um arco de episódios voltados às profissões existentes em uma empresa de games. Neste episódio discutiremos o que é necessário para ser um bom programador de jogos. Quais são as linguagens, técnicas e postura adequada para se tornar um bom profissional nesta função? Confira as respostas e comente

Participantes: Everton Vieira  e Alessandro Nornberg

Categoria: Técnico – Programação

Links comentados na seção de recados e e-mails

• Blog do Eduardo Pereira;
• Taipa de açude;
• Google PlayN.

Links comentados neste episódio

• Padrões de Projeto aqui no Aoj;
• Braid;
• Post sobre dicas para se tornar um bom programador de games;
• Palestras sobre Arquitetura de Componentes
  
  • GDC Canadá 2009 (inglês);
  • GDC Canadá 2010 (inglês).
    • Site do palestrante.

Trilha Sonora

• You Shook me all night long – AC/DC

PodCast

Siga o nosso podcast em http://abrindoojogo.com.br/feed/podcast. Para o Itunes, basta copiar e colar este endereço em “Advanced – Subscribe to podcast…” ou acesse direto na store por aqui.

Hoje daremos continuidade ao nosso arco de posts sobre a matemática nos games. No epsisódio anterior, vimos como utilizar a rotação de ponto em um game de corrida top down (Super Sprint). Neste episódio vamos um pouco além da proposta orginal, adentrando em uma outra área de conhecimento que, apesar das semelhanças, é uma ciência a parte. Estamos falando da “temida” Física. Mas não se preocupe, os seus pesadelos do ensino médio, não estarão de volta

Bom, precisamos finalizar o nosso protótipo do Super Sprint, certo? Para isso, precisamos implementar uma feature muito importante para um game de carro, a Aceleração. Se pesquisarmos em nossos alfarrábios, veremos que aceleração é variação de velocidade de um corpo em um determinado intervalo de tempo. O resultado esperado seria o carrinho levar algum tempo para atingir sua velocidade máxima, em seguida, desacelerando gradativamente. Para isso, criaremos uma variável acceleration que será aplicada ao ponto rotacionado do nosso exemplo anterior. Ela funcionará como um acréscimo/decréscimo percentual ao ponto de destino. Observe o trecho de código genérico com comentários a seguir:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

//Novas variáveis
var acceleration:Number=1;
var accelerrationLimit:Number = 1.5;
var deceleration:Number=0.08;
 
function onUpdate(event:Event)
{
	if(left)
		angle -= angleVariation;
	if (right)
		angle += angleVariation;
	if(up)
	{
		newPoint = getNextPoint(angle,velocity);
                //removemos a movimentação do carro deste ponto
		//car.x += newPoint.x;
		//car.y += newPoint.y;
 
              // Se aceleração não estiver no limite, incrementa
              if(aceleration <= acelerrationLimit)
			aceleration += 0.1;
	}
 
        // A moviemntação do carro fica fora do IF, sendo acionada agora a todo looping do game.
	car.x += newPoint.x * acceleration;
	car.y += newPoint.y * acceleration;
 
	//Em todo looping decrementa a aceleração não permitindo que esta seja negativa
        acceleration -= deceleration;
	if(acceleration < 0)
		acceleration = 0;
 
	if(angle < 0 )
            angle = 360 + angle;        
        else if(angle > 360)
		angle = 0;
 
	car.rotation = angle;
	tAngle.text = "ângulo: "+angle
}

Com esta pequena alteração, já teremos um resultado interessante. Perceba que agora o carro acelera gradativamente e, mesmo depois de soltar o acelerador (seta para cima), ele simula um efeito de desaceleração e inércia.

Bom, com a aceleração já implementada, partimos para a velocidade. A física descreve a velocidade uniforme como distância/tempo. Simples não? Mas, temos que ter uma atenção para a distância em um espaço 2D. Para calcularmos esta reta não podemos apenas diminuir os pontos. Observe na figura a seguir como duas retas de mesmo tamanho podem parecer diferentes dependendo de sua angulação.

Para solucionar este problema precisamos utilizar a nossa velha amiga trigonometria. A solução chama-se cálculo da reta, e para entendê-lo basta lembrarmos do post passado, onde mostrei que seria possível enxergar uma triângulo retângulo entre os pontos. Sendo assim, podemos identificar: Cateto oposto (ao ângulo), cateto adjacente (ao ângulo) e a hipotenusa. Estes três fazem parte de uma fórmula bastante conhecida:

(hipotenusa)² = (catetoOposto)² + (catetoAdajscente)²

Queremos encontrar exatamente o valor da hipotenusa, correto? É ela que corresponde ao tamanho da reta entre os dois pontos, ou seja, a nossa distância. Isolando a variável, ficamos com:

hipotenusa = Raiz Quadrada de (catetoOposto)² + (catetoAdajscente)²

Com esta fórmula em mãos, já temos todas as ferramentas, basta partir para o código. Vamos lá

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

var acceleration:Number=1;
var accelerrationLimit:Number = 1.5;
var deceleration:Number=0.08;
 
//Novas variáveis
var distance:Number;
// ponto utilizado no cálculo da distância, armazenando a posição anterior do carro
var lastPoint = new Point(car.x,car.y);
// tempo utilizado no cálculo da velocidade, armazenando os milisegundos entre um pulso e outro
var lastTime:Number = new Date().time;
 
function onUpdate(event:Event)
{
         //Melhoria que permite girar o carro apenas quando houver aceleração
	if(acceleration!=0 && left)
		angle -= angleVariation;
	if (acceleration!=0 && right)
		angle += angleVariation;
	if(up)
	{
		newPoint = getNextPoint(angle,velocity);
 
		// Se aceleração não estiver no limite, incrementa
		if(acceleration <= accelerationLimit)
			acceleration += 0.1;
	}
 
	car.x += newPoint.x * acceleration;
	car.y += newPoint.y * acceleration;
 
	acceleration -= deceleration;
 
        if(acceleration < 0)
	{
		acceleration = 0;
                tVelocity.text = "velocidade: 0";
	}
 
	if(angle < 0 ) 		
          angle = 360 + angle; 	
       else if(angle > 360)
	  angle = 0;
 
	car.rotation = angle;
	tAngle.text = "ângulo: " + angle;
 
        // Calcula a distancia através do novo método criado.
	distance = calcDistance(lastPoint, new Point(car.x,car.y));
 
        // Só calcula a velociadade se a distância for superior a 10px. Isso evita que o cálculo seja executado a todo momento, deixando o indicador da tela ilegível.
	if(distance > 10)
	{
                 // Atribui a caixa de texto a distancia dividida pelo tempo percorrido. Dividimos o resultado por 1000 para obtermos a unidade pixels/seg.
		tVelocity.text = "velocidade: " + Math.round(distance/( (new Date().time-lastTime) / 1000 ));
		lastTime = new Date().time;
		lastPoint = new Point(car.x,car.y);
	}
 
}
 
function calcDistance(point1:Point, point2:Point)
{
	//calcula o tamanho do cateto adjascente
        var adjoiningSide:int = Math.abs(point1.x - point2.x);
	//calcula o tamanho do cateto oposto
	var oppositeSide:int = Math.abs(point1.y - point2.y);
	return Math.sqrt(Math.pow(adjoiningSide,2) + Math.pow(oppositeSide,2));
}

Vejam como ficou o resultado final.

O que achou do segundo post sobre matemática? Experimente modificar os valores iniciais de aceleração para obter outros resultados. No próximo veremos um importante conceito chamado Vetores. Não, não confunda com o Objeto de programação similar ao Array, esse vem da matemática

Até mais e não esqueçam de deixar seus comentários com dúvidas ou sugestões de código.

já faz algum tempo que começamos uma série de posts sobre a entrevista feita com a equipe de desenvolvimento do Super Mário Bros. Retomando essa série, vejam que interessante a abordagem utilizada na época para a função de projeto de níveis e a gigante preocupação e importância que teve que ser dada para a falta de memória e limitações do hardware existente na época.

Então… vamos lá!

O projeto de níveis em conjunto

Tezuka: Não estamos falando de um game show sobre compras, mas precisamos impor limites no game. Os novos colaboradores não tem bom senso para trabalhar com limites.

Iwata: Nos dias de hoje, se alguém pede para você fazer algo com 30 bytes de memória, você não consegue fazer nada. Mas naquele tempo, era possível. “Uau, são mais 10 objetos no game!” (Risos)

Miyamoto: Nós gostávamos… Isso não nos abalava.

Tezuka: É isso aí!

Iwata: Tezuka, você entrou para o time como um artista. Você gostava de todas essas restrições tecnológicas também?

Tezuka: Era realmente divertido. Eu havia acabado de entrar para a companhia e ficava sempre perguntando quais eram as restrições que tínhamos para desenvolver o projeto.

Iwata: Isso foi divertido para mim também. Na época, eu ficava muito feliz quando alguém chegava para mim e dizia: – Estou com problemas porque não há memória suficiente. Isso fazia com que o programador se destacasse resolvendo este tipo de situação.

Miyamoto: Se nós deixássemos para o Iwata resolver, ele resolveria.

Iwata: Eu gostava do jeito que eu trabalhava.

Nakago: (Folheando alguns documentos) Por exemplo, este castelo foi assim.

Nakago: No início o castelo é pequeno. No final da fase, o castelo é grande. Mas se pararmos para analisar o castelo é o mesmo. Usamos muito reaproveitamento de códigos.

Tezuka: Na verdade, o que fizemos foi pegar o topo do castelo grande que já estava pronto e colocamos ele no início como um castelo pequeno.

Nakago: Se olhar atentamente para o andar superior, vai ver que tem uma porta, mas para nós aquilo é uma janela. (risos)

Iwata: (risos)

Nakago: Estávamos sempre pensando em alternativas de viabilizar o game.

Iwata: O objetivo era fazer o game ficar muito rico com pouca quantidade de dados pois nossa memória era muito limitada.

Nakago: Suamos muito para fazer muito com pouco espaço de memória.

Iwata: Nakago, você começou a fazer o Super Mario Bros e implantou vários artifícios chaves de jogos anteriores. Qual foi o ponto que você acha que realmente seria inovador?

Nakago: Quando fizemos o plano de fundo do game.

Iwata: Quando trocaram o fundo preto para o céu azul?

Nakago: Sim!

Miyamoto: (Pegando um folheto de planejamento) Aqui está.

Nakago: Oh… lá está o Mario.

Iwata: Tezuka, foi você que desenhou este draft?

Tezuka: Eu acho que foi o Miyamoto.

Iwata: Miyamoto, foi você?

Miyamoto: Eu desenhei isso? Hum… Sim, fui eu. Eu assinei este draft.

Iwata: (Olhando para a data) Está assinado em 28 de fevereiro de 1985, apenas uma semana depois das primeiras especificações.

Miyamoto: Não é que eu trabalho rápido mesmo? (risos)

Iwata: (risos)

Miyamoto: No canto direito superior tem uma paleta de planejamento de cores. Usamos muito isso para trabalhar as cores dos objetos semelhantes.

Iwata: A vegetação e as nuvens são feitas com um mesmo objeto apenas trocando as cores.

Miyamoto: Tudo isso em função das restrições de capacidade do hardware que estavamos usando na época – Famicom.

Iwata: Foi um grande quebra-cabeça fazer o Super Mario Bros.

Miyamoto: Foi divertido fazer.

Nakago: Com certeza foi.

Miyamoto: Foi divertido para nós fazer o game. E, o projeto de níveis ficou interessante para os jogadores. Os níveis de dificuldade ficaram divertidos.

Iwata: Quem projetou os níveis?

Miyamoto: Tezuka e eu.

Tezuka: Nós projetamos em conjunto.

Miyamoto: E mais ninguém. Fomos nós dois.

Nakago: É verdade, foram somente eles.

Miyamoto: Projetamos todos os níveis em conjunto usando traços das nossas personalidades. Incorporamos isso no projeto de níveis para que ficasse interessante.

Iwata: Tezuka, o que você tinha em mente na época sobre o posicionamento de inimigos? Mesmo 25 anos depois, todos reconhecem que o posicionamento dos inimigos no game é algo muito interessante. Como esse mapeamento foi feito?

Tezuka: Hum…

Iwata: “Por acaso” (risos)

Tezuka: Não foi por acaso. (risos) Eu projetava um nível, simulava como o jogador iria jogar e as possibilidades que ele tinha e mostrava para o Miyamoto.

Iwata: Entendi!

Tezuka: Eu pensava: “O jogador vai provavelmente fazer isso aqui. Quando um inimigo aparecer aqui o jogador vai correr dessa forma. Mas ele pode bater a cabeça do Mario aqui se for fazer aquilo. …” Então íamos consertando o que não estava bom.

Iwata:  Tezuka, você comentou sobre alguns mapas que o Miyamoto fez. Certo?

Tezuka: Eu?

Miyamoto: (risos)

Iwata: Ou foi o Miyamoto – o mestre? Não lembro.

Tezuka: Ele era o mestre. Naquela época só era possível ver a versão do trabalho uma vez por dia.

Iwata: Ah, sim. Essa era outra restrição do projeto. Na época não tínhamos todas as ferramentas que temos hoje e não podíamos testar a cada item novo inserido no game. Então montávamos um mapa de tudo no papel primeiro.

Tezuka: Quando me perguntasse, achei realmente que eu tinha feito isso.

Iwata: Desculpe. (risos)

Miyamoto: O trabalho era duro!

Fim da parte 4

Então pessoal, o que acharam? Não tem como negar que a criatividade faz milagres. Quando maiores as limitações, mais criativo o game developer deve ser. Quais seriam as maiores limitações que encontramos hoje? São as mesmas de antigamente? Comentem …

fonte:Entrevista Iwata_asks Mario 25th

Começamos hoje um novo arco de posts técnicos. O assunto? Um elemento presente desde Tennis for Two de 1958 até o novo Battle Field 3 – a saudosa ciência conhecida como Matemática. Para alguns, um bixo de sete cabeças – para outros, nem tanto. Porém, sempre tendo um papel importantíssimo na história do desenvolvimento de jogos. Esta ciência muitas vezes não recebe a devida atenção por parte dos desenvolvedores. Muito programadores desconhecem que vários dos seus problemas podem ser resolvidos com um conhecimento mínimo de trigonometria. Estamos aqui para mudar esta realidade.

Falando em trigonometria, ela será a base para o nosso primeiro assunto. Para quem não recorda, ela é o segmento da matemática que foca o estudo das relação dos lados de um triângulo retângulo. Porém, a ideia aqui não será repetir os ensinamentos do meu professor de ensino médio, mas sim, através de exemplos práticos, mostrar a utilidade e aplicação da matemática nos games. Para isso, criaremos um case, um game básico, para justificar nossos ensinamentos. Neste primeiro post, vou utilizar um título que fez parte da minha infância. Logo quando ganhei o meu Phantom System (versão da Gradiente para o NES), peguei emprestado de um colega um divertido game de corrida chamado, Super Sprint.

Ok,  temos que dar um desconto, isso foi em 1991 . Apesar de simples, utilizando uma visão top-down da pista de corrida, Super Sprint rendeu boas horas de diversão. Vamos experimentar um pouco da sua mecânica através do protótipo a seguir. Clique e utilize as setas do teclado para girar e mover o carro.

Analisando o protótipo, você consegue imaginar o algoritmo por trás do game? Qual seria a técnica responsável por fazer o carro girar e movimentar-se em qualquer direção?

Temos basicamente dois movimentos para o carro, translação e rotação. Para obtermos o movimento de translação, bastaria somarmos a velocidade nas posições x e y . Algo como, se seta para direta pressionada, x += velocidade. Porém, Super Sprint é um pouco mais complexo que isso. Não podemos simplesmente somar a velocidade nos dois eixos. Você pode notar que podemos mover e girar o carro em qualquer direção. Observe que o movimento é realizado levando em conta o ângulo do veículo (canto superior direito). A seta para cima, sempre move o carro para frente, enquanto as setas para direita e esquerda aumentam e diminuem o ângulo de rotação.  Como faremos isso? Vamos primeiro ver um exemplo. Observe a imagem a seguir para entender bem o que precisamos. Através de um determinado ângulo (qualquer um) e um distância (velocidade) precisamos encontrar o ponto seguinte para movermos o nosso carrinho.

Figura 1

A posição atual do nosso carro seria x=10 e y=20. A velocidade, neste exemplo, está configurada para 20 pixels. Sendo assim, chegaríamos no  ponto p1 de coordenadas x=25 e y= 33. O que devemos fazer para chegar nestes valores? A matemática nos auxilia na solução desse problema através de um conceito chamado rotação de ponto. Você já ouviu falar de seno e cosseno? Entendeu como eles funcionam e qual a sua utilidade? Pois é, durante o ensino médio isso pode não ter ficad0 muito claro, mas vamos acabar com os seus problemas .

Figura 2

Observe a imagem a cima. A definição nos diz que, dado um círculo trigonométrico de centro (0,0) e raio de valor 1, o seno de um angulo X é sua representação no eixo Y. Já o Cosseno,  é a representação no eixo X. Lembre-se, cosseno (com sono), é o eixo deitado . É importante também registrar que os pontos formam um triângulo retângulo (veremos a utilidade disso nos próximos posts).

O valor de seno ou cosseno para um ângulo X pode ser obtido através das funções Math.sin e Math.cos de sua linguagem de programação favorita, ou através da tabela trigonométrica.

Ok Everton, mas como isso irá me ajudar a fazer a movimentação do carro exatamente? Bom, a matemática vai fazer a pior parte. Com o ângulo em mãos, e utilizando seno e cosseno, vimos que é possível encontrar o ponto que seria a extremidade de uma reta de tamanho 1. Depois disso, basta multiplicarmos pelo valor desejado para obter o resultado. Vamos fazer uma prova com o exemplo da figura 1:

• A posição atual é x=10 y=20
• O ângulo de rotação é de 40º
• A velocidade (distância a ser percorrida) é de 20 pixels
• Cosseno de 40º é 0,766
• Seno de 40º 0,6428
• Multiplicando os valores de seno e cosseno pela velocidade de 20, relacionando-os a x e y, teremos:
  • x = 15,32
  • y = 12,85
• Note que esta técnica parte do princípio que o ponto de equilíbrio está no centro do círculo. Sendo assim, teremos que fazer a translação do nosso carro somando sua posição atual (x=10,y=20) aos valores obtidos, resultando em:
  • x = 25,32
  • y = 32,85
• Arredondando os valores, chegamos no resultado exato apresentado pela figura 1.

Vamos ver como ficaria o código genérico para este mecânica.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

// Em um método que executa de forma intermitente (pulso do game)
function onUpdate(event:Event)
{
   // Testa as teclas do teclado para modificar o ângulo
   if(left)
     angle -= velocity;
   if (right)
     angle += velocity;
   // Se a seta pra cima estiver pressionada, calcular o próximo ponto e somar na posição atual do carro
   if(up)
   {
     var newPoint:Point = getNextPoint(angle,velocity);
     car.x += newPoint.x;
     car.y += newPoint.y;
   }
 
   // Testa as extremidades dos ângulos, algumas linguagens suportam graus multiplos de 360 fazendo automaticamente a relação
   if(angle < 0 )
      angle = 360 + angle;    
   else if(angle > 360)
     angle = 0;
 
   car.rotation = angle;
}
 
// Método que calcula a rotação do ponto através de um angulo e um comprimeto
function getNextPoint(angle, lenght):Point
{
  var newPoint:Point = new Point();
  // Precisamos convertar o valor de graus para radianos devido a função da classe Math trabalhar com esta unidade.
  newPoint.x = Math.cos(convertDegreesToRadians(angle))* lenght;
  newPoint.y = Math.sin(convertDegreesToRadians(angle))* lenght;
  return newPoint;
}
 
//Método que converte um valor em graus para radianos
function convertDegreesToRadians(degrees:int)
{
    return (Math.PI * degrees) / 180;
}

E ai, o que acharam? Ficou mais claro a aplicação do Seno e Cosseno para encotrarmos o ponto rotacionado?O nosso Super Sprint ainda não está pronto. Precisamos acrescentar um pouco de física para deixá-lo mais próximo da versão original. Mas, isso fica para o próximo post

Mandem suas dúvidas através dos comentários.

Grande abraço e até a próxima.

Após o nosso podAbrir sobre Unity3D, vários leitores pediram dicas de como configurar um editor externo para programar nesse interessante game engine. Bom, montei rapidamente um post mostrando as principais dicas pra esta configuração. Vamos aos passos

MonoDevelop

Conforme comentamos no podcast, a primeira opção para o programador seria o MonoDevelop. Um editor que já acompanha o pacote de instalação do Unity3D desde a versão 3. Apesar de ser a ferramenta padrão para edição de código, vamos apenas reforçar os passos necessários.

Passo 1

Passo 2

Após configurar, ou conferir, o editor padrão. Basta sincronizar os scripts de seu projeto. Para fazer isso, basta acessar a opção Sync MonoDevelop Project no menu Asset, conforme mostra a figura abaixo.

Passo3

Após a sincronização, basta dar dois cliques sobre o asset de script para o editor abrir automaticamente. Abaixo confira o layout do MonoDevelop.

MonoDevelop

Eu considero o MonoDevelop um editor leve e com boas funcionalidades. Para projetos de pequeno e médio porte, não há dúvida que ele dará conta do recado. Sua versão padrão não acompanha nenhum tipo de controle de versão de arquivos, porém, isso poderá ser resolvido através de plugins adicionais, ou até mesmo, de clientes de controle de versão como o Tortoise.

Visual Studio C#

Mesmo o MonoDevelop sendo uma boa opção, não podemos deixar de comentar sobre a integração do Unity3D com o Visual Studio C#, o editor da Microsoft bastante conhecido dos programadores de .Net. Se você já utiliza esta IDE, há várias vantagens em manter o ambiente de desenvolvimento. Nesse caso, teremos duas formas distintas de integração, uma para a versão Pró (paga) e outra para a versão Express (gratuita).

Para a versão paga, não há segredos. Basta o programador seguir os passos 1, 2 e 3, clicando em Browse e selecionando o executável do editor da Microsoft.  Já a versão Express, tem uma significativa limitação. Além de um erro na opção de sincronizar o projeto (que mostrar ainda o nome do MonoDevelop), a integração com esta versão do editor, não permite que o programador clique no Script e abra a IDE automaticamente mostrando o código para edição. O impecilho pode parecer pequeno, mas com o tempo pode realmente atrapalhar o desenvolvimento.

Para solucionar este problema, há algumas soluções alternativas. Abaixo listo uma das mais simples.

1) Baixe o programa ClassExec, extraindo o .exe para uma pasta conhecida, por exemplo d:\visualUnity.

2) Crie um arquito BAT com o seguinte código:

 "d:\visualUnity\classexec.exe" %1 --class .cs

3) No Unity, siga os mesmos passos 1, 2 e 3 descritos neste post, selecionando o arquivo BAT recém criado como o seu editor externo.

4) Após clicar na opção para sincronizar, os arquivos de Script estarão agora relacionados corretamente ao Visual C# Express, permitindo que o programador utilize o clique duplo para editá-los.

Esta solução, aparentemente nada oficial, está resgistrada na própria wiki da ferramenta, confira.

Bom pessoal, seria isso. Espero que o post bem técnico tenha respondido as dúvidas. Até a próxima