Introduccion

Recientemente, las historias sobre juegos clásicos recibieron una buena recepción en el GDC, pero hubo muy pocas historias sobre las herramientas para su desarrollo. En esta serie de artículos, intentaremos llenar este vacío entrevistando a personas que han jugado un papel importante en la historia de las herramientas de desarrollo de juegos.

En las dos primeras partes de la serie, hablamos con John Romero (sobre el Editor de TEd) y Tim Sweeney (sobre el Editor de Unreal) .

Al escribir el tercer artículo, tuve el honor de hablar con Chris Norden sobre las herramientas que desarrolló para el híbrido FPS / RPG llamado Deus Ex . Charlé con Chris en San Francisco en el GDC 2018.

Antes de la tormenta de iones: origen y espejo

David Lightbone: ¿Cómo comenzaste con Deus Ex en Ion Storm?

Chris Norden: En 1994, trabajé como programador de Origin en Austin. Mi primer proyecto pagado fue Jane's Combat Simulations AD-64D Longbow de Jane's Combat Simulations. Originalmente era un juego arcade llamado Chopper Assault. Junto con Andy Hollis, trabajé en ello durante dos años.



Después del lanzamiento del juego, lo último que me gustaría hacer es hacer otro simulador militar, porque absolutamente no me gusta todo lo militar. De vez en cuando, hablaba con Warren Spector, quien también trabajaba en Origin. Realmente le gustó la trama de los juegos de rol. Pensé para mí mismo: "¡También me gustan estos juegos, quiero trabajar en algo así!"

En 1996, Warren renunció a Origin y se convirtió en el director de Looking Glass Studios en Austin, cuya existencia nadie conocía en ese momento. Este estudio creó puertos para juegos de Mac, como el Links 386 Pro . También estaba en el proceso de desarrollar su propio juego de golf llamado British Open Championship Golf.

Origin todavía estaba desarrollando Ultima Online. Fue apodada Multima, y ​​parece haber usado el motor Ultima VII. Experimenté con él un poco hasta que dejé Origin y me uní a Warren en Looking Glass.

[Nota del autor: el estudio principal de Looking Glass estaba en Cambridge, Massachusetts, cerca de Boston]

Warren escribió un documento de diseño, y durante algún tiempo trabajamos en un juego de rol con la abreviatura AIR (de Austin Internet Role-Playing), que se suponía que era un proyecto en línea. Queríamos hacer algo en 3D, porque mientras los aceleradores 3D empezaban a aparecer. Obtuvimos un prototipo de Voodoo 1 y escribimos un pequeño motor en GLide.

Nos asociamos con la oficina de Looking Glass en Cambridge. Después de lanzar el British Open, ayudé a Mark LeBlanc y Doug Church con un motor Thief llamado Dark Engine .

Por razones financieras y de otro tipo, Looking Glass no se sentía muy bien en ese momento. La compañía tenía juegos increíbles, pero se vendieron mal. Por lo tanto, después de aproximadamente un año, se decidió cerrar la oficina en Austin.

[Nota del autor: Chris tiene toda la razón sobre los juegos: Ultima Underworld, System Shock y Terra Nova fueron muy bien recibidos por los críticos, fueron algunos de los mejores juegos de la década de 1990]

Cuando cerró la oficina, éramos pocos: Warren, yo, Al Yarusso, Harvey Smith, Steve Powers. Todos todavía queríamos trabajar en este juego de rol. Después de cerrar la oficina, nos abrazamos durante unos seis meses, con la esperanza de poder establecer una nueva empresa y hacer algo. Teníamos un documento de diseño muy bueno, comenzamos a "venderlo" a los editores y a comunicarnos con diferentes personas. Ni siquiera recuerdo a todos los editores con los que contactamos. Una de estas personas fue John Romero y Tom Hall, quienes, junto con Eidos, trabajaron para crear un nuevo estudio en Dallas llamado Ion Storm.


Conocí a John desde los primeros años de Id. En 1991, en Dallas, MTV organizó una gran fiesta en barco dedicada a Wolfenstein 3D. Había dos máquinas VR Virtuality Arcade Machine . En ese momento yo era un niño y pensé: "¡Dios, esta es la cosa más genial del mundo!" Conocí a John en los días en que vivía al estilo de "Soy demasiado rico para preocuparme por nada".

John es una persona maravillosa, trabajé con él en Monkeystone Games, ayudé a desarrollar el juego para Gameboy Advance, pero esa es otra historia.

[Nota del autor: el juego se llamaba Hyperspace Delivery Boy. Para Gameboy Advance, se suponía que Majesco lo publicaría, pero en el último momento la compañía se negó a lanzarlo.]

