Quel a été le premier éditeur Unreal

Les rétrospectives des jeux classiques sont récemment devenues populaires, mais elles rappellent rarement les outils de développement classiques. J'ai réussi à parler avec Tim Sweeney de la première version d' Unreal Editor , ou UnrealEd .

BSP et erreurs: «Nous devons écrire notre propre éditeur»

David Lightbone: Merci d'avoir pris le temps de me parler, Tim! Commençons par les premiers jours d'Unreal Editor. J'ai lu que James Schmaltz, le créateur d' Epic Pinball , vous avait montré le jeu sur lequel il travaillait, et quand vous l'avez vu, j'ai suggéré de créer un éditeur pour celui-ci. Ça va?

Tim Sweeney: Exactement! Il s'est inspiré du jeu Bullfrog Magic Carpet . James est un développeur incroyablement talentueux, mais il n'a écrit que du code en langage assembleur, il ne voulait pas apprendre le C. [rires] Ainsi, il a écrit ce moteur 3D en assembleur pur qui rendait l'arrière-plan du relief et les objets du jeu. Il ne voulait pas créer un éditeur, il a donc fait manuellement un arbre BSP et placé une capsule sur ce relief. Quand j'ai vu ça, j'ai dit: "Non, non, non, James, James ... tu dois faire quelque chose de complètement différent." [rires]



Tapis magique James Schmalz et Bullfrog

J'ai dit que j'écrirais un éditeur, alors j'ai commencé à créer l'interface utilisateur Unreal Editor à partir de la mise en page de l'interface utilisateur dans Visual Basic, assez curieusement. Il avait une interface de commande textuelle pour communiquer avec un moteur C ++ rendu. Ensuite, j'ai écrit un éditeur filaire, et le développement s'est poursuivi sur cette base.

Autrement dit, ce fut un processus d'étude intéressant. J'ai pensé que j'écrirais cet éditeur et l'intégrerais dans le rendu de James. Une fois, je lui ai demandé: «Pouvez-vous m'envoyer le code? Je veux comprendre comment intégrer le moteur de rendu. " Et il m'a envoyé 30 000 lignes de code assembleur. [rires] Dans le moteur de rendu 3D, il y avait des éléments d'Epic Pinball et du code d'assembleur précédent, qu'il a simplement copié. J'ai pensé: «Mon Dieu, quel genre de chaos est-ce? Je ne veux pas y toucher! " [rires]

Mais je me suis dit qu'avant de commencer à comprendre, j'écrirais juste un petit outil de mappage de texture. J'ai donc lu l'article de Michael Abrash sur le mappage de texture et étudié le code que Billy Zelsnack partageait. La texturation s'est avérée être un sujet assez simple, alors j'ai décidé: "Je vais essayer de faire face à tout cela."

Avant d'implémenter l'éclairage et autres, une partie importante de la magie des versions antérieures d'Unreal Editor était la création d'une arborescence BSP en temps réel. L'idée était que vous pouviez changer la position des pinceaux dans l'espace 3D, après quoi tout le travail de génération de BSP était complètement mis à jour en temps réel.


Les opportunités offertes par cette fonction ne me convenaient pas, et juste pour montrer toute sa puissance, j'ai créé cet outil pour créer des tori. J'ai contacté James, qui, je m'en souviens, a construit ses BSP manuellement et je lui ai dit: "Vérifiez-le." J'ai créé deux tores connectés et les ai soustraits du monde. Il a dit: «Wow, ça ne peut pas être! C'est génial. " C'était un véritable exemple d'obstination des programmeurs.

JL: En parlant de BSP, si je comprends bien, John Carmack a été l'un des premiers à commencer à utiliser BSP dans les moteurs de jeu et l'idée de travailler avec BSP était assez nouvelle pour l'industrie du jeu de l'époque.

TS: Carmack a écrit un éditeur vraiment puissant sur NeXT . J'ai lu toutes les informations le concernant et j'ai vu des captures d'écran, mais je ne les ai jamais utilisées. A cette époque, je pensais: "Wow, Carmack a écrit un éditeur BSP en temps réel!" Ce que je n'ai pas compris, c'est qu'en fait cela ne fonctionnait pas en temps réel, il y avait un processus de pré-assemblage et d'autres opérations. Je ne le savais pas et pensais qu'il avait créé un éditeur qui fonctionnait complètement en temps réel, alors il a également écrit le même. [rires]



