estamos de volta com mais um podcast sobre desenvolvimento de games. No episódio número 13 do PodAbrir, trazemos a segunda parte da interessante entrevista com Alessandro Lima, Character Design da Aquiris Game Experience.

Na continuação, Alessando fala sobre os projetos que participou e também compartilha detalhes do processo de produção.  Na seção sobre games indie, comentamos sobre o Bastion e a tecnologia Native Client do Google Chrome.

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

• Site do Alessandro Lima
  • www.alessandrolima.com
• Artistas:
  • www.luisroyo.com
  • www.bromart.com
  • www.3d.sk
• Projetos:
  • Vales Magicos
  • Live Demos da Unity 3D
  • Super Volei Brasil
  • Gillete Young Guns
  • Axe Dart Temptation
  • Axe Music Star
  • Goodyear Eagle GT
  • Quantum Conflict

Visitem nossa página no Facebook

]]> http://abrindoojogo.com.br/podabrir-13-3d-character-design-parte-2/feed 5 1:03:12 Olá gurizada, estamos de volta com mais um podcast sobre desenvolvimento de games. No episódio número 13 do PodAbrir, trazemos a segunda parte da interessante entrevista com Alessandro Lima, Character Design da Aquiris Game Experience. Na continuaçã[...] Olá gurizada, estamos de volta com mais um podcast sobre desenvolvimento de games. No episódio número 13 do PodAbrir, trazemos a segunda parte da interessante entrevista com Alessandro Lima, Character Design da Aquiris Game Experience. Na continuação, Alessando fala sobre os projetos que participou e também compartilha detalhes do processo de produção.  Na seção sobre games indie, comentamos sobre o Bastion e a tecnologia Native Client do Google Chrome. Participantes: Everton Vieira Alessandro Nörnberg Alessandro lima Categoria: Técnico: Game Art Links comentados na seção de recados e e-mails: Site da Rockhead Games Bastion Site da Super Giant Games (desenvolvedora do Bastion) Bastion na Chrome Web Store Vídeo do jogo Trilha sonora do Bastion Chrome Native Client (NaCl) Site do Chrome Native Client (aqui tem a visão geral do funcionamento) Críticas ao Chrome Native Client, na Wikipedia. Mais dois projetos com o Native Client na Chrome Web Store: Wolf Toss, feito com o SDK Moai, que também é compatível com Chrome NaCl. Port do MAME (mas apenas o básico) Links comentados neste episódio: Site do Alessandro Lima www.alessandrolima.com Artistas: www.luisroyo.com www.bromart.com www.3d.sk Projetos: Vales Magicos Live Demos da Unity 3D Super Volei Brasil Gillete Young Guns Axe Dart Temptation Axe Music Star Goodyear Eagle GT Quantum Conflict Trilha Sonora Heavy Metal in The Night – Dream Evil PodCast Siga o nosso podcast em http://abrindoojogo.com.br/feed/podcast. Para o Itunes, acesse a store aqui. Visitem nossa página no Facebook Entrevistas, Pod-Abrir Abrindo o Jogo no no http://abrindoojogo.com.br/tutorial-html-5-parte-23 http://abrindoojogo.com.br/tutorial-html-5-parte-23#comments Tue, 14 Feb 2012 06:23:47 +0000 Luiz Nörnberg http://abrindoojogo.com.br/?p=3959 Na primeira parte do tutorial de HTML 5 vimos como usar a tag <canvas> e como mostrar imagens nela, criando uma pequena biblioteca para facilitar o trabalho.

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"></script>
<script src="aoj/aojgame.js"></script>

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

<canvas id="canvas1" width="960" height="600"></canvas>

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>
            var carro = {
                x: 0,
                y: 0,
                dx: 30,
                dy: 30,
                sprite: null
            }
 
            function pulse() {
                update();
                render();
            }
 
            function update() {
                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;
                }
            }
 
            function render() {
                aojFillRect(0, 0, aojCanvas().width, aojCanvas().height, 'gray');
                aojDrawImage(carro.sprite, carro.x, carro.y);
            }
 
            window.onload = function carregaImagem() {
                carro.sprite = aojNewImage('img/simple-travel-car.png', imagemCarregada);
            }
 
            function imagemCarregada() {
                aojFPS(20);
                aojSetPulseCallback(pulse);
                aojSetCanvas('canvas1');
                aojStartGameLoop();
            }
        </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"></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