Hablamos con Romero y Tom Hall, y ellos son: "Warren, eres genial, ¡hagamos este juego!". Y Warren respondió: “Hay un inconveniente. No nos mudaremos a Dallas. No nos mudaremos a California. No nos moveremos a ningún lado. Mantendremos el estudio en Austin. Entonces seguiremos siendo completamente autónomos. Me darás control total sobre todo. Me darás dinero y todo estará bien ”. Ellos respondieron: “Está bien, nos queda bien. Resuelto ".

[Nota del autor: obviamente, esta es una versión demasiado simplificada de las negociaciones, pero da una idea de lo que sucedió]

Warren tenía un excelente documento de diseño para el juego Solucionador de problemas en ese momento, que gradualmente se convirtió en un documento de diseño de Deus Ex.

Entonces, los seis fundamos Ion Storm Austin. En ese momento yo era el director técnico, el jefe del departamento de TI, "Homo Arom", el servicio de seguridad y el ingeniero líder. No teníamos suficientes personas para hacer todas estas cosas. Por lo tanto, era necesario realizar entrevistas rápidamente y reclutar personal.

El equipo era pequeño. Teníamos tres ingenieros: yo, Scott Martin y Al Yarusso. Sheldon Pacotti fue contratado como guionista. Teníamos dos equipos de diseño de tres personas cada uno. Uno fue dirigido por Robert White, el segundo por Harvey. Parecía haber seis artistas más liderados por Jay Lee.

Ah, y también contraté a Alex Brandon porque era un gran fanático de su música para Unreal. Ahora somos grandes amigos. Le presenté a su futura esposa, porque éramos amigos en la escuela secundaria. Es un gran tipo: un excelente músico y muy versado en detalles técnicos.

Luego contratamos a un administrador, y eso es todo. ¡Y luego nos enfrentamos con un trabajo infernal durante dos años y medio! [risas]

Elegir entre motores Unreal y Quake

JL: Entonces, mientras que el resto de Ion Storm trabajó con el motor Quake, elegiste Unreal. ¿Puedes explicar cómo llegaste a esta decisión?

KN: No importa cuánto respeto el motor Quake, sabía que en ese momento no tendríamos ningún soporte. Creamos un juego muy específico en el que queríamos poder hacer cualquier cosa. Quake fue un tirador, y nada más. Si hubiéramos intentado hacer algo diferente a FPS en él, habría requerido mucho trabajo y no habríamos recibido el apoyo de Id. Simplemente grabaron un CD con el código, se lo dieron a los desarrolladores y los dejaron solos.

JL: En mi entrevista con Tim Sweeney, llamó al modelo de licencia de motor Quake de la época "una operación de xcopy de un cuarto de millón de dólares".

KN: ¡Sí, absolutamente correcto! Estoy de acuerdo, el motor fue increíble. En ese momento, hizo una revolución, pero sabíamos que un equipo de tres ingenieros no podría reescribir el motor y no podría escribir el suyo. Simplemente no tendríamos suficiente tiempo.

En un momento fui un gran admirador de la escena de demostración de Amiga, C64 y PC. Comencé a ver un videojuego llamado Unreal y pensé: “Oh, Dios mío, sí, hay iluminación RGB y 3D completo. El motor utiliza MMX, SSE y 3DNow. ¡Se ve muy bien! Pero no pudimos encontrar información detallada sobre él, por lo que planeamos un viaje a Digital Extremes en Londres (Canadá). Nos reunimos con Tim y su equipo, nos mostraron todas las características del motor. También me reuní con Carlo Vogelsang , con quien ahora trabajo con Sony, él está en el departamento de Playstation. Escribió el Galaxy Audio Engine: casi todo en ensamblador, un tipo súper hardcore. El motor tenía un sistema de partículas llamado Fuego. Todo esto estaba dentro del motor. Pensé: "Chicos, me gusta su enfoque".


En ese momento, se centraron en crear herramientas súper convenientes que nadie había hecho antes. Las herramientas de Quake eran buenas, pero para los usuarios no técnicos parecían poco amigables. Teníamos diseñadores que no tenían habilidades de ingeniería, y tuvieron que descubrir cómo usar estos programas.

Entonces decidimos: “Estos muchachos tienen buenas herramientas, todos nos ayudan mucho, hay muchos muchachos de la vieja escuela que escribieron cosas duras en los años 80. ¿Cómo se organizan las licencias? Ellos respondieron: "Nunca hemos hecho esto antes, para nosotros es algo nuevo". Creo que en ese momento no entendían cómo crear un modelo de licencia. Dijimos: "Tenemos a Warren Spector, y él quiere crear un juego en su motor". Cuando escucharon esto, quedó claro que realmente querían trabajar con nosotros.

Honestamente, no recuerdo los detalles de nuestro acuerdo de licencia. Tim probablemente lo recuerda. No recuerdo cuánto pagamos, pero no pienso tanto ".