QuakeEd sur NeXT et John Carmack

JL: [rires] Vous pensiez qu'il était si puissant, alors vous avez accepté le défi.

TS: Oui! De nombreuses fonctionnalités d'Unreal sont apparues en raison de ma mauvaise compréhension de ce que les autres ont fait.

En outre, un groupe d'anciens fabricants de démos Future Crew a créé une société d'équipement et a publié des captures d'écran avec un éclairage surround incroyablement réaliste dans une scène d'intérieur. Il y avait des sources lumineuses avec de grandes sphères autour, et l'éclairage volumétrique était clairement coupé par toute la géométrie qui l'entourait. Il semblait physiquement parfaitement précis. J'ai pensé: "Dieu, je n'ai jamais rien vu de tel, j'ai besoin de comprendre ça!"

J'ai donc commencé à comprendre et à réaliser que je devais calculer l'intégrale linéaire de la caméra à chaque point de l'écran. Au collège, j'ai étudié la matanalyse, alors je me suis dit: "Je dois réussir." J'ai donc dérivé une formule pour cela avec une trigonométrie incroyablement compliquée. Je l'ai implémenté en code, mais c'était cent fois plus lent que nécessaire. Puis j'ai réalisé: «Arrête, je peux faire ces calculs dans l'espace de la carte lumineuse», car la carte lumineuse est une discrétisation de la géométrie en petits fragments. J'ai transféré les calculs sur des cartes d'éclairage et j'ai tout implémenté en temps réel.



Exemples d'éclairage d'Unreal basés sur des cartes d'éclairage

J'ai pris une capture d'écran et l'ai envoyée par la poste à un ami finlandais, qui travaillait pour cette société d'équipement. Il a répondu: «Wow, c'est incroyable! Mais notre image n'est qu'un rendu de 3D Studio Max, car nous ne pouvions pas comprendre comment le faire en temps réel. " [rires]

JL: [rires] Ouais!

