¿Cuál fue el primer editor irreal?

Las retrospectivas de los juegos clásicos se han vuelto populares recientemente, pero rara vez recuerdan las herramientas de desarrollo clásicas. Logré hablar con Tim Sweeney sobre la primera versión de Unreal Editor , o UnrealEd .

BSP y falacias: "Necesitamos escribir nuestro propio editor"

David Lightbone: ¡ Gracias por tomarte el tiempo de hablar conmigo, Tim! Comencemos desde los primeros días de Unreal Editor. Leí que James Schmaltz, el creador de Epic Pinball , le mostró el juego en el que trabajó, y cuando lo vio, le sugerí crear un editor para él. ¿Eso está bien?

Tim Sweeney: ¡Exactamente! Se inspiró en el juego Bullfrog Magic Carpet . James es un desarrollador increíblemente talentoso, pero solo escribió código en lenguaje ensamblador, no quería aprender C. [risas] Por lo tanto, escribió este motor 3D en ensamblador puro que representaba el fondo en relieve y los objetos del juego. No quería crear un editor, por lo que hizo manualmente un árbol BSP y colocó una cápsula en este relieve. Cuando vi esto, dije: "No, no, no, James, James ... tienes que hacer algo completamente diferente". [risas]



James Schmalz y Bullfrog Magic Carpet

Dije que escribiría un editor, así que comencé a crear la interfaz de usuario de Unreal Editor a partir del diseño de la interfaz de usuario en Visual Basic, por extraño que parezca. Tenía una interfaz de comando basada en texto para comunicarse con un motor de C ++ que se procesaba. Luego escribí un editor de estructura alámbrica, y el desarrollo continuó sobre esta base.

Es decir, fue un proceso de estudio interesante. Pensé en escribir este editor e integrarlo en el renderizador de James. Una vez que le pregunté: "¿Puedes enviarme el código? Quiero entender cómo integrar el renderizador ". Y me envió 30 mil líneas de código ensamblador. [risas] En el motor de renderizado 3D, había algunos elementos de Epic Pinball y algún código de ensamblador anterior, que simplemente copió. Pensé: "Dios mío, ¿qué clase de caos es este? ¡No quiero tocar esto! " [risas]

Pero me dije a mí mismo que antes de comenzar a resolverlo, simplemente escribiría una pequeña herramienta de mapeo de texturas. Entonces leí el artículo de Michael Abrash sobre mapeo de texturas y estudié el código que compartió Billy Zelsnack. La textura resultó ser un tema bastante simple, así que decidí: "Trataré de hacer frente a todo esto".

Antes de implementar la iluminación y similares, una parte importante de la magia de las versiones anteriores de Unreal Editor fue la creación de un árbol BSP en tiempo real. La idea era que podía cambiar la posición de los pinceles en el espacio 3D, después de lo cual todo el trabajo para generar BSP se actualizó por completo en tiempo real.


Las oportunidades proporcionadas por esta función no cabían en mi cabeza, y solo para mostrar todo su poder, creé esta herramienta para crear tori. Me puse en contacto con James, quien, recuerdo, construyó sus BSP manualmente y le dije: "Compruébalo". Creé dos toros conectados y los resta del mundo. Él dijo: "¡Guau, eso no puede ser! Esto es asombroso ". Este fue un verdadero ejemplo de obstinación del programador.

JL: Hablando de BSP, según tengo entendido, John Carmack fue uno de los primeros en comenzar a usar BSP en motores de juegos y la idea de trabajar con BSP era bastante nueva en la industria de los videojuegos de la época.

TS: Carmack escribió un editor realmente poderoso en NeXT . Leí toda la información sobre él y vi capturas de pantalla, pero nunca la usé. En ese momento pensé: "¡Guau, Carmack escribió un editor BSP en tiempo real!" Lo que no entendí fue que, de hecho, no funcionó en tiempo real, hubo un proceso de premontaje y otras operaciones. No sabía esto y pensé que había creado un editor que funcionaba completamente en tiempo real, por lo que también escribió el mismo. [risas]