JL: ¿Probablemente comparable a cuántos Id solicitaban Quake en ese momento?

KN: Creo que menos! Y esa fue otra ventaja. Su motor era relativamente nuevo, pero no fuimos los primeros licenciatarios. Uno de los primeros fue Wheel of Time y Klingon Honor Guard.

[Nota del autor: puede leer más sobre el historial de licencias de Unreal Engine en mi entrevista con Tim Sweeney sobre Unreal Editor ]

Por lo tanto, decidimos elegirlo. Los desarrolladores nos dieron el código fuente y dijeron: "Te apoyaremos tan pronto como podamos". Siempre hablábamos cara a cara. Si teníamos una pregunta, enviamos un correo electrónico: no había un sistema de soporte técnico.

Tuvimos muchos problemas porque nunca antes habían hecho esto. Les enviamos mucho código y preguntas, tuvimos una larga correspondencia y recibimos actualizaciones. Pero creo que fue la decisión correcta. Creo que si elegimos Quake, entonces el juego sería mucho más difícil de crear.

Además, me convertí en miembro del Unreal Tech Advisory Group. Se nos ocurrió la idea de la primera reunión técnica, en la que los jefes de todas las compañías que se convirtieron en licenciatarios (había cuatro en ese momento) se reunieron, discutieron formas de mejorar el motor, regañaron a Tim por aspectos inconvenientes, resolvieron el problema con el alcohol y la comida, bueno, todo es como por lo general Todavía me mantengo en contacto con todas estas personas.

JL: ¿Has compartido algo con otros miembros del Unreal Tech Advisory Group?

KN: Creo que compartimos principalmente mejoras en Unreal Editor. El motor era excelente, pero todavía tenía un largo camino por recorrer. Luego, cuando pudimos contratar aún más diseñadores y artistas, también comenzaron a hacer sugerencias para mejorar los procesos de trabajo. Los implementamos nosotros mismos, o los enviamos al equipo de Unreal, o le preguntamos al equipo de Unreal si podían hacerlo más rápido que nosotros.

Hicimos muchos cambios en el editor principal, pero la mayoría de ellos solo estaban relacionados con nuestro juego. Compartimos algunas de las mejoras, pero la mayoría de los otros desarrolladores estuvieron involucrados en juegos completamente diferentes.

Tuve que escribir un montón de sistemas que creo que fueron los primeros de su tipo. Al menos nunca los he visto. Por ejemplo, un sistema de mezcla de animación; Esencialmente, esto es lo que los objetivos de transformación o formas de mezcla se llaman hoy. No recuerdo a nadie haciendo esto en los juegos en ese momento. Es posible que ya se haya implementado en alguna parte, pero antes del uso generalizado de Internet, compartir información era muy difícil.

JL: ¿Puedes hablar sobre los cambios que hiciste en Unreal Editor?

KN: Uno de los sistemas, que por alguna razón no estaba en el editor en ese momento, es la visualización de splines de cámara.

En las primeras versiones de UnrealEd, tenía que arrastrar la cámara y establecer los puntos de su ruta. En este caso, fue posible ver los puntos, pero no las conexiones entre ellos, lo que determinó el camino de la cámara.


JL: ¡Es como un juego de punto a punto, pero sin números!

KN: ¡Exactamente! La spline tenía puntos de corte y los diseñadores no siempre podían descubrir cómo sería el camino. Querían saber con mucha precisión cómo se movería la cámara en el camino. Así que agregué este sistema y les gustó.

Fue muy simple. Me refiero a la simplicidad del código: dibuje los ejes de coordenadas en cada punto de control principal, y luego dibuje el punto de control para ver realmente a dónde se fue. Realmente ayudó al diseñador, y hacer un sistema así fue muy simple. No sé por qué tuvimos que agregarlo. Supongo que Tim no pensó que ella realmente sería necesaria.

DL: Esto es divertido porque si recuerdas la primera demostración de Unreal para el público, lo primero que la gente vio fue una cámara volando alrededor del castillo, es decir, Epic no parecía haber creado ningún camino para la cámara.


KN: Creo que la razón fue que muchos de sus diseñadores de nivel eran súper técnicos y estaban acostumbrados a simular esas cosas en sus cabezas. Pero la industria de los videojuegos maduró gradualmente, por lo que fue necesario crear herramientas para personas con diferentes niveles de experiencia. No todos los diseñadores eran ingenieros, ¡y hoy aún más! Esta fue la excepción más que la regla. Por lo tanto, la herramienta debería haberse vuelto conveniente y simple.

Por cierto, todavía no sé por qué la cabeza de un dinosaurio denota a Pawn.

