dragonUnreal

Si has creado juegos con Unreal, hay algunas diferencias clave que necesitarás conocer para empezar en All Out.


Esta guía es para desarrolladores de Unreal Engine (Blueprints / C++) que están migrando a All Out y CSL (el lenguaje de scripting personalizado de All Out).

El gran cambio (modelo mental)

En Unreal, a menudo piensas en términos de:

  • Actores en un mundo (generados, replicados, poseídos)

  • Componentes adjuntos a Actores

  • Blueprint graphs / C++ impulsando la jugabilidad

  • RPC + Replicación lo programas explícitamente

En All Out, normalmente pensarás en términos de:

  • Entidades en una escena (con componentes)

  • Componentes (componentes de CSL proporcionados por el motor + los tuyos propios)

  • Habilidades para acciones del jugador (UI primero para móviles + enfriamiento + apuntado)

  • Jugabilidad con autoridad del servidor donde la sincronización de estado es automática (sin necesidad de infraestructura RPC personalizada para la mayoría de la jugabilidad)

Mapeo rápido: Unreal → All Out / CSL

Unreal
All Out / CSL
Notas

UWorld / Nivel

Escena

Las entidades existen en la escena; también puedes crearlas/destruirlas en tiempo de ejecución.

AActor

Entidad

Las entidades tienen transformaciones y componentes.

UActorComponent

Componente

Programas la jugabilidad escribiendo componentes de CSL y adjuntándolos a las entidades.

BeginPlay

ao_start

Punto de entrada del ciclo de vida del componente.

Tick(float DeltaTime)

ao_update(dt) / ao_late_update(dt)

Usa la actualización tardía para patrones de UI/entrada usados por el motor (por ejemplo, botones de habilidades).

Blueprint graphs

Código CSL

Basado en texto, compilado como parte de tu proyecto.

Pawn/Character

Player_Base subclases

La lógica de tu jugador normalmente vive en un Player componente/clase.

Asignaciones de entrada

Habilidades + atajos de teclas

Primero móvil: prioriza botones de habilidades sobre la entrada bruta.

Replicación (Replicadas vars)

Sincronización automática de estado

Evita crear tus propios patrones de replicación/RPC a menos que realmente los necesites.

RPCs (Servidor, Cliente, NetMulticast)

Normalmente no necesario

Usa las capacidades del motor (por ejemplo, notificaciones) en lugar de una proliferación de RPC personalizados.

Generación de actores

Scene.create_entity() / instantiate(Prefab_Asset)

Los prefabs son assets y pueden instanciarse.

UAsset referencias

get_asset(...)

Los assets viven dentro de /res y se referencian por ruta.

Tu primer archivo CSL (imports)

CSL usa un patrón de importación único de “raíz”: importa en main.csly no repartas imports por cada archivo.

Entidades y componentes (vs Actores y Componentes)

Crear una entidad en tiempo de ejecución

Añadir y acceder a componentes

Escribir un componente personalizado (ciclo de vida)

Iterar entidades/componentes

Acciones del jugador: usa Habilidades (en lugar de entrada bruta)

Los proyectos de Unreal suelen empezar con asignaciones de entrada (Enhanced Input) y luego construir la UI/UX encima. En All Out, Habilidades son la forma predeterminada de implementar acciones del jugador con:

  • Una compatible con móviles interfaz de botones

  • Enfriamientos

  • Apuntado opcional (arrastrar para apuntar en móvil, apuntado con ratón en PC)

Dibuja botones de habilidades desde Player.ao_late_update dentro de is_local_or_server():

Ver: Habilidades para la API completa y los patrones.

Redes: la “replicación” no es tu trabajo (la mayor parte del tiempo)

Qué es diferente de la replicación de Unreal

  • El estado de la jugabilidad se sincroniza automáticamente del servidor → los clientes.

  • Por lo general no escribes RPCs para los flujos estándar de jugabilidad.

  • Aun así debes diseñar pensando en múltiples jugadores : evita el estado global; guarda el estado por jugador en la instancia del jugador.

Lógica solo de cliente vs lógica compartida/servidor

Usa estos patrones:

  • is_local_or_server() para entrada + UI de jugabilidad (se ejecuta en el servidor + cliente local)

  • is_local() para UI/efectos puramente cosméticos (se ejecuta solo en el cliente local)

Assets, prefabs y rutas

El /res carpeta

Los assets están en /res. Al referenciar assets, omite /res de la ruta.

Prefabs

Los prefabs son assets (carpetas que terminan en .prefab) y pueden instanciarse:

Eventos de colisión y superposición (error común en Unreal)

Si estás acostumbrado a los callbacks de superposición/golpe de Unreal (OnComponentBeginOverlap, OnHit), ten en cuenta que la jugabilidad en CSL suele usar consultas en lugar de callbacks de eventos.

Patrón común: consultar componentes cercanos y comprobar la distancia:

Ver: Navmesh y colisión.

Diferencias de UI (UMG vs UI de CSL)

Los juegos de All Out son prioridad móvil, así que evita construir una UX solo para teclado. Usa las utilidades de UI del motor y los botones de habilidades.

Si necesitas UI personalizada, consulta la documentación de UI y sigue los patrones estándar (no inventes una jerarquía de widgets al estilo UMG salvo que la documentación lo indique).

Flujo de partida, inventario, interactuables

Si buscas equivalentes a sistemas de jugabilidad comunes de Unreal:

“Trampas” de Unreal a CSL

  • No construyas una capa personalizada de RPC/replicación: empieza con lógica autoritativa del servidor y deja que el motor sincronice el estado.

  • Evita singletons globales para el estado de la jugabilidad: se conectan varios jugadores; guarda el estado en el jugador o en la instancia del componente relevante.

  • Las importaciones están centralizadas: importa carpetas una sola vez desde main.csl, no por archivo.

  • Prefiere Habilidades para las acciones: resuelve de forma consistente la UX móvil + enfriamientos + apuntado.

  • Cosméticos vs jugabilidad: mantén los efectos solo cosméticos en local; mantén el estado de jugabilidad bajo autoridad del servidor.

Siguientes pasos

Última actualización