Execução

O runtime trata cenas como módulos Node típicos. Uma vez que o sandbox esteja configurado (ou seja, todos os globals são injetados e modules estão prontos para ser carregados), o código da scene será avaliado para que possa preencher o exports objeto.

Dois métodos serão captados pelo host a partir de exports: onStart (opcional) e onUpdate (obrigatório).

type Exports = {
  onStart?: () => Promise<void>;
  onUpdate: (deltaSeconds: number) => Promise<void>;
};

Durante o ciclo de vida de uma scene, o runtime garantirá que as chamadas a esses métodos nunca sejam feitas em simultâneo. O valor retornado Promise será sempre aguardado antes de a scene receber uma nova chamada.

A sincronização eficaz e de alto desempenho entre scenes individuais e o engine de rendering do jogo é um assunto complicado. Pode encontrar lições da implementação da Foundation em ADR-148.

onStart

O ciclo de vida de uma scene começa com o assíncrono onStart método. É o lugar para fazer inicializações únicas que devem ser concluídas antes da primeira chamada a onUpdate ser feita.

onStart(): Promise<void>

As Scenes devem usar esta chamada para solicitar qualquer estado pré-existente do runtime (como as basic entities) e realizar a sua própria configuração inicial.

Exportar onStart é recomendado para todas as scenes (e feito automaticamente ao usar o SDK), mas não é exigido pelo protocolo. O método pode estar ausente ou devolver um Promise.

onUpdate

Enquanto uma scene está a correr ativamente, o assíncrono onUpdate método será invocado periodicamente pelo runtime para reportar a passagem do tempo. Este é o coração da scene: em cada chamada sucessiva, as entities podem ser atualizadas, a input processado, animations reproduzidas, messages enviadas, UI exibida, etc.

onUpdate(deltaSeconds: number): Promise<void>

O deltaSeconds parâmetro é a fração do número de segundos decorridos desde a última chamada a onUpdate foi iniciada pelo runtime (independentemente de quando a Promise foi resolvida). Isto é específico de cada scene em execução.

Como onUpdate as chamadas nunca se sobrepõem, a sequência de deltaSeconds produz uma linha temporal coerente.

Em circunstâncias ideais, as scenes têm oportunidade de correr onUpdate antes de cada frame ser renderizado. No entanto, dependendo dos recursos disponíveis, scenes com uma carga de trabalho pesada podem não resolver as suas Promise a tempo para o frame seguinte. Cada scene é independente neste aspeto: implementações leves de onUpdate podem ser invocadas várias vezes no mesmo período, tal como uma única chamada demorada noutra scene.

Veja ADR-148 para mais detalhes.

A Executar Múltiplas Scenes

O World Explorer não deve apenas suportar a execução de várias scenes em sandbox, deve fazê-lo em permanência. Há dois motivos para isso:

Primeiro, quando os jogadores exploram o world, a sua visão vai para além dos limites geográficos da scene em que estão. As nearby scenes (até uma distância arbitrária ou configurável) devem estar em execução para gerar o conteúdo que os players devem conseguir ver.

Segundo, as scenes não correm apenas dentro dos seus próprios limites não sobrepostos. Também podem ser sobrepostas umas sobre as outras, afetando a área em torno do player mas fornecendo funcionalidades diferentes.

Isto aplica-se em particular a dois tipos de scenes: a avatar scene e as portable experiences.

A Avatar Scene

A partir do momento em que o player entra no world, uma global scene encarregada de renderizar os avatars de outros players começa a ser executada.

Esta scene não é limitada por fronteiras geográficas e pode exibir as suas entities (assim como widgets de UI para comunicação) independentemente da localização do player.

Portable Experiences

Decentraland permite que os wearables tenham o seu próprio comportamento, que é executado no seu próprio contexto de scene. Estas scenes são centradas no player e podem enriquecer a experiência adicionando entities ou mostrando widgets de UI.

Começam a ser executadas quando o wearable é equipado e param quando é removido.