• Visualziar o exemplo de input
• Baixar o código fonte do exemplo

Na terceira e última parte artigo “Repensando o Loop”, compartilho algumas soluções para tornar a produção musical do seu jogo mais interessante, sem aumentar significativamente o custo/tempo de projeto.

Existem muitas outras soluções disponíveis. Tudo depende do objetivo que você quer atingir e da experiência da sua equipe de áudio. Para ser relevante na indústria de jogos, é necessário encarar desafios e tentar resolvê-los da melhor maneira possível.

Use as dicas abaixo e seja criativo! Se possível, compartilhe aqui no Abrindo o Jogo o resultado dos seus trabalhos!

Boa leitura!

Caso não tenha lido a Parte 1, clique aqui.
Caso não tenha lido a Parte 2, clique aqui.

Repensando o loop – Parte 3

Para criar músicas em loop que possam ser reutilizadas minimizando a possibilidade de fadiga auditiva, primeiro é necessário avaliar essa necessidade. Tente descobrir quanto tempo em média os jogadores passam durante cada sessão, fase ou segmento do seu jogo. Neste artigo, vamos chamar esse tempo de Tempo de Jogo. Dada a natureza não-linear dos jogos, é impossível saber com precisão essa duração, mas é necessário ter uma ideia baseada no planejamento e, principalmente, analisando os resultados de testes com diversos perfis de jogadores.

Para que a música não se repita, a duração dela precisa ser maior ou igual ao Tempo de Jogo. Esse cenário é o ideal, já que teoricamente o jogador só ouviria música original. Na prática, esse cenário é muito difícil de ser atingido com baixo orçamento. Se a duração da música é igual a 50% do Tempo de Jogo, ela vai se repetir duas vezes, o que é tolerável e não incomoda a maioria dos jogadores. Porém, se a música começar a se repetir de 3 a 5 vezes, é necessário ficar atento. O limite de repetição já está sendo alcançado e a trilha pode afastar o jogador. Se a música se repetir mais de 5 vezes durante o Tempo de Jogo, é extremamente recomendável repensar a produção musical.

A tabela abaixo mostra cenários da relação entre o número de repetições do loop e o resultado sensorial na maioria dos jogadores.

Cenários de implementação musical nos jogos.

Se a música do seu jogo se encontra no cenário D, a melhor solução é criar mais conteúdo musical e tentar se aproximar do cenário A.

Entretanto, se não for possível produzir mais conteúdo musical, por motivos de orçamento ou tempo disponível, existem algumas soluções alternativas. É importante ressaltar que até mesmo jogos AAA utilizam essas técnicas, como estratégia para minimizar o custo do projeto. Todas as soluções estão relacionadas ao conceito de arranjos dinâmicos (horizontais e verticais) e podem ser usados com ou sem um motor de áudio dedicado.

Seguem abaixo as soluções, bem como suas vantagens e desvantagens.

Solução 1 – Inversão das partes da música

Descrição: Músicas são divididas em partes diferentes que se sucedem ao longo do tempo. Na estrutura de uma música popular, é comum chamar as partes de A, B, ponte e refrão. Essa estrutura existe em todos os gêneros musicais. Com algumas adaptações, é possível alterar a ordem as partes da música, tornando a nova versão levemente diferente. Quanto mais partes a música tiver, maior a possibilidade de combinações.

Vantagens: A música não começa exatamente da mesma maneira durante o Tempo de Jogo. Isso mitiga a sensação de repetição no momento em que o jogador começa a ouvir a música. É especialmente útil quando a mesma música é usada em diferentes fases.

Desvantagens: Uma vez que a música completa o ciclo do loop, o jogador percebe que o artefato é o mesmo utilizado anteriormente. Dependendo do nível de experiência do ouvinte, ele pode perceber até mesmo a alteração da ordem das partes antes mesmo que o ciclo se complete.

Sugestão de implementação: O compositor precisa exportar diferentes versões da música, com a ordem das partes invertida. Se o jogo possuir algum motor de áudio dinâmico, é possível tentar exportar cada parte separadamente e depois montá-las em tempo real usando o motor do jogo.

Solução 2 – Exclusão da melodia

Descrição: A melodia é o elemento mais memorável da música. Se você pensar em qualquer música neste momento, é possível que você se lembre justamente dela. Melodias são poderosos artefatos sonoros que, se usados de forma adequada, podem tornar o seu jogo ainda mais memorável. Porém, quando ela se repete em demasia, pode repelir o ouvinte.

