Studio / ROBLOX

Por qué un personaje no completa la ruta: revisar Pathfinding en Studio

Un pequeño patio de práctica ayuda a separar los problemas del cálculo de ruta de los del movimiento. Prepara una investigación clara antes de añadir una persecución o un ayudante al juego.

Actualizado: 2026-10-08

Elige una pregunta para la escena #

Imagina un patio de prueba independiente: el personaje empieza a la izquierda, una zona marcada representa el destino a la derecha y dos pasos conectan ambos lados. Es un ejercicio inventado para tu proyecto, no la descripción de un ayudante ya operativo en los juegos del autor. La primera pregunta es sencilla: ¿puede este personaje llegar por el paso ancho y abierto?

Anota las condiciones antes de empezar: posición inicial, objeto de destino y criterio de finalización. Deja las recompensas, las persecuciones y los viajes entre mundos fuera de este primer ejercicio. Los sistemas adicionales dificultan explicar una ruta básica que todavía falla. Guarda la escena de práctica separada del nivel de producción.

Observa el espacio disponible #

Abre Visualization Options en la parte superior derecha de la vista 3D de Studio y activa Navigation mesh. La visualización ayuda a examinar el espacio considerado para navegar. Compárala con tu patio: ¿existe una conexión reconocible entre inicio y destino?, ¿por dónde pasa el límite junto al muro?

Prepara dos variantes de tu propia escena. La primera conserva un paso ancho sin decoración; la segunda añade un arco bajo. Registra cuál has comprobado realmente. La malla es una pista para el diagnóstico, pero el resultado del ejercicio debe ser una llegada observada, no solamente una captura atractiva del editor.

Relaciona el tamaño del personaje con el paso #

Los parámetros del agente influyen en la posibilidad de calcular una ruta por el espacio disponible. La documentación identifica radio, altura y acciones permitidas. Elige un personaje y un conjunto fijo de parámetros para el ejercicio. Después cambia únicamente la geometría: ensancha el paso o retira el arco y compara.

Evita declarar que la búsqueda de rutas está rota tras un único intento fallido. Una observación concreta resulta más útil: con el arco no se confirmó la ruta y sin él sí. Cambiar a la vez modelo, anchura y ajustes hace perder la relación entre modificación y resultado. Una tabla de variantes facilita entregar el problema a otro desarrollador.

Separa el cálculo del movimiento #

CreatePath crea el objeto de ruta y ComputeAsync calcula entre los extremos. El resultado se evalúa mediante la propiedad independiente Status. ComputeAsync no devuelve una confirmación de que el personaje haya llegado. Un cálculo satisfactorio permite investigar la ruta, pero no completa todo el escenario del juego.

Crea tres filas independientes en el registro: cálculo, avance por los puntos y llegada. Supón que el cálculo se confirma pero el personaje permanece en el inicio. Esa pregunta es distinta de no disponer de ruta. Separar las etapas ahorra tiempo: investigas la observación concreta en vez de modificar todos los sistemas juntos.

Sigue la secuencia de puntos #

GetWaypoints obtiene los puntos de la ruta calculada. Trátalos como un plan de movimiento. Marca inicio y final con colores distintos y registra la etapa actual. No describas el último punto calculado como visitado hasta comprobar la acción correspondiente del personaje.

Imagina que el registro muestra una ruta obtenida y avance hasta el primer punto, mientras el siguiente no se alcanza. Guarda el lugar de la parada y una captura de la escena. Esto ayuda más que afirmar que el personaje no camina. Identifica también quién controla el movimiento. El ejemplo oficial controla al personaje del jugador; no equivale automáticamente a un sistema completo de NPC en el servidor.

Introduce un obstáculo por delante #

Recupera la variante básica que funcionaba y añade una caja móvil. Primero registra el recorrido con el paso libre; después bloquea una sección pendiente. Path.Blocked proporciona el índice del punto bloqueado. La documentación distingue entre obstáculos por delante y por detrás del progreso actual en la ruta.

