NPC en los videojuegos: cómo funcionan los personajes no jugadores (con demos jugables)

Un NPC en un videojuego es un personaje no jugador: una entidad que el jugador no controla directamente, pero que ocupa espacio, mantiene un estado y responde a las condiciones del mundo. El término es deliberadamente amplio, y esa amplitud causa la mayor parte de la confusión. Un tendero con un horario, un compañero de escuadrón que te sigue por un pasillo y un mercader errante que repite una sola frase son todos NPC, pero no se construyen igual ni cuestan lo mismo de ejecutar.

Esta página explica qué es realmente un NPC, cómo se construye y cómo distinguirlo de un desencadenante programado que solo parece vivo. Cuatro mundos jugables de este sitio se usan como ejemplos prácticos —Agent Sprite Forge, The Cyclops' Island, Mini World y el propio creador de juegos 3D— para que puedas acercarte a un NPC y observar su comportamiento en lugar de leer sobre él.

Respuesta rápida: qué cuenta como NPC en un videojuego

Un NPC es cualquier personaje del mundo del juego que no está bajo el control directo del jugador. Tiene una posición, un estado y al menos un comportamiento que se activa sin que el jugador pulse un botón. Si quitas al jugador de la escena y el personaje sigue haciendo algo —recorrer una ruta, abrir una puerta, reaccionar a un evento cercano—, es un NPC.

La línea divisoria entre un personaje y un mecanismo es la propiedad del estado. Un personaje posee variables que persisten entre fotogramas: salud actual, objetivo actual, índice de patrulla actual, nodo de diálogo actual. Un mecanismo es, en la práctica, sin estado: se activa una vez cuando se cumple una condición y ahí termina. Una placa de presión que abre una reja es un mecanismo. Un guardia que reacciona a la apertura de la reja, recuerda que estabas ahí y cambia su ruta es un NPC. La diferencia no es la fidelidad visual. Es si algo sobrevive al fotograma en el que ocurrió el evento.

Breve historia del NPC en los videojuegos

Las aventuras de texto de finales de los años setenta y de los ochenta ejecutaban los NPC como objetivos del analizador sintáctico. Un personaje existía solo como un sustantivo con nombre que el analizador reconocía, más un pequeño bloque de banderas. El ladrón de las primeras aventuras de texto robaba un objeto si estabas en la misma sala y aún no lo había hecho: eso es un NPC de dos variables, presencia y una bandera de ya-ha-robado. Sin búsqueda de rutas, sin animación, sin horarios. El comportamiento estaba en la bandera, no en el personaje.

Los NPC de la era de los sprites añadieron animación y colisión, pero mantuvieron el comportamiento mínimo. Un aldeano recorría un bucle fijo de dos puntos, reproducía una animación de reposo cuando el jugador estaba dentro de un radio y abría un cuadro de diálogo al contacto. El cambio técnico importante fue que el NPC ahora tenía una posición en el mundo físico, así que debía ser barato. Con docenas en pantalla a la vez en hardware de 8 y 16 bits, cada NPC recibía unos pocos bytes de estado y ejecutaba una comprobación por fotograma no más compleja que una comparación de distancias.

Los NPC impulsados por horarios llegaron cuando los presupuestos de memoria y CPU permitieron que un personaje existiera con independencia de la ubicación del jugador. Un tendero con un valor de horario de apertura, un punto de ruta de casa y una ruta de caminata puede estar en otro sitio cuando llegas, y esa ausencia es legible para el jugador. La implementación es un reloj más una tabla de consulta: a la hora de juego 21, apunta al punto de ruta de casa; a las 08, apunta a la tienda. El jugador nunca ve la tabla, solo la consecuencia.

Los NPC generados son la era actual. En lugar de escribir una frase por estado, escribes una descripción del personaje y dejas que un modelo produzca diálogo, réplicas o comportamiento en tiempo de ejecución. La disyuntiva ya no es el almacenamiento, sino el determinismo: una frase generada no se puede previsualizar del todo, así que necesitas límites en el tono, la longitud y lo que el NPC puede mencionar. En el creador de juegos 3D, las indicaciones de los NPC se limitan a una descripción y a un pequeño conjunto de comportamientos precisamente por este motivo.