Vantagens: Ao excluir a melodia, é possível aumentar a vida útil da trilha, sem prejudicar a imersão do jogador.

Desvantagens: Se a melodia for excluída com frequência, a música pode perder o seu impacto e deixar de ser memorável.

Sugestão de implementação: Peça ao seu compositor para exportar duas versões da música, uma com melodia e outra sem. Depois, reproduza-as alternadamente, tomando cuidado para não repetir muitas vezes a música com melodia. Você também pode emudecer as faixas que reproduzem a melodia, caso o motor do seu jogo tenha essa capacidade.

Essa técnica é usada no Skyview Temple, o primeiro “calabouço” do jogo Zelda: Skyward Sword. Quando Link está na sala principal, uma versão com melodia do tema é reproduzida. Ao entrar em salas menores, uma versão sem melodia se torna o pano de fundo sonoro.

Solução 3 – Implementação do silêncio

Descrição: Uma solução semelhante à 2, mas um pouco mais radical. Ao repetir a música um determinado número de vezes, é possível simplesmente desligá-la caso o número de repetições se aproxime do cenário D, descrito anteriormente.

Vantagens: Como não há música, o jogador não corre o risco de ficar entediado.

Desvantagens: Se o jogo ficar em silêncio por muito tempo, reintroduzir a música de forma repentina pode resultar em um efeito de repulsa semelhante ao da repetição prolongada.

Sugestão de implementação: Faça com que o seu jogo reproduza a música no máximo 3 vezes (se aproximando do cenário C). Após a terceira repetição, deixe a música desparecer sutilmente. Deixe o jogo em silêncio por um tempo e repita a operação. Também é possível deixar o jogo em silêncio até o término da fase/segmento do jogo.

Essa solução foi utilizada em Halo. Quando o jogador passava muito tempo em uma fase, a música simplemente desaparecia.

Solução 4 – Lista randômica

Descrição: Esta solução propõe a utilização de diferentes músicas reproduzidas de forma aleatória, como um reprodutor de música com a opção “shuffle” ativada.

Vantagens: O jogador tem maior diversidade de conteúdo musical disponível durante o Tempo de Jogo. Além disso, a música pode ser criada sob medida para combinar com a temática do projeto. O resultado é uma melhor imersão, comparada à substituição da trilha do jogo pela lista de reprodução do jogador.

Desvantagens: Por mais diversa que seja a produção musical, em algum momento ela vai se esgotar.

Sugestão de implementação: Reproduza as músicas em sequência aleatória, tomando cuidado para não reproduzir o mesmo arquivo duas vezes seguidas. Isso também pode ser feito através de alguns middlewares de áudio.

Solução 5 – Final expansível

Descrição: Trata-se de um loop curto que pode ser agregado ao final de música e repetido ad infinitum. A música completa pode ser reintroduzida após algum tempo de repetição do final expansível.

Vantagem: Tem um efeito semelhante ao da solução 3, mas um pouco mais sutil. Ao criar um final em loop, é possível descansar o ouvido do ouvinte e prepará-lo para a próxima repetição.

Desvantagens: O final expansível, se usado durante muito tempo, pode se tornar inoportuno, da mesma forma qualquer outro loop musical.

Sugestão de implementação: Peça ao seu compositor para criar um loop de curta duração (30 segundos é mais que suficiente), utilizando o mesmo BPM e elementos percussivos da música que ele vai se conectar. Esse arquivo deve ser flexível o suficiente para se conectar com o começo da música em questão ou de outras músicas presentes no seu jogo.

Para tornar a sua produção musical mais interessante e com baixo custo, tente combinar essas soluções. Você pode criar uma lista randômica (solução 4) com músicas de final expansível (solução 5). Também é possível usar músicas com final expansível (solução 5), cujas repetições sucessivas não tem melodia (solução 2) e caem no silêncio (solução 3), voltando com partes invertidas (solução 1). Basicamente, qualquer combinação de solução pode ser feita e todas terão um resultado semelhante: a expansão da sua produção musical existente, sem aumento significativo de custo de produção.

Iniciamos a temporada 2012 do nosso podcast sobre desenvolvimento de jogos. O primeiro episódio do ano traz mais uma entrevista bacana com um profissional da área de games. Nosso convidado de hoje é Alessandro Lima, escritor e Lead Character Designer na empresa Aquiris Game Experience.

