ElevenLabs conectó NPC con voz a Unity con solo 10 minutos de configuración

Un NPC con voz en Unity suele comenzar como un prototipo entretenido y terminar convertido en la conocida maraña de gestión del micrófono, conexión de red, reproducción de audio y sincronización con el estado del juego. ElevenLabs ha reunido estas piezas en un SDK específico de Unity para ElevenAgents. El jugador se acerca a un personaje y habla en voz alta; este responde con voz, conoce los eventos de la escena e invoca código del juego cuando es necesario.

La empresa afirma que el ejemplo inicial puede ponerse en marcha en unos 10 minutos. No es una promesa de obtener un personaje listo para producción, pero sí una buena forma de comprobar rápidamente la principal hipótesis de producto: si el jugador realmente querrá hablar con un NPC en lugar de elegir respuestas escritas de antemano.

Cómo funciona la conversación

El desarrollador crea un agente de voz en el panel de ElevenLabs y proporciona su identificador al iniciar una sesión. El SDK abre la conexión, prepara los dispositivos de audio y selecciona el transporte adecuado. En el Editor y las compilaciones de escritorio se utiliza WebSocket, mientras que WebGL admite WebSocket o WebRTC.

Un escenario sencillo funciona así: se coloca un activador alrededor del personaje. Cuando el jugador entra en su zona, el juego llama a StartSessionAsync; cuando sale, llama a EndSession. De forma predeterminada, la voz se reproduce como audio bidimensional convencional, pero el desarrollador puede proporcionar su propio AudioSource para que la intervención suene desde la posición del personaje.

El SDK también devuelve el volumen actual de la respuesta en un intervalo de 0 a 1. Esto ya basta para una animación básica de la boca, iluminar un indicador o mover el modelo. La función no sustituye una sincronización labial completa, pero permite crear un prototipo comprensible sin una canalización independiente de animación facial.

Un agente, varios personajes

No es necesario crear un agente independiente para cada NPC. Al iniciar una sesión, el juego puede proporcionar variables dinámicas, como el color, la profesión o el estado de ánimo del personaje. Estos valores se insertan en las instrucciones del sistema y en la primera intervención. Las diferencias más notables pueden configurarse mediante anulaciones temporales de la voz y de los ajustes del agente, siempre que se hayan autorizado previamente en la configuración de seguridad.

Imaginemos a dos posaderos en una misma escena. Ambos utilizan el mismo guion básico de conversación, pero el primero recibe las variables “tranquilo” y “amistoso”, mientras que el segundo recibe “irritado” y “desconfiado”. El ahorro no se limita al número de configuraciones: las reglas comunes de comportamiento pueden modificarse de forma centralizada sin eliminar las diferencias entre los personajes.

Los eventos del juego se transmiten mediante SendContextualUpdate. Si el jugador encuentra la llave del sótano, el agente se entera sin necesidad de generar una intervención artificial en nombre del jugador. La comunicación en sentido inverso funciona mediante herramientas del cliente: el agente puede solicitar que se abra una puerta, se inicie una misión o se entregue un objeto, y un controlador registrado ejecutará la acción y devolverá el resultado.

Esta es una frontera arquitectónica importante. El modelo propone una acción, pero es el juego quien la ejecuta. Por tanto, el controlador debe comprobar de forma independiente los permisos, el estado de la escena y la validez de los parámetros. No se debe permitir que un modelo de texto modifique directamente el inventario o el progreso solo porque haya generado una llamada a función convincente.

Qué debe tenerse en cuenta antes del lanzamiento

El Editor, Windows, macOS, Linux y WebGL figuran como plataformas compatibles. iOS, Android y XR siguen en beta. En dispositivos móviles es necesario solicitar por separado el permiso de acceso al micrófono. Para WebGL hay que habilitar WebAssembly.Table; además, la reproducción en el navegador presenta limitaciones: algunos ajustes de AudioSource no se trasladan a Web Audio API y WebRTC ignora el OutputAudioSource proporcionado.

La principal limitación está relacionada con la seguridad. Para una primera prueba local, ElevenLabs propone desactivar la autenticación y conectarse mediante el identificador del agente. Esto no debe hacerse en un juego publicado. El servidor del desarrollador debe obtener una URL firmada de corta duración y proporcionársela al cliente. La clave de API de ElevenLabs no debe incluirse en la compilación, ya que podría extraerse y utilizarse a costa del desarrollador.

La conclusión práctica es sencilla: el SDK resulta adecuado para crear rápidamente un prototipo vertical de un personaje conversacional. Empiece con un NPC y una acción verificable, como abrir una puerta. Después, mida la latencia de respuesta, el coste de la sesión, la frecuencia de errores y la proporción de jugadores que realmente utilizan la voz. Si la mecánica funciona, añada memoria, animación y nuevas herramientas, pero mantenga la validación final de las acciones del juego dentro de su propio código.