> 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-es/tiempo-de-ejecucion-de-la-escena/execution.md).

# Ejecución

El runtime trata [escenas](https://github.com/decentraland/docs/tree/main/contributor/contributor/content/entity-types/scenes.md) como módulos Node típicos. Una vez que el sandbox está configurado (es decir, que todos [globales](https://github.com/decentraland/docs/tree/main/contributor/globals.md) se han inyectado y [módulos](https://github.com/decentraland/docs/tree/main/contributor/modules.md) están listos para cargarse), el código de la scene se evaluará para que pueda poblar el [exports](https://github.com/decentraland/docs/tree/main/contributor/globals.md#module) objeto.

El host tomará dos métodos de `exports`: [`onStart`](#onStart) (opcional) y [`onUpdate`](#onUpdate) (obligatorio).

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

Durante el ciclo de vida de una scene, el runtime se asegurará de que las llamadas a estos métodos nunca se hagan concurrentemente. La Promise devuelta `Promise` siempre se esperará antes de que la scene reciba una nueva llamada.

```mermaid
flowchart LR
    A[onStart] -->|await| B[onUpdate]
    B -->|await| B
```

{% hint style="info" %}
La sincronización eficaz y eficiente entre scenes individuales y el motor de renderizado del juego es un asunto complicado. Puedes encontrar lecciones de la implementación de la Foundation en [ADR-148](https://adr.decentraland.org/adr/ADR-148).
{% endhint %}

**`onStart`**

El ciclo de vida de una scene comienza con el método asíncrono `onStart` método. Es el lugar para realizar inicializaciones únicas que deben completarse antes de la primera llamada a [`onUpdate`](#onUpdate) onStart(): Promise\<void>

```ts
onStart(): Promise<void>
```

Las scenes deberían usar esta llamada para solicitar cualquier estado preexistente al runtime (como los [basic entities](https://github.com/decentraland/docs/tree/main/contributor/entities.md)) y realizar su propia configuración inicial.

Exportar `onStart` se recomienda para todas las scenes (y se hace automáticamente al usar el SDK), pero no es obligatorio según el protocolo. El método puede no existir, o devolver una `Promise`.

**`onUpdate`**

Mientras una scene se está ejecutando activamente, el método asíncrono será invocado periódicamente por el runtime para informar el paso del tiempo. Este es el corazón de la scene: en cada llamada sucesiva, las entities pueden actualizarse, el input procesarse, las animations reproducirse, los mensajes enviarse, la UI mostrarse, etc. `onUpdate` método será invocado periódicamente por el runtime para informar el paso del tiempo. Este es el corazón de la scene: en cada llamada sucesiva, las entities pueden actualizarse, el input procesarse, las animations reproducirse, los mensajes enviarse, la UI mostrarse, etc.

```ts
onUpdate(deltaSeconds: number): Promise<void>
```

El `deltaSeconds` es el número fraccionario de segundos transcurridos desde la última llamada a `onUpdate` se inició por el runtime (independientemente de cuándo la `Promise` Promise devuelta

Dado que `onUpdate` las llamadas nunca se superpondrán, la secuencia de `deltaSeconds` produce una línea temporal coherente.

En circunstancias ideales, las scenes tienen la oportunidad de ejecutarse `onUpdate` antes de que se renderice cada frame. Sin embargo, dependiendo de los recursos disponibles, las scenes con una carga de trabajo pesada pueden no resolver sus `Promise` a tiempo para el siguiente frame. Cada scene es independiente en este aspecto: implementaciones ligeras de `onUpdate` pueden invocarse varias veces en el mismo periodo que una sola llamada que consume mucho tiempo en otra scene.

Ver [ADR-148](https://adr.decentraland.org/adr/ADR-148) para más detalles.

### Ejecución de múltiples scenes

World Explorer no solo debe soportar la ejecución de varias scenes aisladas, también debe hacerlo en todo momento. Hay dos razones para esto:

Primero, cuando los players exploran el World, su vista llega más allá de los límites geográficos de la scene en la que están parados. Las scenes cercanas (hasta una distancia arbitraria o configurable) deben estar ejecutándose para generar el contenido que los players deberían poder ver.

Segundo, las scenes no solo se ejecutan dentro de sus propios límites, que no se superponen. También pueden apilarse unas sobre otras, afectando el área alrededor del player pero proporcionando distinta funcionalidad.

Este es el caso de dos tipos de scenes en particular: la Avatar Scene y las portable experiences.

#### La Avatar Scene <a href="#avatarscene" id="avatarscene"></a>

Desde el momento en que el player entra en el World, una scene global encargada de renderizar los avatars de otros players comienza a ejecutarse.

Esta scene no está limitada por fronteras geográficas y puede mostrar sus entities (así como UI widgets para la comunicación) independientemente de la ubicación del player.

#### Portable Experiences

Decentraland permite que los wearables tengan su propio comportamiento, que se ejecuta en su propio contexto de scene. Estas scenes están centradas en el player y pueden enriquecer la experiencia añadiendo entities o mostrando UI widgets.

Comienzan a ejecutarse cuando el wearable se equipa y se detienen cuando se quita.


---

# 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-es/tiempo-de-ejecucion-de-la-escena/execution.md?ask=<question>&goal=<user_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.