JL: [risas] ¡Sí, Tim y yo discutimos esto en una entrevista! Por cierto, ¿te arrepientes de las decisiones tecnológicas que tomaste?

KN: Utilizamos demasiado UnrealScript. Este fue uno de los errores. UnrealScript era muy flexible, pero demasiado lento. Necesitábamos escribir mucho más en C nativo que en UnrealScript.

Norte verdadero y fallas falsas

[Nota del autor: en esta etapa de la entrevista, abrí el Deus Ex Editor (versión para UnrealEd), así como la documentación del Deus Ex SDK]

JL: El instalador de Deus Ex SDK tiene una carpeta Docs con un par de archivos de documentación que usted, Robert White, Sheldon Pacotti, Al Yarusso y Scott Martin parecen estar patrocinando. ¿Puedes decir quiénes eran estas personas y en qué trabajaban?

KN: Al estuvo involucrado en el editor de diálogo. Scott trabajó en IA. Lo hice ... todo . [risas] Entre otras cosas, fui asistente de dirección y programador principal. Pero hicimos un poco de todo, porque en todo el proyecto de principio a fin solo había tres ingenieros.


Chris Norden (abajo a la izquierda), El Yarusso (a la derecha y arriba de Chris, con un reloj en la mano), Robert White (fila central, ligeramente a la derecha del centro, con gafas de sol), Sheldon Pacotti (abajo a la derecha) y Scott Martin (en el segundo fila, a la derecha, también con gafas de sol)

DL: Hay una sección en la documentación para el editor que dice "Unreal no tiene soporte nativo para escaleras verticales, pero se agregan a Deus Ex". ¿Puedes contarnos más sobre esto?

KN: Las escaleras son una historia interesante, porque tuvimos que movernos por el nivel, y en los juegos de disparos en primera persona de esa época, las escaleras inclinadas y los ascensos suaves se usaban tradicionalmente para esto.

Uno de los decretos de Warren (¡porque el diseño es la ley!) Dijo que un jugador debería poder completar cualquier misión de cualquier manera. La idea clave del juego era que si lo desea, puede pasar por todo, sin disparar nunca. De hecho, no tuvimos éxito: hay varias zonas donde debes disparar un par de veces, pero estábamos muy cerca.

DL: Creo que los desarrolladores tuvieron éxito en las secuelas.

KN: Sí, probablemente.

Entonces, el jugador debería haber podido pasar por todo el juego sin disparar un tiro. Además, podría pasar por todo el juego sin hacer nada más que disparar. El jugador podría pasar por todo el juego para que nunca fuera detectado por el enemigo. Fue posible atravesarlo de maneras completamente diferentes.

JL: ¿Fue la falta de escaleras verticales uno de los temas que discutió con Tim en las reuniones del Grupo Asesor de Tecnología Unreal?

KN: Para responder, necesito encontrar y buscar en el código del script si dice "¡Jódete, Tim!" [risas], porque eso es exactamente lo que hicimos cuando estábamos enojados: escribimos comentarios para recordar esto más tarde.

Cuando comenzamos a pensar en cómo agregar soporte para escaleras verticales, primero razonamos "creemos la geometría, y luego tal vez podamos hacer trucos físicos difíciles para que el jugador pueda agarrar las barras con animación sincronizada". Pero después de que decidimos, bueno, esto es todo un infierno, demasiado complicado.

JL: [risas]

KN: Teníamos que hacer esto muy rápido, porque los diseñadores exigieron crear esta mecánica.

Por lo tanto, como resultado, tuve que ir a hacks infernales. El motor tenía el concepto de "grupos de texturas". Esencialmente, es una etiqueta de cadena asignada a ciertos tipos de texturas para facilitar su clasificación. Podríamos solicitarlos en código. Entonces pensamos: "¿por qué los artistas simplemente no hacen algunas texturas para que puedan ser escaladas?" Después de eso, simplemente los agregamos al grupo de texturas, realizamos una emisión de rayos para reconocerlos, y luego simplemente con algunas restricciones, el jugador se les pegó en la dirección de su movimiento. Esto funcionó bien, pero no siempre es perfecto, porque cuando el jugador subió a la parte superior de la textura, el rayo ya no se emitió y tuvimos que empujar al jugador hacia arriba y hacia la plataforma. Es decir, la solución es imperfecta, pero como resultado funcionó. Fue un truco barato y fácil.

Los lectores de hoy podrían pensar: ¿por qué no había escaleras en el motor, es eso lógico? Pero en esos días no había nada. Estos eran solo fragmentos de BSP, no teníamos mallas estáticas, no había nada de eso.


JL: UnrealEd tenía un generador de escalera de caracol muy bueno [risas], pero no había escaleras verticales.