Mais um podcast dedicado aos artistas que acompanham o AoJ. Porém, o papo é muito legal também para quem não é da área. Não deixe de conferir.

Participantes

• Everton Vieira
• Luiz Alessandro
• Alessandro Lima
• Participação Especial:  Nero - O Labrador de estimação do nosso entrevistado

Categoria:

• Técnico – Game Art

Links comentados neste episódio:

• Referências
  • Site Oficial
  • Entrevista para o progama Conexão Digital
  • CompuManager
  • South Logic
  • Ubisoft
  • Aquiris
• Projetos:
  • Flushed Away (Game Cube)

Olá pessoal, este é meu primeiro texto para o Abrindo o Jogo.

Depois da entrevista que fiz o ano passado fui convidado para participar também do Site.
Achei a proposta interessante, mas decidi pensar um pouco sobre como poderia contribuir de uma forma bacana, sem apelar para re-posts ou assuntos já manjados.

Para facilitar a minha tarefa, vou focar os assuntos na área de Arte para games, mais precisamente a etapa de Arte Conceitual. Acho mais justo deixar o 3D e o Pixel-Art para outros Colaboradores; que lidam com isso diariamente. Assim não corro o risco de escrever sobre algo que não experimentei de fato.

Sendo assim, deixa mostrar o que trouxe para vocês hoje…

A tradução do melhor Tutorial para Artistas Digitais!

Já há algum tempo quis traduzir o famoso tutorial escrito por Arne Niklas Jansson. Provavelmente você não conhece nenhum dos dois (o sujeito e o artigo que ele escreveu), mas bastam alguns meses lendo os diversos Fóruns da Internet para saber como esse artigo é altamente recomendado a todos que querem melhorar o desenho e a pintura.

Niklas Jansson é um artista que já está há um bom tempo nesse ramo. Ficou bastante conhecido na área pelos ‘re-designs’ de jogos antigos: análises, descrições dos elementos dos jogos, idéias alternativas para jogabilidade e o mais fantástico (na minha opinião), sua excelente habilidade com Arte Conceitual.

Infelizmente o material publicado de Niklas não é muito – digamos – organizado. Os textos podem parecer confusos e há muita coisa perdida nas páginas de seu antigo site. Quem se interessar, pode visitar os links que cito no final do artigo e desvendar por si só todo esse vasto conteúdo. É uma tarefa para poucos, mas a recompensa é valiosa. Garanto.

O artigo ‘The Art Tutorial’ foi escrito originalmente em 2005. De lá pra cá muita coisa mudou no processo de criação de Arte Digital (softwares foram atualizados, técnicas foram inventadas), mas o conteúdo do texto permaneceu atual, por se tratar de conhecimento teórico e dicas realmente úteis…

Eu confesso que levei anos pra traduzir esse tutorial.

Na verdade, a tradução do texto foi feita em alguns dias, mas para entender e experimentar o que o autor explica foi necessário alguns bons anos e alguns insights, que aos poucos criavam conexões com o que Arne compartilha no artigo.

Para quem esta começando a desenhar agora, talvez o artigo não pareça tão legal assim. Mas se você já tem uma certa quilometragem com o Lápis e a Tablet, recomendo imprimir e guardar como referência. Volta e meia é bom ter o texto em mãos para relembrar algumas das dicas.

Após escrever para o autor (pedir a liberação para publicar, etc.) descobri que existia um outro texto, um pouco mais recente, com alguns pensamentos sobre Arte e Design. Achei válido gastar um tempo a mais e trazer, para a comodidade da nossa língua, algumas idéias dessa Mente-Criativa.

É isso aí!

Espero que gostem, experimentem e coloquem algumas das dicas em uso assim que possível.

Aqui o Link para o artigo traduzido.

Ah! Vamos usar os comentários aqui do Abrindo o Jogo para estender o assunto. Se houver dúvidas sobre os termos traduzidos, questões sobre os tópicos abordados, etc. Basta perguntar.

Outros Links relacionados:

• O artigo original, em Inglês
• Site ‘oficial’ do artista
• Blog com os projetos de re-design
• Outro blog, esse com conteúdo aleatório (mas lindas imagens)

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.

<script src="aoj/aojcanvas.js"></script>
<div id="info">Abrindo o Jogo - exemplo de uso do elemento canvas</div>

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