Cómo se construyen los NPC modernos

Todo NPC es una pila de cinco partes que cooperan: estado, navegación, animación, diálogo y percepción. El estado son los datos que posee el NPC: salud, objetivo, índice de patrulla, nodo de diálogo, nivel de alerta. La navegación es cómo se mueve entre puntos. La animación es cómo se muestran el movimiento y los momentos de reposo. El diálogo es el texto y la voz que se producen en respuesta a las condiciones. La percepción es la entrada que le dice al NPC que algo cambió, normalmente una comprobación de distancia, un raycast de línea de visión o el solapamiento de un volumen de activación.

En un proyecto típico, estas partes viven en lugares separados. El estado es un script o un componente en la entidad del NPC: en términos de Unity, un MonoBehaviour; en Godot, un script de Node; en una compilación de Three.js para navegador, un objeto simple adjunto a la malla. La navegación son datos de puntos de ruta o un navmesh. La animación es una máquina de estados con clips con nombre como reposo, caminar o atacar. El diálogo es un archivo de datos, a menudo un pequeño grafo de nodos o una tabla indexada por estado. La percepción suele ser una forma de colisión y una comprobación por fotograma.

El modo de fallo más común es que el estado y la animación se separen. El NPC está en un estado de persecución, pero sigue reproduciendo el clip de reposo, así que se desliza hacia ti sin mover las piernas. La solución no es más animación; es un único lugar en el código que escribe el estado actual y un único lugar que lo lee para seleccionar el clip. Cuando esos dos viven en scripts distintos, aparece el deslizamiento. Cuando son la misma función, no.

El segundo fallo más común es una navegación que no coincide con el nivel. Una ruta de patrulla creada para una distribución antigua enviará al NPC contra una pared o por un borde después de que cambie la geometría. En las compilaciones para navegador, el enfoque robusto más barato es mantener los puntos de patrulla como objetos vacíos con nombre y volver a resolverlos al cargar, de modo que mover una pared no deje huérfana la ruta.

La percepción es donde los NPC se vuelven caros. Un raycast por NPC y por fotograma está bien para unos pocos personajes y es un desperdicio para cientos. Las optimizaciones habituales son una cuadrícula espacial compartida, un intervalo de comprobación y un descarte temprano por distancia antes de que se ejecute cualquier raycast. Si un NPC está a 40 metros y su radio de percepción es 8, el raycast nunca debería ejecutarse.

Estado: en la propia entidad del NPC. Mantenlo pequeño: un puñado de números y una cadena para el nodo de diálogo actual. Si necesitas más que eso, divide el NPC en dos personajes.

Navegación: como una lista de puntos en el espacio del mundo guardada junto a la escena, no incorporada al modelo. Animación: como clips con nombre en el esqueleto, seleccionados por un único conmutador de estado. Diálogo: en un archivo de datos aparte, para que los guionistas puedan editarlo sin tocar el código. Percepción: como un volumen de activación más una comprobación de distancia, con el raycast como último paso, no como primero.

Cuatro mundos jugables, cuatro tipos de NPC

La forma más clara de entender el comportamiento de un NPC es pararte junto a uno y cambiar lo que puede ver. Estos cuatro mundos de Neta Studio demuestran cada uno un patrón de comportamiento distinto. Ábrelos, entra en el rango de percepción del NPC y luego sal y observa qué cambia.

Agent Sprite Forge ejecuta NPC definidos por una breve descripción del personaje más un pequeño conjunto de estados. Acércate a uno y su respuesta se genera a partir de esa descripción, limitada a los estados que expone el mundo. La prueba interesante es la repetición: acércate dos veces al mismo NPC y compara cuánto varía la segunda respuesta. Esa variación es del modelo, no del mundo: la máquina de estados es fija.