QuakeEd en NeXT y John Carmack

JL: [risas]. Pensaste que era tan poderoso, así que aceptaste el desafío.

TS: Si! Muchas características de Unreal han surgido debido a mi malentendido de lo que otras personas han hecho.

Además, un grupo de antiguos creadores de demo de Future Crew creó una compañía de equipos y lanzó algunas capturas de pantalla con una iluminación envolvente increíblemente realista en una escena interior. Había fuentes de luz con grandes esferas alrededor, y la iluminación volumétrica estaba claramente cortada por toda la geometría que la rodeaba. Parecía físicamente perfectamente preciso. Pensé: "Dios, nunca había visto algo así, ¡tengo que resolver esto!"

Entonces comencé a comprender y me di cuenta de que necesitaba calcular la integral lineal de la cámara a cada punto de la pantalla. En la universidad, estudié matanálisis, así que me dije: "Tengo que tener éxito". Así que obtuve una fórmula para esto con una trigonometría increíblemente complicada. Lo implementé en código, pero fue cien veces más lento de lo necesario. Entonces me di cuenta: "Detente, puedo hacer estos cálculos en el espacio del mapa de luz", porque el mapa de luz es una discretización de la geometría en pequeños fragmentos. Transferí los cálculos a mapas de iluminación e implementé todo en tiempo real.



Ejemplos de iluminación de Unreal basados ​​en mapas de iluminación

Tomé una captura de pantalla y se la envié a un amigo de Finlandia, que trabajaba para esa compañía de equipos. Él respondió: "¡Guau, esto es increíble! Pero nuestra imagen es solo un renderizado de 3D Studio Max, porque no pudimos entender cómo hacer esto en tiempo real ". [risas]

JL: [risas] ¡Sí!

[Nota del autor: la empresa de la que habla Tim son los Bit Boys ]

TS: Es decir, el Unreal Engine resultó ser el primer motor de iluminación volumétrica del mundo, según creo ... y se basó en mi falacia.

Fue un momento increíble en la historia temprana de la industria del juego porque el 3D apenas comenzaba a ser posible. Ya se habían escrito varios renderizadores de software, pero ninguno podía resolver problemas a gran escala: cómo hacer que la iluminación funcione en un mundo grande, cómo hacer que la geometría en tiempo real funcione en un mundo grande. Este proceso de desarrollo avanzó a pasos agigantados: Carmack implementó nuevas ideas locas, me di cuenta de nuevas ideas locas y constantemente lanzamos capturas de pantalla de lo que somos capaces.

Si lo miras ahora, en solo cuatro años, recreamos unos 20 años de investigación de las décadas de 1980 y 1990, que anteriormente solo eran posibles a través de cálculos preliminares, y no en tiempo real.

JL: Sí, cómo la idea de BSP se basó en un artículo escrito en 1969.

TS: ¡ Exactamente, antes de mi nacimiento!

TurboPascal y Maya: inspiración irreal

JL: ¿Qué fuentes de inspiración usaste para desarrollar la filosofía de diseño de Unreal Editor?

TS: Solo hubo algunas fuentes de inspiración.

Si observa el juego ZZT , lanzado en 1991, verá el conjunto básico de funciones de Unreal Engine. En esencia, es un motor de juego con un juego incorporado. El juego tiene un lenguaje de programación pequeño, que, a pesar de su simplicidad, era un lenguaje totalmente programado que le permitía escribir pequeñas secuencias de comandos del juego.

[Nota del autor: los detalles de ZZT se pueden encontrar en el libro Anna Anthropy publicado por Boss Fight Books]

El juego tenía un editor interactivo WYSIWYG en tiempo real para crear niveles. Al presionar algunas teclas, puede moverse, agregar niveles y verificarlos en el juego, y luego procesarlos. Tal flujo de trabajo interactivo fue una característica clave del juego.



ZZT, modo de juego y modo editor