Chegamos à segunda parte do artigo “Repensando o Loop”.

Neste texto, convido-os a refletir sobre um grande desafio da produção moderna de jogos: a intolerância à repetição.

Na terceira e última parte, que será publicada em 02/2012, vamos falar sobre possíveis soluções de baixo custo para este desafio.

Caso não tenha lido a Parte 1, clique aqui.

Boa leitura!

Repensando o loop – Parte 2

A indústria de jogos vem evoluindo rapidamente desde a geração dos videogames de 8 e 16 bits. Em 2012, a competitividade nessa indústria tende a ser ainda maior, tornando o mercado cada vez mais segmentado. Os jogos terão de ser produzidos sob medida para atender a perfis diferentes, tornando ainda mais necessária a evolução das técnicas de produção para manter tais produtos mais atraentes, sem aumentar o tempo e custo do projeto.

Nesse contexto, a música nos jogos mantém sua função de promover a imersão do jogador. Porém, esse atingir objetivo também fica mais difícil quando se trata de música de curta duração, que se repete ad infinitum, como é o caso do loop. Essa técnica maravilhosa vai continuar sendo utilizada, mas devidamente adequada às novas exigências do mercado.

Existem diversos motivos que sustentam a revisão e adaptação dessa técnica e eles variam de acordo com o gênero do jogo, o público-alvo e o objetivo que se deseja atingir com o produto. Analisar todos os possíveis motivos não é o objetivo deste artigo, já que cada situação exige uma análise própria e nem sempre a solução pode ser aplicada em todos os contextos. Porém, existe uma característica que permeia quase todas as situações. Essa característica será explorada a seguir.

A intolerância à repetição

Alguns jogadores mais experientes desenvolveram sua audição e são capazes de identificar o ponto do loop, o momento em que o segmento musical se repete. O ouvido treinado não aceita a “mágica” da extensão, eliminando vantagem de se usar essa técnica. O efeito do loop, antes agradável na geração 8 e 16 bits, hoje tem efeito contrário. Em vez de promover a imersão do jogador, prejudica a experiência de jogo.

Mesmo os jogadores menos experientes são capazes de perceber a repetição. Talvez eles não tenham a audição tão apurada a ponto de perceber o exato momento do ponto do loop, mas sabem que a música está se repetindo. No fim, o resultado é semelhante: a música se torna incômoda e indesejável.

Além disso, a grande oferta de dispositivos de reprodução de música digital a um preço acessível mudou a maneira como se consome música. Os jogadores (e também consumidores de música) têm um arsenal gigantesco de conteúdo musical disponível nos seus bolsos. Muitos estão acostumados a ouvir horas de música diversificada durante o dia e isso os tornou mais exigentes. Quando se deparam com jogos com conteúdo musical que se repete e os irrita, a tendência é simplesmente ignorar a música que está tocando, desligando-a ou abaixando o volume.

Muitos jogos modernos também possuem a opção de substituir a música do jogo pela música armazenada no aparelho. Portanto, não há motivo aparente para um jogador continuar ouvindo música que se repete se ele pode facilmente substituir essa música pelo vasto conteúdo que ele possui.

É importante salientar que essas afirmações são feitas com base na observação do comportamento dos jogadores, assim como conversas informais com outras pessoas que trabalham nessa indústria. O objetivo deste artigo não é ser uma base científica para comprovação de fatos, mas um documento que analisa os desafios deste mercado e pode servir como orientação e inspiração para os profissionais que produzem jogos.

Como dito anteriormente, em nenhum momento este artigo procura anular a utilização do loop. Esta técnica ainda é crucial em praticamente todos os jogos e há muitos exemplos de produtos maravilhosos (alguns que são até referência na produção musical dessa indústria), que continuam usando os loops de maneira muito semelhante às gerações anteriores. O que se busca com essa análise é alertar os produtores de jogos sobre os desafios da criação de música para videogame e o impacto que a utilização do loop pode causar em algumas situações. No fim, a decisão artística de utilização ou não dos loops, bem como a forma de implementação é tomada de acordo com o produto, o público-alvo, o orçamento e o objetivo que se deseja atingir.

A resposta da indústria

Produtores de jogos conhecidos como “AAA” (jogos com alto valor de produção) já perceberam essa mudança de contexto e muitos atualizaram a abordagem da produção musical dos seus jogos. A solução, em alguns casos, é produzir mais música, tornando o conteúdo mais diversificado. Teoricamente, maior quantidade de música ajudaria a diminuir os efeitos indesejáveis da repetição contínua.