The Cyclops' Island usa un NPC grande con un patrón de persecución y búsqueda. Cuando el jugador está dentro del radio de percepción, el cíclope persigue; cuando el jugador rompe la línea de visión, busca la última posición conocida y luego vuelve a una ruta de patrulla. El paso de búsqueda es lo que hace que se lea como un personaje y no como un misil teledirigido: actúa con información desactualizada.

Mini World coloca varios NPC pequeños en bucles cortos con avisos de interacción. Su comportamiento es deliberadamente mínimo: caminar, hacer una pausa, responder cuando el jugador está a menos de un metro. El valor aquí es la cantidad. Puedes observar cinco o seis a la vez y ver lo barato que resulta en realidad un bucle de NPC convincente.

El creador de juegos 3D es donde colocas y configuras los NPC directamente. Cada NPC recibe una descripción, una ruta de patrulla y un conjunto de estados. Construye algo pequeño —una sala, un NPC, una ruta— y prueba los límites: reduce el radio de percepción hasta que el NPC nunca te note y luego auméntalo hasta que no deje de notarte. La amplitud de la banda útil entre esos dos extremos es el problema de ajuste, y existe en todos los motores.

Una nota sobre el rendimiento. En una compilación para navegador, el coste de los NPC lo dominan las comprobaciones de percepción y la animación, no la geometría. Diez NPC con raycasts por fotograma costarán más que diez NPC con comprobaciones por intervalos compartidas, aunque los modelos de alto detalle estén en los que usan comprobaciones por intervalos. Si una escena se entrecorta cuando los NPC están activos, revisa primero el bucle de percepción.

Por qué el comportamiento, y no los gráficos, vende un NPC

Un personaje de bajo detalle que recorre una ruta, se detiene ante una puerta y está en otro sitio cuando vuelves se lee como vivo. Un personaje de alto detalle que se queda en un punto y repite una frase se lee como un mueble. El jugador no está evaluando polígonos. El jugador está construyendo un modelo de lo que quiere el personaje, y ese modelo proviene de los tiempos y la posición, no de la malla.

El mecanismo son las expectativas. Si un personaje está en el mercado por la mañana y en casa por la noche, el jugador formula una hipótesis —este personaje tiene una rutina— y la hipótesis se confirma en la segunda visita. Esa confirmación es todo el efecto. Cuesta un reloj y una tabla de consulta. No puede sustituirse añadiendo detalle a una estatua, porque la estatua nunca contradice ni confirma nada.

Por eso los NPC impulsados por horarios de juegos mucho más antiguos siguen siendo objeto de conversación, mientras que los NPC estáticos visualmente superiores se olvidan. El comportamiento es el contenido. El modelo es el envoltorio. Si estás construyendo en un editor de navegador y tienes poco tiempo, dedícalo a las transiciones de estado y a las rutas de patrulla antes que a las texturas.

Cómo distinguir un NPC de un desencadenante programado

Tanto los NPC como los desencadenantes responden al jugador, y por eso se confunden en las revisiones de diseño. La distinción es si algo persiste después del evento. Usa las señales de abajo como lista de comprobación cuando decidas cuál de los dos estás mirando.

La tabla no es una prueba de pureza. Muchos juegos usan un desencadenante para iniciar el comportamiento de un NPC: un volumen de activación que pasa a un guardia de patrulla a alerta. Eso es normal y correcto. El problema es cuando un desencadenante se presenta al jugador como un personaje: se activa una vez, el personaje nunca vuelve a reconocer nada y la ilusión se derrumba en el segundo encuentro.

Entra en el mundo al que pertenece

Un sprite es un personaje sin ningún sitio donde estar. El último paso es el que nadie más ofrece: toma la hoja que acabas de crear y ponla en un mundo por el que alguien pueda caminar: una isla pequeña, un planeta, una esquina lluviosa. Todos los mundos de este sitio se crearon a partir de una descripción escrita y se publicaron como una página que puedes jugar.