Otra inspiración fue Turbo Pascal , que fue la primera herramienta de desarrollo que realmente me encantó. Fue un editor muy fácil de usar para crear código y compilar. Acaba de ingresar el código, luego de unos segundos ya se compiló y lo ejecutó. El proceso iterativo de creación de programas fue sorprendente en comparación con lo que estaba acostumbrado en ese momento. Si observa la implementación de ZZT, realmente parece una versión de texto de Unreal Engine. Todo el modelo de Unreal se inspiró en él.

Hay otra fuente seria de inspiración que condujo a la creación de muchos elementos de diseño del motor: Visual Basic, similar al clon de Microsoft Delphi, es decir, una versión de Object Pascal para Windows con edición en la interfaz visual de Borland. Pero nunca usé Delphi, solo trabajé en Visual Basic.

La idea era que el usuario tiene un editor de formularios, dibuja elementos de formulario, campos y todo eso, y luego hace clic en ellos y abre el código. El código aparece de inmediato y el usuario simplemente continúa ingresándolo y continúa trabajando.



TurboPascal por Borland

Transferí estos principios a Unreal: puedes arrastrar un objeto a un nivel, hacer doble clic en él para abrir el editor de guiones, luego ingresar el guión y guardarlo. Para comenzar a escribir código, crear objetos tridimensionales y hacer todo en tiempo real, basta con unos pocos clics del mouse.

Otro aspecto importante en el desarrollo de Unreal fue que Epic compró varias estaciones de trabajo de Silicon Graphics que lanzaron la primera versión de Maya. Maya estaba completamente desactualizada en ese momento, pero había un modo 3D interactivo con un espacio de fondo azul-rojo-negro en el que se dibujaban objetos y estructuras en tiempo real. Esto no podría ser realizado por ningún programa en la PC; todos están atascados en código heredado y patrones de IU heredados.



Entonces, lo primero que hice cuando comencé a trabajar en Unreal Editor fue crear un fondo negro con líneas azules y rojas copiando Maya. Escribí un procedimiento para dibujar líneas y creé contornos tridimensionales de todos los objetos. Ese fue el ejemplo que me inspiró, que demostró que era posible.

De Visual Basic a Slate: evolución de la interfaz UnrealEd

[Nota del autor: al comienzo de la entrevista, lancé UnrealEd 1 en una máquina virtual en mi computadora portátil. Le di un mouse a Tim para que pudiera trabajar en ella.]

TS: Wow, genial, ¡ya lo lanzaste!

JL: si! Les presenté que la versión que vemos aquí es Visual Basic.

TS: Si, si!