[Note de l'auteur: la société dont parle Tim est les Bit Boys ]

TS: Autrement dit, l'Unreal Engine s'est avéré être le premier moteur d'éclairage volumétrique au monde, comme je pense ... et il était basé sur mon erreur.

Ce fut une période incroyable au début de l'histoire de l'industrie du jeu, car la 3D commençait tout juste à être possible. Plusieurs logiciels de rendu ont déjà été écrits, mais personne n'a pu résoudre des problèmes à grande échelle: comment faire fonctionner l'éclairage dans un grand monde, comment faire fonctionner la géométrie en temps réel dans un grand monde. Ce processus de développement a évolué à pas de géant: Carmack a mis en œuvre de nouvelles idées folles, j'ai réalisé de nouvelles idées folles et nous avons constamment publié des captures d'écran de ce dont nous sommes capables.

Si vous le regardez maintenant, en seulement quatre ans, nous avons recréé environ 20 ans de recherches sur les années 1980 et 1990, qui n'étaient auparavant possibles que par des calculs préliminaires et non en temps réel.

JL: Oui, comment l'idée de BSP était basée sur un article écrit en 1969.

TS: Exactement, avant ma naissance!

TurboPascal et Maya: inspiration irréelle

JL: Quelles sources d'inspiration avez-vous utilisées pour développer la philosophie de conception d'Unreal Editor?

TS: Il n'y avait que quelques sources d'inspiration.

Si vous regardez le jeu ZZT , sorti en 1991, vous verrez l'ensemble de base des fonctions d'Unreal Engine. En substance, c'est un moteur de jeu avec un jeu intégré. Le jeu a un petit langage de script qui, malgré sa simplicité, était un langage entièrement scripté qui vous permettait d'écrire de petits scripts de jeu.

[Note de l'auteur: les détails de ZZT se trouvent dans le livre d'Anna Anthropy publié par Boss Fight Books]

Le jeu avait un éditeur interactif WYSIWYG en temps réel pour créer des niveaux. En appuyant sur quelques touches, vous pouvez vous déplacer, ajouter des niveaux et les vérifier dans le jeu, puis les traiter. Un tel flux de travail interactif était une caractéristique clé du jeu.



ZZT, mode jeu et mode éditeur

Une autre inspiration était Turbo Pascal , qui était le premier outil de développement que j'aimais vraiment. C'était un éditeur très facile à utiliser pour créer du code et compiler. Vous venez de saisir le code, puis après quelques secondes il a déjà été compilé et vous l'avez exécuté. Le processus itératif de création de programmes était incroyable par rapport à ce à quoi j'étais habitué à l'époque. Si vous regardez l'implémentation ZZT, cela ressemble vraiment à une version texte du moteur Unreal. L'ensemble du modèle Unreal s'en est inspiré.

Il existe une autre source d'inspiration sérieuse qui a conduit à la création de nombreux éléments de conception du moteur: Visual Basic, similaire au clone Microsoft Delphi, c'est-à-dire une version d'Object Pascal pour Windows avec édition dans l'interface visuelle de Borland. Mais je n'ai jamais utilisé Delphi, je ne travaillais qu'en Visual Basic.

L'idée était que l'utilisateur dispose d'un éditeur de formulaire, il dessine des éléments de formulaire, des champs et tout ce qu'il contient, puis clique dessus et ouvre le code. Le code apparaît immédiatement et l'utilisateur continue simplement de le saisir et continue de travailler.



TurboPascal par Borland

J'ai transféré ces principes à Unreal: vous pouvez simplement faire glisser un objet vers un niveau, double-cliquer dessus pour ouvrir l'éditeur de script, puis saisir le script et l'enregistrer. Pour commencer à écrire du code, créer des objets tridimensionnels et tout faire en temps réel, il suffit de quelques clics de souris.

Un autre aspect important dans le développement d'Unreal a été qu'Epic a acheté plusieurs stations de travail Silicon Graphics qui ont lancé la première version de Maya. Maya était complètement obsolète à l'époque, mais il y avait un mode 3D interactif avec un espace de fond bleu-rouge-noir sur lequel des objets et des filaires étaient dessinés en temps réel. Cela ne pouvait être fait par aucun programme sur le PC; ils sont tous coincés dans le code hérité et les modèles d'interface utilisateur hérités.



Donc, la première chose que j'ai faite quand j'ai commencé à travailler sur l'éditeur Unreal était de créer un fond noir avec des lignes bleues et rouges en copiant Maya. J'ai écrit une procédure pour dessiner des lignes et créé des contours filaires tridimensionnels de tous les objets. C'est l'exemple qui m'a inspiré, qui a prouvé que c'était possible.

De Visual Basic à Slate: évolution de l'interface UnrealEd

[Note de l'auteur: au début de l'interview, j'ai lancé UnrealEd 1 dans une machine virtuelle sur mon ordinateur portable. J'ai donné à Tim une souris pour qu'il puisse y travailler.]

TS: Wow, super, vous l'avez déjà lancé!

JL: Oui! J'ai présenté que la version que nous voyons ici est Visual Basic.

TS: Oui, oui!

[Note de l'auteur: Tim était content quand il a créé le niveau à partir de zéro. De l'extérieur, cela ressemblait à une réunion d'amis qui n'avaient pas été vus depuis longtemps.

JL: Qu'est - ce qui vous a amené à utiliser Visual Basic pour développer l'interface de la première version d'UnrealEd, et quelles autres options aviez-vous?



Alan Cooper et Visual Basic

TS: C'était en 1995. À ce moment, les cadres d'interface utilisateur pour C ++ étaient tout simplement horribles. Il y avait Microsoft Foundation Classes, qui était le morceau d'API le plus misérable que vous puissiez imaginer. L'utilisateur a commencé à dessiner des contrôles de fenêtre et le framework a créé d'énormes quantités de code C ++ avec des tas de commentaires comme: "ici, nous créons un contrôle pour vous!" Si l'utilisateur déplaçait l'objet, le framework mettait à jour une partie du code, mais pas les autres parties, et il se cassait constamment, alors je me suis dit: "Je ne toucherai plus à ça."

Visual Basic était un outil formidable pour développer une interface utilisateur dans laquelle vous pouvez placer très efficacement tous les contrôles, éléments de menu et parties de l'interface utilisateur. C'était la boîte à outils la plus productive pour l'interface utilisateur que j'ai jamais vue, principalement parce que c'était un programme très clair et interconnecté: vous avez dessiné une interface utilisateur, cliqué dessus et ajouté un code simple pour son interaction. J'ai réalisé qu'il est beaucoup plus facile de créer une interface utilisateur, puis de la transmettre à C ++ via l'interface de ligne de commande, en envoyant du texte dans les deux sens, comme un moyen de sérialiser les données. Je pense que la situation n'a pas changé pendant une douzaine d'années, jusqu'à ce qu'au début des années 2000, des boîtes à outils d'interface utilisateur décentes pour C ++, telles que Qt et similaires, commencent à apparaître.

[Note de l'auteur: la première version de Visual Basic a été développée par Alan Cooper , souvent appelé le « père de Visual Basic ». Il est également une figure importante dans le domaine de la convivialité et de l'expérience utilisateur]



UnrealEd 3, dans lequel des éléments wxWidgets étaient présents

DL : Je pense qu'avec le temps, certaines parties de l'éditeur ont commencé à être remplacées par d'autres parties. Comment cette évolution s'est-elle produite?

TS: Après avoir terminé Unreal Editor 1, je me suis calmé et j'ai fait tout un tas de recherches de nouvelle génération qui n'ont généralement pas porté leurs fruits jusqu'à ce que Warren Marshall apparaisse, qui a réécrit des parties de Visual Basic dans Unreal Editor avec C ++ en utilisant wxWidgets . wxWidgets qui était à l'époque la meilleure boîte à outils. Cela est devenu la base du cadre d'interface utilisateur dans Unreal Editor 2.

Au milieu du processus de développement Unreal Engine 2, le code Visual Basic a complètement disparu du moteur. Nous avions un framework C ++ plus pratique et plus propre. Ainsi, nous avons obtenu presque la même interface utilisateur, mais sans difficultés de langue. Mais le vrai problème était que wxWidgets ne s'est pas développé et que d'autres boîtes à outils d'interface utilisateur sont sorties, nous avons donc continué à les intégrer pour des outils spéciaux. Par conséquent, au moment où le cycle de développement d'Unreal Engine 4 a commencé, nous avions cinq boîtes à outils d'interface utilisateur différentes ...

JL: Cela arrive souvent ...

TS: ... y compris des morceaux fous de WPF écrits en C # et intégrés dans Unreal Engine 4 qui ne fonctionnaient pas sur Mac, par exemple. Par conséquent, à ce moment de notre code, il y a eu un énorme chaos.

Parallèlement, Nick Atamas a créé un prototype de la nouvelle couche d'interface utilisateur en C ++ et au fil du temps, nous avons décidé de l'utiliser. Il s'est donc transformé en ardoise. Nous avons donc réécrit 100% de l'interface utilisateur d'Unreal Engine, nous avons supprimé toutes les boîtes à outils de l'interface utilisateur du plug-in et l'avons refaite dans le même style. Cela nous a permis d'augmenter l'échelle de l'éditeur et d'en arriver à ce que nous avons aujourd'hui.


Capture d'écran de UnrealEd avec Slate UI

Mais nous ne pouvions toujours pas atteindre la commodité qui existait à l'époque de Visual Basic. Même le cadre de l'interface utilisateur C # n'était qu'un énorme tas de XML et d'autres folies inutiles. Il semble que chaque nouvelle génération implémente l'interface utilisateur d'une manière de plus en plus sophistiquée et s'aggrave.

Captures d'écran et XCopy: l'importance des licences

DL: Quelles entreprises ont été les premières à utiliser Unreal Editor?

TS: Au début, deux ans avant la sortie, nous avions déjà deux acheteurs de licence: Unreal Engine a utilisé Microprose, puis Legend Entertainment l'a utilisé pour sa Wheel of Time, et nous leur avons fourni un soutien.



Legend Entertainment Wheel of Time

JL: Ils vous ont aidé aussi, non? La collaboration faisait partie de cette relation.

TS: Oui, leur paiement de licence a maintenu Epic à flot pendant le processus de développement d'Unreal.

À cette époque, je prenais la licence très au sérieux, car cela nous permettait de payer des factures, ce qui nous a conduit au modèle de licence du moteur, qui était complètement différent du modèle Id. À cette époque, il y avait une blague selon laquelle la licence du moteur d'Id revenait à acheter XCopy pour un quart de million de dollars: vous payez un quart de million, et ils entrent dans la commande DOS XCopy pour vous donner une copie de la source ... et c'est tout. [rires]

JL: [rires] D'accord, alors qu'est-ce qui a conduit à la vente de la licence Unreal Engine à Microprose et Legend Entertainment avant même la sortie d'Unreal 1?

TS: Je pense que cela s'est produit parce que nous en étions encore aux premiers stades, vers 1995, à publier des captures d'écran incroyables non seulement de notre jeu, mais aussi des captures d'écran de notre éditeur. Cela a amené l'entreprise à nous contacter. Ils nous ont appelés de Microprose et ont dit: "Nous voulons autoriser votre moteur!", Et nous sommes comme: "Moteur? Quel moteur? Ah, notre moteur! Cela vous coûtera très cher. » [rires] Voilà littéralement à quoi ressemblait la conversation.



L'une des toutes premières captures d'écran d'Unreal Editor et Unreal

Dinosaures et lézards: terminologie et iconographie UnrealEd

DL: En parlant de captures d'écran: en voici une publiée dans Blue's News à la fin des années 90. Il y a de légères différences notables par rapport à la version qui s'exécute sur ma machine virtuelle: par exemple, dans le coin supérieur gauche, il y a les boutons Lecture, Aide et Epic, qui ne sont pas dans la version finale.

Pouvez-vous nous en dire un peu plus?


Capture d'écran d'UnrealEd publiée sur Blues News en 1998

TS: Il s'agit définitivement d'Unreal Engine 1, vers 1998, car il a le code Steve Polge, qui à l'époque coordonnait le jeu multijoueur.

Le bouton "Epic" n'était qu'un lien vers une page Web, ce qui semblait ennuyeux pour tout le monde car ils cliquaient constamment et étaient ennuyés: "Ah, le navigateur s'ouvre à nouveau!" [rires]

JL: [rires] Eh bien, pouvez-vous parler un peu d'iconographie?

TS: Pour tous les éléments de l'interface utilisateur, j'ai dessiné des icônes absolument terribles, puis je les ai envoyées à Dan Cook, un artiste qui s'occupait des graphismes de notre premier jeu de tir Tyrian .

Il avait besoin de dessiner une icône pour l'élément Pion, alors il a créé une pièce d'échecs. J'ai dit: «Non, non, non», et il a répondu: «Eh bien, alors dites-moi ce qu'est un pion.» J'ai dit que c'était quelque chose comme un monstre, quelque chose de très cool, alors il a dessiné la tête d'une créature incompréhensible: ils ont dit que c'était un dinosaure, un lézard ou autre chose ... mais ces icônes sont restées avec nous pendant environ dix ans.



Daniel Cook et les icônes qu'il a créées pour UnrealEd. L'icône «Ajouter un pion» est en bas, troisième à droite.

DL: Nous avons déjà parlé du mot «pion». L'avons-nous inventé nous-mêmes ou l'avons-nous vu quelque part?

TS: Je pense qu'il a été proposé par Steve Polge ou James Schmalz.

JL: Et "acteur"?

TS: Carmack a créé sa propre terminologie, il a appelé les objets «entités», et j'ai pensé: «Non, nous avons besoin de quelque chose d'unique.»

JL: [rires]

TS: Nous avons décidé d'avoir des objets désignés comme acteurs, car dans les années 80, SmallTalk , dont j'étais amoureux à l'époque, proposait des principes de programmation basés sur le modèle de l'acteur . Le modèle était orienté objet et semblait être un bon début pour nous. Par conséquent, nous avons eu l'idée des pions et des instigateurs, qui déterminent le début d'une série d'événements et de toute autre terminologie.

Virus Schmalcism et Bood Voodoo: création d'UnrealScript

JL: Parlez-nous de la façon dont James et Steve ont contribué à l'utilisation et à la création d'UnrealScript.

TS: James Schmalz était un diamant unique, bricoleur. Il était le meilleur artiste de l'équipe, un concepteur de niveaux formidable, et il pouvait également programmer en UnrealScript et assembleur.

DL: Dans les crédits Unreal, son nom apparaît dans une paire de catégories complètement différentes.

TS: Dans toute l'industrie du jeu, il y a extrêmement peu de personnes de ce niveau et il mérite tout le succès obtenu.

Mais il est passé de l'assembleur à UnrealScript et a écrit du code UnrealScript fou, dans lequel il a simplement martelé les lignes pendant qu'elles continuaient à fonctionner, et le soir, je l'ai approché et j'ai simplifié son code. Il avait des expressions sur plusieurs lignes comme "quelque chose d'instigateur dot blah blah dot", et je les ai remplacées par quelque chose comme ... "self". [rires]

JL: [rires]

TS: Nous avons appelé ce code "Schmalcism". Et Polge avait des nombres magiques comme "vitesse de marche = vitesse de course x 3.072" dans son code. Je lui ai demandé: "Y a-t-il vraiment une constante 3.072 en physique que je ne connais pas?" [rires]



TS: UnrealScript a été inspiré par Java; à cette époque, ce langage semblait être le successeur de C ++. Les créateurs de la langue ont copié de nombreuses solutions constructives et, en plus, ont ajouté beaucoup de nouveaux concepts. En UnrealScript, les rudiments des conteneurs de base existaient et seulement quelques générations plus tard sont apparus en Java.

J'ai toujours pensé que lors du développement du langage C #, les auteurs ont suivi UnrealScript car j'ai vu certaines fonctionnalités d'UnrealScript qui ont fait surface en C #. J'ai toujours espéré qu'ils empruntaient certaines de ces idées.

Mais plus je m'enterrais dans la programmation orientée objet et dans SmallTalk, j'étudiais les recherches les plus avancées sur les métaclasses, plus je me rendais compte que c'était une sorte de virus vaudou cérébral qui n'avait aucune base théorique réelle. À son tour, si nous regardons la correspondance Haskell et Curry-Howard , ainsi que d'autres principes de programmation modernes, nous verrons la source et la structure de l'inspiration.

SoftDisk, Id et millions de dollars en chèques

JL: Jay Wilbur et Mark Rein, avec leur orientation commerciale et leur expérience avec le shareware, ont-ils influencé le moteur, les outils, l'éditeur ou les ressources qui leur ont été fournis?

TS: Au début, Epic a travaillé du fait que j'étais engagé dans le côté technique et Mark-in business. Mark a fait le tour du monde, a conclu des accords commerciaux fous qui nous ont rapporté de l'argent. C'était très important, sinon pour lui, nous n'aurions pas survécu à ces premiers stades.



Mark Rain et Jay Wilbur

À un moment donné, nous étions échoués et toutes nos dépenses étaient financées par la carte American Express de Mark, qui a été annulée en conséquence.

JL: [rires]

TS: Puis il s'est envolé pour une réunion avec TG Interactive et en est revenu avec un chèque d'un million de dollars. Cela nous a sauvés. Et cela a donc été répété plusieurs fois dans notre histoire. Il est très important d'avoir d'excellents hommes d'affaires capables de négocier. Il a été le premier président d'Id, et après que Mark Jay est devenu le premier PDG d'Id.

DL: Avant cela, lui et Carmack étaient à SoftDisk, non?

TS:Ok! Et c'est drôle, car en fait j'ai vendu mon premier jeu ZZT à SoftDisk. C'est Jay Wilbur qui a traité mon contrat avec SoftDisk. À la suite de ces négociations, j'ai reçu trois mille dollars de SoftDisk, donc je connaissais Jay depuis très longtemps.


Les débuts d'Id Software. Jay Wilbur à droite.

Travailler avec les gars d'Id m'a inspiré dès le début. Je suis allé à une conférence stupide de shareware et j'y suis apparu. Ils étaient les favoris de l'industrie à l'époque car ils ont sorti Wolfenstein 3D, qui a été le plus grand succès de l'histoire du shareware. Ils ont discuté avec nous, puis ont invité à dîner. C'était tellement génial de voir que les superstars de l'industrie n'étaient que des gars modestes. John Romero est le développeur de jeux le plus mignon du monde.

[Note de l'auteur: je suis d'accord. John Romero a passé beaucoup de temps sur notre interview TEd.]

WYSIWYG et facilité d'utilisation: le plus important - perspectives d'outils

DL: Donc, en novembre 1998, la version Maximum PC est apparue, dans laquelle il y avait une interview avec vous, où vous avez également parlé des différentes technologies qui existaient à l'époque. Cet article dit que "[Unreal Editor] est léger devant tout le monde en termes de simplicité" et "il est difficile de travailler avec la technologie Quake".

Il dit également: «La technologie [Quake III: Arena] est vraiment impressionnante» et «Prey et Trespasser ont l'air et fonctionnent mieux qu'Unreal. Mais s'il s'avère qu'il est plus difficile de travailler avec eux, les développeurs resteront avec Unreal. "

Autrement dit, aviez-vous un objectif dès le début de créer un outil dont l'avantage concurrentiel est la facilité d'utilisation?



Maximum PC, novembre 1998

TS: Oui, c'est vrai. Vous savez, cela a toujours été la chose la plus importante pour moi: écrire un éditeur qui permet aux level designers de créer des créations incroyables. Dès le début, il était clair que l'aspect le plus important de cela était le travail en temps réel et les itérations de conception ultrarapides, la mise en œuvre complète du principe «ce que vous voyez, vous obtenez» («ce que vous voyez est ce que vous obtenez», WYSIWYG) . Ensuite, vous ne serez limité que par votre imagination et votre capacité à trouver de nouvelles idées. Pour nous, Epic a toujours eu un outil très important.

JL: Quel processus Epic a-t-il utilisé pour apporter beaucoup d'attention, investir du temps et du travail dans la simplification de l'utilisation des outils?

TS:Le processus de développement dans Epic est une combinaison de l'équipe de développement du moteur, créant des systèmes, des fonctions et des outils, et l'équipe de jeu, consommant tout cela pour créer des jeux. Nous utilisons un processus itératif lorsque les équipes de développement de moteurs créent de nouvelles idées, puis les partageons avec les équipes de jeu et obtenons un retour constant sur ce qui fonctionne et ce qui ne fonctionne pas. C'est ainsi que notre processus technique a été créé: le fait que les développeurs d'outils étaient censés aider les développeurs de jeux leur a permis d'être honnête.

Nous voulions non seulement créer des outils faciles à utiliser, mais également nous assurer qu'ils fournissent les bons compromis qui vous permettent vraiment de créer le contenu nécessaire à la sortie du jeu.

C'est le revers de la médaille d'utilisation. Il est impossible de considérer la facilité d'utilisation comme un concept distinct. C'est mauvais lorsque les outils sont très faciles à utiliser, lorsque vous commencez à créer un jeu, mais il est très difficile pour eux de terminer la création du jeu, car ils limitent le flux de travail ou les fonctionnalités.


Si vous regardez les cinq ou six dernières années de développement des moteurs, la concurrence entre Epic et Unity est déterminée par la facilité d'utilisation initiale, dans laquelle Unity a un avantage. Dans le même temps, dans le cycle de développement de la sortie du jeu, en termes de performances sur différentes plateformes, Unreal a un avantage. C'est parce que nous nous concentrons sur la possibilité de sortir des jeux d'une échelle épique, c'est-à-dire ceux que nous faisons. En fait, c'est beaucoup plus compliqué que de simplifier le travail de trois personnes en libérant rapidement quelque chose de simple.

Aujourd'hui, la taille du code Unreal Engine est environ 20 plus grande que le code Unreal Engine 1. Les outils sont devenus dix fois plus compliqués, et il y a des raisons à cela. Les gens lancent Unreal et se perdent car il y a tellement d'options de menu. Ensuite, ils passent à Unity et voient que tout est mignon et simple. Et puis ils atteignent le stade où vous devez publier un produit, et il s'avère que vous devez acheter une licence pour le code source pour ajouter des fonctionnalités qui ne sont pas au menu du moteur. Il y a une telle dichotomie.

Source d'inspiration et de patrimoine: L'impact d'UnrealEd

JL: UnrealEd a inspiré certains développeurs de jeux, dont moi-même, non seulement à commencer à créer des jeux, mais aussi à écrire leurs propres outils. Que pensez-vous de l'impact d'UnrealEd sur l'industrie?

TS: Je pense que tous les éditeurs de jeux existants ont emprunté quelque chose à UnrealEd. Ce fut l'un des premiers éditeurs, nous avons pris de nombreuses décisions fondamentales correctes, par exemple, comment l'utilisateur devrait travailler avec des grilles 2D, placer des objets et se déplacer dans le monde. Je pense que vous pouvez suivre l'héritage transmis du premier éditeur Doom à l'éditeur Quake, puis à Unreal. Aujourd'hui, tout est dans une certaine mesure basé sur cela.


Diagramme historique des moteurs FPS de Wikipedia. Cliquez pour ouvrir une version plus grande.

Certains aspects ont été influencés par des principes généraux, par exemple Maya, mais certains sont tout particulièrement liés à Unreal - un moyen de structurer les hiérarchies de classes, de mettre en œuvre un système d'annulation et tous les autres problèmes graves du développement de jeux. Tous ceux qui sont entrés dans l'industrie au début des années 2000 sont généralement passés par Unreal ou Quake. Même si Quake était un jeu beaucoup plus grand, il me semble que la plupart des concepteurs sont passés par UnrealEd parce que ses outils étaient très pratiques.

Multiplication et division de la productivité: conseils aux développeurs de jeux

JL: En 2011, vous avez accordé une interview à Kotaku. Je vais lire quelques citations qui me semblent liées à notre sujet:

«Nous avons toujours abordé le développement de jeux en termes d'outils. Nous avons créé les outils dont nous avions besoin, créé un ensemble d'outils convivial et continué à travailler avec. »

«Chez Epic, nous pensons très loin. Nous sommes comme Intel. Nous réfléchissons à ce que nous ferons dans cinq à dix ans et choisirons les directions de développement appropriées, tandis que pour la plupart des entreprises, la limite de planification est la sortie du prochain jeu. Ils y ont mis toutes leurs ressources, puis font le prochain match. »

"Les grandes sociétés de jeux comme EA ou Activision n'investissent pas dans des outils, elles n'ont pas une planification à long terme comme nous, et nous sommes conscients que nous devons rendre les processus de développement de jeux aussi efficaces que possible."



Dans mon interview avec John Romero, il l'a très bien compris, en disant: "Les outils vivent plus longtemps que les jeux."

Quels conseils pouvez-vous donner aux développeurs de jeux pour qu'ils puissent éviter cette erreur et comprendre la valeur à long terme de l'investissement dans les outils?

TS: Eh bien ... vous n'avez pas à "sembler" créer un moteur. Soit vous construisez le moteur, soit vous ne le faites pas. Maintenant, de nombreuses entreprises paralysent leurs processus de production, créant des moteurs avec des outils inutiles. Ce sont les outils qui tuent les gens.

Regardez tous ces moteurs créés en interne par les entreprises ... Par exemple, Frostbite a des fonctions de rendu plus avancées que les nôtres, et dans de nombreux cas, il dessine des pixels plus beaux que les nôtres, mais les développeurs Unreal peuvent créer du contenu beaucoup plus productif, approximativement 30 à 50% plus productif. Autrement dit, une équipe peut créer un jeu de la même qualité par la moitié de la puissance. Il peut faire plus d'itérations et affiner le jeu mieux qu'avec des outils de moins bonne qualité. Par conséquent, tout le monde doit prendre une décision éclairée - soit investir complètement dans la création d'excellents outils à usage interne, soit utiliser des moteurs tiers.

DL: Parce que vous pensez que les développeurs souffrent de demi-mesures?

TS: Oui. Quelque part à l'intérieur de ces entreprises se trouvent des comptables incroyablement stupides, pensant comme ceci: "Oh, en limitant les dépenses de développement d'outils, nous pouvons économiser 2% du budget." En conséquence, cela entraîne une augmentation de 50% du budget, car beaucoup plus de temps et de travail doivent être investis dans la création du jeu. Par conséquent, cela crée une telle folie, ne justifiant pas des économies de coûts.

Je pense que chaque entreprise devrait prendre une décision - soit investir beaucoup plus dans les outils, soit ne pas les faire du tout.


Et cela s'applique à tout. Non seulement à un éditeur 3D pour créer des niveaux, mais aussi aux systèmes d'assemblage, à un langage de programmation, à la technologie de développement, aux outils DCC, à tout cela.

Les outils devraient augmenter la productivité et s'il s'avère qu'ils la réduisent, vous devez vous en débarrasser.

JL: Super. Merci d'avoir pris le temps de discuter avec moi.