For the complete documentation index, see llms.txt. This page is also available as Markdown.

Entidades y componentes

Los juegos de All Out se construyen alrededor de entidades (cosas en el mundo) y componentes (comportamiento/datos adjuntos a las entidades).

Si has usado Unity antes: piensa “GameObject + Components”. Si has usado Roblox: piensa “Instance + Scripts/Components”. La idea central es la misma: compone la jugabilidad añadiendo componentes a las entidades.

Entidades

Las entidades existen de dos formas comunes:

  • Colocadas en el editor: ya están en la escena al iniciar.

  • Creadas en tiempo de ejecución: las generas desde un script.

Creación y destrucción de entidades

entity := Scene.create_entity();
entity.set_local_position({10, 20});
entity.set_local_scale({2.5, 2.5});
entity.set_local_rotation(0);

// Cuando termines:
entity.destroy();

Iterar sobre entidades

Componentes

Los componentes son las unidades de comportamiento. Un componente “vive en” una entidad y puede leer/modificar esa entidad.

Obtener y añadir componentes

Iterar sobre componentes

Componentes integrados que usarás mucho

Sprite_Renderer

Prefabs (Prefab_Asset)

Los prefabs deben crearse en el editor. En los scripts, los instancias.

Spine (Spine_Animator)

Si usas personajes animados en 2D, a menudo trabajarás con Spine_Animator. Consulta Spine.

Escribir un componente personalizado

Crea nuevos componentes en archivos dedicados (p. ej., orbiter.csl) y adjúntalos a entidades de cualquiera de estas formas:

  • Manualmente en el editor, o

  • En tiempo de ejecución con entity.add_component(...)

Los componentes pueden implementar callbacks del ciclo de vida:

  • ao_start()

  • ao_update(dt)

  • ao_late_update(dt) (después de todas las actualizaciones)

  • ao_end() (al destruirse)

Ejemplo:

Los métodos del ciclo de vida para scripts globales (ao_start, ao_update, ...) se tratan en Ciclo de vida del juego/fotograma.

Campos serializados (@ao_serialize)

Usa @ao_serialize para exponer un campo en el Inspector e incluirlo en la serialización de la escena y de JSON.

Triggers y consultas de proximidad

Los colliders trigger exponen on_trigger_start, on_trigger_stay, y on_trigger_end callbacks. Consulta Navmesh y colisión para la configuración y las firmas de los callbacks.

Usa consultas de proximidad cuando necesites todos los componentes dentro de un radio o solo el más cercano.

Ayudas útiles:

Ejemplo:

Buenas prácticas

  • El estado por jugador debe estar en Player. Evita variables globales que fallarían con varios jugadores.

  • Prefiere componentes para los comportamientos de jugabilidad. Acabarás con piezas reutilizables que puedes adjuntar a distintas entidades.

  • Dibuja la interfaz del jugador desde Player.ao_late_update. Envuélvelo en is_local_or_server().

  • Usa is_local() solo para invalidaciones visuales específicas del jugador. No cambies el estado de jugabilidad ni de la UI dentro de él.

Última actualización