> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/contributor/contributor-pt/runtime-da-scene/execution.md). # Execução O runtime trata [cenas](https://github.com/decentraland/docs/tree/main/contributor/contributor/content/entity-types/scenes.md) como módulos Node típicos. Uma vez que o sandbox esteja configurado (ou seja, todos os [globals](https://github.com/decentraland/docs/tree/main/contributor/globals.md) são injetados e [modules](https://github.com/decentraland/docs/tree/main/contributor/modules.md) estão prontos para ser carregados), o código da scene será avaliado para que possa preencher o [exports](https://github.com/decentraland/docs/tree/main/contributor/globals.md#module) objeto. Dois métodos serão captados pelo host a partir de `exports`: [`onStart`](#onStart) (opcional) e [`onUpdate`](#onUpdate) (obrigatório). ```ts type Exports = { onStart?: () => Promise; onUpdate: (deltaSeconds: number) => Promise; }; ``` 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. ```mermaid flowchart LR A[onStart] -->|await| B[onUpdate] B -->|await| B ``` {% hint style="info" %} 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](https://adr.decentraland.org/adr/ADR-148). {% endhint %} **`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`](#onUpdate) ser feita. ```ts onStart(): Promise ``` As Scenes devem usar esta chamada para solicitar qualquer estado pré-existente do runtime (como as [basic entities](https://github.com/decentraland/docs/tree/main/contributor/entities.md)) 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. ```ts onUpdate(deltaSeconds: number): Promise ``` 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](https://adr.decentraland.org/adr/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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.decentraland.org/contributor/contributor-pt/runtime-da-scene/execution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.