KN: Sí, claro ... Parece que regañamos a los diseñadores por usarlo, porque creó agujeros en BSP. La escalera se veía hermosa si no había nada cerca. Pero tan pronto como comience a hacer cortes angulares en el BSP, puede obtener pequeños agujeros en el BSP a través de los cuales puede caer, pero los agujeros en sí no son visibles. Esta función causó mucho dolor y prohibimos su uso. Se veía bien, pero estaba rota ...

DL: La documentación también describe una clase llamada DeusExLevelInfo que contiene información sobre el mapa (por ejemplo, es multiusuario), el nombre del autor del mapa, el lugar donde se completó la misión, el número de la misión, etc. Pero me gustaría preguntarte sobre TrueNorth.

KN: [risas] ¡Era un tipo BAM de Unreal: motor de medición de ángulo binario!

JL: ¿Qué son estos números locos?

KN: En aquel entonces, las operaciones de coma flotante eran muy caras. El hierro era débil, pero no suficiente memoria. 360 grados se describieron no por un número de 8 bits, lo que proporcionaría 255 unidades de precisión, es decir, aproximadamente 1,4 grados por unidad, lo que no sería suficiente. Tim utilizó un número de 16 bits para las orientaciones, lo que proporcionó una mayor precisión.

Para un programador, todos estos números son bastante simples. Estos son solo poderes de dos, no hay problemas, puedes calcularlos todos en tu cabeza. Pero los diseñadores y artistas estaban teniendo problemas. Por lo tanto, se nos ocurrieron pequeñas simplificaciones para ayudar a los desarrolladores a recordarlas.

[Mientras trabajábamos con el editor, Chris llegó a la clase de Decoraciones]



KN: Decoraciones también fue una gran clase. Todas las mallas con las que puedes interactuar son decoraciones. Es decir, ¡casi todo en el juego!

JL: En la sección Decoraciones de la documentación dice: "Le advertimos que si cambia algunos de los campos que no se enumeran a continuación, el editor puede fallar". ¿No recuerdas por qué sucedió esto?

KN: [risas] Honestamente, no me acuerdo. Creo que porque Decoración era una clase tan grande, y tenía tantas funciones épicas que interactuaban con el motor de una manera extraña, que en lugar de explicarle a un diseñador que no entiende las sutilezas técnicas por qué un determinado campo puede conducir a un comportamiento inesperado, simplemente dijeron "no lo use, de lo contrario el editor falla".

JL: [risas]

KN: Algo así como tácticas de miedo. En las reuniones de programadores, nos preguntamos: ¿cómo explicar a los usuarios que esto provocará daños en la cadena BSP, y que necesita hacer esto y aquello? Solo digamos que el editor se bloqueará.

Debería estudiar el código nuevamente, pero parece que incluso somos culpables de ocultar fallas deliberadas en algunos lugares para asustar a los usuarios que están muy estafados.

JL: Sigamos adelante. La sección ParticleGenerator dice: "Una de las funciones principales es que puede activarse y desactivarse mediante activadores y desencadenadores". Es decir, en la versión del motor Unreal con el que trabajaba, ¿era imposible encender y apagar las partículas?

KN: En ese momento, no. Si insertó un sistema de partículas, estaba presente constantemente y nunca se apagaba. Me parece que este es un descuido extraño.

De lo contrario, el sistema de partículas Unreal fue increíble. La mayoría fueron escritos en ensamblador. Fue de procedimiento y escrito muy bien en comparación con todo lo demás. Los diseñadores la amaban. De hecho, incluso demasiado. Fue posible eliminar toda la velocidad de fotogramas, y se volvieron locos, agregando más y más capas transparentes.

En ese momento, aún teníamos que soportar la representación de software, mientras que la representación de hardware aún no estaba muy extendida. Tim tenía habilidades de programación increíbles y escribió un gran procesador de software, fue genial.

[Al observar diferentes objetos en el juego, noté una categoría con un nombre inusual en el panel Propiedades]

DL: ¿Qué es esta propiedad de Olor?

KN: Los animales necesitaban un aroma para dejar rastro. De hecho, los perros pueden rastrear los nodos de olor. Si recuerdo correctamente, luego de moverme por los niveles, el jugador podría dejar nodos de olor que habían estado activos durante cierto tiempo. Por lo tanto, lo hicimos para que los perros pudieran olerlo.

DL: Es decir, si te escondes detrás de una caja, la gente no te encontrará, pero los perros pueden ...

KN: Precisamente porque esto es lo que sucede en realidad, y pensamos que sería un aspecto interesante del juego. Sin embargo, parece que al final fue cortado. Como no hubo comentarios gráficos, este concepto fue difícil de explicar al jugador.



[ Intro, — , . ]

: . . ...



