Usando a API JavaScript WebAssembly - WebAssembly

Usando a API JavaScript WebAssembly
===================================

Se você já compilou um módulo de outra linguagem usando ferramentas como Emscripten ou carregou e executou o código você mesmo (en-US), a próxima etapa é aprender mais sobre como usar os outros recursos da API JavaScript WebAssembly. Este artigo ensina o que você precisa saber.

**Nota:** Se você não estiver familiarizado com os conceitos básicos mencionados neste artigo e precisar de mais explicações, leia Conceitos do WebAssembly primeiro e depois volte.

Alguns exemplos simples
-----------------------

Vamos percorrer alguns exemplos que explicam como usar a API WebAssembly JavaScript e como usá-la para carregar um módulo Wasm em uma página da web.

**Nota:** você pode encontrar o código de exemplo em nosso webassembly-examples repositório do GitHub.

### Preparando o exemplo

1. Primeiro precisamos de um módulo Wasm! Pegue nosso arquivo `simple.wasm` e salve uma cópia em um novo diretório em seu local máquina.
2. Em seguida, vamos criar um arquivo HTML simples chamado `index.html` no mesmo diretório do seu arquivo Wasm (pode usar nosso modelo simples se você não tiver um facilmente disponível).
3. Agora, para nos ajudar a entender o que está acontecendo aqui, vamos ver a representação de texto do nosso módulo Wasm (que também encontramos em Converting WebAssembly format to Wasm (en-US)):

```wasm
(module
  (func $i (import "imports" "imported\_func") (param i32))
  (func (export "exported\_func")
    i32.const 42
    call $i))
```

4. Na segunda linha, você verá que a importação tem um namespace de dois níveis — a função interna `$i` é importada de `imports.imported_func`. Precisamos refletir esse namespace de dois níveis em JavaScript ao escrever o objeto a ser importado para o módulo Wasm. Crie um elemento `<script></script>` em seu arquivo HTML e adicione o seguinte código a ele:

```js
const importObject = {
  imports: { imported\_func: (arg) => console.log(arg) },
};
```

### Transmitindo o módulo WebAssembly

Uma novidade no Firefox 58 é a capacidade de compilar e instanciar módulos WebAssembly diretamente de fontes subjacentes. Isso é obtido usando `WebAssembly.compileStreaming()` (en-US) e `WebAssembly.instantiateStreaming()` (en-US). Esses métodos são mais fáceis do que suas contrapartes sem streaming, porque eles podem transformar o código de byte diretamente em instâncias `Module`/`Instance`, eliminando a necessidade de colocar separadamente o `Response` em um `ArrayBuffer`.

Este exemplo (consulte nossa demonstração instantiate-streaming.html no GitHub e visualize it live também) mostra como usar `instantiateStreaming()` para buscar um módulo Wasm, importar uma função JavaScript nele, compilá-lo e instanciá-lo e acessar sua função exportada - tudo em uma única etapa.

Adicione o seguinte ao seu script, abaixo do primeiro bloco:

```js
WebAssembly.instantiateStreaming(fetch("simple.wasm"), importObject).then(
  (obj) => obj.instance.exports.exported\_func(),
);
```

O resultado disso é que chamamos nossa função WebAssembly exportada `exported_func`, que por sua vez chama nossa função JavaScript importada `imported_func`, que registra o valor fornecido dentro da instância WebAssembly (42) no console. Se você salvar seu código de exemplo agora e carregá-lo em um navegador compatível com WebAssembly, verá isso em ação!

**Nota:** Este é um exemplo complicado e prolixo que alcança muito pouco, mas serve para ilustrar o que é possível — usar código WebAssembly juntamente com JavaScript em seus aplicativos da web. Como dissemos em outro lugar, o WebAssembly não pretende substituir o JavaScript; os dois, em vez disso, podem trabalhar juntos aproveitando os pontos fortes um do outro.

### Carregando nosso módulo Wasm sem streaming

Se você não pode ou não quer usar os métodos de streaming descritos acima, você pode usar os métodos sem streaming `WebAssembly.compile()` (en-US) / `WebAssembly.instantiate()` (en-US) em vez disso.

Esses métodos não acessam diretamente o código de byte, então requerem uma etapa extra para transformar a resposta em um `ArrayBuffer` antes de compilar/instanciar o módulo Wasm.

O código equivalente ficaria assim:

```js
fetch("simple.wasm")
  .then((response) => response.arrayBuffer())
  .then((bytes) => WebAssembly.instantiate(bytes, importObject))
  .then((results) => {
    results.instance.exports.exported\_func();
  });
```

### Como visualizar o Wasm nas ferramentas do desenvolvedor

No Firefox 54+, o painel do depurador da ferramenta do desenvolvedor tem funcionalidade para expor a representação de texto de qualquer código Wasm incluído em uma página da web. Para visualizá-lo, você pode ir ao Painel do Depurador e clicar na entrada "wasm://".

![Painel do depurador de ferramentas do desenvolvedor destacando um módulo.](/pt-BR/docs/WebAssembly/Using_the_JavaScript_API/wasm-debug.png)

Além de visualizar o WebAssembly como texto, os desenvolvedores podem depurar (colocar pontos de interrupção, inspecionar a pilha de chamadas, passo único, etc.) WebAssembly usando o formato de texto.

Memória
-------

No modelo de memória de baixo nível do WebAssembly, a memória é representada como um intervalo contíguo de bytes não digitados chamados Linear Memory que são lidos e escrito por instruções de carregamento e armazenamento dentro do módulo. Nesse modelo de memória, qualquer load ou store pode acessar qualquer byte em toda a memória linear, o que é necessário para representar fielmente conceitos C/C++ como ponteiros.

Ao contrário de um programa C/C++ nativo, no entanto, onde o intervalo de memória disponível abrange todo o processo, a memória acessível por uma Instância WebAssembly específica é confinada a um intervalo específico — potencialmente muito pequeno — contido por um objeto WebAssembly Memory. Isso permite que um único aplicativo da Web use várias bibliotecas independentes — cada uma delas usando o WebAssembly internamente — para ter memórias separadas totalmente isoladas umas das outras. Além disso, implementações mais recentes também podem criar memórias compartilhadas, que podem ser transferidas entre os contextos Window e Worker usando `postMessage()` (en-US) e usadas em vários lugares.

Em JavaScript, uma instância de Memory pode ser considerada como um `ArrayBuffer` redimensionável (ou `SharedArrayBuffer` (en-US), no caso de memórias compartilhadas) e, assim como com `ArrayBuffers`, um único aplicativo da web pode criar muitos objetos Memory independentes. Você pode criar um usando o construtor `WebAssembly.Memory()` (en-US), que recebe como argumentos um tamanho inicial e (opcionalmente) um tamanho máximo e um `shared` propriedade que informa se é uma memória compartilhada ou não.

Vamos começar a explorar isso observando um exemplo rápido.

1. Crie outra nova página HTML simples (copie nosso modelo simples) e chame-a de `memory.html`. Adicione um elemento `<script></script>` à página.
2. Agora adicione a seguinte linha ao topo do seu script, para criar uma instância de memória:

```js
const memory = new WebAssembly.Memory({ initial: 10, maximum: 100 });
```

A unidade de `initial` e `maximum` são as páginas WebAssembly — elas são fixadas em 64KB de tamanho. Isso significa que a instância de memória acima tem um tamanho inicial de 640 KB e um tamanho máximo de 6,4 MB.
 A memória WebAssembly expõe seus bytes fornecendo um getter/setter de buffer que retorna um ArrayBuffer. Por exemplo, para escrever 42 diretamente na primeira palavra da memória linear, você pode fazer isso:

```js
new Uint32Array(memory.buffer)[0] = 42;
```

Você pode retornar o mesmo valor usando:

```js
new Uint32Array(memory.buffer)[0];
```

3. Tente isso agora em sua demonstração — salve o que você adicionou até agora, carregue-o em seu navegador e tente inserir as duas linhas acima em seu console JavaScript.
### Aumentando a memória

Uma instância de memória pode ser aumentada por chamadas para `Memory.prototype.grow()` (en-US), onde novamente o argumento é especificado em unidades de páginas WebAssembly:

```js
memory.grow(1);
```

Se um valor máximo foi fornecido na criação da instância de memória, as tentativas de ultrapassar esse máximo gerarão uma exceção `RangeError` (en-US). O mecanismo aproveita esses limites superiores fornecidos para reservar memória antecipadamente, o que pode tornar o redimensionamento mais eficiente.

Nota: Como o byteLength de um `ArrayBuffer` é imutável, após um `Memory.prototype.grow()` (en-US) bem-sucedido operação, o buffer getter retornará um novo objeto ArrayBuffer (com o novo byteLength) e quaisquer objetos ArrayBuffer anteriores serão "desconectados" ou desconectados da memória subjacente para a qual apontaram anteriormente.

Assim como as funções, as memórias lineares podem ser definidas dentro de um módulo ou importadas. Da mesma forma, um módulo também pode, opcionalmente, exportar sua memória. Isso significa que o JavaScript pode obter acesso à memória de uma instância do WebAssembly criando um novo `WebAssembly.Memory` e transmitindo-o como uma importação ou recebendo uma exportação de memória (através de `Instance.prototype.exports` (en-US)).

### Exemplo de memória mais envolvida

Vamos tornar as afirmações acima mais claras observando um exemplo de memória mais envolvido — um módulo WebAssembly que importa a instância de memória que definimos anteriormente, a preenche com uma matriz de inteiros e os soma. Você pode encontrar isso em memory.wasm.

1. faça uma cópia local de `memory.wasm` no mesmo diretório de antes.

**Nota:** você pode ver a representação de texto do módulo em memory.wat.
2. Volte para seu arquivo de exemplo `memory.html` e busque, compile e instancie seu módulo Wasm como antes — adicione o seguinte ao final de seu script:

```js
WebAssembly.instantiateStreaming(fetch("memory.wasm"), {
  js: { mem: memory },
}).then((results) => {
  // adicione o código aqui
});
```

3. Como este módulo exporta sua memória, dada uma instância deste módulo chamada instance podemos usar uma função exportada `accumulate()` para criar e preencher um array de entrada diretamente na memória linear da instância do módulo (`mem`). Adicione o seguinte em seu código, onde indicado:

```js
const i32 = new Uint32Array(memory.buffer);

for (let i = 0; i < 10; i++) {
  i32[i] = i;
}

const sum = results.instance.exports.accumulate(0, 10);
console.log(sum);
```

Observe como criamos a visualização `Uint32Array` (en-US) no buffer do objeto Memory (`Memory.prototype.buffer` (en-US)), não na própria Memória.

As importações de memória funcionam exatamente como as importações de função, apenas objetos de memória são passados como valores em vez de funções JavaScript. As importações de memória são úteis por dois motivos:

* Eles permitem que o JavaScript busque e crie o conteúdo inicial da memória antes ou simultaneamente com a compilação do módulo.
* Eles permitem que um único objeto de memória seja importado por várias instâncias de módulo, o que é um bloco de construção crítico para implementar a vinculação dinâmica no WebAssembly.

**Nota:** Você pode encontrar nossa demonstração completa em memory.html (veja ao vivo também) .

Tabelas
-------

Uma tabela WebAssembly é uma matriz redimensionável de referências que pode ser acessada por código JavaScript e WebAssembly. Embora a memória forneça uma matriz digitada redimensionável de bytes brutos, não é seguro que as referências sejam armazenadas em uma memória, pois uma referência é um valor confiável do mecanismo cujos bytes não devem ser lidos ou gravados diretamente pelo conteúdo por motivos de segurança, portabilidade e estabilidade .