[Nota del autor: Tim estaba feliz cuando creó el nivel desde cero. Desde afuera, parecía una reunión de amigos que no habían sido vistos por mucho tiempo.

JL: ¿Qué lo llevó a usar Visual Basic para desarrollar la interfaz para la primera versión de UnrealEd, y qué otras opciones tenía?



Alan Cooper y Visual Basic

TS: Eso fue en 1995. En ese momento, los marcos de interfaz de usuario para C ++ eran simplemente horribles. Hubo Microsoft Foundation Classes, que era la parte más miserable de API que puedas imaginar. El usuario comenzó a dibujar controles de ventana y el marco creó enormes cantidades de código C ++ con montones de comentarios como: "¡aquí creamos un control para usted!" Si el usuario movió el objeto, el marco actualizó parte del código, pero no las otras partes, y se rompió constantemente, así que me dije a mí mismo: "Ya no tocaré esto".

Visual Basic era una herramienta excelente para desarrollar una interfaz de usuario en la que podía colocar de manera muy eficiente todos los controles, elementos de menú y partes de la interfaz de usuario. Fue el kit de herramientas más productivo para la interfaz de usuario que he visto, principalmente porque era un programa muy claro e interconectado: dibujó una interfaz de usuario, hizo clic en ella y agregó un código simple para su interacción. Me di cuenta de que es mucho más fácil crear una interfaz de usuario y luego pasarla a C ++ a través de la interfaz de línea de comandos, enviando texto de un lado a otro, como una forma de serializar datos. Creo que la situación no cambió durante aproximadamente una docena de años, hasta que a principios de la década de 2000 comenzaron a aparecer kits de herramientas de interfaz de usuario decentes para C ++, como Qt y similares.

[Nota del autor: La primera versión de Visual Basic fue desarrollada por Alan Cooper , a menudo referido como el " padre de Visual Basic ". También es una figura importante en el campo de la usabilidad y la experiencia del usuario.



UnrealEd 3, en el que los elementos wxWidgets estaban presentes

DL : Creo que con el tiempo, partes del editor comenzaron a ser reemplazadas por otras partes. ¿Cómo sucedió esta evolución?

TS: Después de completar Unreal Editor 1, me tranquilicé e hice un montón de investigaciones de nueva generación que generalmente no dieron frutos hasta que apareció Warren Marshall, quien reescribió partes de Visual Basic en Unreal Editor con C ++ usando wxWidgets . wxWidgets que en ese momento era el mejor kit de herramientas. Esto se convirtió en la base del marco de la interfaz de usuario en Unreal Editor 2.

A mediados del proceso de desarrollo de Unreal Engine 2, el código de Visual Basic desapareció por completo del motor. Teníamos un framework C ++ más conveniente y limpio. Por lo tanto, obtuvimos casi la misma interfaz de usuario, pero sin dificultades de idioma. Pero el verdadero problema era que wxWidgets no se desarrolló y aparecieron otros juegos de herramientas de interfaz de usuario, por lo que continuamos integrándolos para herramientas especiales. Por lo tanto, cuando comenzó el ciclo de desarrollo de Unreal Engine 4, teníamos cinco kits de herramientas de UI diferentes ...

JL: Esto sucede a menudo ...

TS: ... incluidas piezas locas de WPF escritas en C # e integradas en Unreal Engine 4 que no funcionaban en Mac, por ejemplo. Por lo tanto, en ese momento en nuestro código había un gran caos.

Al mismo tiempo, Nick Atamas creó un prototipo de la nueva capa de interfaz de usuario en C ++ y con el tiempo decidimos usarlo. Entonces se convirtió en una pizarra. Así que reescribimos el 100 por ciento de la interfaz de usuario de Unreal Engine, nos deshicimos de todos los kits de herramientas de la interfaz de usuario y los rehicimos con el mismo estilo. Esto nos permitió aumentar la escala del editor y llegar a lo que tenemos hoy.


Captura de pantalla de UnrealEd con Slate UI

Pero aún no pudimos lograr la conveniencia que existía en los días de Visual Basic. Incluso el marco de interfaz de usuario de C # era solo una enorme pila de XML y otra locura innecesaria. Parece que cada nueva generación implementa la interfaz de usuario de una manera cada vez más sofisticada y está empeorando.

Capturas de pantalla y XCopy: la importancia de las licencias

DL: ¿Qué compañías fueron las primeras en usar Unreal Editor?

TS: En las primeras etapas, dos años antes del lanzamiento, ya teníamos dos compradores de licencias: Unreal Engine usó Microprose, y luego Legend Entertainment lo usó para su Rueda del Tiempo, y les brindamos soporte.



Legend Entertainment Wheel of Time

JL: También te ayudaron, ¿verdad? La colaboración fue parte de esta relación.

TS: Sí, el pago de su licencia mantuvo a Epic a flote durante el proceso de desarrollo de Unreal.

En ese momento, tomé las licencias muy en serio, ya que nos permitía pagar las facturas, lo que nos llevó al modelo de licencia del motor, que era completamente diferente del modelo Id. En ese momento, había una broma diciendo que licenciar el motor de Id era como comprar XCopy por un cuarto de millón de dólares: pagas un cuarto de millón, e ingresan el comando DOS XCopy para darte una copia de la fuente ... y eso es todo. [risas]

JL: [risas] Muy bien, entonces, ¿qué llevó a la venta de la licencia de Unreal Engine a Microprose y Legend Entertainment incluso antes del lanzamiento de Unreal 1?

TS: Creo que sucedió porque todavía en las primeras etapas, alrededor de 1995, lanzamos capturas de pantalla increíbles no solo de nuestro juego, sino también de nuestro editor. Esto hizo que la empresa nos contactara. Nos llamaron desde Microprose y dijeron: "¡Queremos licenciar su motor!", Y pensamos: "¿Motor? Cual motor Ah, nuestro motor! Te costará caro. [risas] Eso es literalmente cómo era la conversación.



Una de las primeras capturas de pantalla de Unreal Editor y Unreal

Dinosaurios y Lagartos: Terminología e Iconografía UnrealEd

DL: Hablando de capturas de pantalla: aquí hay una de ellas publicada en Blue's News a fines de los 90. Hay ligeras diferencias notables con respecto a la versión que se ejecuta en mi máquina virtual: por ejemplo, en la esquina superior izquierda hay botones de reproducción, ayuda y épico, que no están en la versión final.

¿Puedes contar un poco al respecto?


Captura de pantalla de UnrealEd publicada en Blues News en 1998

TS: Este es definitivamente Unreal Engine 1, alrededor de 1998, porque tiene el código Steve Polge, que en ese momento coordinaba el juego multijugador.

El botón "Épico" era solo un enlace a una página web, lo que parecía molesto para todos porque hacían clic constantemente y estaban molestos: "¡Ah, el navegador se abre de nuevo!" [risas]

JL: [risas] Bueno, ¿puedes hablar un poco sobre iconografía?

TS: Para todos los elementos de la interfaz de usuario, dibujé íconos absolutamente terribles y luego se los envié a Dan Cook, un artista que se dedicaba a los gráficos para nuestro primer tirador Tyrian .

Necesitaba dibujar un ícono para el elemento Peón, por lo que creó una pieza de ajedrez. Le dije: "No, no, no", y él respondió: "Bueno, entonces dime qué es el peón". Dije que era algo así como un monstruo, algo muy genial, así que dibujó la cabeza de una criatura incomprensible: dijeron que era un dinosaurio, un lagarto u otra cosa ... pero estos íconos permanecieron con nosotros durante unos diez años.



Daniel Cook y los íconos que creó para UnrealEd. El icono "Agregar peón" está en la parte inferior, tercero a la derecha.

DL: Ya hemos hablado de la palabra "peón". ¿Lo inventamos nosotros mismos o lo vimos en alguna parte?

TS: Creo que fue propuesto por Steve Polge o James Schmalz.

JL: ¿Qué pasa con el "actor"?

TS: Carmack ideó su propia terminología, llamó a los objetos "entidades" y pensé: "No, necesitamos algo único".

JL: [risas]

TS: Decidimos que tendríamos objetos designados como actores, porque en la década de 1980, SmallTalk , del que estaba enamorado en ese momento, propuso principios de programación basados ​​en el modelo de actor . El modelo estaba orientado a objetos y nos pareció un buen comienzo. Por lo tanto, se nos ocurrió la idea de los peones e instigadores, que determinan el inicio de una serie de eventos y toda otra terminología.

Schmalcism and Brain Voodoo Virus: Creando UnrealScript

JL: Cuéntanos más sobre cómo James y Steve contribuyeron al uso y la creación de UnrealScript.

TS: James Schmalz fue un diamante único, manitas. Era el mejor artista del equipo, un excelente diseñador de niveles, y también podía programar en UnrealScript y ensamblador.

DL: En los créditos de Unreal, su nombre aparece en un par de categorías completamente diferentes.

TS: En toda la industria del juego hay muy pocas personas de este nivel de talento y él merece todo el éxito alcanzado.

Pero cambió de ensamblador a UnrealScript y escribió un código loco de UnrealScript, en el que simplemente martillaba en líneas mientras continuaban trabajando, y por las noches me acercaba a él y simplificaba su código. Tenía expresiones de varias líneas como "algo instigador dot blah blah dot", y las reemplacé por algo como ... "self". [risas]

DL: [risas]

TS:Llamamos a este código "Schmalcism". Y Polge tenía números mágicos como "velocidad de caminata = velocidad de carrera x 3.072" en su código. Le pregunté: "¿Existe realmente una constante 3.072 en física que no conozco?" [risas]



TS: UnrealScript se inspiró en Java; En ese momento, este lenguaje parecía ser el sucesor de C ++. Los creadores del lenguaje copiaron muchas soluciones constructivas, y además agregaron muchos conceptos nuevos. En UnrealScript, existían los rudimentos de los contenedores básicos que solo unas pocas generaciones después aparecieron en Java.

Siempre pensé que al desarrollar el lenguaje C #, los autores siguieron UnrealScript porque vi algunas características de UnrealScript que aparecieron en C #. Siempre esperé que tomaran prestadas algunas de estas ideas.

Pero cuanto más me enterré en la programación orientada a objetos y en SmallTalk, estudié la investigación más avanzada sobre metaclases, más me di cuenta de que era una especie de virus vudú cerebral que no tenía una base teórica real. A su vez, si miramos la correspondencia de Haskell y Curry-Howard , así como otros principios de programación modernos, veremos la fuente y la estructura para la inspiración.

SoftDisk, Id y millones de dólares en cheques

JL: ¿Jay Wilbur y Mark Rein, con su orientación comercial y experiencia con shareware, influyeron en el motor, las herramientas, el editor o los recursos que se les proporcionaron?

TS: En las primeras etapas, Epic trabajó debido al hecho de que yo estaba involucrado en el aspecto técnico, y Mark, en los negocios. Mark voló alrededor del mundo, hizo tratos comerciales locos que nos trajeron efectivo. Era muy importante, si no fuera por él, no habríamos sobrevivido en estas primeras etapas.



Mark Rain y Jay Wilbur

En algún momento estábamos encallados y todos nuestros gastos se financiaron con la tarjeta American Express de Mark, que se canceló como resultado.

JL: [risas]

TS: Luego voló a una reunión con TG Interactive y regresó de allí con un cheque por un millón de dólares. Nos salvó Y así se repitió varias veces en nuestra historia. Es muy importante tener excelentes hombres de negocios que puedan negociar. Fue el primer presidente de Id, y después de que Mark Jay se convirtió en el primer CEO de Id.

DL: Antes de eso, él y Carmack estaban en SoftDisk, ¿verdad?

TS:Derecho! Y esto es divertido, porque en realidad vendí mi primer juego ZZT a SoftDisk. Fue Jay Wilbur quien se ocupó de mi contrato con SoftDisk. Como resultado de estas negociaciones, recibí tres mil dólares de SoftDisk, por lo que conocí a Jay por mucho tiempo.


Los primeros días de Id Software. Jay Wilbur a la derecha.

Trabajar con los chicos de Id me inspiró desde el principio. Fui a una conferencia estúpida de shareware y apareció Id. Eran los favoritos de la industria en ese momento porque lanzaron Wolfenstein 3D, que fue el mayor éxito en la historia del shareware. Charlaron con nosotros y luego nos invitaron a cenar. Fue genial ver que las superestrellas de la industria eran solo hombres modestos. John Romero es el desarrollador de juegos más lindo del mundo.

[Nota del autor: estoy de acuerdo. John Romero pasó mucho tiempo en nuestra entrevista con TEd.]

WYSIWYG y facilidad de uso: lo más importante - perspectivas de la herramienta

DL: Entonces, en noviembre de 1998, apareció el lanzamiento de Maximum PC, en el que hubo una entrevista con usted, donde también habló sobre las diferentes tecnologías que existían en ese momento. Este artículo dice que "[Unreal Editor] está un poco por delante de todos en términos de simplicidad" y "es difícil trabajar con la tecnología Quake".

También dice: "La tecnología [Quake III: Arena] es realmente impresionante" y "Prey and Trespasser se ven y funcionan mejor que Unreal. Pero si resulta que es más difícil trabajar con ellos, entonces los desarrolladores se quedarán con Unreal ".

Es decir, ¿tenía un objetivo desde el principio para crear una herramienta cuya ventaja competitiva sea la facilidad de uso?



Máximo PC, noviembre de 1998

TS: Sí, eso es correcto. Sabes, esto siempre ha sido lo más importante para mí: escribir un editor que permita a los diseñadores de niveles crear creaciones increíbles. Desde el principio fue claro que el aspecto más importante de esto es el trabajo en tiempo real y las iteraciones de diseño ultrarrápidas, la implementación completa del principio "lo que ves, lo que obtienes" ("lo que ves es lo que obtienes", WYSIWYG) . Entonces estará limitado solo por su imaginación y su capacidad para proponer nuevas ideas. Para nosotros, Epic siempre ha tenido una herramienta muy importante.

JL: ¿Qué proceso usó Epic para brindar mucha atención, invirtiendo tiempo y trabajo en simplificar el uso de herramientas?

TS:El proceso de desarrollo en Epic es una combinación del equipo de desarrollo del motor, creando sistemas, funciones y herramientas, y el equipo del juego, consumiendo todo esto para crear juegos. Usamos un proceso iterativo cuando los equipos de desarrollo de motores crean nuevas ideas y luego las comparten con los equipos de juego y reciben comentarios constantes sobre lo que funciona y lo que no. Así es como se creó nuestro proceso técnico: el hecho de que los desarrolladores de herramientas debían ayudar a los desarrolladores de juegos les permitió ser honestos.

No solo queríamos crear herramientas fáciles de usar, sino también asegurarnos de que proporcionaran los compromisos correctos que realmente le permitan crear el contenido necesario para lanzar el juego.

Este es el otro lado de la facilidad de uso. Es imposible considerar la facilidad de uso como un concepto separado. Es malo cuando las herramientas son muy fáciles de usar, cuando comienzas a crear un juego, pero es muy difícil para ellos completar la creación del juego, ya que limitan el flujo de trabajo o la funcionalidad.


Si observa los últimos cinco o seis años del desarrollo de motores, la competencia entre Epic y Unity está determinada por la facilidad de uso inicial, en la que Unity tiene una ventaja. Al mismo tiempo, en el ciclo de desarrollo del lanzamiento del juego, en términos de rendimiento en diferentes plataformas, Unreal tiene una ventaja. Esto se debe a que estamos enfocados en poder lanzar juegos de una escala épica, es decir, los que hacemos. De hecho, esto es mucho más complicado que simplificar el trabajo de tres personas que lanzan rápidamente algo simple.

Hoy, el tamaño del código de Unreal Engine es aproximadamente 20 más grande que el código de Unreal Engine 1. Las herramientas se han vuelto diez veces más complicadas, y hay razones para esto. La gente inicia Unreal y se pierde porque hay muchas opciones de menú. Luego cambian a Unity y ven que todo es lindo y simple. Y luego llegan a la etapa en la que necesita lanzar un producto, y resulta que necesita comprar una licencia para el código fuente para agregar funciones que no están en el menú del motor. Existe tal dicotomía.

Fuente de inspiración y patrimonio: el impacto de UnrealEd

JL: UnrealEd inspiró a algunos desarrolladores de juegos, incluido yo mismo, a no solo comenzar a crear juegos, sino también a escribir sus propias herramientas. ¿Cuál cree que es el impacto de UnrealEd en la industria?

TS: Creo que todos los editores de juegos existentes han tomado prestado algo de UnrealEd. Este fue uno de los primeros editores, tomamos muchas decisiones fundamentales correctas, por ejemplo, cómo el usuario debe trabajar con cuadrículas 2D, colocando objetos y moviéndose por el mundo. Creo que puedes rastrear la herencia pasada del primer editor de Doom al editor de Quake y luego a Unreal. Hoy, todo se basa en cierta medida en esto.


Diagrama de historia de motores FPS de Wikipedia. Haga clic para abrir una versión más grande.

Algunos aspectos fueron influenciados por principios generales, por ejemplo, Maya, pero algunos están bastante específicamente relacionados con Unreal, una forma de estructurar jerarquías de clases, implementar un sistema de deshacer y todos los demás problemas serios del desarrollo del juego. Todos los que ingresaron a la industria a principios de la década de 2000 generalmente pasaron por Unreal o Quake. Aunque Quake era un juego mucho más grande, me parece que la mayoría de los diseñadores utilizaron UnrealEd porque sus herramientas eran muy convenientes.

Multiplicación y división de productividad: consejos para desarrolladores de juegos

JL: En 2011, le diste una entrevista a Kotaku. Leeré algunas citas que, me parece, se relacionan con nuestro tema:

“Siempre abordamos el desarrollo de juegos en términos de herramientas. Creamos las herramientas que necesitábamos, creamos un conjunto de herramientas fácil de usar y continuamos trabajando con ellas ”.

“Nosotros en Epic pensamos muy por delante. Somos como Intel Pensamos en lo que haremos en cinco a diez años y elegimos las direcciones apropiadas para el desarrollo, mientras que para la mayoría de las empresas el límite de planificación es el lanzamiento del próximo juego. Ponen todos sus recursos en él y luego hacen el próximo juego ”.

"Las grandes compañías de juegos como EA o Activision no invierten en herramientas, no tienen una planificación a largo plazo como la nuestra, y nuestra conciencia de que necesitamos hacer que los procesos de desarrollo de juegos sean lo más eficientes posible".



En mi entrevista con John Romero, lo entendió muy bien y dijo: "Las herramientas viven más que los juegos".

¿Qué consejo puede dar a los desarrolladores de juegos para que puedan evitar este error y comprender el valor a largo plazo de invertir en herramientas?

TS: Bueno ... no tienes que "parecer" crear un motor. Construye el motor o no lo hagas. Ahora, muchas compañías paralizan sus procesos de producción, creando motores con herramientas inútiles. Son las herramientas las que matan a las personas.

Mire todos estos motores creados internamente por las empresas ... Por ejemplo, Frostbite tiene funciones de renderizado más avanzadas que las nuestras, y en muchos casos dibuja píxeles más hermosos que los nuestros, pero los desarrolladores de Unreal pueden crear contenido mucho más productivo, aproximadamente 30-50 por ciento más productivo. Es decir, un equipo puede crear un juego de la misma calidad con la mitad del poder. Puede hacer más iteraciones y perfeccionar el juego mejor que con herramientas de menor calidad. Por lo tanto, todos deben tomar una decisión informada, ya sea invertir completamente en la creación de excelentes herramientas para uso interno o utilizar motores de terceros.

DL: ¿ Porque crees que los desarrolladores sufren de medias tintas?

TS: Sí En algún lugar dentro de estas compañías hay contadores increíblemente estúpidos, que piensan así: "Oh, al limitar el gasto en el desarrollo de herramientas, podemos ahorrar el dos por ciento del presupuesto". Como resultado, esto lleva a un aumento del 50 por ciento en el presupuesto, porque se necesita invertir mucho más tiempo y trabajo en la creación del juego. Por lo tanto, crea una locura que no justifica el ahorro de costos.

Creo que todas las empresas deberían tomar una decisión: invertir mucho más en herramientas o no hacerlas en absoluto.


Y eso se aplica a todo. No solo a un editor 3D para crear niveles, sino también a sistemas de ensamblaje, a un lenguaje de programación, tecnología de desarrollo, herramientas DCC, a todo esto.

Las herramientas deberían aumentar la productividad, y si resulta que la reducen, entonces debe deshacerse de ellas.

JL: genial. Gracias por tomarte el tiempo de chatear conmigo.