KN: ¡No, los espejos eran reales! Eran muy lentos, por lo que les pedimos a los diseñadores que los usaran raramente, sin embargo, estos son espejos reales.

De hecho, cuando escribí el código láser ... [risas]

DL: [risas] Veo a lo que te refieres ...

KN: ... De hecho, tuve que buscar espejos. Tenía un nivel de prueba donde probé el código para todos los dispositivos. Cuando escribí el código del puntero láser, creé una bola de discoteca de espejo reflectante, y luego construí una habitación con espejos en ambos extremos. Tomé el puntero láser, apunté a la bola de discoteca, ¡y funcionó!

Por supuesto, la velocidad de fotogramas no cayó a ninguna parte, porque tuve que rastrear todas las líneas ...

Vea la onda de luz: herramienta de línea de comandos LWO23D

[Nota del autor: LWO significa Lightwave Object. Este es el formato de geometría 3D del paquete de software Lightwave 3D de Newtek , también con sede en Texas, como el equipo de Deus Ex en ese momento]



Captura de pantalla de Deck Ex Lab de Tack

JL: ¿Por qué su equipo decidió usar Lightwave?

KN: Nuestros artistas lo conocían bien. Por lo tanto, tuvimos que adaptarnos.

JL: Cuéntanos más sobre por qué escribiste el exportador como una herramienta de línea de comandos.

KN: En ese momento, e incluso ahora, a menudo escribo pequeñas herramientas de línea de comandos para automatizar tareas. Soy un programador de la vieja escuela y no me gustan las complicaciones innecesarias. Principalmente no me gusta C ++. No me gustan los patrones No me gusta todo lo que lleva tiempo.

Cuando escribo herramientas de línea de comandos, creo un archivo por lotes Win32, me deshago de todo lo incorporado, empiezo con un archivo vacío, con int main() , y simplemente sigo adelante. Esta es una solución rápida y portátil que no causa problemas.

DL: Creo que exportar mallas estáticas fue un proceso bastante estándar. Pero cuéntanos cómo exportaste la animación.



Captura de pantalla de Deck Ex Lab de Tack

KN: No hubo animación esquelética en el juego. No conozco un solo motor de la época en que se implementa. Por lo tanto, todo se hizo mezclando vértices. El desollado era muy costoso en ese momento. Sin GPU, todo tenía que calcularse en la CPU y de ninguna manera evitar los cálculos de coma flotante.

Dentro de Lightwave, los diseñadores crearon animación esquelética y luego mostraron sus fotogramas clave. Era necesario crear una pose en T, porque para mezclar animaciones era necesario comenzar desde una base común. Es decir, para la combinación correcta, las animaciones eran esencialmente compensaciones de la T-pose. La mezcla se realizó en el lado del motor.

JL: Entonces, en Unreal, ¿todo hizo lo mismo?

KN: Probablemente sí. No creo que Tim haya agregado animación esquelética a la próxima versión.

Cabezas parlantes: ConvEdit y Lipsink

[Ahora abrimos la carpeta ConvEdit]


JL: Cuéntanos sobre ConvEdit

KN: Fue una creación de Al, lo escribió en Visual Basic.

JL: Como UnrealEd en ese momento.

Sí, en aquellos días no había muchas oportunidades para la implementación simple de la interfaz. Hubo Delphi y varios otros marcos de UI. Si no los usó, tuvo que escribirlo todo de forma nativa, por ejemplo, en la API de Win32, GDI y todo eso. Fue un gran problema.

Es decir, Visual Basic, que hoy parece bastante primitivo, en ese momento era muy bueno: un marco visual simple con su propio lenguaje de programación similar a Basic, el predecesor de C #. Nos permitió crear prototipos de funciones y escribir herramientas muy rápidamente.

[Nota: Si está interesado en cómo se usó Visual Basic en las herramientas de desarrollo de juegos de esa época, lea mi entrevista con Tim Sweeney sobre Unreal Editor ]

Fue utilizado principalmente por Sheldon. Necesitaba herramientas para controlar la cámara, herramientas para controlar los sonidos. Quería usar muchas herramientas cinematográficas que nadie había usado antes. Primero aprendí qué es el zoom de la tribuna, trabajando en este juego con Sheldon.

Creo que incluso hoy esta herramienta todavía se usa.

Por cierto, Sheldon tenía el síndrome de la muñeca del túnel (RSI, lesión por esfuerzo repetitivo), por lo que el sello se convirtió en una tortura para él. Trabajó casi por completo en Deus Ex usando la transcripción de voz en Dragon Dictate, que en ese momento era mucho peor que hoy. Sheldon incluso tuvo que usar ortesis, porque el síndrome era muy fuerte.




JL: ¡Guau! No lo sabia El juego tenía muchos diálogos y un montón de ramas ...