Diseña dos pruebas separadas. En la primera, la caja impide seguir avanzando; en la segunda, cierra una sección ya recorrida. No exijas la misma reacción para ambos casos. El ejercicio comprueba si tu decisión considera la parte restante relevante, en lugar de reaccionar indiscriminadamente a cada cambio del patio.

Patio de práctica — Esquema original de variantes del patio, no captura de un juego real.

Describe el comportamiento ante un fallo #

Elige un comportamiento comprensible cuando no se encuentra ruta: detenerse, mostrar un mensaje para el desarrollador o realizar un reintento limitado después de cambiar las condiciones. Es una decisión del proyecto, no algo que aparezca automáticamente con una llamada a la API. No conviertas un fallo en una sucesión interminable de cálculos nuevos.

Distingue en el registro una ruta confirmada, un cálculo sin confirmar y una comprobación terminada con error. Anota el siguiente paso para cada estado. Repetir el mismo ensayo sirve de poco si el arco sigue siendo demasiado bajo. Si se reemplaza el destino, comprueba que movimientos y manejadores antiguos no decidan por la nueva ruta.

Comprueba el destino en su entorno #

Con streaming activado, parte del mundo puede estar ausente en el cliente, por lo que acceder al objeto de destino merece otra comprobación. La documentación explica la visibilidad del mundo en el servidor frente a la de los objetos en el cliente. Esto no exige colocar todas las acciones en un mismo lugar: primero identifica dónde se ejecuta tu sistema.

En la ficha del ejercicio indica quién ejecuta la lógica de movimiento y de dónde salen las coordenadas de destino. Comprueba una variante con objetivo disponible y otra con sus datos todavía pendientes. No inventes un final aleatorio para evitar un error. Explica el estado de espera sin declarar una llegada a un objetivo inaccesible.

Distingue planificar un paso de abrir una puerta #

Un PathfindingModifier con PassThrough puede permitir planificar una ruta a través de un obstáculo concreto. Eso no abre la puerta ni permite físicamente cruzarla por sí solo. La documentación utiliza estas técnicas en situaciones más elaboradas; la acción necesaria del juego sigue requiriendo implementación y comprobación.

Deja la puerta fuera del ejercicio básico. Cuando la añadas, registra dos comprobaciones: la ruta elige el lado previsto y el mecanismo realmente permite pasar. Una línea dibujada detrás de un objeto cerrado no confirma el cruce. El mismo principio ayuda a revisar escaleras, barcos y otras transiciones especiales.

Variante	Registrar
Patio abierto	Cálculo, avance y llegada
Arco bajo	Diferencia respecto a la base
Caja delante	Reacción al tramo pendiente
Caja detrás	Reacción al tramo recorrido

Entrega un resultado reproducible #

Guarda una ficha breve con nombre de escena, personaje, parámetros del agente, coordenadas iniciales y finales y el único cambio del último ensayo. Adjunta observaciones independientes del cálculo, avance y llegada. Añade capturas propias del paso básico y de la variante problemática. Una imagen ajena no demuestra tu prueba.

Esta guía propone un plan de revisión, no un controlador de NPC terminado. No hemos ejecutado tu escena en Studio ni confirmado su comportamiento. Tras implementarla, repite todas las pruebas pequeñas, incluidas las cajas por delante y por detrás. Después lleva la solución revisada a un nivel mayor con más personajes, obstáculos y destinos.

Resultados de la ruta — Esquema original de tres resultados separados. No demuestra una prueba ejecutada.

Observación	Siguiente comprobación
Cálculo sin confirmar	Geometría y parámetros
Ruta disponible, sin movimiento	Control y etapas del movimiento
Parada en la ruta	Punto y cambio de escena
Destino reemplazado	Ruta y manejadores anteriores

Fuentes originales

Roblox Creator Hub — Pathfinding
Roblox Creator Hub — Path API