Dónde vive un script
El mismo script se comporta de forma distinta según a qué lo adjuntes. Elegir el nivel suele importar más que el código.
| Adjunto a | Corre mientras | Muere cuando |
|---|---|---|
| Un objeto | ese objeto está en pantalla | se oculta, se desactiva o se elimina |
| Una escena | esa escena está activa | se abandona la escena |
| Un space | el visitante está en ese space | pasa a otro space |
| El proyecto | siempre, en todos los spaces | se marcha |
En un objeto
La opción por defecto, y la acertada para comportamiento que pertenece a una cosa: una puerta que se abre, un enemigo que persigue, un botón que reacciona.
Su ctx.entity es ese objeto, y se detiene en el mismo momento que el objeto, lo cual es una
virtud. Nunca limpias detrás del script de un objeto que ya no existe.
En una escena
Se añade en la sección Scripts de la escena. Úsalo para lógica sobre la escena en conjunto: secuenciar una introducción, contar cuántos coleccionables quedan, decidir cuándo puede avanzar el visitante.
Arranca cuando la escena se vuelve activa y se para con ella; en un proyecto AR, por tanto, arranca al detectar.
En un space
Se añade en la sección Scripts del space. Este sobrevive a los cambios de escena, que es de lo que se trata: una puntuación que atraviesa tres escenas, un temporizador para toda la visita, un controlador que decide qué escena viene después.
Una entity con comportamiento y sin padre no pertenece a ninguna escena. Sigue corriendo mientras las escenas van y vienen, y todo evento dirigido acaba llegándole: la ruta es objeto, luego escena, luego space.
En el proyecto
Se añade en los ajustes del proyecto. Se inyecta en todos los spaces, así que está ahí vaya donde vaya el visitante.
Recurre a él cuando algo deba sobrevivir a una transición de space: las elecciones del visitante, un contador de progreso general, la analítica.
Qué sobrevive a qué
| Guardado en | Un cambio de escena | Un cambio de space | Una recarga |
|---|---|---|---|
una variable en init | si el script vive | si el script vive | no |
ctx.store | sí | no | no |
| un global | sí | sí | no |
un global @space: | sí | no — aislado a propósito | no |
Ni store, ni los globals, ni nada. Si un valor tiene que estar ahí la próxima vez, mándalo a
algún sitio tuyo mientras el visitante siga en la página.
Elegir, en una pregunta
¿De qué es esta lógica, en el sentido más pequeño posible?
- de un objeto → ponla en el objeto;
- de esta escena → ponla en la escena;
- de toda la visita → ponla en el space, o en el proyecto si hay varios spaces.
Poner todo a nivel de proyecto «por si acaso» funciona, y luego deja de funcionar: un script de proyecto no puede dar por hecho que haya ninguna escena concreta cargada, así que acaba lleno de comprobaciones de existencia que un script a nivel de objeto nunca habría necesitado.
Los patches siguen la misma regla
Un patch también puede adjuntarse en cualquiera de estos niveles, con vidas idénticas. Un patch a nivel de proyecto es la forma habitual de construir un controlador global sin escribir código.
Siguiente: La API de ctx