As tabelas possuem um tipo de elemento, que limita os tipos de referência que podem ser armazenados na tabela. Na iteração atual do WebAssembly, há apenas um tipo de referência necessária para o código do WebAssembly — funções — e, portanto, apenas um tipo de elemento válido. Em iterações futuras, mais tipos de elementos serão adicionados.

Referências de função são necessárias para compilar linguagens como C/C++ que possuem ponteiros de função. Em uma implementação nativa de C/C++, um ponteiro de função é representado pelo endereço bruto do código da função no espaço de endereço virtual do processo e, portanto, pelas razões de segurança mencionadas acima, não pode ser armazenado diretamente na memória linear. Em vez disso, as referências de função são armazenadas em uma tabela e seus índices, que são inteiros e podem ser armazenados na memória linear, são passados.

Quando chega a hora de chamar um ponteiro de função, o chamador do WebAssembly fornece o índice, que pode então ter limites de segurança verificados na tabela antes de indexar e chamar a referência de função indexada. Assim, as tabelas são atualmente um primitivo de baixo nível usado para compilar recursos de linguagem de programação de baixo nível com segurança e portabilidade.

Tabelas podem ser modificadas via `Table.prototype.set()` (en-US), que atualiza um dos valores em uma tabela, e `Table.prototype.grow()` (en-US), que aumenta o número de valores que podem ser armazenados em uma tabela. Isso permite que o conjunto de funções que podem ser chamadas indiretamente mude com o tempo, o que é necessário para técnicas de vinculação dinâmica. As mutações são imediatamente acessíveis via `Table.prototype.get()` (en-US) em JavaScript e para módulos Wasm.

### Um exemplo de tabela