Porém, produzir mais música não é uma solução viável para todos nesta indústria. Existe uma grande quantidade de empresas independentes e de pequeno porte que precisa produzir jogos com baixo orçamento. Muitas vezes, o budget disponível não é necessário para satisfazer a demanda de música do jogador moderno. As empresas continuam “presas” às soluções de baixo custo do passado e continuam produzindo loops de curta duração que são reproduzidos durante a maior parte da experiência de jogo. Essa abordagem é econômica, mas nem sempre é eficaz.

Como produzir conteúdo musical atraente e com baixo custo é o assunto da terceira e última parte desse artigo.

Nesse ano, felizmente, rolou um monte de coisa boa aqui no blog!

Nesse post fazemos um resumão para relembrar os eventos importantes. Se você perdeu algum destes marcos, vale a pena acessar para não deixar passar!

Fevereiro

Com a entrada do Rafael começamos a explorar o lado empreendedor, com artigos focados no mercado e abertura de empresas. Esse assunto revelou-se, ao longo do ano, um sucesso enorme entre nossos leitores, mostrando que o brasileiro tem espírito empreendedor e interesse em posicionar-se corretamente no mercado.

Abril

Julho

Edição número ZERO do podAbrir. Embora tenhamos apostado no conceito, ainda era uma experiência. Será que o pessoal iria aprovar? Bem, terminamos o ano com episódios quinzenais que contam com mais de 15.000 acessos! É, o pessoal gostou!

Agosto

Surge o AoJCursos, área dedicada aos cursos pagos do Abrindo o Jogo. Com um sistema próprio e valores acessíveis, oferecemos os cogumelos do conhecimento para você crescer profissionalmente

Setembro

Outubro

Mais um campeão de audiência na categoria técnico: os artigos sobre a matemática nos games mostrou como esse conhecimento é importante para o desenvolvedor – e, infelizmente, como é mal visto na escola

Novembro

Lançamento histórico do game Minecraft traz à tona mais uma modalidade de mercado, o alphafunding.

Entra em cena a PlayN, API para jogos do Google. Como não oderia deixar de ser, o Abrindo o Jogo traz em primeira mão um how-to sobre a tecnologia e mais tarde um curso no AoJCursos.

Dezembro

Concluindo…

Foi um ano legal! Mas esperamos fechar 2012 com muito mais – cada comentário, cada e-mail dos leitores nos motiva a seguir com o trabalho, trazendo sempre o melhor possível para a comunidade de desenvolvedores de games do Brasil.

Que no próximo ano todos alcancem o crescimento profissional e encontrem as oportunidades necessárias para entrar de vez neste mercado. Que ele nos dê muito trabalho (sabemos que dá), mas também a realização de sonhos e, porque não, muito dinheiro no bolso!

Em nome de toda a equipe do Abrindo o Jogo, desejo a todos os leitores, e agora também ouvintes, um  Natal repleto de saúde e paz. Que 2012 seja um ótimo ano para a indústria nacional de games.

Aproveito o post para informar que, tendo em vista o período de festividades, faremos um pequeno recesso nas próximas duas semanas, voltando no dia 09/01 com várias novidades nos posts e podcasts.

O PodAbrir volta dia 03/02 seguindo o arco de entrevistas com profissionais da área. Anote ai na sua agenda para não perder

Que o Papai Noel traga vários consoles e games de última geração, além de um mercado  promissor para todos nós

Obviamente, deixamos o melhor para o final. Nessa segunda parte, Dado fala sobre seus projetos atuais e as principais dicas e macetas para se tornar um bom Concept Artist. Não seja maluco de perder.

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

• Site do Dado Almeida
  • http://www.dadoalmeida.com
• Blog de Desenvolvedor do game e da nova UBI Art Framework:
  • http://ubi-art.uk.ubi.com/
• Link para o Talk of Fight feito pela Aquiris:
  • http://apps.facebook.com/talkorfight/
• Link para o jogo Fim da Picada:
  • http://apps.facebook.com/fimdapicada/
• Comunidades sobre Game Art:
  • http://www.polycount.com
  • http://www.gameartisans.org/forums/index.php
  • http://www.cghub.com
• Site do Concept Artist Paul Richards
  • http://www.autodestruct.com/