cubesEntidades y componentes

Todos los juegos de Out se construyen en torno a entidades (cosas en el mundo) y componentes (comportamiento/datos adjuntos a las entidades).

Si ya has usado Unity antes: piensa en “GameObject + Components”. Si has usado Roblox: piensa en “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.

Crear y destruir 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 hayas terminado:
entity->destroy();
circle-exclamation

Iterar 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 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 estás usando personajes animados en 2D, a menudo trabajarás con Spine_Animator. Ver Spine.

Escribir un componente personalizado

Crea nuevos componentes en archivos dedicados (por ejemplo, orbiter.csl) y asígnalos a las entidades ya sea:

  • 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:

circle-info

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

Campos serializados (@ao_serialize)

Usa @ao_serialize para exponer un campo en el editor (y a menudo para habilitar guardado/persistencia cuando corresponda).

Encontrar componentes cercanos (consultas de proximidad)

CSL no tiene callbacks de colisión. Un patrón común es “consultar componentes cercanos y comprobar la distancia”.

Ayudas útiles:

Ejemplo:

Mejores prácticas

  • El estado por jugador pertenece a Player. Evita variables globales que se romperían con varios jugadores.

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

  • Mantén el trabajo cosmético local. La UI y las partículas normalmente deberían ejecutarse detrás de is_local() comprobaciones.

Última actualización