Vejamos um exemplo de tabela simples — um módulo WebAssembly que cria e exporta uma tabela com dois elementos: o elemento 0 retorna 13 e o elemento 1 retorna 42. Você pode encontrar isso em [table.wasm](https://raw.githubusercontent. com/mdn/webassembly-examples/master/js-api-examples/table.wasm).

1. Faça uma cópia local de `table.wasm` em um novo diretório.

**Nota:** você pode ver a representação de texto do módulo em table.wat.
2. Crie uma nova cópia do nosso modelo HTML no mesmo diretório e chame-o de `table.html`.
3. Como antes, busque, compile e instancie seu módulo Wasm — adicione o seguinte a um elemento `<script>` na parte inferior do corpo do HTML:

```js
WebAssembly.instantiateStreaming(fetch("table.wasm")).then((results) => {
  // adicione o código aqui
});
```

4. Agora vamos acessar os dados nas tabelas — adicione as seguintes linhas ao seu código no local indicado:

```js
const tbl = results.instance.exports.tbl;
console.log(tbl.get(0)()); // 13
console.log(tbl.get(1)()); // 42
```

Este código acessa cada referência de função armazenada na tabela por sua vez e as instâncias para imprimir os valores que contêm no console — observe como cada referência de função é recuperada com um `Table.prototype.get()` (en-US), adicionamos um conjunto extra de parênteses no final para realmente invocar a função.

**Nota:** você pode encontrar nossa demonstração completa em table.html (veja ao vivo também).

Globais
-------

O WebAssembly tem a capacidade de criar instâncias de variáveis globais, acessíveis a partir de JavaScript e importáveis/exportáveis em uma ou mais instâncias `WebAssembly.Module` (en-US). Isso é muito útil, pois permite a vinculação dinâmica de vários módulos.

Para criar uma instância global WebAssembly de dentro do seu JavaScript, você usa o construtor `WebAssembly.Global()` (en-US), que se parece com isto:

```js
const global = new WebAssembly.Global({ value: "i32", mutable: true }, 0);
```

Você pode ver que isso requer dois parâmetros:

* Um objeto que contém duas propriedades que descrevem a variável global:
    + `value`: seu tipo de dados, que pode ser qualquer tipo de dados aceito nos módulos WebAssembly — `i32`, `i64`, `f32` ou `f64`.
    + `mutável`: um booleano que define se o valor é mutável ou não.
* Um valor contendo o valor real da variável. Pode ser qualquer valor, desde que seu tipo corresponda ao tipo de dados especificado.

Então, como usamos isso? No exemplo a seguir, definimos um global como um tipo `i32` mutável, com valor 0.

O valor do global é então alterado, primeiro para `42` usando a propriedade `Global.value`, e então para 43 usando a função `incGlobal()` exportada do módulo `global.wasm` (isso adiciona 1 a qualquer valor que lhe for atribuído e, em seguida, retorna o novo valor).

```js
const output = document.getElementById("output");

function assertEq(msg, got, expected) {
  const result =
    got === expected
      ? `SUCESSO! Obteve: ${got}<br>`
      : `FALHA!<br>Obteve: ${got}<br>Esperado: ${expected}<br>`;
  output.innerHTML += `Testando ${msg}: ${result}`;
}

assertEq("WebAssembly.Global exists", typeof WebAssembly.Global, "function");

const global = new WebAssembly.Global({ value: "i32", mutable: true }, 0);

WebAssembly.instantiateStreaming(fetch("global.wasm"), { js: { global } }).then(
  ({ instance }) => {
    assertEq("obtendo valor inicial de wasm", instance.exports.getGlobal(), 0);
    global.value = 42;
    assertEq(
      "obtendo valor atualizado por JS do wasm",
      instance.exports.getGlobal(),
      42,
    );
    instance.exports.incGlobal();
    assertEq("obtendo valor atualizado de JS", global.value, 43);
  },
);
```

**Nota:** Você pode ver o exemplo executando ao vivo no GitHub; consulte também o código-fonte.

Multiplicidade
--------------

Agora que demonstramos o uso dos principais blocos de construção do WebAssembly, este é um bom lugar para mencionar o conceito de multiplicidade. Isso fornece ao WebAssembly uma infinidade de avanços em termos de eficiência arquitetônica:

* Um módulo pode ter N instâncias, da mesma forma que um literal de função pode produzir N valores de fechamento.
* Uma instância de módulo pode usar instâncias de memória 0–1, que fornecem o "espaço de endereço" da instância. Versões futuras do WebAssembly podem permitir instâncias de memória 0–N por instância de módulo (consulte Múltiplas memórias).
* Uma instância de módulo pode usar instâncias de tabela 0–1 — este é o "espaço de endereço de função" da instância, usado para implementar ponteiros de função C. Versões futuras do WebAssembly podem permitir 0–N instâncias de tabela por instância de módulo.
* Uma instância de memória ou tabela pode ser usada por instâncias de módulo 0–N — todas essas instâncias compartilham o mesmo espaço de endereço, permitindo vinculação dinâmica.

Você pode ver a multiplicidade em ação em nosso artigo Compreendendo o formato de texto — consulte a seção Tabelas mutantes e vinculação dinâmica.

Resumo
------

Este artigo apresentou os fundamentos do uso da API WebAssembly JavaScript para incluir um módulo WebAssembly em um contexto JavaScript e fazer uso de suas funções e como usar a memória e as tabelas do WebAssembly em JavaScript. Também tocamos no conceito de multiplicidade.

Veja também
-----------

* webassembly.org
* Conceitos do WebAssembly
* WebAssembly no Mozilla Research


Anatomia de um vídeo game - Desenvolvimento de jogos

Anatomia de um vídeo game
=========================

Este artigo analisa a anatomia e o fluxo de trabalho do vídeo game médio de um ponto de vista técnico, em termos de como o loop principal deve ser executado. Isso ajuda os iniciantes da arena do desenvolvimento de jogos modernos a entender o que é necessário ao construir um jogo e como os padrões da web como o JavaScript se prestam como ferramentas. Os programadores de jogos experientes que são novos no desenvolvimento da web também podem se beneficiar.

Apresentar, aceitar, interpretar, calcular, repetir
---------------------------------------------------

O objetivo de todo vídeo game é **apresentar** ao usuário uma situação, **aceitar** sua entrada, **interpretar** estes sinais em ações, e **calcular** uma nova situação resultante dessas ações. Jogos estão constantemente repetindo estes estágios, de novo e de novo, até alguma condição final ocorrer (como vencer, perder, ou sair para ir dormir). Não surpreendentemente, este padrão corresponde a como um mecanismo de jogo está programado.

As especificidades dependem do jogo.

Alguns jogos guiam este ciclo pela entrada do usuário. Imagine que você está desenvolvendo um *"encontre as diferenças entre estas duas imagens similares"*. Esses jogos **apresentam** duas imagens ao usuário, eles **aceitam** seus cliques (ou toques), eles **interpretam** as entradas como um sucesso, falha, pausa, interação com o menu, etc., finalmente, eles **calculam** uma cena atualizada resultante dessas entradas. O ciclo do jogo é avançado pelas entradas do usuário e pela esperas até que ele as forneça. Isso é mais aproximado de um *jogo* *baseado em turnos* onde não há demanda de uma constante atualização a cada frame, somente quando o jogador reaje.

Outros jogos demandam controle sobre cada um dos menores intervalos de tempo possíveis. Os mesmos princípios acima aplicam-se com uma pequena diferença: cada frame de animação avança o ciclo e cada mudança na entrada do usuário é capturada no primeiro turno disponível. Este modelo *uma vez por frame* é implementado em algo chamado **loop principal.** Se o seu jogo é baseado em tempo, então essa será a autoridade a qual as suas simulações irão obedecer.

Mas o jogo pode não precisar de controle por frame. Seu game loop pode ser similar ao exemplo *encontre as diferenças* e basear-se em eventos de entrada. Ele pode requerer ambos, entrada e tempo simulado. Ele pode até mesmo ter um ciclo baseado em algo totalmente diferente.

JavaScript Moderno — como descrito nas próximas seções — felizmente, facilita o desenvolvimento de um loop principal "execute uma vez por frame". É claro, seu jogo será somente tão otimizado quando o fizer. Se parece que algo deveria estar ligado a um evento menos frequente, seria uma boa ideia implementá-lo fora do loop principal (mas não sempre).

Contruindo um loop principal em JavaScript
------------------------------------------

JavaScript trabalaha melhor com eventos e chamadas de funções. Navegadores modernos esforçam-se para chamar métodos à medida que são necessários e ociosos (ou fazem suas outras tarefas) nos intervalos. É uma excelente ideia ligar seu código aos momentos apropriados a eles. Pense se a sua função realmente precisa ser chamada em um estrito intervalo de tempo, a cada frame, ou somente após algo acontecer. Ser mais específico com o navegador sobre quando a sua função precisa ser chamada permite que o navegador otimize essa chamada. Também, isso facilitará o seu trabalho.

Alguns códigos precisam ser rodados frame por frame, então por quê ligar essas funções a qualquer coisa que não seja a atualização de tela do navegador? Na web, `window.requestAnimationFrame()` será a base da maioria dos mais bem programados loops principais do tipo frame por frame. Uma chamada de função deve ser passada dentro da função anterior quando a mesma for chamada. Esta chamdada de função será executada em um tempo adequado antes da próxima atualização de tela. Eis um exemplo de um loop principal simples:
```

window.main = function () {
  window.requestAnimationFrame( main );

  // Whatever your main loop needs to do.
};

main(); //Start the cycle.
```

**Nota**: Em cada método do `main()` discutido aqui, nós agendamos uma nova requisição `requestAnimationFrame` antes de executar o conteúdo de nosso loop. Isso não é por acidente, e é considerado boa prática. Chamando o próximo `requestAnimationFrame` anteriormente garante que o navegador receba a chamada a tempo de planejar adequadamente, mesmo que seu frame atual falhe em sua (?VSync window?).

O trecho de código acima possui duas declarações. A primeira cria uma função como uma variável global chamada `main()`. Esta função faz algum trabalho e também diz ao navegador para camá-la na próxima frame com `window.requestAnimationFrame()`. A segunda declaração chama a função `main()`, definida na primeira declaração. Pelo fato do `main()` ser chamado uma vez na segunda declaração e cada chamada dele colocá-lo na lista de coisas a fazer na próxima frame, `main()` é sincronizado com a sua taxa de frame.

É claro que esse loop não é perfeito. Antes de discutirmos maneiras de mudá-lo, deixe-nos discutir o que já está bem.

Cronometrando o loop principal para quando o navegador atualiza a tela o permite rodar o seu loop tão frequentemente quanto o navegador queira atualizar. Você tem controle sobre cada frame de animação. Isso é muito simples por que `main()` é a única função em loop. Um jogo de primeira pessoa (ou um jogo similar) apresenta uma nova cena a cada frame. Você realmente não pode ser mais suave e receptivo do que isso.

Mas não assuma imediatamente que animações requerem controle frame por frame. Animações simples podem ser facilmente desenvolvidas até mesmo com aceleração-GPU, com animações CSS e com outras ferramentas inclusas no navegador. Existem muitas delas que farão sua vida mais fácil.

Construindo um loop principal *melhor* em Javascript
----------------------------------------------------

Existem dois problemas óbvios com nosso loop principal anterior: `main()` polui o objeto ``window`` (onde todas as variáveis globais são armazenadas) e o código de exemplo não nos permite *parar* o loop a menos que toda a aba seja fechada ou atualizada. Para o primeiro problema, se você quer que o loop principal apenas rode sem precisar de fácil acesso (direto) a ele, você pode criá-lo como uma Função Diretamente Invocada (Immediately-Invoked Function Expression - IIFE).
```

/*
* Starting with the semicolon is in case whatever line of code above this example
* relied on automatic semicolon insertion (ASI). The browser could accidentally
* think this whole example continues from the previous line. The leading semicolon
* marks the beginning of our new line if the previous one was not empty or terminated.
*/

;(function () {
  function main() {
    window.requestAnimationFrame( main );

    // Your main loop contents.
  }

  main(); // Start the cycle
})();
```

Quando o browser alcançar este IIFE, ele irá definir o seu próprio loop principal e imediatamente agenda-o para para o próximo frame. Ele não será anexado a nenhum objeto e `main` (ou `main()` para métodos) será um nome válido sem uso no resto da aplicação, livre para ser definido como outra coisa.

Nota: Na prática, é mais comum previnir o próximo `requestAnimationFrame()` com uma declaração `if`, no lugar de chamar `cancelAnimationFrame()`.

Para o próximo problema, parando o loop principal, você precisará cancelar a chamada a `main()` com `window.cancelAnimationFrame()`. Você precisará passar para `cancelAnimationFrame()` o token do ID dado pelo `requestAnimationFrame()` quando ele foi chamado. Vamos assumir que as funções do seu jogo e variáveis estão construídas em um namespace que você chamou de `MyGame`. Expandindo o nosso último exemplo, o loop principal ficaria parecido com isto:
```

/*
* Starting with the semicolon is in case whatever line of code above this example
* relied on automatic semicolon insertion (ASI). The browser could accidentally
* think this whole example continues from the previous line. The leading semicolon
* marks the beginning of our new line if the previous one was not empty or terminated.
*
* Let us also assume that MyGame is previously defined.
*/

;(function () {
  function main() {
    MyGame.stopMain = window.requestAnimationFrame( main );

    // Your main loop contents.
  }

  main(); // Start the cycle
})();
```

Nós temos agora uma variável declarada no namespace do nosso `MyGame`, que nos chamamos de `stopMain`, e que contém o ID retornado pela execução mais recente do `requestAnimationFrame()` do nosso loop principal. Em algum ponto, nós podemos parar o loop principal pedindo ao browser para cancelar a requisição que corresponde ao nosso token.
```

window.cancelAnimationFrame( MyGame.stopMain );
```

A chave para programar loop principal, no JavaScript, é anexá-lo a qualquer evento que deve estar dirigindo sua ação e prestar atenção a como os diferentes sistemas envolvidos interagem entre si. Você poderá ter multiplos componentes dirigidos por multiplos diferentes tipos de eventos. Isto parece complexidade desnecessária mas pode ser só uma boa otimização (não necessária, é claro). O problema é que você não está programando um loop principal típico. No JavaScript, você está usando o loop principal do browser e está tentando fazê-lo efetivamente.

Construindo um loop principal mais *otimizado* no JavaScript
------------------------------------------------------------

Finalmente, no JavaScript, o browser está rodando o seu loop principal e o seu código existe em algum de seus estágios. As seções acima descrevem loops principais que tentam não eliminar o controle do navegador. Esses métodos principais anexam eles mesmos ao `window.requestAnimationFrame()`, que pergunta ao browser por controle sobre o próximo frame. É responsabilidade do browser saber como relacionar esses requests ao loop principal. A especificação da W3C para o requestAnimationFrame não define realmente quando os browsers tem que executar os callbacks do requestAnimationFrame. Isto pode ser uma vantagem por que os fornecedores de browsers podem ter a liberdade de experimentar com as soluções que sintam que seja melhor e podem modifica-la com o passar do tempo.

Versões modernas do Firefox e Google Chrome (e provavelmente outros) tentam conectar os callbacks do `requestAnimationFramea` a sua thread principal no primeiro intervalo de tempo de um frame. A thread principal portanto tenta fazer o seguinte:

1. Começar uma nova frame (enquanto a anterior é tratada pela exibição).
2. Go through the list of `requestAnimationFrame` callbacks and invoke them.
3. Perform garbage collection and other per-frame tasks when the above callbacks stop controlling the main thread.
4. Sleep (unless an event interrupts the browser's nap) until the monitor is ready for your image (VSync) and repeat.

Modern versions of Firefox and Google Chrome (and probably others) *attempt* to connect `requestAnimationFrame` callbacks to their main thread at the very beginning of a frame's timeslice. The browser's main thread thus *tries* to look like the following:

1. Start a new frame (while the previous frame is handled by the display).
2. Go through the list of `requestAnimationFrame` callbacks and invoke them.
3. Perform garbage collection and other per-frame tasks when the above callbacks stop controlling the main thread.
4. Sleep (unless an event interrupts the browser's nap) until the monitor is ready for your image (VSync) and repeat.

You can think about developing realtime applications as having a budget of time to do work. All of the above steps must take place every 16-and-a-half milliseconds to keep up with a 60 Hz display. Browsers invoke your code as early as possible to give it maximum computation time. Your main thread will often start workloads that are not even on the main thread (such as rasterization or shaders in WebGL). Long calculations can be performed on a Web Worker or a GPU at the same time as the browser uses its main thread to manage garbage collection, its other tasks, or handle asynchronous events.

While we are on the topic of budgeting time, many web browsers have a tool called *High Resolution Time*. The `Date` object is no longer the recognised method for timing events because it is very imprecise and can be modified by the system clock. High Resolution Time, on the other hand, counts the number of milliseconds since `navigationStart` (when the previous document is unloaded). This value is returned as a decimal number accurate to a thousandth of a millisecond. It is known as a ``DOMHighResTimeStamp` (en-US)` but, for all intents and purposes, consider it a floating point number.

**Note**: Systems (hardware or software) that are not capable of microsecond accuracy are allowed to provide millisecond accuracy as a minimum. They should provide 0.001ms accuracy if they are capable of it, however.

This value is not too useful alone, since it is relative to a fairly uninteresting event, but it can be subtracted from another timestamp to accurately and precisely determine how much time elapsed between those two points. To acquire one of these timestamps, you can call `window.performance.now()` and store the result as a variable.
```

var tNow = window.performance.now();
```

Back to the topic of the main loop. You will often want to know when your main function was invoked. Because this is common, `window.requestAnimationFrame()` always provides a `DOMHighResTimeStamp` to callbacks as an argument when they are executed. This leads to another enhancement to our previous main loops.
```

/*
* Starting with the semicolon is in case whatever line of code above this example
* relied on automatic semicolon insertion (ASI). The browser could accidentally
* think this whole example continues from the previous line. The leading semicolon
* marks the beginning of our new line if the previous one was not empty or terminated.
*
* Let us also assume that MyGame is previously defined.
*/

;(function () {
  function main( tFrame ) {
    MyGame.stopMain = window.requestAnimationFrame( main );

    // Your main loop contents.
    // tFrame, from "function main ( tFrame )", is now a DOMHighResTimeStamp provided by rAF.
  }

  main(); // Start the cycle
})();
```

Several other optimizations are possible and it really depends on what your game attempts to accomplish. Your game genre will obviously make a difference but it could even be more subtle than that. You could draw every pixel individually on a canvas or you could layer DOM elements (including multiple WebGL canvases with transparent backgrounds if you want) into a complex hierarchy. Each of these paths will lead to different opportunities and constraints.

It is decision... time
----------------------

You will need to make hard decisions about your main loop: how to simulate the accurate progress of time. If you demand per-frame control then you will need to determine how frequently your game will update and draw. You might even want update and draw to occur at different rates. You will also need to consider how gracefully your game will fail if the user's system cannot keep up with the workload. Let us start by assuming that you will handle user input and update the game state every time you draw. We will branch out later.

***Note**:* Changing how your main loop deals with time is a debugging nightmare, everywhere. Think about your needs, carefully, before working on your main loop.

### What most browser games should look like

If your game can hit the maximum refresh rate of any hardware you support then your job is fairly easy. You can simply update, render, and then do nothing until VSync.
```

/*
* Starting with the semicolon is in case whatever line of code above this example
* relied on automatic semicolon insertion (ASI). The browser could accidentally
* think this whole example continues from the previous line. The leading semicolon
* marks the beginning of our new line if the previous one was not empty or terminated.
*
* Let us also assume that MyGame is previously defined.
*/

;(function () {
  function main( tFrame ) {
    MyGame.stopMain = window.requestAnimationFrame( main );

    update( tFrame ); //Call your update method. In our case, we give it rAF's timestamp.
    render();
  }

  main(); // Start the cycle
})();
```

If the maximum refresh rate cannot be reached, quality settings could be adjusted to stay under your time budget. The most famous example of this concept is the game from id Software, RAGE. This game removed control from the user in order to keep its calculation time at roughly 16ms (or roughly 60fps). If computation took too long then rendered resolution would decrease, textures and other assets would fail to load or draw, and so forth. This (non-web) case study made a few assumptions and tradeoffs:

* Each frame of animation accounts for user input.
* No frame needs to be extrapolated (guessed) because each draw has its own update.
* Simulation systems can basically assume that each full update is ~16ms apart.
* Giving the user control over quality settings would be a nightmare.
* Different monitors input at different rates: 30 FPS, 75 FPS, 100 FPS, 120 FPS, 144 FPS, etc.
* Systems that are unable to keep up with 60 FPS lose visual quality to keep the game running at optimal speed (eventually it outright fails, if quality becomes too low.)
### Other ways to handle variable refresh rate needs

Other methods of tackling the problem exist.

One common technique is to update the simulation at a constant frequency and then draw as much (or as little) of the actual frames as possible. The update method can continue looping without care about what the user sees. The draw method can view the last update and when it happened. Since draw knows when it represents, and the simulation time for the last update, it can predict a plausible frame to draw for the user. It does not matter whether this is more frequent than the official update loop (or even less frequent). The update method sets checkpoints and, as frequently as the system allows, the render method draws instants of time around them. There are many ways to separate the update method in web standards:

* Draw on `requestAnimationFrame` and update on a `window.setInterval` (en-US) or `window.setTimeout` (en-US).
    + This uses processor time even when unfocused or minimized, hogs the main thread, and is probably an artifact of traditional game loops (but it is simple.)
* Draw on `requestAnimationFrame` and update on a `setInterval` or `setTimeout` in a Web Worker (en-US).
    + This is the same as above, except update does not hog the main thread (nor does the main thread hog it). This is a more complex solution, and might be too much overhead for simple updates.
* Draw on `requestAnimationFrame` and use it to poke a Web Worker containing the update method with the number of ticks to compute, if any.
    + This sleeps until `requestAnimationFrame` is called and does not pollute the main thread, plus you are not relying on old fashioned methods. Again, this is a bit more complex than the previous two options, and *starting* each update will be blocked until the browser decides to fire rAF callbacks.

Each of these methods have similar tradeoffs:

* Users can skip rendering frames or interpolate extra ones depending on their performance.
* You can count on all users updating non-cosmetic variables at the same constant frequency minus hiccups.
* Much more complicated to program than the basic loops we saw earlier.
* User input is completely ignored until the next update (even if the user has a fast device).
* The mandatory interpolation has a performance penalty.

A separate update and draw method could look like the following example. For the sake of demonstration, the example is based on the third bullet point, just without using Web Workers for readability (and, let's be honest, writeability).

*Note: This example, specifically, is in need of technical review.*
```

/*
* Starting with the semicolon is in case whatever line of code above this example
* relied on automatic semicolon insertion (ASI). The browser could accidentally
* think this whole example continues from the previous line. The leading semicolon
* marks the beginning of our new line if the previous one was not empty or terminated.
*
* Let us also assume that MyGame is previously defined.
*
* MyGame.lastRender keeps track of the last provided requestAnimationFrame timestamp.
* MyGame.lastTick keeps track of the last update time. Always increments by tickLength.
* MyGame.tickLength is how frequently the game state updates. It is 20 Hz (50ms) here.
*
* timeSinceTick is the time between requestAnimationFrame callback and last update.
* numTicks is how many updates should have happened between these two rendered frames.
*
* render() is passed tFrame because it is assumed that the render method will calculate
*          how long it has been since the most recently passed update tick for
*          extrapolation (purely cosmetic for fast devices). It draws the scene.
*
* update() calculates the game state as of a given point in time. It should always
*          increment by tickLength. It is the authority for game state. It is passed
*          the DOMHighResTimeStamp for the time it represents (which, again, is always
*          last update + MyGame.tickLength unless a pause feature is added, etc.)
*
* setInitialState() Performs whatever tasks are leftover before the mainloop must run.
*                   It is just a generic example function that you might have added.
*/

;(function () {
  function main( tFrame ) {
    MyGame.stopMain = window.requestAnimationFrame( main );
    var nextTick = MyGame.lastTick + MyGame.tickLength;
    var numTicks = 0;

    //If tFrame < nextTick then 0 ticks need to be updated (0 is default for numTicks).
    //If tFrame = nextTick then 1 tick needs to be updated (and so forth).
    //Note: As we mention in summary, you should keep track of how large numTicks is.
    //If it is large, then either your game was asleep, or the machine cannot keep up.
    if (tFrame > nextTick) {
      var timeSinceTick = tFrame - MyGame.lastTick;
      numTicks = Math.floor( timeSinceTick / MyGame.tickLength );
    }

    queueUpdates( numTicks );
    render( tFrame );
    MyGame.lastRender = tFrame;
  }

  function queueUpdates( numTicks ) {
    for(var i=0; i < numTicks; i++) {
      MyGame.lastTick = MyGame.lastTick + MyGame.tickLength; //Now lastTick is this tick.
      update( MyGame.lastTick );
    }
  }

  MyGame.lastTick = performance.now();
  MyGame.lastRender = MyGame.lastTick; //Pretend the first draw was on first update.
  MyGame.tickLength = 50; //This sets your simulation to run at 20Hz (50ms)

  setInitialState();
  main(performance.now()); // Start the cycle
})();
```

Another alternative is to simply do certain things less often. If a portion of your update loop is difficult to compute but insensitive to time, you might consider scaling back its frequency and, ideally, spreading it out into chunks throughout that lengthened period. An implicit example of this is found over at The Artillery Blog for Artillery Games, where they adjust their rate of garbage generation to optimize garbage collection. Obviously, cleaning up resources is not time sensitive (especially if tidying is more disruptive than the garbage itself).

This may also apply to some of your own tasks. Those are good candidates to throttle when available resources become a concern.

Summary
-------

I want to be clear that any of the above, or none of them, could be best for your game. The correct decision entirely depends on the trade-offs that you are willing (and unwilling) to make. The concern is mostly with switching to another option. Fortunately, I do not have any experience with this but I have heard it is an excruciating game of Whack-a-Mole.

An important thing to remember for managed platforms, like the web, is that your loop may stop execution for significant periods of time. This could occur when the user unselects your tab and the browser sleeps (or slows) its `requestAnimationFrame` callback interval. You have many ways to deal with this situation and this could depend on whether your game is single player or multiplayer. Some choices are:

* Consider the gap "a pause" and skip the time.
    + You can probably see how this is problematic for most multiplayer games.
* You can simulate the gap to catch up.
    + This can be a problem for long drops and/or complex updates.
* You can recover the game state from a peer or the server.
    + This is ineffective if your peers or server are out-of-date too, or they don't exist because the game is single player and doesn't have a server.

Once your main loop has been developed and you have decided on a set of assumptions and tradeoffs which suit your game, it is now just a matter of using your decisions to calculate any applicable physics, AI, sounds, network synchronization, and whatever else your game may require.


Ferramentas para o desenvolvimento de jogos - Desenvolvimento de jogos

Ferramentas para o desenvolvimento de jogos
===========================================

Nesta página você pode encontrar links para a nossa ferramenta de desenvolvimento de jogos, artigos, os quais eventualmente abrangem frameworks, compiladores, e ferramentas de debug.

asm.js

Asm.js é um subconjunto muito limitado da linguagem JavaScript, que pode ser muito otimizado e executado em ahead-of-time (AOT) como motor de compilação para um desempenho muito mais rápido do que o seu desempenho JavaScript típico. Isto é, naturalmente, ótimo para jogos.

Emscripten

Um compilador LLVM para JavaScript; com Emscripten, você pode compilar C++ e outras linguagens que podem compilar para bytecode LLVM em JavaScript de alto desempenho.Esta é uma ótima ferramenta para portar aplicativos para a Web! Há um tutorial útil de Emscripten disponível na wiki. Note que estamos cobrir o Emscripten em sua própria seção de MDN.

Gecko profiler

The Gecko profiler extension lets you profile your code to help figure out where your performance issues are so that you can make your game run at top speed

A extensão Gecko profiler permite que você recorte seu código para ajudar a descobrir onde seus problemas de desempenho de modo a poder fazer o seu jogo executar em alta velocidade.

Motores de jogos e ferramentas

Uma lista de engines, templates e tecnologias úteis pare desenvolvedores de jogos.

Shumway

O Shumway é um renderizador para o Adobe Flash construído inteiramente em JavaScript, WebGL, etc., reduzindo a diferença entre os padrões do Flash e da web. Este artigo mostra como fazer uso do Shumway e como contribuir correções e bugs para o projeto.

Toolchain for developing and debugging games

Como isso difere da depuração normal de aplicativos da web? Que ferramentas especializadas estão disponíveis? Um monte disso está sendo coberto pelo Will em ferramentas, mas aqui nós devemos fornecer um tipo de tutorial de prática para jogos de depuração toolchain, com links para coisas do Will:

* Visão geral de ferramentas básicas
* Editor de shader
* Ferramentas de performance (ainda en produção, estimada no início de 2014)


Introduction to HTML5 Game Development (summary) - Desenvolvimento de jogos

Introduction to HTML5 Game Development (summary)
================================================

Vantagens
---------

1. Os Jogos criados com HTML5 funcionam em Smartphones, tablets, PCs e smart TVs.
2. Anuncie e promova seu jogo na Web, bem como em outros meios de comunicação.
3. Pagamentos. Carregue o que quiser e use o serviço de processamento de pagamento que desejar.
4. Atualize seu jogo sempre que quiser.
5. Colete suas próprias análises.
6. Conecte-se com seus clientes mais de perto.
7. Usuários podem jogar sempre que quiserem e quando quiserem.
Tecnologias da Web
------------------

| **Function** | **Tecnologias** |
| --- | --- |
| **Audio** | Web Audio API (en-US) |
| **Gráficos** | WebGL (OpenGL ES 2.0) |
| **Entrada** | Touch events (en-US), Gamepad API (en-US), sensores de dispositivos, WebRTC (en-US), Full Screen API (en-US), Pointer Lock API (en-US) |
| **Linguagens** | JavaScript (ou C/C++ usando Emscripten para compilar o JavaScript) |
| **Networking** | WebRTC (en-US) e/ou WebSockets |
| **Armazenamento** | IndexedDB ou a "nuvem" |
| **Web** | HTML, CSS, SVG, Social API (e muito mais!) |

Full Screen API (en-US)

gameplay de tela cheia

Gamepad API (en-US)

Use gamepads ou outros controladores de jogos.

HTML e CSS

Contrua, estilize e disponha a interface de usuário do seu jogo.

HTML audio

Reproduza facilmente efeitos sonoros simples e música.

IndexedDB

Armazene os dados de usuário em seu próprio computador ou dispositivo.

JavaScript

Linguagem de programação web rápida para escrever o código do seu jogo, para portar facilmente seus jogos existentes Emscripten ou Asm.js.

Pointer Lock API (en-US)

Bloquei o mouse ou outro dispositivo apontador na interface do seu jogo.

SVG (Gráficos Vetorias Escaláveis)

Crie gráficos vetoriais que sejam dimensionados sem problemas, independemente do tamanho ou da resolução da exibição do usuário.

Typed Arrays (en-US)

Acessar dados binários brutos de dentro do JavaScript; Manipule texturas GL, dados de jogos ou qualquer outra coisa.

Web Audio API (en-US)

Controle a reprodução, síntese e manipulação de aúdio em tempo real.

WebGL

Crie gráficos 2D e 3D acelerados por hardware de alto desempenho. OpenGL ES 2.0.

WebRTC (en-US)

Comunicações em tempo real para controlar dados de aúdio e vídeo, incluindo teleconferência e transmissão de outros dados de aplicativos entre dois usuários, como bate-papo.

WebSockets

Conecte seu aplicativo ou site a um servidor para transmitir dados em tempo real. Perfeito para ação de jogo multiplayer, serviços de bate-papo e assim por diante.

Web Workers (en-US)

Crie threads em segundo plano executando seu próprio código JavaScript para processadres multi-core.

XMLHttpRequest e File API

Envie e receba quaisquer tipo de dados que você quiser de um servidor da Web, como baixar novos níveis de jogos e ilustrações para transmitir informações de status de jogos não em tempo real.


Introdução ao desenvolvimento de jogos para a Web - Desenvolvimento de jogos

Introdução ao desenvolvimento de jogos para a Web
=================================================

A web moderna rapidamente tem se tornado uma plataforma não só para criar jogos esplêndidos de alta qualidade, mas também para a distribuição desses mesmos jogos.

A gama de jogos que podem ser criados é compatível com as partes equivalentes de Desktop e contrapartes nativas de SO. Com modernas tecnologias da Web e um navegador recente, é perfeitamente possível fazer jogos impressionantes e de primeira qualidade para a Web. E não estamos falando de jogos de cartas simples ou de jogos sociais multijogadores que, nos tempos antigos, foram feitos usando Flash®. Estamos falando de FPS de ação 3D, RPGs e mais. Graças às melhorias de desempenho macias em tecnologia de compilação just-in-time de JavaScript e novas APIs, você pode construir jogos que são executados no navegador (ou em dispositivos com HTML5 como aqueles baseados no sistema operacional Firefox) sem compromissos.

A plataforma de jogo HTML5
--------------------------

Você pode realmente pensar na Web como uma melhor plataforma de destino para o seu jogo. Como gostamos de dizer , "A Web é a plataforma". Vamos dar uma olhada no núcleo da plataforma da Web:

| Função | Tecnologia |
| --- | --- |
| **Audio** | Web Audio API |
| **Gráficos** | WebGL (OpenGL ES 2.0) |
| **Entrada (Input)** | Touch events, Gamepad API (en-US), device sensors, WebRTC (en-US), Full Screen API (en-US), Pointer Lock API (en-US) |
| **Linguagem** | JavaScript (ou C/C++ usando Emscripten para compilar para JavaScript) |
| **Rede** | WebRTC (en-US) e/ou WebSockets |
| **Armazenamento** | IndexedDB ou o "cloud" |
| **Web** | HTML, CSS, SVG, Social API (e muito mais!) |

O caso de negócios
------------------

Como desenvolvedor de jogos, seja individual ou um grande estúdio de jogos, você quer saber por que faz sentido ter como alvo a Web com o seu próximo projeto de jogo. Vejamos como a Web pode ajudá-lo.

1. O alcance da Web é enorme; Está em toda parte. Jogos criados com HTML5 em smartphones, tablets, PCs e Smart TVs.
2. O marketing e a descoberta são melhorados. Você não está limitado a promover o seu aplicativo na loja de aplicativos de outra pessoa. Em vez disso, você pode anunciar e promover o seu jogo em toda a Web, bem como outros meios de comunicação, aproveitando a capacidade de compartilhamento inerente e compartilhamento da Web para alcançar novos clientes.
3. Você tem controle onde isso importa: Pagamentos. Você não precisa entregar mais de 30% de suas receitas para outra pessoa apenas porque seu jogo está em seu ecossistema. Em vez disso, carregue o que deseja e use qualquer serviço de processamento de pagamento que você gosta.
4. Novamente com mais controle, você pode atualizar seu jogo sempre que quiser. Não espera sem fôlego para aprovação, enquanto alguém escondido em outra empresa decide se a sua correção crítica de erros será ou não enviada hoje ou amanhã.
5. Controle suas análises! Em vez de confiar em outra pessoa para tomar todas as decisões sobre o que você precisa, você pode coletar o seu próprio — ou escolha o terceiro que você gosta do melhor — para coletar informações sobre suas vendas e o alcance do seu jogo.
6. Você consegue gerenciar seu relacionamento com o cliente de forma mais próxima, à sua maneira. Não há mais comentários do cliente filtrados através dos mecanismos limitados de uma loja de aplicativos. Participe com seus clientes da maneira que você quiser, sem intermediário.
7. Seus jogadores podem jogar seu jogo em qualquer lugar, a qualquer hora. Como a Web é onipresente, seus clientes podem verificar o status do seu jogo em seus telefones, tablets, laptops domésticos, desktops de trabalho ou qualquer outra coisa.
Tecnologias da Web para desenvolvedores de jogos
------------------------------------------------

Para as pessoas de tecnologia, vamos cavar as APIs que a Web traz à mesa que atendem aos desenvolvedores de jogos. Aqui está uma lista completa para dar uma amostra do que a Web pode fazer por você:

Full Screen API (en-US)

Esta API simples permite que seu jogo ocupe toda a tela, imergindo assim o jogador em ação.

Gamepad API (en-US)

Se você quiser que seus usuários possam usar gamepads ou outros controladores de jogos para trabalhar seu jogo, você precisará desta API.

HTML e CSS

Juntas, essas duas tecnologias permitem que você possa criar, estilizar e definir a interface do usuário do seu jogo. Parte do HTML é o `<canvas>` elemento, que fornece uma maneira de fazer gráficos 2D.

HTML audio

O `<audio>` elemento permite reproduzir facilmente efeitos sonoros e música. Se suas necessidades estão mais envolvidas, confira a API Web Áudio para obter poder real de processamento de áudio!

IndexedDB

Uma poderosa API de armazenamento de dados para manter os dados do usuário em seu próprio computador ou dispositivo. Uma ótima maneira de salvar o estado do jogo e outras informações localmente, portanto não precisa ser baixado sempre que for necessário. Também é útil para ajudar a tornar o seu jogo jogável mesmo quando o usuário não está conectado à Web (como quando estão presos em um avião por horas a fio).

JavaScript

JavaScript, a linguagem de programação usada na Web, está sendo lançada rapidamente em navegadores modernos e cada vez mais rápido. Use seu poder para escrever o código do seu jogo, ou olhe para usar tecnologias como Emscripten ou Asm.js para facilmente acessar seus jogos existentes.

Pointer Lock API (en-US)

O Pointer Lock API permite bloquear o mouse ou outro dispositivo apontador na interface do seu jogo, de modo que, em vez do posicionamento absoluto do cursor, você receba deltas de coordenadas que lhe dê medidas mais precisas sobre o que o usuário está fazendo e evite que o usuário envie acidentalmente sua entrada para outro lugar. Falta de uma ação importante.

SVG (Scalable Vector Graphics)

Permite criar gráficos vetoriais que se dimensionem sem problemas, independentemente do tamanho ou resolução da exibição do usuário.

Typed Arrays

JavaScript typed arrays da acesso a dados binários em bruto a partir do JavaScript; Isso permite manipular texturas GL, dados de jogos ou qualquer outra coisa, mesmo que não esteja em formato nativo do JavaScript.

Web Audio API

Essa API para controlar a reprodução, síntese e manipulação de áudio a partir do código JavaScript, você pode criar efeitos de som incríveis, além de reproduzir e manipular música em tempo real.

WebGL

Permite criar 3D de alta performance, acelerado por hardware (e 2D) a partir de conteúdo da Web. Esta é uma implementação suportada pela Web de OpenGL ES 2.0.

WebRTC (en-US)

O WebRTC (Real-Time Communications) API Dá-lhe o poder de controlar dados de áudio e vídeo, incluindo teleconferência e transmissão de outros dados de aplicativos de um lado a outro entre dois usuários. Quer que seus jogadores possam conversar um com o outro enquanto explodem monstros? Esta é a API para você.

WebSockets

O WebSocket API permite conectar seu aplicativo ou site a um servidor para transmitir dados de um lado para o outro em tempo real. Perfeito para a ação de jogo multiplayer, serviços de bate-papo, e assim por diante.

Web Workers (en-US)

Os trabalhadores dão-lhe a capacidade de gerar threads de fundo executando seu próprio código JavaScript, para aproveitar os modernos processadores multi-core.

XMLHttpRequest e File API (en-US)

A combinação de XMLHttpRequest e o File API Permite enviar e receber qualquer tipo de dados que você deseja (não deixe o "XML" te jogar!) de um servidor da Web. Esta é uma ótima maneira de fazer qualquer coisa, desde o download de novos níveis de jogos e obras de arte para a transmissão de informações de status do jogo não real-time para frente e para trás.


Publishing games - Desenvolvimento de jogos

Publishing games
================

Jogos em HTML5 possuem uma grande vantagem sobre jogos nativos em termos de publicação e distribuição — você possui a liberdade de distribuição, promoção e monetização do seu jogo na Web, ao invés de que cada versão ficará presa em uma única loja controlada por uma empresa. Você pode se beneficiar com a Web sendo realmenete multiplataforma. Essa série de artigos demonstra as opções que você têm quando for publicar e distribuir o se jogo, e ter algum retorno enquanto você espera para se tornar famoso.Distribuição do jogo
--------------------

Então você realizou um (en-US) ou dois tutoriais (en-US) e desenvolveu um jogo em HTML5 - isso é ótimo! Distribuição de jogos provém tudo o que você necessita saber para poder distribuir o seu jogo recém criado para o mundo — incluindo hospedagem online, submetendo para marketplaces aberto, e submetendo para marketplaces fechados como Google Play ou iOS App Store.

Promovendo o jogo
-----------------

Desenvolver e terminar um jogo não é coisa fácil. Você precisa deixar claro ao mundo que você fez uma coisa interessante estar disponível, em que as pessoas irão se divertir jogando. Existem diversas técnicas de promover os jogos (en-US) — muitos deles sendo de graça — então mesmo você passando por dificuldades e batalhando para que consiga se sustentar como um desenvolvedor indie com zero de orçamento você consegue fazer muita coisa para deixar as pessoas sabendo sobre o seu mais eletrizante jogo. Promover o jogo ajuda, e em muito, conseguir monetizar ele mais pra frente, então é importante que você faça de uma forma efetiva.

Monetização do jogo
-------------------

Quando você passa horas e horas construindo, publicando e promovendo o seu jogo, você vai considerar, em algum ponto, conseguir algum sustento financeiro com ele. Monetização de jogos (en-US) é essencial para qualquer pessoa que considera o seu trabalho de desenvolvimento de jogos um esforço sério no caminho para se tornar um desenvolvedor de jogos independente, capaz de se sustentar, então leia mais e veja quais são as suas opções. A tecnologia está madura o suficiente; é apenas uma questão de escolher a melhor abordagem.


asm.js - Desenvolvimento de jogos

asm.js
======

Asm.js é uma especificação que define um subconjunto de JavaScript que é altamente otimizável. Esta seção examina exatamente o que é permitido no subconjunto asm.js, que melhorias confere, Onde e como você pode fazer uso dele, e mais Principais recursos e exemplos.

O que é asm.js, exatamente?
---------------------------

É muito pequeno estrita subconjunto de JavaScript, que permite que apenas coisas como `while`, `if`, números, chamado funções de nível superior, e outros meros constructos. Ele não permite que objetos, cordas, fechos, e basicamente qualquer coisa que requer a alocação heap. Asm.js se assemelha ao código C, em muitos aspectos, o objectivo é ainda válida JavaScript Chamada completamente que será executado em todos os motores atuais. Ele empurra motores de JS para otimizar este tipo de código e compiladores como emscripten Dá uma definição clara de que tipo de código para gerar. Vamos mostrar o que asm.js código se parece com e explicar como ele ajuda e como você pode usá-lo.

Este subconjunto de JavaScript já é altamente otimizado motores de JavaScript em Many fantasia usando Just-In-Time (JIT) compilação técnica. No entanto, através da definição de um padrão explícito podemos trabalhar com isso otimizando este tipo de código ainda mais e obter o máximo de desempenho como nós podemos sair dela. Ela torna mais fácil para colaborar através de vários motores de JS porque é fácil para falar e benchmark. A idéia é que este tipo de código de correr muito rápido em deveres Cada motor, e se isso não acontecer, é um bug e há uma motores de especificação claro que shoulds otimizar.

Ele aussi Torna mais fácil para as pessoas que escrevem compiladores que deseja gerar código de alto desempenho na Web. Podem consultar a especificação asm.js e sei que ele vai correr rápido Se eles aderem a asm.js padrões. Emscripten, um C / C ++ para compilador JavaScript, EMITE código asm.js para fazê-lo funcionar com desempenho quase nativo em vários navegadores.

Além disso, se um motor especialmente escolhe reconhecer asm.js código, há otimizações ainda mais que pode ser feito. Firefox é o único no navegador para fazer isso agora.

Resumo linguagem asm.js
-----------------------

asm.js é uma linguagem de programação intermediária. asm.js: tem uma taxa de perfomance muito previsível Porque é limitado a um subconjunto muito limitado de JavaScript que fornece inteiros única estritamente tipados, flutuadores, aritmética, chamadas de função, e montão acessos. As características de desempenho estão mais perto de código nativo do que a de JavaScript padrão. Usando um subconjunto de asm.js JavaScript já é suportado pelos principais navegadores web. Desde asm.js executado em um navegador fortemente depende do navegador e do hardware.


Detecção de Colisão 2D - Desenvolvimento de jogos

Detecção de Colisão 2D
======================

Algoritmos para detectar colisões em jogos 2D dependem do tipo de formas que podem colidir (por exemplo, retângulo para retângulo, retângulo para círculo, círculo para círculo). Geralmente, você terá uma forma genérica simples que abrange a entidade conhecida como "hitbox", portanto, mesmo que a colisão não seja perfeita, ela terá boa aparência e terá bom desempenho em várias entidades. Este artigo fornece uma revisão das técnicas mais comuns usadas para fornecer detecção de colisão em jogos 2D.

Caixa delimitadora alinhada por eixo
------------------------------------

Uma das formas mais simples de detecção de colisão é entre dois retângulos alinhados no eixo — ou seja, sem rotação. O algoritmo funciona garantindo que não haja nenhum espaço entre os 4 lados dos retângulos. Qualquer lacuna significa que uma colisão não existe.

```js
var rect1 = { x: 5, y: 5, width: 50, height: 50 };
var rect2 = { x: 20, y: 10, width: 10, height: 10 };

if (
  rect1.x < rect2.x + rect2.width &&
  rect1.x + rect1.width > rect2.x &&
  rect1.y < rect2.y + rect2.height &&
  rect1.y + rect1.height > rect2.y
) {
  // collision detected!
}

// filling in the values =>

if (5 < 30 && 55 > 20 && 5 < 20 && 55 > 10) {
  // collision detected!
}
```

```
<div id="cr-stage"></div>
<p>
  Mova o retângulo com as setas do teclado. Verde significa colisão, azul
  significa não-colisão.
</p>
<script
 type="text/javascript"
 src="https://cdnjs.cloudflare.com/ajax/libs/crafty/0.5.4/crafty-min.js"></script>
```

```
Crafty.init(200, 200);

var dim1 = { x: 5, y: 5, w: 50, h: 50 };
var dim2 = { x: 20, y: 10, w: 60, h: 40 };

var rect1 = Crafty.e("2D, Canvas, Color").attr(dim1).color("red");

var rect2 = Crafty.e("2D, Canvas, Color, Keyboard, Fourway")
  .fourway(2)
  .attr(dim2)
  .color("blue");

rect2.bind("EnterFrame", function () {
  if (
    rect1.x < rect2.x + rect2.w &&
    rect1.x + rect1.w > rect2.x &&
    rect1.y < rect2.y + rect2.h &&
    rect1.h + rect1.y > rect2.y
  ) {
    // collision detected!
    this.color("green");
  } else {
    // no collision
    this.color("blue");
  }
});
```

**Nota:** Outro exemplo sem o Canvas ou bibliotecas externas.

Colisão Circular
----------------

Outra forma simples para detecção de colisão é entre dois círculos. Esse algoritmo funciona tomando os pontos centrais dos dois círculos e garantindo que a distância entre os pontos centrais seja menor que os dois raios somados.
```

<div id="cr-stage"></div>
<p>
  Move the circle with arrow keys. Green means collision, blue means no
  collision.
</p>
<script
 type="text/javascript"
 src="https://cdnjs.cloudflare.com/ajax/libs/crafty/0.5.4/crafty-min.js"></script>
```

```
#cr-stage {
  position: static !important;
  height: 200px !important;
}
```

```
Crafty.init(200, 200);

var dim1 = { x: 5, y: 5 };
var dim2 = { x: 20, y: 20 };

Crafty.c("Circle", {
  circle: function (radius, color) {
    this.radius = radius;
    this.w = this.h = radius \* 2;
    this.color = color || "#000000";

    this.bind("Move", Crafty.DrawManager.drawAll);
    return this;
  },

  draw: function () {
    var ctx = Crafty.canvas.context;
    ctx.save();
    ctx.fillStyle = this.color;
    ctx.beginPath();
    ctx.arc(
      this.x + this.radius,
      this.y + this.radius,
      this.radius,
      0,
      Math.PI \* 2,
    );
    ctx.closePath();
    ctx.fill();
    ctx.restore();
  },
});

var circle1 = Crafty.e("2D, Canvas, Circle").attr(dim1).circle(15, "red");

var circle2 = Crafty.e("2D, Canvas, Circle, Fourway")
  .fourway(2)
  .attr(dim2)
  .circle(20, "blue");

circle2.bind("EnterFrame", function () {
  var dx = circle1.x + circle1.radius - (circle2.x + circle2.radius);
  var dy = circle1.y + circle1.radius - (circle2.y + circle2.radius);
  var distance = Math.sqrt(dx \* dx + dy \* dy);

  if (distance < circle1.radius + circle2.radius) {
    // collision detected!
    this.color = "green";
  } else {
    // no collision
    this.color = "blue";
  }
});
```

```js
var circle1 = { radius: 20, x: 5, y: 5 };
var circle2 = { radius: 12, x: 10, y: 5 };

var dx = circle1.x - circle2.x;
var dy = circle1.y - circle2.y;
var distance = Math.sqrt(dx \* dx + dy \* dy);

if (distance < circle1.radius + circle2.radius) {
  // collision detected!
}
```

**Nota:** Aqui é outro exemplo sem o Canvas ou bibliotecas externas.

Teorema do eixo de separação
----------------------------

Este é um algoritmo de colisão que pode detectar uma colisão entre quaisquer dois polígonos \*convexos\*. É mais complicado implementar do que os métodos acima, mas é mais poderoso. A complexidade de um algoritmo como esse significa que precisaremos considerar a otimização de desempenho, abordada na próxima seção.

A implementação do SAT está fora do escopo desta página, portanto, veja os tutoriais recomendados abaixo:

1. Separating Axis Theorem (SAT) explanation
2. Collision detection and response
3. Collision detection Using the Separating Axis Theorem
4. SAT (Separating Axis Theorem)
5. Separation of Axis Theorem (SAT) for Collision DDetection
Performance de Colisão
----------------------

Embora alguns desses algoritmos para detecção de colisão sejam simples o suficiente para serem calculados, pode ser um desperdício de ciclos testar todas as entidades com todas as outras entidades. Normalmente os jogos dividem a colisão em duas fases, ampla e estreita.

### Fase Larga

A fase ampla deve fornecer uma lista de entidades que \*podem\* estar colidindo. Isso pode ser implementado com uma estrutura de dados espacial que lhe dará uma ideia aproximada de onde a entidade existe e o que existe em torno dela. Alguns exemplos de estruturas de dados espaciais são Quad Trees, R-Trees ou um Spash Hashmap.

### Fase estreita

Quando você tem uma pequena lista de entidades para verificar, você vai querer usar um algoritmo de fase estreita (como os listados acima) para fornecer uma resposta certa sobre se há uma colisão ou não.


Jogos 3D na WEB - Desenvolvimento de jogos

Jogos 3D na WEB
===============

A melhor arma para desenvolver ótimas experiências em jogos na WEB é WebGL, que é renderizada em HTML `<canvas>`. WebGL é, basicamente, uma OpenGL ES 2.0 para a Web — é uma API JavaScript que fornece ferramentas para construir animações ricas e, logicamente, jogos. Você pode gerar e renderizar gráficos dinâmicos em 3D com JavaScript acelerado por hardware.

Documentação e suporte para navegadores
---------------------------------------

A documentação e as especificações do projeto WebGL é mantida pelo Grupo Khronos, não o W3C como a maioria das APIs Web. O suporte nos navegadores modernos é muito bom, até mesmo em mobile, portanto você não terá que se preocupar muito com isso. Todos os navegadores comuns suportam WebGL e tudo mais que você precisar para que possa focar em otimizar o desempenho nos dispositivos que usar.

Há um esforço contínuo em liberar WebGL 2.0 (baseado na OpenGL ES 3.0) em um futuro próximo para, além de trazer muitas melhorias, também ajudar os desenvolvedores a construir jogos para a Web "moderna", usando hardware atual e poderoso.

Explicando a teoria 3D básica
-----------------------------

O básico da teoria 3D gira em torno de formas representadas em um espaço 3D, que corresponde a um sistema de coordenadas usadas para calcular suas posições. Veja noss artigo Explicando a teoria 3D básica (en-US) para todas as informações que você precisar

Conceitos avançados
-------------------

Você pode fazer muito mais com WebGL. Há alguns conceitos avançados que você deve se aprofundar e aprender mais — como shaders, detecção de colisão, ou o mais recente tópico em alta — realidade virtual na web.

### Shaders

É importante mencionar os shaders, que tem uma história separada por sí próprios. Shaders usam GLSL, uma "Linguagem de Sombreamento" OpenGL especial com sintaxe similar a C, que é executada diretamente pelos pipelines de gráficos. Podem ser divididos em Vertex Shaders e Fragment Shaders (ou Pixel Shaders) — o primeiro transforma as posições das formas em coordenadas reais de desenho 3D, enquanto o segundo calcula cores de renderização e outros atributos. Recomendamos fortemente que você veja o artigo GLSL Shaders (en-US) para aprender mais sobre eles.

### Detecção de Colisão

É difícil de imaginar um jogo sem detecção de colisão — nós sempre precisamos trabalhar com algo batendo em alguma outra coisa. Temos informações disponíveis para você aprender em:

* Detecção de colisão 2D
* Detecção de colisão 3D (en-US)
### WebVR

O conceito de realidade virtual não é novo, mas está crescendo na web devido os avanços de hardware, tal como o Oculus Rift, e a (atualmente experimental) WebVR API para capturar informações de hardware via Realidade Virtual (RV) e tonaná-la acessível para uso em aplicações JavaScript. Para mais informações, leia WebVR — Realidade Virtual para a Web (en-US).

Também há o artigo Desenvolvendo uma demo básica com A-Frame (en-US) que te mostra como é fácil construir ambientes 3D para realidade virtual usando o framework A-Frame.

O surgimentos de bibliotecas e frameworks
-----------------------------------------

Codificar WebGL diretamente é bem complexo, mas você vai querer se familiarizar com isso a longo prazo quando seus projetos avançarem (veja nossa documentação WebGL para começar). Para projetos do mundo real você provavelmente também usará um framework para acelerar o desenvolvimento e ajudar na administração do projeto em que estiver trabalhando. Usar um framework para jogos 3D também ajuda muito a otimizar o desempenho, assim você pode focar no desenvolvimento do jogo.

A biblioteca JavaScript 3D mais popular é Three.js, uma ferramenta multiuso que deixa técnicas 3D comuns mais simples de serem implementadas. Há outras bibliotecas de desenvolvimento de jogos populares e alguns frameworks que valem a pena serem checados também; A-Frame, PlayCanvas e Babylon.js estão entre os mais reconhecidos, com belas documentações, editores online e comunidades ativas.

### Desenvolvendo uma demo básica com A-Frame

A-Frame é um framework web para desenvolvimento 3D e experiências de RV. Visto mais afundo, é um framework three.js com um padrão componente-entidade declarativo, significando que podemos construir cenas apenas com HTML. Veja a página Desenvolvendo uma demo básica com A-Frame (en-US) para o passo-a-passo da criação de uma demo.

### Desenvolvendo uma demo básica com Babylon.js

Babylon.js é um dos mais populares motores de jogos 3D usados por desenvolvedores. Assim como qualquer outra biblioteca 3D, ela fornece funções integradas para te ajudar a implementar funcionalidades tridimensionais comuns mais rapidamente. Veja a página Desenvovlendo uma demo básica com Babylon.js (en-US) para saber o básico de Babylon.js, incluindo configurações do ambiente de desenvolvimento, estruturar o HTML necessário e escrever o código JavaScript.

### Desenvolvendo uma demo básica com PlayCanvas

PlayCanvas é um popular motor de jogos 3D WebGL de código aberto no GitHub, com um editor acessível online e com boa documentação. Veja a página Desenvolvendo uma demo básica com PlayCanvas (en-US) para detalhes mais avançados e encontrar outros artigos mostrando como usar a bilbioteca PlayCanvas e o editor online.

### Desenvolvendo uma demo básica com Three.js

Three.js, assim como qualquer outra biblioteca, lhe fornece uma enorme vantagem: ao invés de escrever centenas de linhas do código WebGL para construir qualquer coisa interessante, te permite usar as funções auxiliares integradas para desenvolver o que quiser muito mais rápido e fácil. Veja a página Desenvolvendo uma demo básica com Three.js (en-US) para o passo-a-passo da criação de uma demo.

### Outras ferramentas

Tanto Unity quanto Unreal podem exportar o seu jogo para WebGL com asm.js, então você estará livre para usar suas ferramentas e técnicas para desenvolvimento de jogos que serão exportados para a web.

![](http://end3r.github.io/MDN-Games-3D/A-Frame/img/shapes.png)

Para onde ir agora
------------------

Com esse artigo nós apenas arranhamos a superfície do que é possível fazer com as tecnologias disponíveis atualmente. Você pode desenvolver jogos imersivos, belos e rápidos na WEB usando WebGL, e as bibliotecas e frameworks construídos sobre ele.

### Código-fonte

Você pode encontrar todo o código fonte para esta série de demos no GitHub.

### APIs

* Canvas API
* WebGL API
* WebVR API
### Frameworks

* Three.js
* Whitestorm.js (baseado em Three.js)
* PlayCanvas
* Babylon.js
* A-Frame
### Tutoriais

* Desenvolvendo uma demo básica com Three.js (en-US)
* Desenvolvendo uma demo básica com Whitestorm.js
* Desenvolvendo uma demo básica com PlayCanvas (en-US)
* Desenvovlendo uma demo básica com Babylon.js (en-US)
* Desenvolvendo uma demo básica com A-Frame (en-US)


Desenvolvedor Web Front-end - Aprendendo desenvolvimento web

Desenvolvedor Web Front-end
===========================

Boas vindas a nossa trilha de estudos para Desenvolvedor Web Front-end!

Aqui nós provemos um curso estruturado que irá lhe ensinar tudo o que você precisa para se tornar um desenvolvedor web front-end. Simplesmente trabalhe em cada sessão, aprendendo novas habilidades (ou melhorando as existentes) à medida que avança. Durante cada sessão, você encontrará exercícios e avaliações para testar sua compreensão antes de avançar.

Temas cobertos
--------------

Os temas gerais abordados são:

* Configuração básica e aprender como aprender
* Padrões Web e melhores práticas (como acessibilidade e compatibilidade cross-browser)
* HTML, a linguagem que fornece significado e estrutura ao conteúdo web
* CSS, a linguagem usada para estilizar as páginas web
* JavaScript, a linguagem de scripts usada para criar funcionalidades dinâmicas na web
* Ferramentas usadas para facilitar o desenvolvimento client-side moderno.

As diferentes sessões são desenhadas para trabalhar em ordem, mas cada uma também é independente. Se, por exemplo, você já souber HTML, pode avançar rapidamente para a sessão de CSS.

**Pré**-**requisitos**
----------------------

Você não precisa de nenhum conhecimento prévio para começar este curso. Tudo o que você precisa é um computador executando um navegador web moderno, uma conexão com internet, e vontade de aprender.

Se você não tem certeza se o desenvolvimento front-end é para você, e/ou se deseja uma introdução mais suave antes de começar um curso mais completo, você pode conferir primeiro nossa Introdução à web.

Conseguindo ajuda
-----------------

Nós tentamos deixar os estudos de desenvolvimento web front-end o mais confortável possível, entretanto, você provavelmente chegará em algum ponto em que irá travar por não entender alguma coisa, ou algum código pode não funcionar como deveria.

Não entre em pânico. Às vezes, todas as pessoas ficam presas, sejamos iniciantes ou profissionais em desenvolvimento web. O artigo Aprendendo a Aprender (à ser adicionado) irá te prover uma série de dicas e sugestões sobre como procurar informações e se ajudar. E se você continuar travando, sinta-se à vontade para postar uma dúvida em nosso fórum no Discourse.

Vamos começar. Boa sorte!

A trilha de estudos
-------------------

### Começando

Tempo para completar: 1–2 horas

#### Pré-requisitos

Nada, exceto conhecimentos básicos de informática.

#### Como saberei se posso seguir em frente?

Não há avaliações nesta parte do curso. Certifique-se de não ignorá-lo — é importante para te preparar para enfrentar os exercícios mais tarde.

#### Guias principais

* Instalando os programas básicos — configuração básica das ferramentas (15 min de leitura)
* Introdução à Web e aos Padrões Web (45 min de leitura)
* Aprendendo a buscar ajuda (en-US) (45 min de leitura)
### Semântica e estrutura HTML

Tempo para completar: 35–50 horas

#### Pré-requisitos

Nada, exceto conhecimentos básicos de informática e o ambiente de desenvolvimento web básico.

#### Como saberei se posso seguir em frente?

As avaliações em cada módulo são projetadas para testar seu conhecimento sobre o assunto — a conclusão de cada uma provará que você pode passar para o próximo.

#### Guias principais

* Introdução ao HTML (15–20 horas de leitura/exercícios)
* Multimídia e Incorporação (15–20 horas de leitura/exercícios)
* Tabelas em HTML (5–10 horas de leitura/exercícios)
### Estilizando e layout com CSS

Tempo para completar: 90–120 horas

#### Pré-requisitos

É recomendável que você possua o conhecimento básico de HTML antes de começar aprender CSS. Você pode estudar nossa Introdução ao HTML primeiro.

#### Como saberei se posso seguir em frente?

As avaliações em cada módulo são projetadas para testar seu conhecimento sobre o assunto — a conclusão de cada uma provará que você pode passar para o próximo.

#### Guias principais

* Primeiros passos com CSS (10–15 horas de leitura/exercícios)
* Blocos de construção CSS (35–45 horas de leitura/exercícios)
* Estilizando Texto (15–20 horas de leitura/exercícios)
* CSS layout (30–40 horas de leitura/exercícios)

#### Conteúdo adicional

* CSS layout cookbook
### Interatividade com JavaScript

Tempo para completar: 135–185 horas

#### Pré-requisitos

É recomendável que você possua o conhecimento básico de HTML antes de começar aprender JavaScript. Você pode estudar nossa Introdução ao HTML primeiro.

#### Como saberei se posso seguir em frente?

As avaliações em cada módulo são projetadas para testar seu conhecimento sobre o assunto — a conclusão de cada uma provará que você pode passar para o próximo.

#### Guias principais

* Primeiros passos com JavaScript (30–40 horas de leitura/exercícios)
* Elementos construtivos do Javascript (25–35 horas de leitura/exercícioss)
* APIs web do lado cliente (30–40 horas de leitura/exercícios)
* Introdução a objetos em Javascript (25–35 horas de leitura/exercícios)
* JavaScript Assíncrono (25–35 horas de leitura/exercícios)
### Formulários Web — Trabalhando com dados de usuário

Tempo para completar: 40–50 horas

#### Pré-requisitos

Formulários demandam conhecimento em HTML, CSS e JavaScript para o seu bom uso. Eles são complexos e, portanto, recebem tratamento separado.

#### Como saberei se posso seguir em frente?

As avaliações em cada módulo são projetadas para testar seu conhecimento sobre o assunto — a conclusão de cada uma provará que você pode passar para o próximo.

#### Guias principais

* Formulários da Web - Trabalhando com dados do usuário (40–50 horas)
### Fazendo uma web para todas as pessoas

Tempo para completar: 60–75 horas

#### Pré-requisitos

É uma boa ideia que você saiba HTML, CSS e JavaScript antes de ler esta sessão — muitas das técnicas e melhores práticas contidas aqui utilizam várias tecnologias.

#### Como saberei se posso seguir em frente?

As avaliações em cada módulo são projetadas para testar seu conhecimento sobre o assunto — a conclusão de cada uma provará que você pode passar para o próximo.

#### Guias principais

* Cross Browser Teste (en-US) (25–30 horas de leitura/exercícioss)
* Acessibilidade (20–25 horas de leitura/exercícios)
### Ferramentas modernas

Tempo para completar: 55–90 horas

#### Pré-requisitos

É uma boa ideia que você saiba HTML, CSS e JavaScript antes de ler esta sessão, as ferramentas citadas aqui utilizam várias dessas tecnologias.

#### Como saberei se posso seguir em frente?

Não temos avaliações específicas neste conjunto de módulos, mas os tutoriais de estudo de caso no final dos 2º e 3º módulos irão te preparar bem para compreender os elementos essenciais das ferramentas modernas.

#### Guias principais

* Git and GitHub (en-US) (5 hour read)
* Understanding client-side web development tools (en-US) (20–25 horas de leitura)
* Understanding client-side JavaScript frameworks (30-60 horas de leitura/exercícios)


Ferramentas e teste - Aprendendo desenvolvimento web

Ferramentas e teste
===================

Assim que você se sentir mais confortável programando nas tecnologias web básicas (como HTML, CSS e JavaScript), e pegar mais experiência, ler mais recursos, e souber mais dicas e truques, você começará a se deparar com todos os tipos de ferramentas, de CSS e JavaScript precompilados, a automação e testes de aplicações, além de outros assuntos mais avançados. Quando seus projetos começam a crescer e a ficarem mais complexos, você irá querer começar a aproveitar mais dessas ferramentas, e a elaborar planos de testes mais confiáveis para seu código. Esta parte do aprendizado está focada em te dar o que você precisa para iniciar e tomar decisões com melhores informações.

A indústria de internet é um excitante lugar de trabalho, mas não é por ter menos problemas. Muito pelo contrário. As tecnologias básicas que usamos para construir sites estão razoavelmente estáveis agora, mas novas funcionalidades estão sendo introduzidas o tempo todo, assim como novas ferramentas — que facilitam o trabalho, e ainda são construídas usando essas mesmas tecnologias — estão constantemente aparecendo. Além disso, nós ainda precisamos ter sempre em mente que essas tecnologias devem funcionar em todos os navegadores, e ter certeza que nosso código segue as melhores práticas que permitem nossos projetos funcionarem em todos os tipos de navegadores e dispositivos que nossos usuários estão usando para navegar na internet, e ainda serem usados por pessoas com deficiência.

Saber quais ferramentas você deve utilizar pode ser um processo bem difícil, então escrevemos esses artigos para te manter informado de quais tipos de ferramentas estão disponíveis, e o que elas podem fazer pra você, e como usar as preferidas do mercado.

**Nota:** pelo fato de novas ferramentas e tecnologias aparecerem e saírem de moda o tempo todo, nós, deliberadamente, escrevemos este material para ser o mais neutro possível — queremos focar, antes de mais nada, nos tipos de tarefas gerais que essas ferramentas podem ajudar você a terminar, e endereçar ferramentas específicas o menos possível. Obviamente precisamos mostrar o uso das ferramentas para demonstrar técnicas específicas, mas que fique claro que com isso não estamos necessariamente, recomendando as ferramentas usadas nas demonstrações como as melhores, ou como único jeito, de se fazer as coisas — na maioria dos casos existem outras formas de se fazer, mas queremos dar a você a forma mais clara que funciona.

Caminho de aprendizado
----------------------

Você realmente deve aprender os conceitos básicos de HTML, CSS e JavaScript antes de utilizar as ferramentas descritas aqui. Isto é, você precisará conhecer os principios fundamentais dessas linguagens antes de começar a debugar problemas em códigos mais complexos da internet, ou usar alguma biblioteca JavaScript, ou escrever testes e rodá-los no seu código com executores de testes, etc.

Você realmente precisa de uma base forte de conhecimento nessas tecnologias antes de ir mais além.

Módulos
-------

Ferramentas de Desenvolvimento Web do Mundo Real (TBD)

Neste módulo, exploramos os diferentes tipos de ferramentas de desenvolvimento web disponíveis. Isso inclui revisar os tipos de tarefas mais comuns que será pedido a você para resolver, como elas se complementam no trabalho, e as melhores ferramentas disponíveis atualmente para endereçar essas tarefas.

Testes de navegadores (en-US)

Este módulo olha especificamente para a área de testes de projetos web sobre diferentes navegadores web. Neste módulo, procuramos identificar seu público alvo (por exemplo, quais usuários, navegadores e dispositivos você mais precisa se preocupar?), como elaborar os testes, os principais problemas que você vai enfrentar com tipos de código diferentes e como consertar ou mitigá-los, e como usar a automação para acelerar os testes.


Questões comuns - Aprendendo desenvolvimento web

Questões comuns
===============

Esta sessão de Área de Aprendizado é voltada para dar respostas à questões comuns que possam surgir, que não necessariamente sejam parte do núcleo dos meios de aprendizado (ex. artigos sobre HTML ou CSS.) Estes artigos foram feitos para funcionar de forma independente.

Questões sobre HTML e CSS
-------------------------

Leia Use HTML to solve common problems (em inglês) e Use CSS to solve common problems (en-US) (em inglês) para solução de problemas comuns com HTML/CSS.

Como a Web funciona?
--------------------

Esta seção cobre a mecânica da Web —questões relacionadas a conhecimentos gerais sobre o ecossistema da Web e como ele funciona.

Como a Internet funciona?

A **Internet** é a espinha dorsal da Web, a infraestrutura técnica que faz a Web possível. Mais basicamente, a Internet é uma gigantesca rede de computadores que se comunicam juntos. Este artigo discute o básico sobre o funcionamento da Internet.

Qual a diferença entre webpage, website, web server, and search engine?

Nesse artigo nós descrevemos vários conceitos relaciona a Web: webpages, websites, Web servers, and search engines. Esses termos são frequentemente confundidos por iniciantes na web, ou são utizados de maneira incorreta. Vamos entender o que eles realmente significam!

O que é uma URL? (en-US)

Com Hypertext (en-US) e HTTP, URL é um conceito-chave quando se trata da Internet. Ele é um mecanimos utilizado pelos navegadores para recuperar qualquer recurso publicado na Web

O que é um domain name?

Domain names eles são uma parte essencial para a infraestrutura da internet. Eles deixam o endereço legivel por humanos para qualquer Web server disponivel na internet.

O que é um web server?

O termo "Web server" pode se referir ao hardware ou ao software que serve sites para clientes na Web — ou ambos deles trabalhando juntos. Nesse artigo nós veremos como Web servers funcionam, e porque eles são importantes.

O que são hyperlinks?

Nesse artigo, nós veremos do que são hypelinks e porque eles importam.

Tools and setup
---------------

Questions related to the tools/software you can use to build websites.

How much does it cost to do something on the Web? (en-US)

When you're launching a website, you may spend nothing or your costs may go through the roof. In this article we discuss how much everything costs and what you get for what you pay (or don't pay).

What software do I need to build a website?

In this article we explain which software components you need when you're editing, uploading, or viewing a website.

What text editors are available? (en-US)

In this article we highlight some things to think about when choosing and installing a text editor for web development.

How do I set up a basic working environment? (en-US)

When working on a web project, you'll want to test it locally before you show it to the world. Some types of code require a server to test, and in this article we'll show you how to set one up. We'll also cover how to put a scalable structure in place so that your files stay organized even when your project gets big.

What are browser developer tools?

Every browser features a set of devtools for debugging HTML, CSS, and other web code. This article explains how to use the basic functions of your browser's devtools.

How do you make sure your website works properly? (en-US)

So you've published your website online — very good! But are you sure it works properly? This article provides some basic troubleshooting steps.

How do you upload files to a web server?

This article shows how to publish your site online with FTP (en-US) tools — one fo the most common ways to get a website online so others can access it from their computers.

How do I use GitHub Pages? (en-US)

This article provides a basic guide to publishing content using GitHub's gh-pages feature.

How do you host your website on Google App Engine?

Looking for a place to host your website? Here's a step-by-step guide to hosting your website on Google App Engine.

What tools are available to debug and improve website performance?

This set of articles shows you how to use the Developer Tools in Firefox to debug and improve performance of your website, using the tools to check the memory usage, the JavaScript call tree, the amount of DOM nodes being rendered, and more.

Design and accessibility
------------------------

This section lists questions related to aesthetics, page structure, accessibility techniques, etc.

How do I start to design my website?

This article covers the all-important first step of every project: define what you want to accomplish with it.

What do common web layouts contain? (en-US)

When designing pages for your website, it's good to have an idea of the most common layouts. This article runs thorugh some typical web layouts, looking at the parts that make up each one.

What is accessibility? (en-US)

This article introduces the basic concepts behind web accessibility.

How can we design for all types of users? (en-US)

This article provides basic techniques to help you design websites for any kind of user — quick accessibility wins, and other such things.

What HTML features promote accessibility? (en-US)

This article describes specific features of HTML that can be used to make a web page more accessible to people with different disabilities.


Accessibility - Aprendendo desenvolvimento web

Accessibility
=============

Aprender HTML, CSS e Javascript é útil se você quer se tornar um desenvolvedor web, mas seu conhecimento precisa ir além. Você deve usá-las de forma a maximizar a audiencia dos seus sites, e permitir que todos possam acessar o conteúdo. Para conseguir isso, será necessário seguir boas práticas, realizar testes em vários navegadores (cross browser testing (en-US)) e pensar em acessibilidade desde o início do desenvolvimento. Este módulo abordará a acessibilidade em detalhes.

Visão geral
-----------

Quando alguem descreve um site como 'acessível', entende-se que qualquer usuário pode acessar o conteúdo, independente de como o conteúdo foi acessado - mesmo, e especialmente portadores de limitações físicas ou mentais.

* Os sites devem ser acessíveis por teclado, mouse ou telas sensíveis, e qualquer outra forma, incluindo leitores de tela, ou assistentes de voz, como Alexa, ou Google home.
* As aplicações devem ser compreensíveis e usáveis pelos usuários independentemente de suas habilidades auditivas, visuais, físicas ou cognitivas.
* Os sites também não podem oferecer perigo: alguns movimentos podem causar enxaquecas ou ataques epiléticos.

**Por padrão, o HTML é acessível, se utilizado corretamente.** A acessibilidade web presume que o conteúdo continuará acessível, independente de como o conteúdo será acessado.

O recurso **Inspecionar propriedades de acessibilidade** é uma ótima ferramenta para verificar problemas de acessibilidade nos sites. O vídeo a seguir fornece uma boa introdução sobre a ferramenta.

Prerequisitos
-------------

Para ter o máximo proveito deste módulo, recomendamos que esteja familiarizados com pelos os dois primeiros módulos de HTML, CSS, e JavaScript, ou melhor ainda, com as partes principais do módulo de acessibilidade de cada capítulo, à medida em que vai estudando.

**Nota:** Se você está estudando em um dispositivo que não pode criar novos arquivos, voce pode testar os exemplos em alguma aplicação de codificação online, como JSBin ou Thimble.

Guias
-----

O que é acessibilidade? (en-US)

Este artigo fornece uma visão geral do que é a acessibilidade - isso inclui quais grupos de pessoas devemos considerar e o motivo, quais ferramentas de acessibilidade são utilizadas para interagir com a web e como podemos fazer da acessibilidade web parte do nosso fluxo de desenvolvimento.

HTML: A base para a acessibilidade

Boa parte do conteúdo da Web pode ser 'acessível' apenas garantindo que as tags HTML sejam sempre usadas para a finalidade correta. Este artigo analisa detalhadamente como utilizar o HTML garantindo a máxima acessibilidade.

CSS e JavaScript: accessibilidade e boas práticas (en-US)

CSS e JavaScript, usados corretamente, também podem proporcionar experiências acessíveis na web, mas se mal utilizadas, podem prejudicar a navegação. Este artigo descreve como utilizar o CSS e JS de forma a garantir que mesmo conteúdos complexos sejam acessíveis.

Básico de WAI-ARIA (en-US)

Continuando to tópico anterior, não é facil fazer interfaces web com HTML e conteúdo dinâmico atualizado por JavaScript. O WAI-ARIA é uma tecnologia que pode ajudar com esses problemas, adicionando mais propriedades semanticas que navegadores e tecnologias assistivas podem reconhecer e usar para permitir que os usuários saibam o que está acontecendo na tela. Aqui mostraremos o básico destas técnicas para melhorar a acessibilidade.

Multimedia acessível (en-US)

Outra categoria de conteúdo que pode criar problemas de acessibilidade é a multimédia - Audio, vídeo e imagens precisam de alternativas textuais, assim poderão ser compreendidas por tecnologias assistivas de seus usuários. Este artigo detalha como.

Accessibilidade Mobile (en-US)

O acesso por dispositivos móveis e smartphones é muito popular, e plataformas como iOS e Android já possuem ferramentas bastante consolidadas, assim é importante considerar a acessibilidade do seu conteúdo também nestas plataformas. Este artigo faz considerações sobre acessibilidade mobile.

Avaliações
----------

Solução de problemas

Na avaliação deste módulo, disponibilizaremos um site com vários problemas de acessibilidade que você deve encontrar e corrigir.

Veja também
-----------

* Comece a desenvolver aplicações web hoje — Marcy Sutton apresenta uma excelente série de video tutorials.
* Recursos Universidade Deque — inclui codigos de exemplo, leitores de tela, e outros recursos interessantes.
* Recursos webAIM — inlui guias, checklists, ferramentas e outras coisas.