KN: Una gran cantidad de datos, incluso para una misión.

Sheldon quería tener un fuerte control sobre el juego y muchos diálogos interactivos. Quería que el jugador tomara una decisión significativa. Él y Warren odiaban tener que hacer clic en los diálogos sin una opción. Querían que el jugador interactuara con los personajes y eligiera cosas importantes, para que el juego dejara banderas y recordara cómo interactuó con los personajes y se comportó durante el pasaje.

JL: Desde el primer recorrido de Deus Ex, recuerdo la sesión informativa de Anna Navarre en su oficina. Como es habitual en cualquier videojuego, comencé a correr por la oficina haciendo todo tipo de tonterías hasta que los NPC terminaron su diálogo. De repente, ella detuvo su diálogo, se volvió hacia mí y me preguntó: "¿Qué demonios estás haciendo?"

KN: [risas]

DL: Por un segundo me congelé y me pregunté: "¿Es esto lo que realmente sucedió?" Fue un evento tan significativo para mí en términos de inmersión en el juego. Ni un solo juego antes de que este se haya conocido. Sospecho que esto se debe en parte al Editor de conversaciones.

KN: Uno de los preceptos de Warren era: "Si un jugador está en la oficina de alguien, se comporta como animales y rompe cosas, ¡entonces el personaje debe decir algo!" No debe ignorar al jugador, porque no es realista ".

JL: ¿Hubo algún aspecto relacionado con la escena para el cual resultó ser especialmente difícil crear herramientas?

KN: Tuvimos muchos diálogos, y todos fueron expresados. Pasamos semanas en un estudio de grabación grabando diálogos con actores. Esto significa que tenemos que pensar en sincronizar el movimiento de los labios (lipsyne). Pensé: "¿Cómo crear un lipSink para tantos diálogos?" Después de todo, no solo teníamos un montón de frases, sino también varios idiomas.

En ese momento, no había muchas herramientas para ayudar en el enlucido. La mayoría de los desarrolladores realizaron el preprocesamiento: ejecutaron el diálogo en la herramienta, mostraron un archivo de datos y luego lo reprodujeron. Pero decidí: "No tendremos tiempo para esto, y si tiene que volver a grabar la voz, tendrá que volver a procesar todo nuevamente".

Entonces comencé a pensar que debe haber alguna forma de hacer esto en tiempo real mediante el análisis dinámico de sonido. En la universidad, estudié ingeniería eléctrica y decidí resolverlo yo mismo, sin decírselo a nadie.

JL: [risas]

KN: Pensé: "A ver si puedo hacer esto y sorprender a todos". De nuevo, no creo que nadie haya hecho algo así antes, pero hoy esta técnica está en todas partes.

En ese momento, de todo lo que vi, el más cercano a ese sistema era Half-Life. Los desarrolladores utilizaron la técnica de seguimiento de envolvente, que literalmente era esta: abrir y cerrar la boca según el volumen del sonido. El sistema funcionó, pero no parecía muy realista.

JL: De hecho, fue una "contracción mandibular".

KN: Sí, exactamente, exactamente.

Recuerdo que una vez discutí con Gabe Newell cómo lograron esta tarea, y él dijo: “Oh, solo use el Envelope following , y eso será suficiente. Todo lo demás será demasiado complicado.

Luego regresé a casa y comencé a estimar cálculos matemáticos, y luego escribí un sistema que realizaba FFT ( transformación rápida de Fourier ). Repito, mientras que los cálculos de coma flotante eran muy caros, y probablemente escribí una aproximación entera simulándolos.

Analizó en tiempo real una pequeña grabación de audio y extrajo los principales componentes de frecuencia, y luego los ató a seis o siete fonemas diferentes.

Secretamente, le pedí a uno de los artistas que simulara varias formas de fusión (combinar formas): necesitaba "oh", "a", labios cerrados y cosas por el estilo. Me preguntó por qué, y le respondí que simplemente hizo esto y me dio los datos.



Transformada rápida de Fourier (imagen de Wikipedia) y Preston Blair Phonemes Series

JL: [risas] Esta parece ser la combinación perfecta para la combinación de animaciones que usaste en Deus Ex.

KN: Sí, exactamente, perfecto.

Entonces, él me dio los datos, escribí cálculos matemáticos y, como pude, adjunté los formularios manualmente. No hice ninguna investigación seria, y el sistema era bastante costoso en términos de rendimiento.

Creé un nivel de prueba con una cabeza enorme en el medio, y le di un par de líneas. Revisé la frase en alemán, en inglés, en francés, y todo se sincronizó perfectamente. Pensé: "Maldita sea, esto es increíble! ¡Realmente funcionó!

Encontré a Warren y le dije: "Quiero mostrarte algo genial". Parece que estaba aturdido. [Risas] Él me preguntó: "¿Qué demonios, podemos poner esto en el juego? ¡Es simplemente increíble!

Como resultado, lanzamos un juego con este sistema, pero por razones de rendimiento, tuve que reducirlo mucho, lo que redujo la calidad visual. Pero mi primer nivel de prueba fue genial. Todavía creo que este fue el primer sistema de sincronización de labios en tiempo real. No recuerdo que nadie haya hecho esto antes.

Quizás valió la pena patentarlo. Pero no creo en las patentes de software porque creo que es una práctica viciosa ...

También tuve una gran discusión con uno de los directores de arte en Dallas, que quería usar este sistema en Anacronox. Ella debería haber salido antes de nuestro juego. Le dije: "No me importará compartir, pero quiero que Deus Ex sea el primer juego en el que aparezca". Él dijo: "¡No, debes dárnoslo!" Prácticamente nos gritó en el pasillo. Respondí: "No, no debería", y Warren me apoyó. Dio la casualidad de que lanzamos el juego primero, por lo que esto no era importante de todos modos. De hecho, creo que como resultado, implementaron independientemente su propia versión del sistema, porque no queríamos regalarlo. Puede haber sido egoísta, pero quería que nos graduaramos primero para poder demostrar esta característica.

Todo lo demás producido por Ion Storm se desarrolló en Dallas: Dominion: Storm Over Gift 3 , Daikatana , Anacronox ; todo se hizo en Dallas. Solo Deus Ex fue creado en Austin, y solo estaba nuestro equipo, nadie más. Estábamos en una burbuja, bastante aislados de la oficina en Dallas, y esto se hizo a propósito. No queríamos meternos con un montón ... Seré sincero, con un montón de toda su basura. Esta separación fue completamente intencional y muy importante para nosotros. Nuestro equipo y sus equipos no intercambiaron tecnologías, ni contactos reales.

Conclusión

DL: Entonces, para resumir, quiero preguntar: si pudieras dar consejos a los desarrolladores de herramientas que leen este artículo, ¿qué dirías?

KN: Escucha a tu cliente. Nunca escriba herramientas en el vacío. Como ingeniero, puede pensar: "Puedo usar esta herramienta de esta manera, y este método es más efectivo, así que lo escribiré así".

Pero casi siempre te equivocas. Debe escuchar a los diseñadores y artistas porque su flujo de trabajo es muy diferente. Funcionan completamente diferentes al resto. La herramienta no será utilizada por usted, la mayoría de las veces es para ellos.

DL: ¿Alguna vez te has encontrado con esa mentalidad en los equipos con los que trabajaste? ¿Y cómo lidiaste con esto?

KN: Solo necesita decirles a los programadores: “¿Por qué creen que el usuario tiene este problema? ¿Crees que el problema está en el código? ¿O tal vez el problema es la estructura de la pantalla? ¿La fuente es demasiado pequeña? ¿Color de botón incorrecto? ¿Quizás estás haciendo algo no estándar?

Porque si observa la mayoría de las herramientas con un diseño profesional, generalmente son bastante consistentes. Hay guías de diseño sobre cómo deberían funcionar las cosas.

El equipo creativo debería poder usar estas herramientas. No debe ser que tengan que leer la documentación. En un mundo ideal, todo debería ser obvio.

Hoy en día hay diseñadores UX / UI, pero en ese momento no había ninguno, por lo que tuvimos que crear el diseño de la interfaz nosotros mismos, pero con los comentarios de los usuarios.

Por lo tanto, siéntese junto a los usuarios y vea cómo usan la herramienta. Vimos cómo funcionan en Lightwave. Cuando escribimos la primera versión de la herramienta, nos sentamos cerca, sin preguntar qué hacer, y los miramos, tomando notas, como "hubo dificultades con esto" o "constantemente tienen que subir al menú para encontrar eso", o "tal vez vale la pena convertirlo en una tecla de acceso rápido ". Solo míralos, aprende y adapta.

Es decir, realmente debería pensar en el flujo de trabajo de los diseñadores. Es necesario minimizar los movimientos innecesarios, minimizar el rastreo en el menú, intentar agregar teclas de acceso rápido. Promocionamos activamente los atajos de teclado para todas las funciones porque aceleran el flujo de trabajo. En el proceso de aprendizaje de la herramienta, acelera en gran medida el trabajo con la ayuda de teclas de acceso rápido, y no necesita subir al menú.

No es necesario caer en la trampa clásica para los ingenieros: “Lo sé mejor, escribí el instrumento, sé cómo funciona. Si no puedes usarlo, entonces eres un idiota ”. Esto es lo peor que puede ocurrir al desarrollar una herramienta.

JL: Excelente consejo. Muchas gracias Chris!